Archive for the 'Programmers Toolbox' 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 problem in ecommerce is fraudulent orders from overseas customers. The risk is so high in fact that some merchant account providers will not allow their merchants to accept orders from foreign countries. Even if they did, and you wished to solicit foreign orders, some regions pose such a high risk for fraud that accepting any order from that region would be just bad business.

So how do you reduce your risk of fraud from there regions? The easiest way to mitigate your risk is to block users from these regions from reaching your site. The Apache webserver offer the ability to block these regions as a group from your website. To do this create a file called .htaccess and place it in the root directory of your website (or your store if you only want to block that part). Place this code inside of it:


<Limit GET POST>
order allow,deny
allow from all
deny from 195
deny from 218
deny from 219
deny from 220
deny from 201
deny from 221
deny from 222
deny from 202
deny from 80
deny from 223
deny from 211
deny from 60
deny from 210
deny from 57
deny from 58
deny from 59
deny from 60
deny from 77
deny from 78
deny from 79
deny from 80
deny from 81
</Limit>


That’s it! This should block users from high risk parts of the world from accessing your site. Keep in mind they can still use an open proxy to make their IP address appear to be different and this doesn’t mean that the users now able to visit your site is honest. You still need to scrub your orders for fraud. But this should reduce the opportunity for fraudulent users in high risk areas to attempt to commit fraud on your website.