Category: Transaction Processing

EMV Secure Remote Commerce

Also known as: SRC, Secure Remote Commerce, EMV SRC, Click to Pay

Simply put

EMV Secure Remote Commerce (SRC) is a set of specifications developed by EMVCo that is intended to make online and in-app checkout more consistent and convenient for shoppers and merchants. It acts like a virtual payment terminal that can work across websites and apps, and it is sometimes offered to consumers under the 'Click to Pay' brand. It is designed to help make remote card payments easier to complete without merchants and consumers having to re-enter card details for each transaction.

Formal definition

EMV Secure Remote Commerce (SRC) is an EMVCo specification framework that defines an interoperable approach for card-based remote (card-not-present) payments across websites, apps, and multiple device types, providing what the specifications describe as a virtual payment terminal for online checkout. EMVCo updated the SRC Specifications (announced January 2023) to support more flexible online checkout options for merchants and consumers. SRC is a specification framework maintained by EMVCo and is distinct from PCI DSS and from other EMVCo work such as EMV 3-D Secure; the consumer-facing implementation is often branded 'Click to Pay.' The evidence provided describes SRC's purpose and scope qualitatively and does not establish specific security control details, fraud-reduction figures, or its effect on PCI DSS scope, which would depend on the specific implementation and validation.

Why it matters

Card-not-present checkout has long been fragmented, with each merchant, website, and app collecting and handling card details in its own way. This inconsistency creates friction for consumers, who must re-enter card data across many sites, and it complicates the payment experience for merchants. EMV Secure Remote Commerce (SRC) matters because it offers an EMVCo-maintained specification framework intended to make online and in-app checkout more consistent, convenient, and interoperable across websites, apps, and device types, functioning as what the specifications describe as a virtual payment terminal.

Because SRC is an interoperable specification rather than a single proprietary product, it is designed to work across multiple channels and devices, and the consumer-facing implementation is often presented under the 'Click to Pay' brand. EMVCo announced updates to the SRC Specifications in January 2023 to support more flexible online checkout options for merchants and consumers, reflecting ongoing evolution of the framework rather than a fixed, static specification.

SRC should not be read as a standalone security guarantee. The evidence provided describes SRC's purpose and scope qualitatively but does not establish specific security control details, fraud-reduction figures, or its effect on PCI DSS scope. Any effect on PCI DSS scope, and any fraud or chargeback outcomes, would depend on the specific implementation and its validation, and on separate card brand and network rules that vary by region and change over time. SRC is distinct from PCI DSS and from other EMVCo work such as EMV 3-D Secure, and it is not a substitute for those.

Who it's relevant to

E-commerce and in-app merchants

Merchants building or maintaining online and in-app checkout flows are the primary audience for SRC, since the framework is designed to offer a more consistent and interoperable checkout experience across websites and apps and to reduce the need for consumers to re-enter card details. Merchants should assess how a specific SRC or 'Click to Pay' implementation fits their existing checkout and what, if any, effect it has on their PCI DSS scope based on implementation and validation, not on the label alone.

Payment processors and gateways

Processors and gateways that integrate remote payment acceptance need to understand SRC as an EMVCo specification framework distinct from PCI DSS and EMV 3-D Secure. They are relevant parties for implementing the interoperable, multi-device, multi-channel checkout approach the specifications describe, and for tracking specification updates such as the January 2023 changes.

Compliance officers and PCI DSS assessors

Those responsible for compliance should note that SRC is separate from PCI DSS, and that the evidence available does not establish SRC's effect on PCI DSS scope. Any scoping impact depends on the specific implementation and its validation, so assessors should confirm control details against the current published SRC specifications and the applicable PCI standards rather than assuming outcomes from the SRC name or the 'Click to Pay' brand.

Fraud and risk analysts

Fraud and merchant risk teams may encounter SRC and 'Click to Pay' in card-not-present transaction flows. Because the evidence provided does not establish fraud-reduction figures or specific security controls for SRC, analysts should treat any fraud or chargeback outcomes as dependent on implementation, on separate card brand and network rules that vary by region, and on their own measured results rather than on the framework's stated convenience or security goals.

Inside SRC

SRC Specification

EMV Secure Remote Commerce is a set of specifications published by EMVCo that defines a common framework for processing e-commerce transactions across participating card networks, aiming to standardize the checkout experience in card-not-present environments.

SRC System and Roles

The framework defines roles such as the SRC System, SRC Initiator, Digital Card Facilitator, and participating card networks, which together coordinate how payment data is captured, exchanged, and routed during a remote transaction.

Digital Card / Tokenized Credential

SRC is often implemented alongside network tokenization so that a merchant may receive a token rather than the underlying PAN. Tokenization and SRC are distinct concepts; the effect of any token on PCI DSS scope depends on the specific implementation and validation, not on the SRC label alone.

Checkout Experience

SRC is intended to provide a consistent, recognizable checkout interaction across supported networks, reducing the need for consumers to manually enter card data at each merchant.

Relationship to Authentication Standards

SRC addresses how remote commerce data is exchanged and is separate from EMV 3-D Secure, which addresses cardholder authentication. They may be used together but govern different parts of a transaction and should not be conflated.

Cardholder Data Handling

