The Green Sheet Online Edition

September 10, 2012 • Issue 12:09:01

Opening gateways to AVS

By Chandan Mukherjee
PayCube Inc.

While Address Verification Service (AVS) has been available for most networks and processors for a long time now, there are still significant pitfalls to integrating AVS into a payment gateway. As a result, many implementers have ignored AVS. But a carefully implemented AVS can reduce transaction fraud to a great extent.

AVS varies from network to network and between processors. There are also variations in AVS in the United States as opposed to international AVS. This article addresses basics that a gateway provider must be familiar with to implement a robust AVS.

Keep in mind that this is a general discussion; it is strongly urged that developers reference processor specifications.

Furthermore, please note there may be differences in processor support for AVS. Hence, if a gateway supports multiple processors, it is conceivable the AVS must be tailored to each processor.

Address verification basics

Conceptually, AVS validates that the individual holding a payment card and conducting a transaction - in either a card-not-present environment, such as online, or in a brick-and-mortar location - is indeed the person issued the card. It is assumed that if someone stole a card or card number, it is unlikely the thief would know the actual billing address tied to the cardholder's stolen card.

So, the billing address, or part of the billing address information, is sent along with the card authorization request for the network and the card issuer to validate. If the billing address information matches the billing address on file for the card, then a match is returned. Otherwise error codes are returned.

Address verification options

Fundamentally, three kinds of address verification services are available:

• Postal Code Only: Postal code verification is about validating the postal code in the billing address of the cardholder. In the United States, the postal code generally means the five digit ZIP, but there are implementations that use 5+4 ZIP formats.

  In some markets where the postal code contains alphanumeric characters, some issuers and networks implement matching for numeric components only. In such cases, the alphanumeric characteristics are removed before matching is done. This may result in matching of fewer than five digits, depending on the postal code format.

• Street Address Matching (in compressed form): This type of address verification is more advanced than postal code matching. It takes into account the actual street address as stated in the billing address field. But the matching is not done based on the full street address.

  The matching is done for the first five numeric digits before the first alphanumeric character is encountered in the address, going from left to right. Though it is a better matching option than Postal Code Only, the compressed form of Street Address Matching does not take into account the street name, etc., especially for street names that are character-based. (Please see comments in best practices below).

• Street Address Matching (in expanded form): This is the best available form of AVS. It involves an attempt to match a minimum of 20 characters (and up to a predefined maximum) of the street address - numeric and text included.

  The first 20 characters, read from left to right, are taken into account for matching of the address. Address lines that are fewer than 20 characters are padded with spaces on the right.

  Address lines that are longer than the maximum character length are truncated at the maximum character amount. (Generally the maximum is 40 characters, but refer to processor specs for exact numbers.)

Best practices

Here are high-level best practices for implementing AVS at the gateway's application protocol interface or card entry web page.

• Some card networks match the cardholder name, too. If that is supported by the processor, the cardholder name is added to the billing address.

• There is no need to restrict what card applicants provide when they fill in personal information on application forms. All special characters are generally ignored during matching anyway.

• Convert all spelled-out numeric values to actual numbers. (for example, convert "Nine My Street" to "9 My Street" or "21 First street" to "21 1st Street").

• Even with street address matching, the postal code is matched, too. So the postal code must be entered.

• Ensure that the user is aware that what is required is the billing address, not the shipping address or service address, etc.

• If the gateway tokenizes cardholder data and stores it, provisions must be made so that the billing address is stored along with tokenized data. If the gateway supports storing of multiple card information for the same customer, multiple card billing addresses must also be stored.

• Make sure to program for error codes that are returned. If the street address and the postal code both match, success is returned. Otherwise, error codes may be any of the following types:
  • Either street address and/or postal code did not match
  • AVS not supported for the card type
  • AVS not supported by the card issuer
  • "Street-level" AVS is not available, only postal code is matched
  • AVS system is not available or is offline
• Program for "auth-cancellation" if the AVS does not return success. In most cases, the issuing banks do not decline the authorization due to AVS failure. This results in funds (available balance) being withheld as part of the authorization. If you do not wish to use this authorization, submit an auth-cancellation promptly.

A fraud deterrent

Given the amount of fraud associated with credit and debit cards, it is imperative that AVS be implemented by all reputable gateway operators. While the implementation of AVS can be time consuming, it can be successfully implemented if basic rules are followed. The benefits of implementing AVS are huge and go a long way toward reducing fraud.

Chandan Mukherjee is the co-founder of PayCube Inc., a San Francisco Bay Area-based payment consulting and IT services company providing custom software solutions and custom gateways for acquirers, ISOs, retailers and varied organizations in the world of payments and consumer transactions, including prepaid and gift card program, loyalty and promotion, payment start-up, POS solution, mobile payment and e-commerce players. PayCube uses a blend of on-site and offshore delivery capabilities, with a staff of retail and payments-focused software engineers, systems architects, project managers, tech leads and systems analysts. For more information, email cm@paycubeinc.com, call 510-545-6854 or visit www.paycubeinc.com.

The Green Sheet Inc. is now a proud affiliate of Bankcard Life, a premier community that provides industry-leading training and resources for payment professionals. Click here for more information.

Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.