Click to Pay and EMV SRC: What They Are and What They Are Not

Four different things get called the same thing in most Click to Pay explainers: the EMVCo specification, the consumer brand, network tokenisation, and 3-D Secure. They are related. They are not interchangeable, and an operator who treats them as one will scope the wrong project.

The specification itself is unusually clear about the boundaries, which is worth reading before anything else.

The four things, separated

EMV Secure Remote Commerce (SRC) is a specification published by EMVCo. It defines participant roles, an API surface, a JavaScript SDK and a checkout choreography. It is technology, not a brand.

Click to Pay is the consumer-facing brand built on SRC. In EMVCo's own words, the SRC Specifications "provide a common baseline for the development of Click to Pay ecommerce payment solutions," and Click to Pay solutions "are indicated by the Click to Pay icon" — an icon EMVCo licenses to participating merchants. Visa, Mastercard, American Express and Discover each operate their own SRC System and their own Click to Pay instance. Discover states this directly: Discover SRC is "the Discover Global Network implementation of EMVCo's globally interoperable EMV Secure Remote Commerce Specifications."

Network tokenisation is a separate EMVCo specification. SRC does not require it.

3-D Secure is separate again. SRC does not perform it.

Those last two are not inference. The Use Cases supplement to the SRC Specifications says so in one paragraph, in Section 1.2.2:

The SRC Specifications do not provide any requirements for payment authentication nor govern activities within it. However, they offer the Digital Payment Application the choice to conduct payment authentication […]

The SRC Specifications support the option for SRC Participants to implement other EMV technologies during checkout, such as Payment Tokenisation and 3-D Secure. The SRC Participants will conform to requirements defined by Payment Tokenisation and 3-D Secure implementations.

Read that carefully, because it settles two arguments at once. SRC accommodates tokenisation and 3DS; it mandates neither, and it explicitly disclaims governing authentication. Any statement that "Click to Pay authenticates the cardholder" or "Click to Pay is tokenisation" is describing an implementation choice made by the networks, not a property of the standard.

The roles, which are the actual vocabulary

SRC defines a role model, and the role names are what you will meet in integration documentation:

Two things follow from this table that matter commercially.

First, the SRCI is the integration point, and it is normally your PSP. American Express describes merchants integrating "by partnering with an SRC Initiator (SRCi) of their choice," with the SRCi integrating with the SRC systems of multiple networks on the merchant's behalf. A merchant can be its own SRCI, but essentially all practical guidance assumes an intermediary.

Second, expect naming to diverge between schemes. The role names above are EMVCo's, and each network documents its own implementation in its own vocabulary. If you are reading two schemes' documentation side by side and the roles do not obviously line up, map each back to the specification rather than to the other.

Enrolment is the issuer's, not yours

EMVCo states that "consumers enrol in Click to Pay via participating payment card issuers."

This is the single most important structural fact for a merchant, and it is easy to miss because it is stated as a consumer-facing detail rather than an operational constraint.

It means your recognition rate at checkout — the proportion of shoppers whose cards are already available in an SRC System — is primarily a function of issuer participation, not of anything you build. You can influence placement, messaging and fallback. You cannot enrol your customers. A Click to Pay rollout that assumes merchant-driven enrolment is scoped against a mechanism that does not exist.

What actually happens at checkout

The choreography, from the specification and from PSP documentation:

1. The SRCI initialises against one or more SRC Systems.
2. Recognition — the SRCI asks each SRC System whether this consumer or device is already recognised.
3. If not recognised, identity lookup by email or phone number, then a one-time passcode.
4. The consumer is shown a candidate list of available Digital Cards.
5. Review and confirm, presented by the Digital Card Facilitator.
6. A payload is returned for authorisation.

Step 6 is where the tokenisation question resolves in practice. The specification is neutral, but implementations are not: Adyen's Click to Pay fields are token references rather than card numbers, and the PSP documentation cited here treats the PAN as withheld from the merchant unless an account is specifically configured otherwise.

So: you should expect a token and a cryptogram, and treat receiving a raw PAN as something that has to be deliberately arranged. That has direct consequences for PCI scope and for how the credential sits alongside whatever you already store — a question covered in depth in the payment credential vault architecture reference, which sets out the five credential types a merchant might hold and who controls each. A Click to Pay payload is not a sixth type competing with those; it is a delivery mechanism that hands you one of them.

3-D Secure sits on top, and so does any liability shift

Because SRC disclaims governing authentication, 3DS behaviour is decided outside it. Adyen documents this plainly: Click to Pay "is compatible with 3D Secure, meaning that transactions may or may not require 3D Secure authentication, based on regular 3D Secure decision-making."

