Visa Payment Passkey: The Acquirer Mandate and the Liability Protection

Visa has attached a fraud liability protection to a specific authentication method, and required acquirers in several regions to make sure their merchants can offer it. Both halves of that sentence are worth an operator's attention, and the regions they apply to are not the same.

What a Visa Payment Passkey is, in the rules' own terms

The Visa Rules define it, with effect from 18 April 2026:

A Visa solution, leveraging Fast Identity Online (FIDO®) security standards, that enables Cardholder verification during Electronic Commerce Transactions using passkey authentication.

Within the AP region the rules add a plainer gloss: a payment passkey is a FIDO authentication credential that "allows a user to authenticate a payment transaction with the same process that they use to unlock their device (for example: biometrics, PIN, or pattern)."

That is a cardholder verification method, not a protocol and not a token. Keeping those apart matters, and the next section is the reason.

Four things this is not

The vocabulary in this area is a mess, and conflating any two of these will produce a wrong implementation.

• Not EMV 3-D Secure. 3DS is a messaging protocol between merchant, acquirer, scheme and issuer. A passkey is a credential used to verify the cardholder. They interact — see the Click to Pay section below — but they are different layers.
• Not network tokenisation. A passkey authenticates a person. A network token replaces a card number. Neither implies the other.
• Not, by itself, strong customer authentication under EU law. SCA is a legal test under the payment services framework. Nothing in the rules cited here states that a passkey satisfies it, and this article does not claim so.
• Not automatically a liability shift. The protection is conditional on what the authorization message carries, not on what happened at checkout. That distinction is the single most common way merchants lose a benefit they think they have.

Where it applies, and where it does not

Visa Payment Passkey sits inside the Digital Commerce Authentication Program (DCAP). One naming quirk to note before you search internally for it: in the Europe Region the programme is known as Visa ecommerce experience (Vee). Same programme, different label, and a European colleague may know it only by the second name.

DCAP participation applies to qualifying domestic, intraregional and interregional transactions, effective 18 April 2026 in the AP Region, Europe Region and LAC Region (Argentina), and effective 24 October 2026 in the Canada Region, CEMEA Region and the rest of LAC.

Two exclusions are explicit and easy to miss:

• AP Region: does not apply to Bangladesh, Bhutan, India, Nepal
• LAC Region: does not apply to Chile

The issuer obligations

Effective 18 April 2026 in the AP and Europe regions, and 24 October 2026 in Canada, CEMEA and LAC, an issuer must both:

• Support Visa Payment Passkey transactions, including merchant-led enrolments, and not systematically decline such requests
• Not systematically delete Visa passkeys bound to a cardholder's device, unless there is suspected fraud

The first is the commercially significant one. Merchant-led enrolment is named explicitly, which means an issuer cannot confine passkey creation to its own app or website and treat merchant-initiated enrolment as out of scope.

The second is quieter and more unusual: a rule against deleting a credential. Passkeys are bound to a device, and an issuer that periodically clears them would silently undo enrolment a merchant paid to acquire.

An issuer can still decline — the carve-out, read rather than assumed

The no-systematic-decline duty points to a separate rule, and reading it changes how absolute the obligation looks.

That rule requires an issuer to evaluate each transaction properly accepted, processed and submitted in order to make an authorization or other decision, and not to block, refuse or decline authorization requests "in a systematic or wholesale manner." It then carves out three categories:

• an immediate fraud threat, or an exception otherwise specified by applicable laws or regulations or in the Visa Rules
• a card issued under an approved special purpose issuance program
• a Visa Commercial Card issuer choosing to block gambling transactions, or transactions acquiring non-fiat currency such as cryptocurrency or non-fungible tokens

The rule also directs that where an issuer has determined a transaction is illegal, it must send decline response code 93 (transaction cannot be completed — violation of law).

So per-transaction risk decisions remain entirely the issuer's. What the rules prohibit is blanket treatment of the authentication method itself. If you are modelling approval rates, do not assume passkey authentication guarantees an approval — assume it removes a category of blanket refusal.

The acquirer obligation, and the region that is missing from it

This is the part merchants should read twice.

An Acquirer must ensure its Electronic Commerce Merchants can actively offer Visa Payment Passkey authentication at checkout and submit an Authorization Request with Visa Payment Passkey data.

Effective 18 April 2026 in the AP Region, and 24 October 2026 in the Canada, CEMEA and LAC Regions.

The Europe Region appears in the issuer paragraph of that rule and does not appear in the acquirer paragraph. That asymmetry is in the source text, not a simplification here. A European merchant should therefore not assume its acquirer carries the same obligation that a Canadian or Singaporean merchant's acquirer carries from those dates — ask, rather than infer, and get the answer in writing if the roadmap depends on it.

Note also the verb: actively offer. The obligation is not that the acquirer permits passkey data to pass through if a merchant builds it. It is that merchants can offer the authentication at checkout and submit the resulting data.

What actually earns the liability protection

A Merchant will receive fraud Liability protection on a Visa Payment Passkey Transaction if the Authorization Request includes a valid Cryptogram and an Electronic Commerce Indicator (ECI) 5 or ECI 6.

Two conditions, both in the authorization request:

1. a valid cryptogram
2. an ECI of 5 or 6

Offering a passkey at checkout earns nothing on its own. The benefit is carried by the message, so the integration question is whether your gateway and acquirer populate both fields correctly and whether you can see them in your own logs.

