Click to Pay Explained: A Merchant's Guide to the Card Schemes' New Online Checkout Standard

Most online checkouts still ask the shopper to do data entry by hand. Find the card, read off sixteen digits, copy the expiry, flip it over for the security code, then type a billing address that may not match what the bank has on file. On a phone, one-handed, that sequence is exactly where a large share of buyers quit.

Click to Pay is the card networks' fix for that. It is one scheme-neutral way to check out online that removes manual card entry, recognises returning shoppers, and pays with a tokenised, cryptographically protected credential instead of a raw card number. Visa, Mastercard, American Express and Discover all back it. It runs on a shared industry standard. And it is increasingly being switched on by default in the cards your customers already carry, rather than being a wallet they have to go and find.

For a merchant, Click to Pay lands on three things you already track: conversion, fraud, and the cost of touching card data. This guide covers what it is, where it came from, how it works for each party involved, why the schemes are pushing it this hard, and what it actually changes for a business accepting payments online.

What Click to Pay actually is

Click to Pay is the consumer-facing name for payment solutions built on the EMV Secure Remote Commerce (SRC) specifications. EMVCo, the technical body collectively owned by the major card networks and responsible for the EMV chip and contactless standards in billions of cards, published the SRC specifications in June 2019. The following year, EMVCo settled on a single consumer name, Click to Pay, with one recognisable icon, so shoppers would learn one checkout instead of a different one per card brand.

That history tells you what Click to Pay is not. It is not a proprietary wallet owned by one company, the way PayPal is. It is not locked to one device maker, the way Apple Pay is locked to Apple hardware. It is a shared set of specifications: an API spec, a JavaScript SDK spec, and customer-experience guidelines, all published royalty-free. The people meant to gain from it are the merchants and shoppers who use it, not the bodies that wrote it.

The cleanest way to picture it is the physical world. EMV chip and contactless gave in-store payments one consistent, secure, tap-and-go experience. Click to Pay aims to do the same for e-commerce, so paying online feels as quick and as safe as tapping a card in a shop.

The buttons that came before

If this feels familiar, that's because the schemes tried it before. Visa ran Visa Checkout. Mastercard ran Masterpass. Both were proprietary, brand-specific buttons, and both hit the same wall: they split the checkout into competing logos, shoppers had to work out which button matched which card, and adoption stalled. SRC was built specifically to retire those efforts and put one scheme-neutral experience in their place. Visa Checkout and Masterpass have since been wound down in favour of Click to Pay.

It isn't just Visa and Mastercard

The two big networks get the airtime, but Click to Pay is a shared standard, and the breadth is the point. American Express runs its own implementation with no integration fee and no impact on the merchant rate, and its SafeKey authentication can drive a liability shift the way 3-D Secure does elsewhere. Discover participates too. Because SRC is an open, royalty-free EMVCo specification rather than a Visa or Mastercard product, domestic and regional schemes can build on it as well. For a merchant, the upside is that one integration presents cards from multiple networks through a single interface, instead of a separate button per brand.

What it solves, from a merchant's seat

Three structural problems sit under most online payment pain. Click to Pay goes after all three.

The first is cart abandonment, and the numbers are stark. A 2024 Mastercard global checkout study reported that 83% of online shoppers have abandoned a cart, with the most common reasons being the lack of a frictionless payment step (49%), being asked to enter or save too much information (40%), and checkout simply taking too long (25%). A typical US checkout can run to more than 14 form fields. Visa, citing Hotjar, has put the global cost of abandonment near $260 billion a year. Every field is another chance to lose the buyer, and the damage is worst on mobile, where typing card details is slowest and most error-prone.

The second is declined transactions. A card-not-present payment can fail for reasons that have nothing to do with the customer's intent or balance: an expired card on file, a stale credential, an issuer's risk model flagging an unfamiliar manual entry. Each false decline is a sale lost at the final step.

The third is fraud and the cost of handling card data. A keyed-in card number is trivial for a fraudster to test and reuse. And every merchant that touches a raw PAN inherits PCI DSS obligation and breach risk along with it.

