Address Verification Service (AVS) is designed for businesses who process credit card sales where the customer (and hence the credit card) is not physically present when making a purchase. This includes sales via the internet (i.e. iNet e-Store), as well as mail order and telephone order (also known as MOTO) sales. Internet and mail/telephone orders have a much higher risk of a chargeback due to fraud. A chargeback is a disputed credit card transaction, and unless you the merchant has a signed credit card receipt you will, almost always, bear the loss when faced with a possible chargeback. Use AVS to help minimize fraud on card-not-present transactions.
AVS asks you to enter additional customer address and card information during the credit authorization process, and passes that information to the processor. An AVS response code is returned by the processor, allowing the clerk to proceed or not proceed with the transaction accordingly. AVS validates that the customer is the legitimate and authorized card holder by verifying the billing address against the card information. A response code to the AVS request indicates if the AVS data is an exact match, a partial match, or not a match at all. AVS transactions request an AVS response code and a Card Verification (CV) response code. The CV code (the three or four-digit number printed on the back or front of the card) further ensures that the consumer actually has the credit card in their possession, because the CV code is not included in the embossed account number or in the magnetic stripe data.
If the authorization request is approved, it is up to you, the merchant, to evaluate the AVS and CV response codes and decide whether or not to proceed with the transaction. It is important to note that using AVS for a transaction does not provide protection for a chargeback; rather, it is a tool for assessing the risk of fraud, giving you a greater level of confidence when deciding whether or not to complete a card-not-present transaction.
The topics in the Address Verification book cover two types of AVS: Retail AVS and MOTO AVS.
Retail AVS is available to all Eagle for Windows users with ProtoBase, and is helpful when a customer is in the store purchasing goods, but their bank card cannot be scanned. The clerk is required to enter zip code information before the transaction can proceed, and can optionally enter the CV code. This additional information is sent to the processor along with the transaction data; however, the zip and CV code are NOT verified with Retail AVS. The benefit of Retail AVS is a reduction in processing fees for non-scanned transactions.
MOTO AVS is a purchase option for ProtoBase users who process mail, telephone, and/or Internet orders. With MOTO AVS, you start by running a test transaction for 1.00 when the customer places their order. This routine lets you know if the card is good, while protecting you from creating an erroneous hold for the amount of the transaction against the customer’s open to buy, specifically in cases where you decide to decline the transaction based on the AVS or CV response, even though the transaction was approved by the processor. You want to avoid such erroneous holds because holds can take many days to be removed from the consumer’s open to buy. Additionally, it is against Visa rules to bill a customer for products and services prior to shipment.
When you test a card and it comes back approved and the AVS and CV responses are acceptable, it is likely the card will be good when you actually bill the cardholder. If the AVS/CV responses cause you to not accept the card, or if a clerk simply mistyped address information on a legitimate card, testing the card only ties up $1.00 of the customer's available credit (for about a 7 to 10-day time frame). Later, when you invoice the customer's order, the final credit approval request sends the transaction's AVS and CV information to the processor for the purpose of ensuring the best discount rate available on the transaction. The system does not validate the AVS and CV responses at this point, because it is assumed that the "test card" process already validated those responses.