What Is Secure Remote Commerce (SRC)?

Secure Remote Commerce (SRC) is the EMVCo specification that defines how online card payments work without the shopper having to type their card number into every merchant's checkout form. SRC describes the roles, the message flows, the authentication signals and the data formats that let any participating network share enrolment and tokenise card data on the way to a merchant. Click to Pay is the shopper-facing brand built on top of SRC — the button, the user experience, the marketing. SRC is the technical layer underneath, owned and published by EMVCo (the same standards body that gave the world chip-and-PIN). For most shoppers, the distinction doesn't matter. For merchants, gateway engineers and acquirers, it matters quite a lot.

The short version: SRC is the spec, Click to Pay is the product. EMVCo wrote the SRC specification so that every card network would implement online checkout the same way. The four big networks — Visa, Mastercard, American Express and Discover — each run their own SRC System but they all conform to the same EMVCo rules, and they share enrolment status with each other so a shopper doesn't have to enrol the same card four times. If you've been searching for "what is SRC payments" and the answers all just say "it's Click to Pay", that's not wrong, but it skips the part that explains why the button looks the same on a Mastercard site and a Visa site, and why the data flowing under the hood is consistent across networks.

The Roles SRC Defines

SRC describes a small ecosystem of named roles. Once you've got these straight, the rest of the spec falls into place.

The SRC System is the central operator — one per network. Visa runs an SRC System, Mastercard runs one, Amex and Discover the same. The SRC System holds the enrolled cards, runs the authentication checks, and issues network tokens to merchants.

The SRC Initiator is the merchant's checkout (or the merchant's payment service provider acting on its behalf). It's the thing on the merchant's site that calls into the SRC System and says "this shopper wants to pay, here's their email, give me the available cards".

The Digital Card Facilitator (DCF) is the UI piece that handles the shopper's interaction — the email entry box, the one-time-code prompt, the card-selection screen. It can be hosted by the SRC System or embedded in the merchant's page. Either way, the DCF is what the shopper actually touches.

And the Payment Account is the shopper's enrolled card. SRC doesn't really care whether that's a debit card, a credit card or a prepaid card — it just needs a token-issuing PAN behind it.

SRC vs Click to Pay

This is the question most people land on this page wanting answered. The cleanest way to put it:

SRC is the standard. Click to Pay is the brand.

EMVCo publishes the SRC specification. Anyone implementing online checkout in compliance with it follows that spec. The four card networks all implement SRC under the shared Click to Pay brand and the shared four-bird logo. So from the shopper's point of view there's one consumer-facing product: Click to Pay. From the merchant's integration point of view, what they're actually integrating against is the SRC API (usually wrapped by their gateway), and the spec they should read if they want to understand what's happening is the EMVCo SRC specification, not any individual network's marketing page.

Other brands using SRC exist, particularly in regions where the four global networks aren't dominant — domestic networks in some markets have built their own SRC-compliant checkout buttons. But globally, Click to Pay is by far the dominant SRC brand.

How the Data Flow Works

Here's what happens when a shopper clicks the Click to Pay button on a merchant's checkout, in SRC terms.

The merchant's site (the SRC Initiator) calls the SRC System and identifies the shopper, usually by email address. The SRC System checks whether that email has any enrolled cards across the networks. If it does, it returns a recognition signal to the merchant. The DCF then opens — either as an overlay on the merchant's page or as a popup hosted by the SRC System — and the shopper authenticates. That might be a one-time code by email, a passkey on supported browsers, or in some markets a 3D Secure step inside the same flow.

Once the shopper is authenticated, they pick a card from the list of enrolled options. The SRC System then issues a network token for that card, scoped to that merchant, plus a one-off cryptogram. The merchant receives the token and the cryptogram — not the real PAN — and submits the standard authorisation request to its payment gateway with the token in place of the card number. The issuer's authorisation system de-tokenises on the way in, runs its usual checks, and approves or declines.

The data that touched the merchant: an email address, an enrolment confirmation, a network token, a cryptogram. The data that didn't touch the merchant: the real card number.

Why SRC Matters for Merchants and PSPs

The most important practical consequence of SRC is the same as for Click to Pay — the merchant doesn't handle the PAN. From a PCI DSS point of view, a merchant integrating SRC through its PSP is in the same category as one using a fully hosted payment page or tokenisation: card data flows through the network, not the merchant. That's an SAQ A-level burden rather than a full SAQ D.

The second consequence is on authorisation rates. Issuers see SRC transactions as authenticated and tokenised, so the risk signals coming in with the auth request are richer. In practice, that produces a small but consistent uplift in approval rates compared with raw-PAN e-commerce — Visa and Mastercard both publish figures in the 2-4% range, depending on geography and basket.

And the third — relevant if you're building a checkout — is that integrating against SRC once gets you all four networks at once, instead of building four separate single-network integrations the way merchants used to with Visa Checkout, Masterpass and Amex Express Checkout. That convergence is the reason SRC exists at all.

What SRC Doesn't Do

SRC isn't a payment scheme in its own right. It doesn't replace Visa or Mastercard — it sits on top of them. Once the merchant has the network token, the authorisation still flows through the normal four-party model (cardholder, merchant, acquirer, issuer). SRC also doesn't replace 3D Secure — where SCA rules apply, 3DS is layered into the SRC flow rather than bypassed. And SRC isn't a wallet in the Apple Pay sense; it's a browser-based checkout standard, not a device-bound credential.

Where to Read the Spec

EMVCo publishes the SRC specification at emvco.com. The current version at time of writing is SRC 1.3, which sets out the message formats, the cryptographic requirements and the certification programme. Most merchants will never need to read it directly — gateway providers and PSPs have done the work — but if you're building a checkout from first principles, or building an SRC Initiator yourself, that's where to start.