Explain It in 30 Seconds
A shopper wants to pay for an order.
Instead of repeatedly entering card details, the shopper can identify an enrolled profile, confirm identity where required and choose an available card.
The merchant receives the payment information through its supported integration and continues the payment process.
The selected card still belongs to its issuing relationship. The merchant still needs its acquiring and processing arrangements.
Click to Pay simplifies the interaction between those existing parts. It does not replace all of them. [S40][S41]
Where It Sits in Visa
Click to Pay supplies a checkout layer within Visa, above credential and processing infrastructure.
VTS manages the supported digital credential; Click to Pay helps the shopper select and use it.
Several industry participants can implement the EMVCo framework. The common name and icon do not make every implementation Visa-owned. [S40][S66]
The Problem It Solved
Repeated payment entry creates mistakes and checkout abandonment. Separate merchant experiences can also make a familiar task feel different at every store.
SRC supplies a common foundation for a recognizable interaction across participating merchants.
Its intended benefit is less friction. Actual order completion still depends on the merchant's implementation and customers.
How It Works — Simple Version
A simplified consumer journey is:
1. Recognize that the merchant supports Click to Pay. 2. Identify the enrolled profile, for example through an email address. 3. Complete the required identity confirmation. 4. Choose an enrolled card. 5. Continue the merchant's payment and order process. [S41]
Behind that experience, the merchant or payment-service provider facilitates card selection and receives a payment payload through its integration. [S87]
The consumer sees a short journey.
The merchant must still connect the payment outcome to the correct order and support what happens next.
The Participants Behind the Checkout
Issuer
The issuer maintains the underlying card account.
It can help enroll cardholders and manage the relevant profile and credential lifecycle, directly or through supported partners. [S40]
Merchant
The merchant owns the product, cart and order relationship.
It decides how the supported payment experience fits within its checkout.
Payment-service provider
The PSP can supply the integration to many merchants.
That gives the service a distribution path through existing merchant relationships rather than requiring every merchant to build the same infrastructure independently.
Shopper
The shopper selects and uses an eligible payment method.
An enrolled profile does not create another deposit balance or a new credit limit.
Integration Is a Product Choice
Visa documents API, SDK, drop-in and Cybersource-connected Unified Checkout routes.
They differ in supported networks, interface control and gateway requirements. [S87]
A merchant may choose more control or a maintained prebuilt component. A PSP must support that choice across its merchant base.
The shared standard does not remove the real integration or provider relationship.
Checkout and Tokenization Are Different Layers
Tokenization manages the credential; Click to Pay organizes its selection and use.
Visa's implementation builds on VTS, but the services have distinct jobs. Authentication also remains necessary: a recognized profile and valid credential do not establish that every order is legitimate. [S29][S40]
The Order Continues After the Click
In an illustrative physical-goods order, selecting a card completes only the checkout interaction.
The merchant still connects the result to the order, fulfills it and handles cancellation or return.
Checkout attempts, approvals and completed orders are therefore different measures. The buyer needs to know which changed before attributing a business benefit to the integration.
Who Uses It and Who Buys It?
Shoppers use the experience
Their immediate objective is completing the purchase with less repeated entry or confusion.
Merchants adopt the capability
Their decision includes payment completion, compatibility with existing systems and the work required to operate it.
PSPs distribute and maintain integrations
A PSP can make the capability available within its merchant proposition.
Its own technical and support decisions affect what the merchant can offer.
How the Economics Work
Order value is not Click to Pay revenue, and the merchant retains its applicable gateway and acquiring arrangements.
The economic comparison concerns completed legitimate orders, failed attempts, fraud/dispute costs, support and ongoing implementation work.
An easier interface can help without guaranteeing a positive financial return.
What It Depends On
Enrollment
The payment experience needs an eligible enrolled credential and supported user journey.
A customer cannot assume every account is automatically available.
Provider support
The merchant's chosen PSP or integration must support the actual production capability.
An old tutorial is not proof of present availability.
Braintree states that its Visa Click to Pay support ended on January 20, 2026. That is a provider-specific withdrawal, not the global end of Click to Pay. [S72]
Merchant implementation
The cart, payment payload and order result need to work together.
The merchant must also support unsuccessful or uncertain attempts.
Underlying payment infrastructure
The chosen account, token and processing path retain their own requirements.
A consistent interface does not erase the institutions behind it.
What Depends on Click to Pay
Participating merchants and PSPs rely on the selected checkout and credential workflow.
Issuers can support use of their existing products through enrollment. That is a defined integration, not dependence of every merchant payment method on Click to Pay.
Why It Matters to Visa
Click to Pay gives Visa's digital infrastructure a recognizable role in remote checkout by making supported credentials easier to select.
That opportunity requires issuer, merchant and provider participation. The specification supplies a foundation; adoption produces the working experience.
Before / After
Repeated manual entry
A shopper supplies payment information separately in each merchant's checkout.
A supported enrolled-profile experience
The shopper identifies a profile, confirms identity and chooses an enrolled card. [S41]
This changes repeated entry while preserving the issuer account and merchant processing arrangements.
What Most People Misunderstand
“Click to Pay belongs only to Visa.”
Visa supplies a solution based on an industry framework used by multiple participants. [S66]
“The icon is a generic Visa payment logo.”
“Enrollment creates a new source of funds.”
The customer still uses the selected underlying card relationship.
“Tokenization and checkout are the same service.”
They solve related but separate credential and interface problems.
“One provider ending support means the entire standard ended.”
Braintree's documented change concerns its own integration. [S72]
Key Milestones
June 2019 — SRC specifications
EMVCo launched the specifications underlying the common remote-commerce framework. [S88]
June 2020 — Click to Pay description and icon guidance
EMVCo confirmed the consumer-facing name for solutions based on SRC and the accompanying icon rules. [S88]
January 20, 2026 — Braintree support change
The provider's withdrawal demonstrates why a merchant must distinguish a shared standard from a particular implementation. [S72]
Evidence
- [S40] Visa developer overview and ecosystem roles.
- [S41] Merchant explanation of the consumer journey.
- [S29] The distinct token layer.
- [S66] EMVCo's current description of SRC.
- [S87] Different integration choices and institutional requirements.
- [S88] The dated framework history and shared icon.
- [S42] Visa brand guidance.
- [S72] Braintree's specific support limitation.
The illustrative order and operating-economics comparisons explain the product's role; they are not reports of a particular merchant's measured uplift.