There's a consumer tension underneath all three. Shoppers dislike re-typing card details, but they are also wary of leaving them on file: in Mastercard's research most shoppers still key in a card on most purchases, and among those who won't save one, security worries are the leading reason (58%). Visa has reported that more than eight in ten consumers are reluctant to store their credentials on merchant sites at all. So the merchant is caught between friction and mistrust. Click to Pay threads that needle, because the credential lives with the network rather than being saved on each merchant's site.

Click to Pay hits all three at once. It shortens and de-risks the checkout, swaps fragile stored card numbers for tokens that issuers treat more kindly, and keeps the actual card credential out of the merchant's hands entirely.

How it works, step by step

Start with the shopper's experience, then look underneath.

From the shopper's point of view

A returning, recognised shopper sees a short option at checkout. Because Click to Pay can recognise the device, their saved cards can appear straight away, shown as card art and the last four digits, with nothing to type. They pick a card, confirm, authenticate if asked, and the order is done.

A first-time or unrecognised shopper enters an email address or mobile number instead of reaching for a card. Click to Pay uses that identifier to check whether a profile already exists, possibly created at a completely different store, since the profile travels across every participating merchant. If it does, their cards show up. If not, they enrol a card once, often with an option to be remembered on that device, and from then on they're recognised wherever Click to Pay appears.

Under the hood

When the shopper clicks to pay, the merchant's checkout software signals the relevant system to begin. The shopper is recognised through a previously set cookie or device binding, or identified by email or phone. The system finds the profile and shows the eligible cards. The shopper selects one and, where needed, completes a verification step.

Here's the part that matters. The system returns a secure payload to the merchant's checkout, and that payload does not contain the real card number. It carries a payment token, a surrogate value standing in for the underlying PAN, plus a one-time cryptogram generated for that single transaction. The merchant submits this for authorisation the way it would any payment, but the sensitive credential never lands in the merchant's environment. Intercept a token and cryptogram and you get nothing useful: the cryptogram is single-use, so a replayed transaction won't match and gets declined.

A clarification here, because it trips people up. Click to Pay is built on the same EMV payment-tokenisation technology as network tokens and delivers the same protections. But the two aren't equivalent: they come through different provisioning paths and arrive in a different token format. A network token is provisioned through a merchant's own token requestor setup. A Click to Pay token is issued through the Click to Pay flow, tied to the shopper's profile. Both can ultimately support one-off and recurring payments; the difference is in how the token is created and managed, not what it can be used for. Different provisioning, near-identical benefit: no raw PAN, a fresh cryptogram per transaction, and the approval and security gains of tokenisation.

To learn more about how network tokens work end to end, see our guide to network tokenization.

The payload usually carries more than the payment credential. A Click to Pay profile holds the shopper's billing and shipping address, email and phone, and these can come back to the checkout alongside the token. That removes the separate address form, one more set of fields the shopper would otherwise type, and the address arrives from the profile rather than a typo-prone form, which helps delivery accuracy and address verification at authorisation. On privacy: the customer's data sits with the scheme and the issuer, shared with the merchant through the Click to Pay flow rather than from a card number you store.

The stakeholders: who does what

A card payment online is never just you and the shopper. The same cast sits behind every transaction, and Click to Pay rearranges what each one does rather than inventing a new set of players.

The pattern to take from this: the scheme runs the checkout system and the tokenisation, the issuer holds the customer relationship and the card data, and your payment service provider carries the integration and the on-page component. In the standard's own language your provider acts as the "SRC Initiator" for you, but in practice your job is to switch the experience on and present it well. You are deliberately kept away from the raw card credential and the authentication step, and that separation is exactly where the security and compliance benefits come from.

Why the schemes are pushing this so hard

Click to Pay isn't arriving on its own. The networks are driving it hard, through vision-setting, money, and outright rules. If you're deciding how seriously to take it, that pressure matters as much as the technology, because it tells you where the ecosystem is going regardless of what any single merchant does.

A stated goal to kill manual card entry

In 2024, Mastercard publicly committed to phasing out manual card entry for e-commerce in Europe by 2030, replacing it with one-click checkout built on tokenisation, Click to Pay, and payment passkeys. The company called it a win for shoppers, retailers and issuers alike, and said it would bring issuing and acquiring banks along so it happens sooner. Visa has set out a closely matching view: that Click to Pay should replace PAN key entry for e-commerce much as chip and contactless replaced the magnetic stripe in store. When the two largest networks both put a public end-date on typing in card numbers, that's a direction of travel, not a slogan.

