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):

• Trim/normalize white spaces.
• Ignore casing.
• Ignore unit numbers when determining the numeric prefix.
• Normalize postal codes.
• Treat blank/omitted request fields as not provided (affects code determination as described below).
• Support “compressed numeric” (e.g., 123 SE Greenville Blvd, Ste 456-789 can match 12345 via numeric concatenation/prefix).

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 in to 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:

• Was the field provided in the network message?
• Was the override for that field a match or no_match?

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 provided any overrides, both overrides must be provided.

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

• If a user provides AVS match/no match overrides, Increase will use them in combination with what address parts were provided in the authorization request to compute the final appropriate AVS code.
• If a user does not provide AVS match/no match overrides in an approved Real-Time Decision request, Increase will use its own AVS code determination logic to compute the AVS code.
• Increase’s default AVS code determination logic computes AVS codes by comparing the cardholder address on file to the authorization’s postal_code and line1, using normalization and numeric matching rules.
• Visa’s simplified AVS codes mean “not checked” and “no match” are no longer distinguished, and any missing address parts will always be treated as no_match.
• If both postal_code and line1 are not provided, the result is always blank (not_checked).