Archive for the 'Processing Methods' Category

One common complaint about the Authorize.Net Automated Recurring Billing (ARB) system is that there is no way to handle subscriptions that are declined when processing a future scheduled payment. As it turns out there is a way to handle this failures programmatically and automate your response to them.

Authorize.Net has a little known, and poorly documented feature called Silent Post URL. This is a URL that you specify where the results of all transactions are posted. This is in addition to the response given via their API.

The results of all transactions, including those processed using the Advanced Integration Method, are posted to this URL. This means you will be responsible for determining which are real-time transactions and which are using the ARB API. How you can do this is quite simple. When an ARB transaction’s results are posted two extra fields are included:

x_subscription_id - This is the ARB subscription ID of the transaction processed. You should probably already have this stored in a database somewhere.

x_subscription_paynum - This is the number of the occurrence of the subscription that failed. If this was the fifth recurring transaction for that subscription the value of this field would be ‘5′.

You can look for the presence of either of these two fields to indicate the transaction is an ARB transaction and act accordingly.

Here is some sample PHP code for handling a response posted to the Silent Post URL:


// Flag if this is an ARB transaction. Set to false by default.
$arb = false;

// Store the posted values in an associative array
$fields = array();

foreach ($_REQUEST as $name => $value)
{
// Create our associative array
$fields[$name] = $value;


// If we see a special field flag this as an ARB transaction
if ($name == ‘x_subscription_id’)
{
$arb = true;
}
}

// If it is an ARB transaction, do something with it
if ($arb == true && $fields[’x_response_code’] != 1)
{
// Suspend the user’s account
…

// Email the user and ask them to update their credit card information
…

// Email you so you are aware of the failure
…
}


To set the Silent Post URL simply login into your Authorize.Net control panel and click on your Settings links. It will be one of the options on that page. Simply add the URL you want them to post the responses to and submit it. It will take effect immediately.

So, if you have read our article Integrate the Authorize.Net Recurring Billing API with PHP and wanted to find a way to handle recurring billing failures in an automated fashion, then this solution should be music to your ears.

We are happy to announce a new article has been published today. Integrate the Authorize.Net Recurring Billing API with PHP is a follow up to our article Integrate the Authorize.net Payment Gateway with PHP. This new article expands upon our original article by explaining how the Authorize.Net recurring billing API works and walks developers through the process of:

1. Writing a class in PHP that simplifies the Authorize.Net API so it is easier for us to work with
2. Using that class to establish a recurring billing subscription
3. Understanding what we need to do to successfully establish a subscription logically

As with our previous articles sample code is included.

So check out Integrate the Authorize.Net Recurring Billing API with PHP and let us know what you think in our Merchant Account Forums.

Recently Authorize.Net released their API for their new Customer Information Manager (CIM) feature of their payment gateway. This feature is a boon for merchants who wish to store credit card information or do recurring billing in different amounts or varied schedules.

The main features of this new service are:

• PCI Compliance

  Remove the specter of PCI compliance from your ecommerce website by letting Authorize.Net handle the storing of sensitive information for you. Because your customers’ information reside on the Authorize.Net servers you do not have to worry about encrypting and protecting sensitive data. Not only do not have to worry about PCI compliance but your website is no longer an inviting target for hackers who want to steal this information from you.

• Process Irregularly Priced Recurring Billing Charges

  The Authorize.Net Automated Recurring Billing System is great for businesses that charge a fixed amount each billing period. But it does not work if you have a varying amount to charge during each billing period. CIM allows your website to handle the varying billing amounts and CIM will handle the storage of the billing information and processing of the recurring transaction. Now your recurring payments can be completely automated.

• Process Irregularly Scheduled Recurring Billing Charges

  Do you need to charge your customers on a recurring basis but the schedule is not consistent? With CIM you can store the credit card and billing information with Authorize.Net and only need to handle the actual scheduling of the payments. This allows you to automate the entire process reducing your costs and time spent processing payments.

• Create A “One Click” Checkout

  Creating a quick and easy checkout system is an important feature of any successful ecommerce website. Allowing your customers to store their data so they do not have to enter it again the next time they make a purchase can make shopping at your online store more appealing then your competitors’. With CIM you can provide this functionality for your customers and increase customer satisfaction and loyalty.

Naturally we created our own class to access their CIM API. This API, as well as the potential functionality of this service is complex, but here are a couple of examples to get you started in using this new service.

Here’s how to create a new CIM account:


