Address Verification Service (AVS)

The Address Verification Service (AVS) is a credit card fraud prevention system developed to assist merchants by verifying the address of American customers. By submitting the credit card billing address and the corresponding ZIP code with the authorization request, payment processing systems which use AVS can compare existing records with the order. If the billing address and the ZIP code in the card issuer's records matches the billing address and the ZIP code submitted, a degree of certainty is created for the merchant that the person using the card for the order is who they claim to be. Ideally, this reduces the number of customer disputes and charge backs for the merchant, especially since it could prove difficult to reacquire shipped merchandise.

Note that not all financial institutions use AVS.

AVS compares the billing address and the ZIP code submitted with an authorization request with the card issuer's address records. An AVS result code is returned to indicate if the submitted data matches the stored data. For example:

0

Both street address and ZIP code match

1

Street address matches, but ZIP code does not

2

ZIP code matches, but street address does not

3

Neither street address nor ZIP code match

4

AVS result not available

The Payment rules engine has three types of responses to AVS codes: Pass, Reject, and AttentionRequired. Action is taken after a successful Approve or ApproveAndDeposit transaction is returned. A payment plug-in is responsible for mapping AVS scores specific to its payment back-end system to the AVS codes predefined by WebSphere Commerce. The AVS acceptable codes are 0 to 4.

The following table describes what the Payment rules engine does when a successful Approve or ApproveAndDeposit transaction is returned:

Transaction	Pass	Reject	AttentionRequired
Approve	Continues normally	Reverses the approval and marks the result as failed.	Sets the AttentionRequired flag to true in the result and creates a tickler. The transaction proceeds but the order is blocked.
ApproveAndDeposit	Continues normally	Marks the result as failed. Since the deposit cannot be reversed, a tickler is generated.	Sets the AttentionRequired flag to true in the result and creates a tickler. The transaction proceeds but the order is blocked.

For example, if during an ApproveAndDeposit action, the AVS code returned by a plug-in is mapped to a Rejection response, the Payment rules engine marks the result of the overall as failed and creates a tickler because the deposit cannot be reversed.

The mapping of AVS scores 0 to 4 to responses Pass, Reject, and AttentionRequired is done using an AVS configuration XML file provided in the configuration for each payment method.

If we are configuring payment processing or writing a payment plug-in, you do not have to modify the AVS configuration XML file. If we are writing a plug-in, ensure that you map the protocol-specific AVS codes into WebSphere Commerce AVS codes 0 to 4. For more information, refer to the API information for the setAvsCode method in the Payment interface described in com.ibm.commerce.payments.plugin.

Mapping of AVS codes returned by payment system and the default AVS configuration

The following PaymentechConstants.AVS_CODE* are defined in the AVSRules XML file:

• I1, I3, IA maps to PaymentechConstants.AVS_CODE_BOTH_MATCH (0)

• I5, I7, IB maps to PaymentechConstants.AVS_CODE_STREET_MATCH (1)

• I2, I4, IP maps to PaymentechConstants.AVS_CODE_POSTAL_MATCH (2)

• I6, I8 maps to PaymentechConstants.AVS_CODE_NEITHER_MATCH (3)

• N2, N2, IG, IU, ID, IE, IS, IC maps to PaymentechConstants.AVS_CODE_OTHERS (4)