Archive for the 'Payment Gateways' Category

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

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