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:

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.
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_no_match_address_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).