Read where that sentence sits, not just what it says

This is the most important structural point in the article, and it is easy to miss. The liability sentence is not a free-standing rule. It is the second sentence of the acquirer paragraph quoted above — it carries no "Effective … In the … Region:" preamble of its own.

On the document's own structure, a paragraph's opening date-and-region preamble governs the sentences that follow it until the next preamble. That means the liability protection appears to inherit exactly the same gating as the acquirer duty beside it:

• 18 April 2026 in the AP Region, 24 October 2026 in Canada, CEMEA and LAC
• the same footnote markers, so not in Bangladesh, Bhutan, India, Nepal or Chile
• and, like the acquirer duty, no Europe Region in the preamble

So the same caution applies to the benefit as to the obligation: do not assume the liability protection is available to you before you have confirmed your region and date. A European merchant in particular should not read this sentence as an unconditional entitlement — the public text does not resolve whether the protection operates in Europe ahead of an acquirer duty there.

Ask your acquirer both questions together: are you bound to let us offer this, and is the liability protection available to us on this date, in this country?

This article does not gloss what ECI 5 and ECI 6 each signify separately, because the Visa Rules cited here define the liability trigger rather than the indicator semantics, and PaymentBrief found no definition of either value in them.

One adjacent data point, stated for what it is rather than as a definition: Visa's dispute rules list ECI 5 together with an issuer authentication confirmation using Visa Secure with EMV 3DS and the CAVV being present as conditions that jointly make an Other Fraud (Dispute Condition 10.4) dispute invalid. That is a three-part test for a dispute outcome, not a statement of what ECI 5 means on its own, and it should not be read as one.

Confirm with your acquirer which indicator your stack actually emits on a passkey transaction before you rely on the protection in a chargeback.

The Click to Pay connection

A separate rule ties passkeys to Click to Pay in the AP, Europe and CEMEA regions. An issuer participating in Visa Secure with EMV 3DS must perform challenge-based cardholder authentication when requested by Click to Pay in the EMV 3DS protocol. And issuers must not decline any transaction using Click to Pay with successful passkey authentication "in a systemic or wholesale manner."

That rule carries a terminology transition worth knowing if you are comparing documents of different vintages: through 17 April 2026 it referred to "successful FIDO or payment passkey" authentication; from 18 April 2026 it refers to "Visa Payment Passkey" authentication. The obligation did not change shape; the defined term arrived. If a vendor document uses the older phrasing, it is not necessarily out of date on substance.

For the surrounding Click to Pay mechanics, see the Click to Pay operator reference.

What the public rules do not tell you

DCAP has a second half, and the part that binds you is not published.

To qualify for DCAP and be eligible for its benefits, an acquirer and its merchants must comply with eligible solution requirements and meet minimum data quality requirements — both stated only "as specified in the Digital Commerce Authentication Program (DCAP) Guide - Data Sharing Solution." The AP carve-out points to a Visa Secure Program Guide for the country list. Neither guide is public, and PaymentBrief could not locate either one as at 28 August 2026.

Be precise about what that does and does not mean. Visa's own DCAP programme page is public and describes the data-sharing solution at a working level: it states that merchants send four required enhanced data fields — Device ID, IP address, email address and full billing address — through one of Visa's Intelligent Data Exchange solutions, which Visa validates and delivers with risk scores to issuers during authorization. So the shape of the data-sharing path is documented.

What is not documented anywhere public is the thresholds: what "minimum data quality" actually requires, and what happens when you miss it. That number lives in the Guide. If a vendor quotes you a DCAP data-quality threshold, ask which document it comes from and whether you can read it.

Two paths, and only one of them moves liability

This is the distinction most likely to cause an expensive mistake, and it is why this article is careful not to say "DCAP shifts liability."

• The data-sharing path performs no cardholder authentication. It enriches the issuer's risk decision. No authentication event means no liability shift, and the merchant keeps fraud liability.
• The passkey path described above is authentication, and carries the fraud liability protection — conditional on the cryptogram and ECI in the authorization request.

Both sit under the DCAP umbrella. Treating the programme as a single thing, in either direction, will get the liability answer wrong. For the data-sharing path and how it compares with delegated authentication, see the SCA exemption strategy playbook.

This article also does not describe Mastercard's equivalent, because PaymentBrief could not check Mastercard's rulebook. Do not infer Mastercard requirements from these.

What an operator actually does differently

• Find out which list you are on. The issuer dates and the acquirer dates differ, and Europe is in one and not the other. Your region and your role both matter.
• Check the exclusions before scoping. Bangladesh, Bhutan, India and Nepal are out within AP; Chile is out within LAC.
• Instrument the authorization message, not the checkout. The liability protection depends on a valid cryptogram and ECI 5 or 6 being present in the request. Log both, and alert when a passkey transaction goes out without them.
• Ask your acquirer for the ECI it emits on a passkey transaction, in writing, before you count the protection in a dispute model.
• If you are in Europe, ask rather than assume. The acquirer obligation as drafted does not list your region.
• Do not retire your 3DS strategy. Passkeys operate alongside EMV 3DS, and the Click to Pay rule assumes issuer participation in Visa Secure with EMV 3DS. See 3-D Secure 2 and the authentication tax for the trade-offs that do not go away.