Integrate the Authorize.Net Recurring Billing API with PHP
Establish subscriptions and recurring payments for your website
Author: Jim Conners
Rating: 10.0
Conclusion
As in our article Integrate the Authorize.Net Payment Gateway with PHP we make a very focused attempt to abstract the Authorize.Net ARB API into a class that is reusable and easy to use. Combined with the AIM API it allows for subscription based transactions to be integrated seamlessly and easily. Hopefully you can envision uses for this to allow your business to earn recurring revenue with minimal intervention on your part.
Some Good Advice
It might seem like it is unnecessary to verify a credit card is legitimate before establishing a recurring billing subscription. It might even be tempting to skip processing a regular transaction altogether and instead schedule a recurring billing subscription to occur immediately to process the initial payment for your user. This is a bad idea.
Why? Because if your user used a bad credit card (e.g. a card that will be declined) you will not know until the recurring billing transaction is run and the transaction is declined. Unfortunately this will be after you have granted access to your content to your user as recurring transactions are not run immediately by Authorize.Net. All recurring billing transactions, even those set to run the same day, are not run until approximately at midnight Pacific Time. This means it is not run immediately but later in the day.
The safest, and smartest, way to handle all recurring billing transactions is to process the initial transaction through the AIM API (in the case of delayed billing subscriptions using it to do an AUTH_ONLY transaction). Not only is this the purpose of the AIM API (and not that of the ARB API) but it gives you an immediate response from which you can base your decisions on. Plus by verifying the credit card immediately if there is a problem with the credit card the user is still available for you to notify and seek an alternative form of payment. If you wait until the first recurring billing transaction fails to determine if a credit card is bad not only do you have to manually notify the user of the error you have to hope you can get a hold of them and wait for them to address the issue.
Managing Recurring Subscriptions
Managing recurring billing subscriptions goes much further then simply verifying you have a legitimate credit card and establishing the subscription through the ARB API. How do you deal with cancellations? What do you do when a user wishes to change their credit card associate with their subscription? Fortunately the ARB API includes functionality to delete and edit recurring billing subscriptions.
However, to manage your existing subscriptions you will need to keep track of your subscriptions yourself. How you specifically handle the information necessary to manage your recurring billing subscriptions depends on your application. But you will need to keep track of a few key pieces of information to successfully manage existing accounts. Actually, only one piece of information is required and the rest just makes your application more robust. The key piece of information you will need is the subscription ID for each recurring billing subscription you establish as it is how you will identify which subscription you are modifying through the ARB API. The additional information you should store are the last four digits of the credit card associated with the subscription and the expiration date for that credit card. These pieces of information will help you, and your user, know which card is currently associated with their recurring billing subscription.
Be careful what information you store
You will notice that it is recommended that you store only the last four digits of the user's credit card number. This is because of the security ramifications of storing a complete credit card number. There are security regulations in place from the major credit card companies that must be followed and they are not cheap or easy to implement. However, you can avoid PCI-compliance issues by not storing the full credit card number. Since there is no need to store the entire credit card number you should not be taking the unnecessary risks associated with storing it . Despite the lower risk associated with storing only a partial credit card number it is still recommended that you encrypt it and the expiration date to ensure that your user's information is treated with the highest level of security available.
With this information your application can present the user who will be making the changes with their current information and offer them the opportunity to make changes. Once changes are made you can use the ARB API to send those changes to Authorize.Net to ensure your subscriptions are current.
Setting Up Annual Subscriptions
Annual subscriptions are very similar to monthly subscriptions except you will wait one full year before charging your user again. However, handling annual subscriptions does require a little bit of special attention as it is not as straight forward as it may seem.
The ARB API does not have a concept of 'years'. It only understands 'days' and 'months'. This means if you wish to establish an annual subscription you must tell Authorize.Net to charge the card again in 12 months and not one year.
Here's the code necessary to establish an annual subscription:
$arb->setParameter('startDate', date("Y-m-d", strtotime("+ 1 year")));
$arb->setParameter('interval_length', 12);
$arb->setParameter('totalOccurrences', 9999);
You will notice that the start date is set to one year from now. Then next recurring billing date is set for 12 months from now.
Source Code
Would you like a nice clean copy of the class created in this article? You can download a copy of the PHP 5 source code here: Authorize.Net ARB PHP 5. You can get a copty of the PHP4 version here: Authorize.Net ARB PHP 4.
Looking for a more polished version of this script that is ready to go out of the box? You can download a copy of it here: Authorize.Net ARB Integration Script (PHP 5) | Authorize.Net ARB Integration Script (PHP 4) (Sorry, no documentation for it yet).
Discuss This Article
Want to discuss this article? Have questions about the content? Be sure to use our merchant account forums.
Delayed Payment | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
Rate This Article