In other words, selecting Click to Pay does not change your authentication strategy. Your existing 3DS and exemption logic still governs.

On liability, be careful. The only liability language found in the sources reviewed is American Express's, and it is explicitly conditioned on 3DS rather than on Click to Pay: merchants meeting SafeKey FLS eligibility "may receive SafeKey FLS benefits if they initiate a SafeKey transaction when Click to Pay is selected at the checkout." That is a SafeKey benefit that survives a Click to Pay selection — not a benefit of Click to Pay.

No equivalent Visa or Mastercard liability statement tied to Click to Pay itself was found in the sources reviewed. That is an absence of evidence in those sources, not proof that none exists — you should not assume a Click to Pay liability shift, and should ask your acquirer for the position in writing before modelling one.

Updated 2026-08-28. Visa's rules do carry a liability statement in adjacent territory, and it is worth knowing about here even though its trigger is not Click to Pay. Where a transaction uses Visa Payment Passkey, the rules state that a merchant receives fraud liability protection if the authorization request includes a valid cryptogram and an Electronic Commerce Indicator of 5 or 6 — and a separate rule requires an issuer participating in Visa Secure with EMV 3DS to perform challenge-based authentication when Click to Pay requests it in the EMV 3DS protocol. The protection attaches to the passkey transaction and its message content, not to Click to Pay selection. Region and date scope matter and are not universal. See the Visa Payment Passkey operator reference.

Recurring: the specification allows it, your PSP may not

EMVCo's Use Cases document describes a Digital Card being designated as a merchant card-on-file and used for subsequent merchant-initiated transactions where the consumer has authorised recurring payments.

Implementation diverges sharply beneath that:

• Braintree documents support for vaulting and recurring billing.
• Adyen documents that "Currently, Adyen’s Click to Pay integration only supports recurring payments on Mastercard Click to Pay."

That Adyen line is the useful one, because it shows the failure mode: spec-level support does not mean uniform PSP support, and it does not mean uniform support across the four networks within one PSP. If recurring billing is part of your case for Click to Pay, verify it per PSP and per network before it becomes a roadmap assumption.

Platform support moves, and it moves with dates

Click to Pay is not a stable substrate you integrate once. Braintree's own documentation carries the note: "Effective January 20, 2026, Visa Click to Pay (Secure Remote Commerce) will no longer be supported." It goes on to say that transactions attempted with Visa Click to Pay after that date will fail.

A dated, scheme-specific withdrawal on one PSP is exactly the kind of change that arrives through the release-guide channel rather than from the scheme — which is its own operational problem, covered in how card scheme mandates reach you.

What is current, and where it is going

Publicly listed specification status as of writing: SRC API v1.5 (30 October 2025) and Click to Pay CX Guidelines v1.2 (18 March 2026) are public; a JavaScript SDK v1.6 draft is subscriber-only. The current version of the SRC Core Specification could not be confirmed from the sources reviewed — the Use Cases supplement quoted above references Core v1.1, but that document is from June 2022 and should not be taken as current.

Version 1.5 added two things worth knowing. Passkeys for card listing — EMVCo notes that "a passkey is a consumer-facing term for a Fast Identity Online (FIDO) authentication credential" — which addresses the one-time-passcode friction in the unrecognised-consumer path. And EV charging, with data elements enabling SRC for open payments at charging stations supporting ISO 15118 Plug and Charge. The second is a signal about where EMVCo sees SRC going: beyond browser checkout.

What was not found, and should not be invented

Two gaps are worth stating rather than filling.

No public operational benchmark was found in the sources reviewed. No scheme or PSP document reviewed publishes recognition rates, checkout drop-off, or fallback-to-manual-PAN rates for Click to Pay. Recognition rate and fallback rate are the two metrics you would actually instrument, and you will have to establish your own baseline because there is no published one to compare against.

Visa issuer-mandate dates circulate but could not be verified. Specific enrolment-mandate timelines by region appear in industry commentary. PaymentBrief found no mandate dates on Visa's own Click to Pay issuer page. Those dates are therefore not repeated here. If a mandate date matters to your planning, get it from your acquirer with a bulletin reference rather than from a summary.

What to take from this

• SRC is the specification; Click to Pay is the brand on top of it. Four networks, four Click to Pay instances, one role model.
• Tokenisation is optional to the standard and standard in practice. Expect a payload, not a PAN.
• SRC does not authenticate. 3DS is layered on, your existing exemption logic still applies, and no liability shift is inherent.
• Enrolment belongs to issuers. Recognition rate is largely not yours to move.
• Recurring support is a per-PSP, per-network question, not a spec question.
• Instrument recognition and fallback yourself, because nobody publishes a benchmark.