Archive for the 'Programmers Toolbox' Category

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.

As we saw in our previous posts Building a Recurring Billing System and Building a Recurring Billing System Part 2: Storing Information, and Building a Recurring Billing System Part 3: Updating the Credit Card we can combine the Authorize.Net ARB API to build a powerful subscription system. In part three we discussed how we would update a customer’s credit card through our own interface. In this part we will create a need to use the functionality discussed in our last post.

The Authorize.Net ARB system allows for us to establish subscriptions that will not expire for up to three years. However, it is possible a customer’s credit card will expire before their subscription is complete. Unfortunately Authorize.Net will not inform us of this until after the credit card has been declined. So our system will need to track expiring credit cards for us.

Fortunately this is easy to do and can be completely automated to boot. In part two we discussed what information we wanted to store. One piece of information we decided to store was the expiration date of the customer’s credit card. This was done specifically so we could keep track of expiring credit cards. How we use it is very straight forward. We will write a cron job that looks for credit cards that within the next 30 days. If we find any we will send those customers an email letting them about the impending expiration of their credit card and invite them to use the page we created in part three to update their credit card information. This is nice because it is all automated!

Sample code this might look like this:


$link = mysql_connect('mysql_host', 'mysql_user', 'mysql_password')
or die('Could not connect: ' . mysql_error());

mysql_select_db(’my_database’) or die(’Could not select database’);

$query = ‘SELECT * FROM my_table’;

$result = mysql_query($query) or die(’Query failed: ‘ . mysql_error());

while ($row = mysql_fetch_array($result, MYSQL_ASSOC))
{
$to = $row[’email_address’];
$subject = “Update your subscription!”;
$body = “Time to update your subscription.
Go to http://www.domain.com/update.php.”;
mail($to, $subject, $body);
}

mysql_free_result($result);

mysql_close($link);


So far we have created a way for customers to update their subscription and an automated tool to inform them of the expiration of their credit card that invites them to use this tool. Next we will have to deal with the three year limit of the Authorize.Net ARB system.

Technorati Tags: Authorize.Net, payment gateway, recurring billing

As we saw in our previous posts Building a Recurring Billing System and Building a Recurring Billing System Part 2: Storing Information we can combine the Authorize.Net ARB API to build a powerful subscription system. In part two we discussed what information we needed to store to make our system work effectively. Now we will begin to use that information to drive our system.

One issue our system will need to address is the need to change the credit card used in a customer’s subscription. Credit cards expire, are closed, reach their limit or find other reasons where they can not be used either temporarily or permanently. In these cases the customer will want to update the credit card used in the their subscription so it doesn’t go into default.

The concept of how this is pretty straight forward and is a good place for us to start our system. If you remember from part one of Building a Recurring Billing System the Authorize.Net ARB API does offer the ability to change the credit card associated with a subscription. So all we need to do is tell Authorize.Net what subscription to change and what information to replace it with.

So what do we need from our system to make this happen? We will need a web page that will do the following:

• Display the current information associated with the subscription
• Offer the customer an opportunity to provide a new credit card
• Validate the new credit card
• Change the information in the ARB system
• Update our database to reflect this new information

This really is pretty straight forward:

• The customer’s information is easily retrieved from our database
• A basic form will capture the new credit card information
• The code we used when we originally validated the credit card can be used again here
• The ARB system provides a specific API for changing this information so we don’t need to come up with a strategy to complete this task like we will for other tasks our system will offer

Now that we have a system in place for changing a customer’s credit card information, we can expand our system to put this to good use.

Technorati Tags: Authorize.Net, payment gateway, recurring billing

As we saw in our previous post Building a Recurring Billing System, we will need to be responsible for providing a system to effectively manage our customers’ recurring subscriptions. Authorize.Net can take care of the payment processing for us as well as the scheduling of each payment. But to take our level of management and customer service to a higher level we will need to build a system to effectively manage it for us.

To effectively manage this system we will need to store some information pertinent to our transactions. Fortunately we do not need to store sensitive information but it would still be good to point out that being PCI compliant couldn’t hurt.

So what kind of information do we need to store? To determine that we need to know what information Authorize.Net is storing to do our recurring transactions. Any complete recurring billing subscription will store the customer’s credit card information (number and expiration date) and customer’s billing information (name, address, city, state, and zip code). Storing the credit card information is obviously required if the credit card is to be charged again at any point in the future. The billing information is required so Address Verification (AVS) can be done on each transaction (this is only necessary to keep your rates to a minimum. After the first transaction AVS serves no real purpose). Most subscriptions will also contain the customer’s ID number for the website so you can associate the subscription with their record in your system.

The customer billing information can be stored in its entirety as this is not considered sensitive information and you will find no objections from your customers. In fact the odds are your application will require this information anyway. As far as storing the credit card information we do not need to store much. We do not want nor need to store the credit card number. Once it is in the Authorize.Net ARB system we have no use for it. But we will find storing the last four digits handy if we plan to inform our customers of which card they are currently using. Storing the expiration date will be necessary if we plan to inform our customers of their impending expiration and invite them to change it before it does expire.

Do we need to store anything else? Yes. Since the ARB system only allows for subscriptions to be set for a maximum duration of three years, we will need to keep track of how long a customer’s subscription is so as they approach their three year anniversary we can handle the updating of their subscription for another three years. Also, when we initially establish a subscription we will be provided with a subscription ID. We will need to store that if we wish to edit or delete that subscription at a later date.

To summarize, we need to store:

• Last four digits of the customer credit card number
• Expiration date
• Billing address
• Customer ID
• Subscription ID

With this information we have the foundation from which we can build our own subscription system. Now we can begin to offer functionality to our system that will enhance our customer’s user experience and make our job of managing these subscriptions easier.

Technorati Tags: Authorize.Net, payment gateway, recurring billing, PCI DSS CISP