Incentives and funded development

The schemes aren't only describing a destination. They're paying to move the market toward it.

Because Click to Pay transactions are tokenised, they can tap the existing incentives around tokenisation. Visa, for example, offers an interchange cost reduction commonly cited at 0.10% on tokenised card-not-present consumer credit transactions. That saving compounds at volume, and for large merchants it has been reported to reach six or seven figures a year. On top of the economics, the networks pour investment into the integration tooling itself: drop-in UI components, JavaScript SDKs, unified checkout interfaces, and detailed developer docs, much of it built to make the lift for a merchant or payment service provider as small as possible. The standard itself is royalty-free. So the schemes are effectively subsidising both the build and the running cost to lower the barrier to entry.

Mandates

Where incentives fall short, the networks use rules. Click to Pay is increasingly a required issuer-offered service. Visa now requires issuers across a defined list of countries and territories to provide Click to Pay both as an issuer-offered service and as a card-level feature for all eligible Visa cards.

How the card actually gets switched on splits by book. For new, renewal and replacement cards, the model is opt-out only: the issuer pre-activates Click to Pay, the card arrives already enabled, and the cardholder is told and given a clear way to opt out. For existing cards not up for renewal (the back-book), issuers must provide an activation path, and here they have a choice. They can pre-activate as they do for new cards, or they can offer cardholder-initiated activation, "opt in," or "activate and consent," where the shopper adds the card themselves.

Visa's stated preference is opt-out, but it notes that an opt-in approach may be appropriate under applicable law in some territories, and tells issuers to review the options with their legal teams. In practice that means markets with strict consent rules tend to run opt-in. Switzerland is a live example: cardholders there add their card to Click to Pay manually.

This is the single most important shift for a merchant to understand. However a given card gets enabled, Click to Pay is being made a standard feature of cards, like contactless, not a wallet a shopper has to discover and sign up for. As the base of enabled cards grows, the value of supporting it at checkout grows with it.

The "expected outcome" push

There's a subtler form of pressure too. The schemes increasingly place Click to Pay at the top of their own best-practice frameworks, tied to the outcomes merchants want most. Visa's "Vee" model ranks payment approaches from poor to best, and puts Click to Pay, alongside Visa Payment Passkey, firmly in the "best" tier: the one associated with the lowest fraud rates, approval rates of 98% and above, and the best user experience. An unauthenticated, manually keyed PAN sits in the "poor" tier, paired with high fraud and low approvals. The message isn't "you must use this." It's "here's the setup that produces the results you're chasing, and it includes Click to Pay." That pushes adoption through self-interest, which tends to work better than obligation.

Where issuers are now required to offer it

Click to Pay's value to a merchant scales with how many of their customers' cards are enabled, so the geographic reach of the issuer mandates is directly relevant. Based on a Visa issuer requirements list published on 22 June 2026, issuers must provide Visa Click to Pay as an issuer-offered service and a card-level feature for cards issued in these countries and territories:

The implication is significant. Across most of Europe, large parts of Latin America and the Caribbean, much of the Gulf, and several Southeast Asian markets, new and renewed cards are reaching customers already enabled for Click to Pay. Europe stands out: the list covers effectively the entire continent, from the EU and the Nordics to the UK, Switzerland and Iceland, which reads like a blanket, region-wide mandate.

What's absent is just as telling. Several of the world's largest card markets aren't on the list: Brazil, Mexico, the United States, Australia, Japan and India. Absence here usually doesn't mean a market is behind. It more often means a mandate isn't the right tool, either because Click to Pay is already established there (the US launched it earliest and runs under separate rules), or because local rails and regulation dominate (India's payments run largely on UPI). So read the list as "where Visa is actively pushing adoption," not "where Click to Pay exists."

Lists like this change, and each network keeps its own, so treat it as a snapshot of direction rather than a fixed fact, and confirm current scope with your scheme contacts. For a merchant serving these markets, the pool of Click-to-Pay-ready shoppers is growing with no action required from the consumer.

What's actually in it for merchants

Set the strategy aside. The question is what you get. The evidence points to four things.

Higher conversion