try
{
require_once("AuthnetCIM.class.php");

$cim = new AuthnetCIM();
$cim->setParameter(’company’, ‘Fake Cpmpany’);
$cim->setParameter(’cardNumber’, ‘4111111111111111′);
$cim->setParameter(’expirationDate’, ‘2008-12′);
$cim->setParameter(’firstName’, ‘Joseph’);
$cim->setParameter(’lastName’, ‘Faker’);
$cim->setParameter(’address’, ‘100 Main Street’);
$cim->setParameter(’city’, ‘Townville’);
$cim->setParameter(’state’, ‘NY’);
$cim->setParameter(’zip’, ‘12345′);
$cim->setParameter(’country’, ‘US’);
$cim->setParameter(’phoneNumber’, ‘111-111-1111′);
$cim->setParameter(’faxNumber’, ‘222-222-2222′);
$cim->setParameter(’shipFirstName’, ‘Joseph’);
$cim->setParameter(’shipLastName’, ‘Faker’);
$cim->setParameter(’shipCompany’, ‘Fake Cpmpany.’);
$cim->setParameter(’shipAddress’, ‘100 Main Street’);
$cim->setParameter(’shipCity’, ‘Townville’);
$cim->setParameter(’shipState’, ‘NY’);
$cim->setParameter(’shipZip’, ‘12345′);
$cim->setParameter(’shipCountry’, ‘US’);
$cim->setParameter(’shipPhoneNumber’, ‘333-333-3333′);
$cim->setParameter(’shipFaxNumber’, ‘444-444-4444′);
$cim->setParameter(’description’, ‘Monthly Membership and stuff again’ . time());
$cim->setParameter(’merchantCustomerId’, ‘user04′);

$cim->CreateCustomerProfile();
$profile_id = $cim->getProfileID();
}
catch (AuthnetCIMException $e)
{
$debug = $e->getTrace();
die(”Exception occurred: ” . $e->getMessage() . “. File: ” .
$debug[0][’file’] . ” on line ” . $debug[0][’line’]);
}


Here’s how to add a new profile to that new account:


$cim->setParameter('customerProfileId', $profile_id);
$cim->setParameter('firstName', 'Joseph');
$cim->setParameter('lastName', 'Faker');
$cim->setParameter('address', '100 Main Street');
$cim->setParameter('city', 'Townville');
$cim->setParameter('state', 'NY');
$cim->setParameter('zip', '12345');
$cim->setParameter('country', 'US');
$cim->setParameter('phoneNumber', '111-111-1111');
$cim->setParameter('faxNumber', '222-222-2222');
$cim->setParameter('cardNumber', '4111111111111111');
$cim->setParameter('expirationDate', '2009-12');

$cim->createCustomerPaymentProfile();
$payment_profile_id = $cim->getPaymentProfileId();


Here’s how to add a shipping address to that account:


$cim->setParameter('customerProfileId', $profile_id);
$cim->setParameter('firstName', 'Joseph');
$cim->setParameter('lastName', 'Faker');
$cim->setParameter('address', '101 Main Street');
$cim->setParameter('city', 'Townville');
$cim->setParameter('state', 'NY');
$cim->setParameter('zip', '12345');
$cim->setParameter('country', 'US');
$cim->setParameter('phoneNumber', '111-111-1111');
$cim->setParameter('faxNumber', '222-222-2222');

$cim->createCustomerShippingAddress();
$address_id = $cim->getCustomerAddressId();


Here’s how to process a transaction with that new account:


$cim->setParameter('amount', '1.00');
$cim->setParameter('shipAmount', '1.00');
$cim->setParameter('shipName', 'UPS');
$cim->setParameter('shipDescription', 'UPS Ground');
$cim->setParameter('customerProfileId', $profile_id);
$cim->setParameter('customerPaymentProfileId', $profile_id);
$cim->setParameter('customerShippingAddressId', $address_id);
$cim->setParameter('cardCode', '123');
$cim->setLineItem('12', 'test item', 'it lets you test stuff', '1', '1.00');

$cim->createCustomerProfileTransaction();
echo ‘approval code: ‘ . $cim->getAuthCode();


Hopefully this is enough to get you started in accessing the Authorize.Net Customer Information Manager API. You can be sure an article will follow that will go into further detail about using this feature and API.

They offer two distinct APIs for using this new service. One uses their new XML API and the other uses SOAP. You can download the XML PDF or SOAP PDF of their integration guide from your control panel. You can find an example of PHP code using the SOAP API in their developer section of their website. So far there is no code for the XML API.

You can download a beta version of our Authorize.Net Customer Information Manager Class here. It is written in PHP 5 but can easily be converted to PHP 4 (but why would you want to?). This class has not been tested in a production environment yet so it may be buggy. If you find a bug please report it here so we can update it accordingly.

One this that bothered me about the Authorize.Net ARB subscription functionality is that there was a three year limit on subscriptions. In other words, all subscriptions would expire at most three years and you could not set it to be longer. This was true whether you used their ARB API or set the subscription up manually. The only way to accommodate longer subscriptions was to change the subscription length somewhere down the road after a portion of the subscription has transpired. If you had a large number of subscriptions you would need to create some sort of automated system to use the ARB API to update your subscriptions as they came close to expiring or else you risk losing revenue from those subscriptions.

Fortunately Authorize.Net actually listened to their users and removed this restriction. Now open ended subscriptions can be created both manually and through the ARB API. To do this through the API simply set the ‘totalOccurrences’ parameter to be ‘9999′. This applies to all subscription lengths.

Here is the email sent out by Authorize.Net:

