Zero-Value Authorization: What the Issuer Actually Verifies, and What an Approval Does Not Prove

Most payment stacks fire a zero-value authorization every time a customer saves a card. Very few of the people operating those stacks can say what the issuer actually checked before returning the approval — and a surprising amount of downstream logic quietly assumes it checked more than it did.

This is a reference for what the check is, when Visa requires it, what an approval does and does not establish, and where the operational traps sit. It is built from Visa's published rulebook (18 April 2026 edition) and PSP documentation; the scope section at the end says what that excludes.

What Visa actually calls it

The scheme term is not zero-value authorization or $0 auth. Visa's glossary defines Account Verification (ID# 0029700) as:

A message sent by an Acquirer to the Issuer, using a currency unit of zero, for confirmation that a Transaction can be completed using the Card.

And the merchant-side rule, section 5.7.2.1 (ID# 0030934), makes the zero mandatory rather than conventional:

A Merchant that chooses to verify the validity of an account must use an Account Verification.

The same section requires that the message both

Be for a currency unit of zero

and

Not be used to initiate a purchase Transaction

Two consequences follow directly. First, verification is a distinct message type with its own rules, not a small purchase. Second, the rule cuts both ways: you must not verify with a purchase-sized authorization, and you must not smuggle a purchase into a verification.

PSPs wrap this in their own vocabulary. Checkout.com's card-verification endpoint takes an amount of 0 — or omitted entirely — and returns a payment object whose status is "Card Verified". Stripe buries the message inside its SetupIntent flow: the Setup Intents API exists to set up a payment method for future payments, and its documentation notes that when setting up a card it may be necessary to

authenticate the customer or check the card's validity with the customer's bank

That validity check with the bank is, on Visa rails, this message. Stripe does not name the scheme message; the mapping is this article's, and it is worth knowing because the SetupIntent abstraction hides everything this reference is about.

What the issuer actually verifies — and the part everyone gets wrong

Section 7.3.10.1 (ID# 0031047) lists the issuer's duties. An issuer must

Receive and respond to a zero-amount Account Verification request

must

Validate that the Account Number is valid and has not been reported as lost or stolen

must

Not approve or decline Account Verification requests in a systematic or wholesale manner

and, for an approved response, provide validation results the acquirer asked for — the rule names Card Verification Value (CVV), CVV2 and the Cardholder Authentication Verification Value (CAVV) explicitly.

Then comes the sentence pair that most verification logic silently gets wrong. The issuer must respond with descriptive response codes:

• 00 - Approval (when the Account has balance greater than zero)
• 85 - No reason to decline (when the Issuer has not checked the Account balance)

Read those parentheticals literally, because they are the entire warranty.

A 00 attests that the account had a balance greater than zero at the moment of the check. One cent satisfies that condition. An 85 attests even less: the issuer found no reason to decline and never looked at the balance at all. Both are approvals for verification purposes, and the rule leaves the issuer free to answer with 85 — so your verification pipeline has to treat balance-not-checked as a routine outcome, not an edge case.

So a passed verification establishes, per the rule text: the account number is valid; the card has not been reported lost or stolen; and — only if the response was 00 rather than 85 — that some positive balance existed at check time.

It does not establish any of the following, and the rule text nowhere says otherwise:

• That the card can fund any particular future amount. Neither 00 nor 85 speaks to sufficiency of funds for a charge you have not yet made.
• That a future authorization will approve. The verification response binds the issuer to nothing about the next request; insufficient funds, spending controls, fraud models and account closures all still apply at charge time.
• That the person entering the card is the cardholder. Validity is a property of the credential, not of the presenter. A stolen-but-not-yet-reported card verifies cleanly — this is exactly why card testers love the message, more on which below.
• That authentication happened. A verification is not 3-D Secure. The CAVV line in 7.3.10.1 means the issuer will validate an authentication value you obtained separately and passed in; the verification itself authenticates no one.

If your onboarding flow treats "Card Verified" as evidence the customer can pay, or as evidence the customer is who they say they are, it is asserting things the issuer never said.

When the rule requires one: storing a credential

The clearest mandate is in Table 5-22, the processing requirements for stored credentials (ID# 0029267). Before the first transaction, after the cardholder agreement is completed, a merchant must either submit an authorization request for the transaction amount or:

If payment is not required, submit an Account Verification

That covers every free-trial signup, every save-card-for-later flow, every marketplace onboarding where no money moves on day one. And the table closes the loop with the line that should be wired into your vault as a hard gate:

If the initial Authorization Request or Account Verification is not approved, the Merchant must not store the credential.

This is a strong finding and worth stating plainly: vaulting a card whose verification was declined is a Visa rules breach. It is not a judgment call about data quality. Operationally it is also self-harm — every future merchant-initiated transaction on that credential descends from a decline the rules told you to act on.

One adjacent quirk, small but mandated: for a non-reloadable prepaid card, 7.3.10.1 requires the issuer to decline an account verification for a recurring transaction with

response code 57 (Transaction not permitted)

A gift card cannot anchor a subscription, and the rulebook makes the issuer say so with a specific code. If your recurring signup flow sees 57 on verification, the correct response is a different card, not a retry.

The $1 authorization question

Teams migrating old stacks still find $1 auths used as verification. Visa's position is unambiguous on the rule tier: verification must use the zero-amount message (5.7.2.1 above). The one-unit check has its own defined term — Status Check Authorization (ID# 0025130), an authorization request for one currency unit — and it is defined for exactly one merchant population: Automated Fuel Dispenser merchants. Section 5.7.2.6 and Table 5-10 govern how fuel pumps use it, with per-country amounts and completion-message duties. It is not a general-purpose verification tool.

Two honest caveats before you refactor anything.

First, no penalty or fine for small-value authorizations appears in the public rule text. The rule says what a verification must be; it does not attach a published fee to doing it the old way, and this article will not invent one.

Second, zero-amount support is an issuer capability, not a universal fact. Checkout.com's documentation lists, among the reasons a verification fails:

The issuer may not support zero-amount authorizations.

and documents the fallback:

Manually retry the verification with the amount field set to a low nominal value, and then void the payment.

So the defensible operating position is: zero-value verification as the default, with a nominal-amount-plus-void path as a documented exception for issuers that cannot process zero — ideally one your PSP triggers automatically rather than one you hand-roll.

AVS, CVV2 and name checks ride along — with an effective date to watch

A verification can carry the same ancillary checks as a real authorization. On the acquirer side, 7.3.10.2 (ID# 0031048) requires acquirers to send and receive verification requests carrying additional data including CVV2 and Address Verification Service (AVS) values. On the PSP tier this is visible directly: Checkout.com's verification response returns avs_check and cvv_check fields, and its Account Name Inquiry — checking the customer-supplied name against the issuer's records — runs as a verification with amount 0. Its documentation describes ANI as

a card verification service that works independently of the financial transaction

The issuer-side obligation to answer these checks is where the dates matter, so state them precisely. As of today, the rule is region-scoped: through 23 October 2026, issuers must provide AVS results on verifications in the AP region, Canada, the United Kingdom and the US, and ANI results in Canada, the United Kingdom and the US. Effective 24 October 2026, AVS and ANI validation results join the general list of what an issuer must provide on an approved verification, cross-referenced to the AVS and ANI issuer-requirement sections. That general requirement is scheduled, not yet in force — if an issuer outside the named regions returns nothing useful on your AVS-on-verification today, nothing in this rule currently requires otherwise.

One acquirer-side requirement is already live. Effective 25 July 2026, an acquirer performing ANI or AVS checks must

send genuine Cardholder name and/or address data that the Merchant obtained directly from the Cardholder

and must ensure the merchant information in verification requests — location and MCC included — is

consistent with subsequent Authorization data

(Both carry a carve-out for Chile.) The plain reading: fabricated or recycled AVS/ANI probe data, and verification traffic dressed in different merchant clothing from the charges that follow it, are now explicit acquirer violations. If you operate a data-enrichment flow that guesses addresses to improve match rates, this rule is aimed at you.

Network tokens: a declined verification blocks provisioning

An easy-to-miss footnote gives verifications a second job. In Table 4-9, the Visa Token Service enablement requirements (ID# 0029515), footnote 10 reads:

Where an Issuer authorizes an Account Verification request from the Visa Token Service, that Authorization represents an instruction to Visa to provision a Token. Visa will not issue a Token on the Issuer's behalf if the Issuer declines an Account Verification request from the Visa Token Service.

So when a network token is provisioned for a stored card, the yes/no gate is an account verification — sent by VTS itself, answered by the issuer. A credential that cannot pass verification does not just fail your vault check; it cannot be tokenised, which on modern PSP stacks means it loses the auth-rate and credential-update machinery that comes with network tokens. Verification health and token coverage are the same problem wearing two hats.

What a zero-value authorization is not

Three near-neighbours cause most of the confusion, so one contrast each.

Not a purchase authorization. An authorization reserves an amount against the account and creates something to capture or reverse; a verification moves and reserves nothing, must be for zero, and must not initiate a purchase. Nothing about a verification touches the cardholder's available balance.

Not authentication. 3-D Secure establishes that the cardholder is present and consenting; a verification establishes that the credential exists and is in good standing. The two compose — a verification can carry the CAVV from a prior authentication for the issuer to validate — but neither substitutes for the other.

Not an account updater. A verification is a point-in-time question about a credential you hold; account updater services push you replacement credentials when cards reissue. If your card is expired, verification tells you it is dead; the updater is what tells you what replaced it.

When not to send one

Verifications spend your reattempt budget. Visa's decline-reattempt regime in section 7.3.6.3 covers verifications by name — a merchant that receives a decline

may resubmit the Authorization Request or the Account Verification request only as follows

with Table 7-2 then setting the limits: never resubmit for the same credential after a Category 1 code, and at most 20 attempts in 30 days otherwise. The full category-by-category treatment is in the Visa decline categories reference, whose operator summary applies verbatim here: a zero-amount check is an attempt. A nightly job that re-verifies your whole vault is spending the same budget your retry engine needs.

Verifications are the card tester's favourite message. A free, instant, issuer-answered validity oracle is exactly what enumeration attacks want, which is why 7.3.10.1 forbids issuers from approving or declining verifications in a systematic or wholesale manner, and why the 25 July 2026 genuine-data rule exists. If your card-add endpoint fires a verification per attempt with no velocity control in front of it, you have built the oracle for them.

A verification cannot stand in for an authenticated first transaction. In SCA markets, a recurring agreement needs an authenticated cardholder-initiated transaction as its anchor; a zero-value authorization that skipped 3DS does not establish the stored-credential chain, and subsequent MITs descend from a broken anchor. The failure mode — and how to configure the CIT correctly — is covered in recurring payments and billing operations.

Scope: what this reference is built on

Everything above rests on two tiers: Visa's published Core Rules and Product and Service Rules (18 April 2026 edition) for the rule claims, and Checkout.com and Stripe documentation for the PSP surface. PaymentBrief could not check Mastercard's rules, so nothing here describes them. Mastercard has its own account-status mechanics, and none of the response-code semantics, mandates or effective dates above should be assumed to apply to it. Where your portfolio is scheme-mixed, verify the Mastercard side against documentation you can actually obtain — from your acquirer if not from the scheme — before configuring symmetric behaviour.