Secure Remote Commerce (SRC)

What Is Secure Remote Commerce?

Secure Remote Commerce (SRC) is a set of technical specifications published by EMVCo that defines how online card payments should work across websites, mobile apps, and connected devices. It provides the standardized architecture, APIs, and security requirements that power the consumer-facing brand known as Click to Pay.

Before SRC, each card network ran its own online checkout product: Visa had Visa Checkout, Mastercard had Masterpass, and American Express had Amex Express Checkout. None gained significant adoption because merchants had to integrate each one separately, and consumers faced inconsistent experiences across networks. SRC solved this by defining a single interoperable standard that all networks implement, so one enrollment and one checkout flow work everywhere.

EMVCo released the first SRC specification (v1.0) in June 2019. The standard has evolved through several versions: v1.3 (January 2023) introduced a merchant-orchestrated checkout model and expanded authentication options, v1.5 (October 2025) added passkey support via FIDO, and v1.6 entered public comment in July 2026.

How It Works

The SRC framework defines five principal roles that coordinate during checkout. Understanding these roles clarifies how a payment flows from the consumer's browser to the issuing bank.

Architecture Components

• SRC System (SRC-S): the central orchestration engine operated by each card network. It coordinates the flow between all participants, manages consumer profiles, and interfaces with the network's tokenization platform to generate secure payment data.
• SRC Initiator (SRC-I): a software component integrated into the merchant's checkout page, typically provided by the acquirer or payment processor. It triggers the Click to Pay experience, retrieves digital card data, and transmits information between the DCF and the merchant.
• Digital Card Facilitator (DCF): the entity that provides the consumer-facing interface for card storage and selection. It stores enrolled cards along with billing and shipping addresses, handles user recognition, and manages cardholder verification.
• SRC Participating Issuer (SRC-PI): the card-issuing bank that enrolls cardholders into the SRC system, identifies eligible accounts, and sets preferences for authentication methods.
• Digital Payment Application (DPA): the consumer-facing interface (merchant website, mobile app, or IoT device) where the shopper initiates checkout by invoking the SRC Initiator SDK.

Checkout Flow

A typical SRC-powered checkout proceeds through these steps:

1. The consumer reaches the merchant's payment page. The SRC Initiator SDK loads and checks whether the consumer is recognized (via device fingerprint or stored cookie).
2. If recognized, the DCF displays the consumer's enrolled cards without requiring manual entry. If not recognized, the consumer enters an email or phone number to look up their SRC profile.
3. The consumer selects a card and confirms. The SRC System applies risk-based authentication to determine the verification method: automatic recognition for low-risk transactions, OTP or passkey for moderate risk, or full 3D Secure authentication for high-risk scenarios.
4. Once verified, the SRC System generates a network token and a transaction-specific cryptogram. The merchant receives these instead of the actual card number (PAN).
5. The merchant submits the token and cryptogram to their acquirer. During authorization, the network's Token Service Provider de-tokenizes the token back to the PAN for routing to the issuer, which authorizes based on the actual account.

Security Model

SRC's security architecture layers several mechanisms to reduce card-not-present fraud:

• Dynamic cryptograms: each transaction generates a unique cryptogram transmitted alongside the token. Intercepted data cannot be replayed in a subsequent transaction.
• Token domain controls: the Token Service Provider restricts each token to specific presentment modes (e-commerce only), specific merchants, or specific devices. A token compromised in one context is useless in another.
• Device binding: when a consumer transacts from a device, the SRC System captures device information and binds it to the consumer's profile. Recognized devices can bypass manual verification steps.
• Layered authentication: the system selects from OTP, EMV 3D Secure, FIDO passkeys, Secure Payment Confirmation (SPC), or card security code verification based on risk signals including device recognition, transaction history, and issuer preferences.

The combination of tokenization and dynamic data means merchants compliant with PCI DSS face a significantly reduced scope: they never handle or store actual card numbers.

SRC and 3D Secure

SRC and 3D Secure are complementary rather than competing technologies. The SRC system can perform 3DS authentication on behalf of the merchant, meaning merchants integrating Click to Pay do not need a separate 3DS integration. When 3DS runs within the SRC flow, the checkout response includes the ECI (Electronic Commerce Indicator) value and dynamic data needed for the authorization request, enabling chargeback liability shift to the issuer.

API Integration

Merchants integrate SRC through a JavaScript SDK that the SRC Initiator provides. A simplified integration flow looks like this:

// Initialize the SRC Initiator SDK
const srci = await SrcInitiator.init({
  srcSystemId: "VISA_SRC",
  merchantId: "merchant-12345",
  dpaId: "dpa-67890"
});

// Check if consumer is recognized on this device
const recognition = await srci.identifyConsumer({
  type: "DEVICE"
});

