Monthly Archives: February 2012

4 Non-Obvious Tips When Developing with Credit Card Gateways

I’ve been working with credit card payment gateways as a web developer since 1997, when I built an e-commerce website for a small computer store. It’s a complex industry with myriad fees intentionally obscured behind various jargon. I’ve picked up on some of it along the way, but didn’t really start to get a solid grasp until I became a merchant account reseller myself. After reading a lot of the “behind the scenes” documentation not normally given to merchants, I’ve learned a few dirty secrets that other web developers ought to be aware of…

Include a customer, receipt, or invoice ID with every sale.

This field is normally optional with most payment gateways. However, excluding it can automatically knock the transaction into a higher risk category. This will add a 0.5 – 1.0% surcharge to the credit card sale.

Don’t rely on the gateway to catch bad expiration dates, invalid card numbers, or ZIP codes.

Most developers and merchants know that a credit card transaction costs a flat fee (generally about $0.20 – 0.30), plus a percentage of the sale (again, generally 2.3 – 2.9% for low-volume Internet merchants). However, one thing that is not frequently mentioned when opening an account is that $0.20 – 0.30 fee is charged for every call to the gateway’s API that generates a result code–sale, credit, refund, authorization, decline, etc. This includes submitting expired cards or those with invalid account numbers.

The solution is to make sure you’re properly validating the payment information on your forms. A credit card number can be checked for simple typos (such as transposed or missing digits) by running it through the Luhn algorithm. ZIP codes can be validated against a database or using a web-based API.

AVS should be set to match on both street address and ZIP code.

Address Verification System (AVS) is used to match on the billing address of a card to help reduce fraud. Many gateways allow the merchant to set how strictly an address must match to pass AVS before an authorization is approved: no matching elements, match only on ZIP code, or match on ZIP code and street address. However, if you are accepting cards that don’t match on both ZIP code and street address, the transaction is bumped to a higher risk tier. And, as with omitting an order number, the merchant will pay 0.5 – 1.0% more for that sale.

Splitting a sale across multiple transactions can get your merchant account revoked.

I’ve occasionally seen merchants split a large purchase across two or more transactions (mainly phone orders after the transaction was first declined online). This is generally done because the cardholder has a per-transaction limit on their account because they’re using a debit card or corporate/government purchase card. Don’t do it. The merchant’s bank can easily detect this pattern and will know something shady is up. Note that this is different than using two different cards for the same transaction (known as “split tender”), which is perfectly ok to do.

Share