SRC transactions involve cardholder data such as the PAN, cardholder name, and expiration date. Sensitive authentication data, including CAV2/CVC2/CVV2/CID and any full track or equivalent data, must not be stored after authorization even when encrypted, regardless of the SRC framework being used.

Common questions

Answers to the questions practitioners most commonly ask about SRC.

Does EMV Secure Remote Commerce make an online transaction as secure as an EMV chip transaction at a physical terminal?

No. EMV SRC and EMV chip authentication address different environments and risks. EMV chip authentication is a card-present control that uses cryptographic data generated by the chip during a face-to-face transaction. SRC is a framework intended to standardize how card data is captured, transmitted, and represented in card-not-present e-commerce checkout. The two operate at different points in the transaction and are not equivalent. Using SRC does not convert a card-not-present transaction into a card-present one, and it does not by itself provide the cardholder verification that EMV chip authentication provides.

Is EMV Secure Remote Commerce the same thing as 3-D Secure, or does one replace the other?

No, they are distinct and address different functions. SRC is intended to standardize the checkout and card data exchange experience across participating merchants and networks. 3-D Secure is a separate protocol focused on authenticating the cardholder during a card-not-present transaction and can support liability shift under applicable card brand and network rules. They can be used together in an implementation, but SRC does not perform the cardholder authentication role that 3-D Secure addresses, and 3-D Secure does not provide the standardized checkout data exchange that SRC addresses. Neither replaces the other, and neither eliminates fraud on its own.

How does implementing EMV SRC affect my PCI DSS scope?

The effect on PCI DSS scope depends on the specific implementation and how account data is captured, transmitted, processed, or stored in your environment, not on the SRC label alone. Whether card data traverses or is accessible to your systems determines applicability of PCI DSS requirements. You should assess your integration model, data flows, and any hosted or redirected components with your assessor, and confirm requirements against the current published PCI DSS standard rather than assuming a fixed outcome.

Where does SRC fit relative to tokenization in a checkout implementation?

SRC is a checkout and data-exchange framework, while tokenization is a technique that substitutes card data with a token. They are separate concepts that may be used together in an implementation. Tokenization can transform how card data is represented within your systems, and its effect on PCI DSS scope depends on implementation and validation, not on the label. When planning an SRC integration, determine whether tokens or actual account data are handled at each point in the flow, since that distinction affects both data handling controls and scope.

What should I confirm about handling sensitive authentication data in an SRC integration?

Regardless of the checkout framework, sensitive authentication data such as full track data, card verification values (CAV2/CVC2/CVV2/CID), and PINs or PIN blocks must not be stored after authorization, even when encrypted. Cardholder data such as the PAN may be stored only under defined controls. In an SRC integration, review the data flows to identify which fields your environment receives or retains and ensure no prohibited sensitive authentication data is stored post-authorization. Validate handling against the current published PCI DSS standard.

Does adopting SRC by itself reduce card-not-present fraud or shift chargeback liability?

SRC is intended to standardize the checkout data exchange and may improve consistency of the checkout experience, but by itself it does not authenticate the cardholder and should not be treated as a control that prevents card-not-present fraud. Liability shift and chargeback outcomes are governed by card brand and network rules, which vary by region and change over time; those outcomes are typically associated with specific authentication protocols and program rules rather than with SRC alone. Confirm any liability treatment against the applicable network rules for your region and time period.

Common misconceptions

EMV SRC is the same technology as EMV chip authentication because both carry the EMV name.

EMV chip authentication addresses card-present transactions using a physical chip, while SRC is a specification for card-not-present, remote commerce checkout. They are separate EMVCo specifications addressing different transaction environments and risks.

Adopting SRC removes a merchant's PCI DSS obligations or automatically takes the environment out of scope.

SRC may change how and where cardholder data flows, and when combined with tokenization it can reduce exposure to PAN. However, any reduction in PCI DSS scope depends on the specific implementation, data handling, and validation, and must be confirmed against the current PCI DSS rather than assumed from the use of SRC.

SRC authenticates the cardholder and therefore eliminates card-not-present fraud.

SRC standardizes the remote checkout and data exchange; it is not a cardholder authentication mechanism. Authentication is addressed by separate controls such as EMV 3-D Secure and strong customer authentication. No single control eliminates fraud, and card-not-present fraud, account takeover, and first-party fraud remain possible.

Best practices

Confirm the specific SRC implementation and any associated tokenization design, then assess and document the resulting PCI DSS scope against the current published standard rather than assuming scope reduction from the SRC label.

Do not store sensitive authentication data such as CAV2/CVC2/CVV2/CID or full track-equivalent data after authorization, even when encrypted, regardless of the SRC framework in use.

Treat SRC and cardholder authentication as separate concerns, and evaluate whether to pair SRC with EMV 3-D Secure or strong customer authentication where those controls are appropriate for the risk and region.

Verify how cardholder data and any tokens are transmitted, handled, and retained across each SRC role and system boundary, and apply appropriate controls to each point where data is present.

Layer fraud detection and monitoring for card-not-present risks such as account takeover and first-party fraud, recognizing that detection controls involve false-positive and false-negative trade-offs and that SRC alone does not address these threats.

Confirm liability shift and chargeback treatment with the applicable card brand and network rules for each supported network and region, since those rules vary and change over time.