Archive for the 'Processing Methods' 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 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

For merchants who use Authorize.Net to process their online orders if you accept orders from Canada and the UK you may be losing sales due to a flaw in how Authorize.Net handles Address Verification (AVS). (Read the blog entry The AVS Game to learn more about AVS). Apparently if the card issuing bank for a Canadian or UK credit card supports AVS Authorize.Net will treat the response as an “AVS MISMATCH”. This will cause the transaction to be declined.

The proper way to handle this would be to either fully support AVS and honor the merchant’s settings for handling AVS responses. If they can’t do that, in the meantime they should be marking the transactions as either “AVS NOT AVAILABLE” or “AVS ERROR” so the transaction can continue normally.

Unfortunately Authorize.Net’s response to this has been less then acceptable so far. Their proposed “solutions” are turning off AVS completely (e.g. turn off an important piece of fraud detection) or just accept that orders from Canada and the UK are going to be declined (e.g. accept that you are going to lose business). Naturally if this was business being affected I’d be very unhappy with that response.

So what do you do? Call Authorize.Net and let them know that your business is important to you and thus it should be important to them. There is no reason for this bug to remain unfixed and no excuse for them to expect merchants to expose themselves to fraud or lose sales just because Authorize.Net does not consider this a priority.

Technorati Tags: Authorize.Net, payment gateway, AVS

Authorize.Net announced today that they will add a CAPTCHA security image to its Simple Integration Method (SIM) remotely hosted payment form. This security image is designed to verify the party submitting the form is human and not an automated bot. You can see a demo of the new CAPTCHA on the Authorize.Net website. This option may be turned on and off through the control panel.

In addition to the CAPTCHA security image the SIM method will now also allow merchants to put the URL to their return and privacy policy on their payment page, itemize the order information, as well as preview their order page. All of these new features will go into effect on Thursday, June 7th.

Technorati Tags: Authorize.Net, payment gateway, CAPTCHA, SIM, simple integration method

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