Cutting manual card entry shortens the checkout and removes its most error-prone step, which is exactly where mobile shoppers drop out. Providers report checkout-time reductions in the region of 40% to 50% for Click to Pay versus traditional guest flows, and a recognised shopper completes a purchase far faster than one typing card details. Fewer steps, fewer mid-flow exits, more transactions reaching authorisation.

Higher approval rates

Click to Pay transactions are tokenised, so they inherit the approval advantages of tokenisation. Issuers tend to treat tokens more favourably than raw PANs. Tokens also come with lifecycle management: when a customer's card is reissued or its expiry changes, the token updates behind the scenes, so a stored credential doesn't quietly break.

The reported uplift varies by source and region, but it's consistently positive. Visa has cited roughly a 4.3% global average authorisation lift for tokenised card-not-present transactions versus PAN transactions, and figures as high as an 11% uplift versus manual card entry have been quoted in Europe. Mastercard has reported a similar pattern, with tokenised transactions approving up to 3 to 6 percentage points higher than PAN transactions on first attempt, varying by region. Independent providers commonly see a 2 to 3 percentage point improvement on average, with bigger gains for subscription and recurring models, where automatic credential updates head off a wave of expiry-driven failures. For a high-volume merchant, a few recovered points is real money.

Lower fraud and a possible liability shift

The single-use cryptogram, plus the absence of a reusable card number in the merchant's environment, makes Click to Pay transactions harder to attack than keyed PANs. Authentication sits on top of that. Click to Pay integrates with EMV 3-D Secure and, increasingly, with biometric passkeys, and authenticated transactions can carry a liability shift, moving the cost of fraudulent chargebacks from the merchant to the issuer where the rules are met. Both Visa and Mastercard have signalled that liability protection is expanding, particularly in Europe and Asia-Pacific. Tokenisation plus authentication is precisely the combination that lands Click to Pay in the "best" tier of the schemes' own frameworks.

That distinction matters most when a dispute actually lands. On an authenticated Click to Pay transaction that qualified for the liability shift, a fraud chargeback is generally the issuer's problem, not yours. On an unauthenticated one, the protection may not apply, so the liability picture tracks whether authentication succeeded, not just whether Click to Pay was used. Even where the shift doesn't apply, the data captured during a Click to Pay checkout can help a merchant fight a dispute, supporting the evidence requirements for representment on a card-not-present transaction. The takeaway is to treat authentication as the thing that determines where fraud cost lands, and to confirm with your provider exactly which of your flows qualify.

Reduced PCI scope and data-handling burden

This one is underrated. The real card credential is captured and stored by the scheme's system and handed back to the merchant only as a token. The merchant stays out of the path of the sensitive data. That cuts both the surface a breach can hit and the share of PCI DSS that applies, because you are not the one holding and protecting the PAN. Moving card data out of your own environment is a win on its own, separate from the conversion and approval gains.

Recurring payments and the token lifecycle

For any subscription or repeat-purchase business, this section may be the real headline, bigger than the one-click checkout itself.

Stored cards rot. Cards expire, get reissued after loss or fraud, or change number entirely, and a meaningful slice of recurring payments fail for exactly that reason. Industry estimates commonly put the share of stored credentials that change each year somewhere around a quarter to a third, and expired or replaced cards are a leading cause of involuntary subscription churn. Every one of those failures is lost revenue, a "your card failed" message at the worst possible moment, and a support ticket.

Click to Pay helps here because it is built on tokenisation, and the tokens behind it come with lifecycle management. When the underlying card is reissued or its expiry changes, the issuer updates the token behind the scenes, so the credential you bill against stays current without the customer doing anything. The token reference you hold doesn't change. Only the card data underneath it does.

This works differently from the account updater services that refresh a stored PAN, Visa Account Updater and Mastercard Automatic Billing Updater, which remain the workhorse for merchants still storing raw card numbers. Token lifecycle management is the tokenised equivalent. Either way, once a card is activated for Click to Pay, renewal and replacement updates flow through these processes, so a subscription doesn't quietly break the next time a card is reissued.

One nuance worth flagging. Click to Pay's fast, recognised checkout is customer-initiated. The recurring charges that follow run on a stored token held on your behalf, not the Click to Pay checkout itself, under the usual stored-credential and merchant-initiated-transaction rules. So the value for a subscription business is less about the click and more about the durable, self-updating credential behind it.

