Address Verification System codes and overrides — Increase

Address Verification System codes and overrides

The Address Verification System (AVS) is used during card authorization to validate that the billing address provided by the cardholder matches the address on file with the issuing bank.

At Increase, AVS codes sent in authorizations are either:

  1. Determined by Increase — Increase calculates AVS codes by comparing the cardholder address on file to the postal code and street address (line1) that the merchant sent in the authorization network message. The address parts can be defined or undefined in any combination.
  2. Determined by customer-provided overrides — Optional AVS code overrides customers specify in responses to Real-Time Decision requests.

If no AVS code overrides are provided during the Real-Time Decision request, Increase applies its own AVS code determination logic when generating the authorization response.

Visa’s simplified AVS codes

Historically, AVS had return codes that would distinguish between many more granular scenarios. Specifically, they used to have separate codes to distinguish between “address not checked because it was not provided” and “address provided but did not match”. Visa has since collapsed the set into fewer codes.

This simplification means certain distinctions no longer exist. Now, “address no match” covers both the case where the address was not provided and the case where the address was provided but did not match.

Overview of current Visa AVS codes

Code Definition Increase Representation Notes
Y Postal code matches, address matches. match Full match. Will only be returned if both postal code and address were provided and matched.
A Postal code no match, address matches. postal_code_no_match_address_match Postal code was provided and does not match or was not provided. Address was provided and matched.
Z Postal code matches, address no match. postal_code_match_address_no_match Postal code was provided and matched. Address was provided and did not match or was not provided.
N Neither postal code nor address matches. no_match Both postal code and address were not provided or did not match what was provided. If both were not provided, would be not_checked.
R Indeterminate outcome. Retry. retry The outcome could not be determined. All invalid AVS code values are treated as retry.
U Unable to verify. not_checked Address verification was not possible. Used when neither postal code nor address were provided. Blank AVS codes are treated as not_checked.

If an issuer returns any retired AVS codes, Visa will convert them to the appropriate simplified code and will not notify the issuer of the replacement. This means that issuers that are still using retired AVS codes should not see any change in their AVS outcomes and can continue to use their deployed logic. So for example, if an issuer were to return postal_code_match_address_not_checked, Visa would automatically convert it to postal_code_match_address_no_match.

Here at Increase, we’ve rolled forward to the new simplified codes.

Address matching

A key consideration of Increase’s implementation of AVS is how the address parts on file are compared to the address parts sent in the authorization request. Visa does not recommend exact string comparison. Instead, they emphasize numeric matching: the digits of the address are considered the most reliable indicators of matching.

Increase normalization & matching rules (summary):

Default AVS code determination logic

Increase compares the cardholder address on file to the request’s postal_code and line1 per the rules above. See the examples below for more details.

Examples of default AVS code determination Logic

Scenario Cardholder details Authorization request details Increase AVS code
Nothing matches 123 cool st, 97701 8583 payments ave, 94110 no_match
Exact match 123 cool st, 97701 123 cool st, 97701 match
Case-insensitive 123 cool st, 97701 123 COOL st, 97701 match
White space insensitive 123 cool st␣␣, 97701 123 cool st, 97701␣ match
Postal code white space → no postal sent 123 cool st, 97701 123 cool st, ␣ postal_code_no_match_address_match
Postal code mismatch 123 cool st, 97701 123 cool st, 94110 postal_code_no_match_address_match
Street number mismatch 321 cool st, 97701 123 cool st, 97701 postal_code_match_address_no_match
No street address, zips match 123 cool st, 94110 nil, 94110 postal_code_match_address_no_match
No postal sent at all 123 bank st, (any) nil, nil not_checked
No addresses, zips do not match nil, 00000 nil, 00001 no_match
Ignore unit number 123 cool street #333, 97701 123 cool st, 97701 match
Compressed address numeric 123 SE Greenville Blvd, Ste 456-789, 97701 12345, 97701 match
Visa non-UK example 1 123 1st Street, 91234-0615 123, 912340615 match
Visa non-UK example 2 1 Elm Street, 91234 1, 91234 match
Visa non-UK example 3 (leading numeric) 22 Walnut street #23, 70433-0123 22, 704330123 match
Visa non-UK example 3 (first five) 22 Walnut street #23, 70433-0123 2223, 704330123 match
Visa UK example (first five) 5678 LONDONCOURT #99, 5S76D 56789, 576 match

Acquirer use of AVS codes

Neither Increase nor Visa decline authorizations as a result of a mismatching AVS code—they are purely a signal to the acquirer and the merchant. The most common way they’re used are through $0 verifications, where an invalid address verification check might result in the merchant preventing the customer from saving their card for future use. Beyond $0 verifications they often feed into fraud systems on the merchant and acquirer’s side. A merchant that receives an approved authorization with an invalid address check might show the payment as declined to their customer to avoid the fraud risk, at which point they’ll usually reverse the authorization within a few minutes of the original authorization.

Customer-provided overrides

Customers can supply overrides to control how AVS codes are determined. The conversion from the provided overrides to the final AVS code considers two signals for each field:

If both postal_code and line1 are provided and match, the result is match. If a field is not provided, the result for that field is always no_match regardless of the provided override.

Increase will not check the cardholder address on file when determining the final AVS code if the user has provided overrides in the Real-Time Decision response. Note that per the API, if you wish to provide any overrides, both overrides must be set.

The table below comprehensively shows the AVS code used based on the provided overrides and whether the associated address part was provided in the authorization request.

Full override matrix

Postal code override Postal code provided? Line1 override Line1 provided? AVS code
match ✅ match ✅ match
match ✅ match ❌ postal_code_match_address_no_match
match ✅ no_match ✅ postal_code_match_address_no_match
match ✅ no_match ❌ postal_code_match_address_no_match
match ❌ match ✅ postal_code_no_match_address_match
match ❌ match ❌ not_checked
match ❌ no_match ✅ no_match
match ❌ no_match ❌ not_checked
no_match ✅ match ✅ postal_code_no_match_address_match
no_match ✅ match ❌ no_match
no_match ✅ no_match ✅ no_match
no_match ✅ no_match ❌ no_match
no_match ❌ match ✅ postal_code_no_match_address_match
no_match ❌ match ❌ not_checked
no_match ❌ no_match ✅ no_match
no_match ❌ no_match ❌ not_checked

Summary