// If recognized, retrieve enrolled cards
if (recognition.recognized) {
  const cards = await srci.getCards();
  // Display card selector to consumer
}

// After consumer selects card and authenticates
const checkoutResult = await srci.checkout({
  cardId: selectedCard.id,
  amount: 49.99,
  currency: "USD"
});

// checkoutResult contains:
// - paymentToken (network token, not the PAN)
// - cryptogram (transaction-specific dynamic data)
// - eciIndicator (if 3DS was performed)

Use Cases

Unified E-Commerce Checkout

The primary use case for SRC is simplifying online checkout. Instead of consumers typing 16-digit card numbers, expiration dates, and CVVs on every new merchant site, Click to Pay presents their enrolled cards with one-click selection. This reduces cart abandonment: Visa reports that tokenized transactions see a 4-6% uplift in authorization rates compared to raw PAN transactions.

Cross-Network Interoperability

A consumer who enrolls a Visa card through one merchant's Click to Pay flow is automatically recognized at any other SRC-enabled merchant, even when paying with a Mastercard or Amex card enrolled separately. The SRC systems share enrollment status cross-network, creating a unified identity layer across the four-party model.

Mobile and IoT Payments

SRC extends beyond traditional web checkout. The specification supports in-app payments, connected device transactions, and emerging use cases like EV charging via ISO 15118 Plug and Charge. As the specification evolves, it aims to cover any remote payment context where a physical card is not present.

Merchant-Orchestrated Checkout

Introduced in SRC v1.3, the merchant-orchestrated model lets merchants with existing authentication relationships manage more of the checkout flow directly. This is useful for large merchants and payment orchestration platforms that want tighter control over the user experience while still leveraging SRC's tokenization and security infrastructure.

Adoption and Industry Impact

Mastercard announced in June 2024 that it plans to phase out manual card entry for e-commerce by 2030, starting with Europe. The strategy rests on three pillars: tokenization, Click to Pay, and payment passkeys. As of mid-2025, nearly 50% of Mastercard e-commerce transactions in Europe are tokenized (up over one-third year-over-year), and Click to Pay has expanded to 26 European markets with enrollments more than doubling.

Visa reports that its tokenized transactions show a 28% average reduction in fraud compared to raw PAN transactions, with over 10 billion tokens issued. These statistics reflect the broader network tokenization ecosystem that SRC builds upon, and they demonstrate why the card networks are investing heavily in the standard.

The FIDO Alliance launched a Payments Working Group to create formal recommendations for integrating FIDO authentication with SRC, reflecting the industry's direction toward passwordless checkout using passkeys.

Why It Matters for Payments

SRC represents the card networks' answer to the friction and fraud challenges that have plagued card-not-present transactions since the early days of e-commerce. By tokenizing credentials, binding devices, and layering authentication, it aims to make online card payments as secure as EMV chip transactions reduced fraud at the point of sale.

For merchants, SRC reduces PCI DSS compliance scope (no raw PANs to store), improves authorization rates through tokenization, and lowers chargeback rates through stronger authentication. For consumers, it eliminates repetitive card entry across merchants.

The broader trend SRC reflects is the shift away from static credentials toward dynamic, context-aware payment data. This same principle drives innovation in alternative payment rails: stablecoin networks and Bitcoin Layer 2 protocols like Spark use cryptographic proofs and unique transaction data rather than reusable account numbers, achieving similar fraud resistance through fundamentally different architecture. As fraud prevention in digital payments evolves, the convergence around dynamic credentials spans both traditional card networks and emerging crypto payment infrastructure.

Risks and Considerations

Centralized Infrastructure

SRC depends on the card networks' infrastructure to operate. Each network runs its own SRC System as a centralized service. If a network's SRC System experiences an outage, Click to Pay functionality for that network's cards becomes unavailable. This contrasts with decentralized payment protocols where no single point of failure exists.

Adoption Fragmentation

While SRC was designed for interoperability, merchant adoption remains uneven. Not all payment gateways and acquirers support the SRC Initiator SDK, meaning Click to Pay is unavailable at many merchants. Consumers who enroll may find the experience inconsistent: seamless at one merchant, absent at the next.

Privacy Considerations

Device binding and consumer recognition require storing persistent identifiers (cookies, device fingerprints) that track users across merchants. While this enables the convenience of automatic recognition, it also creates a cross-merchant identity layer controlled by the card networks. Consumers concerned about tracking should understand that SRC profiles aggregate their shopping activity across all participating merchants.

Competing Standards

SRC exists alongside other checkout simplification efforts: Apple Pay and Google Pay offer similar one-click experiences with their own tokenization, browser-native Payment Request API provides a standards-based approach, and Strong Customer Authentication requirements in Europe add regulatory complexity. Merchants must evaluate where SRC fits within their broader payment orchestration strategy.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.