How customers get enrolled

Worth understanding the routes in, because they shape how many of your customers arrive already enabled. A card can be activated by the issuer, increasingly as a default card feature under the mandates covered above, so it shows up in Click to Pay without the customer lifting a finger. A customer can also provision a card themselves from inside their banking app. And a card can be enrolled at checkout, when a shopper adds one that wasn't pre-activated. The direction of travel is clear: issuer-side activation is becoming the norm, which is why the enabled base grows on its own.

How merchants integrate

There's no single "install Click to Pay" button. The networks offer several routes, from direct APIs to drop-in SDKs, and both Visa and Mastercard provide unified, multi-brand options. But for most merchants the common approach is a prebuilt UI component: a drop-in widget your payment service provider provides and you embed in your checkout. It renders Click to Pay natively on your payment page, usually alongside manual card entry and the digital wallets, so one integration covers several methods instead of one build per method, without the redirects that historically hurt conversion.

The merchant-side flow is short. Your server opens a payment session, the component mounts and takes over, recognising the shopper or looking them up by email, showing their Click to Pay cards or a card form, and running authentication (your own, or delegated to Click to Pay, with a fallback to the card form when needed). It returns a token and, for a Click to Pay payment, the one-time cryptogram to forward for authorisation. Because card details are captured in the provider's secure fields rather than on your page, a component like this also tends to keep you at the lightest PCI scope, SAQ A.

So the realistic starting point is your existing payment service provider, which usually supplies the component. The work is mostly switching Click to Pay on, configuring it, and styling the component to match your checkout, rather than building against the raw network APIs yourself.

One piece of setup sits behind that. To accept Click to Pay, your storefront is onboarded as a Digital Payment Application, which produces a DPA ID that identifies you to the Click to Pay system. It is the same shape of step as tokenisation, where a merchant is registered as a token requestor and issued a Token Requestor ID (TRID). Your payment service provider usually handles the registration and holds the identifier behind the integration, so it is rarely something you manage by hand, though it is worth knowing it exists, particularly if you work across more than one provider.

What does it cost a merchant?

A fair question, and one most explainers skip. Click to Pay is not a separate wallet with its own cut, the way a third-party network like PayPal sits outside the card rails and prices its own transactions.

A Click to Pay payment is a card payment. It settles to your normal acquirer and carries your standard interchange and processing costs, the same as if the customer had typed the card in. American Express, for example, states plainly that it charges merchants no fee to integrate Click to Pay and that using it doesn't change the merchant rate. The other networks treat it the same way: standard card economics, not a wallet surcharge.

If anything, the direction on cost is downward. Because Click to Pay transactions are tokenised, they can qualify for the tokenisation incentives the networks already offer, such as Visa's interchange reduction on tokenised card-not-present consumer credit transactions. Fewer false declines and fewer fraud chargebacks pull in the same direction. The cost that does exist is integration and maintenance effort, and how much depends entirely on your provider: a no-code toggle on a hosted payment page at one end, a full API build at the other. That, not a per-transaction wallet fee, is the real budget line.

The authentication shift: passkeys and biometrics

A second wave is layering onto Click to Pay, and it's central to the 2030 plan. Both Visa and Mastercard are folding payment passkeys into the experience: the FIDO-standard, on-device biometric authentication, fingerprint or facial recognition, that people already use to unlock their phones.

The goal is to replace high-friction, failure-prone methods like SMS one-time passcodes with the same biometric gesture a shopper makes dozens of times a day. After a successful authenticated checkout, the shopper can be offered the chance to register a passkey on their device. On later purchases with that card on that device, they just confirm with a fingerprint or their face. The cryptographic proof binds to the device and the payment credential, the issuer keeps full control of the authentication decision, and the experience gets both stronger and smoother than a typed code.

For a merchant, the relevance is direct. Passkey-backed Click to Pay is what produces the lowest-fraud, highest-approval, best-experience combination the schemes keep pointing at. It's the mechanism that turns strong authentication from a tax on conversion into something close to invisible.

The "good, better, best" view of e-commerce payments, following the framework Visa sets out in its Vee model. As the method moves from an unauthenticated card number toward an authenticated token, fraud falls and approvals climb. Click to Pay paired with a payment passkey sits at the top.

