Guides
Explanatory and how-to content
API Reference
Technical documentation
Changelog
Release notes
Dashboard
Manage your account
Status
Service status

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

CodeDefinitionIncrease RepresentationNotes
YPostal code matches, address matches.matchFull match. Will only be returned if both postal code and address were provided and matched.
APostal code no match, address matches.postal_code_no_match_address_matchPostal code was provided and does not match or was not provided. Address was provided and matched.
ZPostal code matches, address no match.postal_code_match_address_no_matchPostal code was provided and matched. Address was provided and did not match or was not provided.
NNeither postal code nor address matches.no_matchBoth postal code and address were not provided or did not match what was provided. If both were not provided, would be not_checked.
RIndeterminate outcome. Retry.retryThe outcome could not be determined. All invalid AVS code values are treated as retry.
UUnable to verify.not_checkedAddress 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

ScenarioCardholder detailsAuthorization request detailsIncrease AVS code
Nothing matches123 cool st, 977018583 payments ave, 94110no_match
Exact match123 cool st, 97701123 cool st, 97701match
Case-insensitive123 cool st, 97701123 COOL st, 97701match
White space insensitive123 cool st␣␣, 97701123 cool st, 97701␣match
Postal code white space → no postal sent123 cool st, 97701123 cool st, ␣postal_code_no_match_address_match
Postal code mismatch123 cool st, 97701123 cool st, 94110postal_code_no_match_address_match
Street number mismatch321 cool st, 97701123 cool st, 97701postal_code_match_address_no_match
No street address, zips match123 cool st, 94110nil, 94110postal_code_match_address_no_match
No postal sent at all123 bank st, (any)nil, nilnot_checked
No addresses, zips do not matchnil, 00000nil, 00001no_match
Ignore unit number123 cool street #333, 97701123 cool st, 97701match
Compressed address numeric123 SE Greenville Blvd, Ste 456-789, 9770112345, 97701match
Visa non-UK example 1123 1st Street, 91234-0615123, 912340615match
Visa non-UK example 21 Elm Street, 912341, 91234match
Visa non-UK example 3 (leading numeric)22 Walnut street #23, 70433-012322, 704330123match
Visa non-UK example 3 (first five)22 Walnut street #23, 70433-01232223, 704330123match
Visa UK example (first five)5678 LONDONCOURT #99, 5S76D56789, 576match

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 overridePostal code provided?Line1 overrideLine1 provided?AVS code
matchmatchmatch
matchmatchpostal_code_match_address_no_match
matchno_matchpostal_code_match_address_no_match
matchno_matchpostal_code_match_address_no_match
matchmatchpostal_code_no_match_address_match
matchmatchnot_checked
matchno_matchno_match
matchno_matchnot_checked
no_matchmatchpostal_code_no_match_address_match
no_matchmatchno_match
no_matchno_matchno_match
no_matchno_matchno_match
no_matchmatchpostal_code_no_match_address_match
no_matchmatchnot_checked
no_matchno_matchno_match
no_matchno_matchnot_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).