At Authorize.Net, we do our best to listen and act on the feedback we receive from our merchants. As a result, we are pleased to announce that we have removed the three year restriction for all Automated Recurring Billing (ARB) subscriptions. You can now create subscriptions with an End Date that occurs more than three years after the Start Date, or with no set End Date at all. Once created, the payment gateway will submit payments for each ongoing subscription until you either cancel or modify the subscription to specify an End Date. Ongoing subscriptions can be created manually in the Merchant Interface by selecting No End Date under the Subscription Duration, or by entering “9999″ in the Ends After field. To turn an existing subscription into an ongoing subscription, you can update the subscription information using the same process. For more information, please see the Merchant Interface Online Help Files, available by clicking Help at the top of any Merchant Interface page. You can also create and update your subscriptions automatically using an Application Programming Interface (API). For more information, please see the ARB API Developer Guide.

Here is a link to the updated guide: Authorize.Net ARB Implementation Guide

A common question in communities around the Web is, “what exactly is a payment gateway”? According to Wikipedia:

A payment gateway is an e-commerce application service provider service that authorizes payments for e-businesses, online retailers, bricks and clicks, or traditional brick and mortar. It is the equivalent of a physical POS (Point-of-sale) terminal located in most retail outlets. Payment gateways encrypt sensitive information, such as credit card numbers, to ensure that information passes securely between the customer and the merchant.

So what exactly does this mean? Here’s an explanation in human terms:

A payment gateway basically is a credit card terminal for your website. It serves the same purpose but is not tangible like a credit card terminal. It’s job is to take the transactions from your website and send it to the processing bank to seek an approval, or decline, and return it to your website so you can complete the transaction (or ask for another form of payment). But, instead of having a human being entering the transaction into a credit card terminal and then reacting to the response (approved or declined), your website is sending over the information on your behalf and reacting to the results based on your website’s programming.

Now that we have a simple explanation of what a payment gateway is, let’s look at what they are not. There are a lot of misconceptions about what payment gateways are and can do. Here’s a couple of things payment gateways in general do not do:

1. Manage orders

   Order management, keeping track of your user’s items being purchased, is the responsibility of your shopping cart. The shopping cart adds up the total amount of the purchase and that is the information it passes on to the payment gateway along with the customer’s personal information.

2. Validate data

   Although the payment gateway will make sure you don’t send it bad information so it is unable to process the transaction (e.g. make sure the credit card is numeric and the right amount of digits, you provide an expiration date, etc.), they won’t make sure that the information you have sent is valid. For example, if someone types in 12345 as their zip code, the payment gateway won’t catch that it is a fake zip code. Same as if someone used 1234123412341234 as their credit card number. Basic data validation is up to your website’s programming to catch and react to.

Here’s a couple things that a payment gateway is not:

1. A merchant account

   As mentioned above, a payment gateway connects to a merchant’s website or POS system to the merchant’s merchant account so it can process credit card transactions. Thus, a payment gateway in and of itself is not a merchant account. It cannot process transactions without a merchant account being linked to it. A payment gateway without a merchant account is even less useful then a credit card terminal without a merchant account. At least a credit card terminal can be used as a paper weight!

2. A third party processor

   Payment gateways are commonly confused with third party processors (see What exactly is a Third Party Processor?) as on the surface the two seem to be very similar. While it is true that third party processors do include a form of payment gateway in their services they are very different things. The service third party processors offer is a sharing of their merchant account. To effectively do this they must have you process everything through their system and as a result offer payment gateway-like functionality to facilitate the process. But these aren’t true payment gateways as they only work with that third party processor and is limited entirely to the services they offer.

After reading that, you may think that payment gateways aren’t all that special. Well, you’d be half right. They are far less complicated then most believe them to be. They are specialized applications and they do their job well. But many payment gateway providers do offer additional services to add value to their products. Some additional tools commonly offered include:

1. Fraud screening

   With Internet sales making up the overwhelming majority of credit card fraud, screening sales for fraud is a high priority for every online merchant. Most gateway providers provide tools to utilize basic fraud tools such as AVS and CVV by reporting the results of these systems or even allowing transactions to be declined automatically that fail either test.

2. Payment history

   Each transaction that is processed through a payment gateway is captured and stored in a merchant’s account for later reference. This makes keeping track of online payments automatic (and hopefully redundant).

3. Recurring billing

   A common feature of subscription based websites is the ability to charge customers on a regular scheduled basis. Some POS software includes recurring payment functionality and many payment gateways offer this feature as well. By doing so they take the burden of PCI Compliance off of the merchant. The merchant does not need to worry about storing credit card information and the security that is required to do so.

All-in-all a payment gateway’s purpose is small in scope but they are still powerful and essential tools for online processing. If they still seem daunting to you, just remember they are just virtual credit card terminals and act almost in the very same way. They connect your website to your merchant account so you can get paid from credit card sales. Simple yet powerful.

Technorati Tags: payment gateway, recurring billing, merchant account, fraud screening, avs, cvv, POS systems, PCI compliance