This connects directly to European rules. Under PSD2, most online card payments in Europe need strong customer authentication, meaning two independent factors from the categories of something you have, something you are, and something you know. A passkey covers that cleanly: the device is the possession factor, the fingerprint or face is the inherence factor. So a passkey-authenticated Click to Pay payment is a strong-authentication payment, not a friction tax bolted on top of one. The regime still allows exemptions, for low-value payments and through transaction risk analysis on low-risk ones, and Click to Pay sits alongside that exemption logic rather than replacing it. The point for a European merchant is that the authentication you're already required to perform can be the same gesture that makes checkout faster, instead of the SMS one-time-code dance that drives abandonment.

Click to Pay versus Apple Pay, Google Pay and proprietary wallets

Click to Pay doesn't compete with the wallets you may already support. It fills a gap they leave.

Apple Pay and Google Pay are good, but they're tied to their ecosystems. Apple Pay needs Apple hardware. Google Pay leans on Android and Chrome. A shopper on a Windows laptop in a non-Apple browser can't use Apple Pay at all. Click to Pay is built to be device-agnostic and browser-agnostic: it works across operating systems, browsers and devices, and it's scheme-neutral, presenting Visa, Mastercard, American Express and Discover cards through one interface. It also skips the third-party intermediary model of something like PayPal. The shopper isn't handing data to a new party or opening a new account that charges its own fees. They're connecting to credentials their existing issuer already holds.

In practice, a good checkout runs several of these in parallel: Apple Pay and Google Pay for shoppers inside those ecosystems, and Click to Pay as the universal, card-based option that catches everyone else, including the large desktop and cross-platform crowd that device wallets miss. Many tokenisation and payment-infrastructure providers can normalise all of them, converting a wallet-specific token back to the underlying card credential and re-tokenising it, so the merchant ends up with one consistent token format no matter how the shopper chose to pay.

What to weigh before you adopt

Click to Pay is a strong move. Go in with the trade-offs in view.

Adoption is still maturing. The base of enabled cards is climbing fast thanks to the issuer mandates, but consumer recognition of the icon, and the habit of using it, is still building and varies by market. Early on, expect a mix of recognised users who breeze through and new users who go through a short enrolment. That said, the appetite looks real: in the card networks' own consumer studies from 2023 and 2024, most shoppers grasped Click to Pay quickly once shown it, and majorities said they would prefer it to hunting for a card and typing the details. Treat vendor surveys with the usual caution, but the pattern points to the gap being familiarity, not willingness.

The customer relationship and the data sit with the scheme and the issuer, not with you. That's the source of the PCI and security benefit. It also means you don't own the Click to Pay profile or control its lifecycle. Issuers handle enrolment, updates and opt-outs. Plan your customer-service and support flows around that, and be clear with shoppers about what's happening.

Authentication and liability rules differ by region. Europe's strong customer authentication requirements shape how and when step-up authentication fires, and liability-shift eligibility isn't universal. Confirm with your payment service provider exactly which of your transactions qualify for protection.

Integration choices have downstream effects. A quick, redirect-based setup is fastest to stand up but can cost conversion, while rendering Click to Pay natively inside your own checkout takes more effort and keeps shoppers on your page. Pick the balance that matches how much you care about controlling the experience versus shipping fast.

Where this is heading

Step back and the trajectory is clear. The networks have set a public goal of removing manual card entry from e-commerce. They're mandating Click to Pay as a standard card feature across a widening list of markets. They're subsidising the integration and rewarding tokenised transactions. And they're folding biometric passkeys into the flow to make strong authentication nearly frictionless. Whether or not any single merchant moves now, the environment is being rebuilt around tokenised, authenticated, identity-linked checkout, and the typed-in card number is being engineered toward the exit.

That changes the decision in front of you. The question isn't really "should I add another checkout button." It's whether you want to sit where the whole card ecosystem is heading and capture the conversion, approval and fraud benefits early, or wait until it's simply the default. Click to Pay is not a silver bullet. It sits alongside device wallets, tokenisation, and good checkout design, not instead of them. But as a way to bring the speed and security of a contactless tap to online payments while moving sensitive card data out of your environment, it's one of the most consequential shifts in e-commerce payments in a decade. Understanding it now is how you stay ahead of it.