Category: Payment Ecosystem

Click to Pay

Also known as: Secure Remote Commerce, SRC

Simply put

Click to Pay is an online checkout method that lets shoppers pay without manually typing their card details each time. After a customer links a card and signs in (for example, with an email address or mobile number), they can complete purchases across participating websites, apps, and other digital channels in just a few clicks. It is intended to make card-not-present checkout faster and more consistent, similar to how contactless works for in-store payments.

Formal definition

Click to Pay is a standardized card-not-present checkout method that provides a common, streamlined online payment experience across participating merchants and digital channels. Consumers enroll their card credentials and authenticate (typically via an email address or mobile identifier) so that card details do not need to be re-keyed at each merchant checkout. It is positioned by card brands and processors as a secure, user-friendly alternative to manual card entry for online transactions. Note that the specific data handling, credential storage, and authentication mechanisms underlying a given Click to Pay implementation determine its security properties and any effect on PCI DSS scope; those details are not established by the evidence provided here and should be confirmed against the relevant implementation and applicable standards. Click to Pay is a checkout method and should not be assumed to be equivalent to or a replacement for cardholder authentication controls such as 3-D Secure.

Why it matters

Card-not-present checkout has long been a source of both friction and fraud risk. Manual entry of card details at every merchant slows conversion, encourages inconsistent checkout experiences, and can expose card data to more points of handling. Click to Pay, built on the Secure Remote Commerce (SRC) framework and positioned by card brands and processors as a streamlined alternative to manual card entry, aims to make online checkout faster and more consistent across participating websites, apps, and other digital channels, much as contactless standardized the in-store tap experience.

For security and compliance teams, the important point is that Click to Pay is a checkout method, not a cardholder authentication control. Its security properties depend entirely on how a given implementation handles credential storage, data flows, and authentication. Whether and how it changes PCI DSS scope is determined by the specific implementation and the applicable standards, not by the Click to Pay label itself. Those details are not established by the evidence available here and should be confirmed against the relevant implementation and current published standards.

Because Click to Pay addresses the convenience and consistency of card-not-present checkout rather than the verification of cardholder identity, it should not be assumed to be equivalent to or a replacement for authentication mechanisms such as 3-D Secure. Teams evaluating Click to Pay should treat questions of fraud liability, authentication, and scope reduction as separate matters that require their own analysis rather than assuming they are addressed by adopting the checkout method.

Who it's relevant to

Merchants and e-commerce teams

Merchants evaluating Click to Pay are typically weighing a faster, more consistent card-not-present checkout against integration and operational considerations. Because the checkout method's effect on data handling and PCI DSS scope depends on the specific implementation, merchant teams should confirm those details against the chosen implementation and applicable standards rather than assuming scope reduction from the label alone.

Payment processors and acquirers

Processors and acquirers that offer or support Click to Pay need to understand how a given implementation manages credential enrollment, storage, and authentication, and how those flows interact with their existing controls. They should be prepared to advise merchants that Click to Pay is a checkout method and not a substitute for cardholder authentication controls such as 3-D Secure.

Compliance officers

Compliance teams should treat any PCI DSS scope impact of Click to Pay as implementation-dependent and confirm it against the current published standard and the specific deployment. The distinction between cardholder data handling, credential storage, and authentication should be assessed separately for each implementation rather than inferred from the Click to Pay name.

Fraud and risk analysts

Fraud teams should note that Click to Pay streamlines checkout convenience and consistency but does not by itself verify cardholder identity. Questions of card-not-present fraud exposure, authentication, and liability shift are governed separately, including by card brand and network rules that vary by region, and should be analyzed independently of the checkout method.

Inside Click to Pay

EMV Secure Remote Commerce (SRC) foundation

Click to Pay is the consumer-facing implementation built on the EMVCo Secure Remote Commerce specifications, which define a common framework for card-not-present checkout across participating card brands. The branding is a customer experience layer over the underlying SRC infrastructure.

SRC System and participating roles

The ecosystem includes SRC Initiators (typically the merchant or its provider), one or more SRC Systems operated by participating card networks, and Digital Card Facilitators. These roles handle enrollment, storage of card profiles, and delivery of transaction credentials at checkout.

Stored card profile and consumer recognition

Enrolled cardholder data such as PAN and expiration date is held within the SRC System rather than by individual merchants, and the consumer may be recognized across participating sites to avoid re-entering full card details.

Payload delivered to the merchant

Rather than the merchant capturing raw card entry, Click to Pay is intended to supply the merchant or its processor with a payment payload for authorization. Depending on implementation, this may involve a network token or other credential in place of the underlying PAN; the exact data returned depends on the SRC System and merchant integration.

Relationship to authentication controls

Click to Pay is a checkout and credential-delivery experience. It is distinct from cardholder authentication mechanisms such as 3-D Secure, which addresses authentication of the cardholder for card-not-present transactions. Whether a given transaction invokes 3-D Secure depends on the implementation and applicable network rules.

Common questions

Answers to the questions practitioners most commonly ask about Click to Pay.

Is Click to Pay the same thing as 3-D Secure?

No. Click to Pay is a checkout experience based on the EMV Secure Remote Commerce (SRC) specification that streamlines how a consumer selects a payment card and shares payment data with a merchant. 3-D Secure is a separate authentication protocol (governed under PCI 3DS for its security requirements) intended to authenticate the cardholder during a card-not-present transaction. They address different parts of the flow: Click to Pay focuses on the checkout and credential-sharing experience, while 3-D Secure focuses on authenticating the shopper. In practice a Click to Pay transaction may still invoke 3-D Secure, and one does not replace the other.

Does using Click to Pay mean my organization is out of PCI DSS scope or that it eliminates fraud?

Not automatically. Whether and how Click to Pay affects PCI DSS scope depends on the specific implementation, how payment data flows through or around your systems, and how that is validated, not on the use of the brand name alone. Similarly, Click to Pay is intended to reduce friction and may reduce certain manual-entry and credential-exposure risks, but it does not prevent or eliminate fraud. Card-not-present fraud, account takeover, and related risks can still occur, so it should be treated as one layer among other controls rather than a standalone solution.

How does Click to Pay affect where cardholder data flows in my environment?

That depends on your integration model. Different implementations can change whether cardholder data enters your systems, is handled by a hosted component, or is exchanged directly between the consumer's browser or device and the SRC infrastructure. You should map the actual data flows for your chosen integration, identify which systems touch or transmit cardholder data, and confirm the resulting PCI DSS scope through your normal scoping and validation process rather than assuming the checkout method removes systems from scope.

Can I still combine Click to Pay with additional authentication controls?

Yes. Click to Pay addresses the checkout and credential-sharing experience and can be used alongside other controls that address different risks, such as 3-D Secure for cardholder authentication, or strong customer authentication and multi-factor authentication where those apply. Because these controls operate at different points in the transaction, teams commonly layer them, and the appropriate combination depends on your risk tolerance, regional rules, and the trade-offs between friction and detection.

What should fraud and risk teams monitor when adopting Click to Pay?

Fraud and risk teams should continue applying their existing detection and monitoring practices, since the checkout method does not remove card-not-present fraud, account takeover, or first-party and chargeback fraud risks. As with any detection control, teams should account for false-positive and false-negative trade-offs when tuning rules, and should not assume the checkout experience alone changes their fraud exposure. How liability and chargebacks apply is governed by card brand and network rules, which vary by region and change over time.

Where should I confirm the technical and security requirements that govern Click to Pay?

Because Click to Pay is built on the EMV Secure Remote Commerce specification and may interact with other standards such as 3-D Secure and PCI DSS, you should confirm the applicable requirements against the current published specifications and standards rather than relying on a fixed reference. Requirement wording, scope, and applicability can differ between versions and standards, so verify the current source that governs each control in your implementation.

Common misconceptions

Click to Pay is a proprietary product owned by a single card brand.

Click to Pay is a shared consumer branding for checkout experiences built on EMVCo's Secure Remote Commerce specifications, and it involves multiple participating card networks. It is not a single-brand proprietary wallet.

Using Click to Pay by itself takes a merchant out of PCI DSS scope.

Scope impact depends on how the solution is implemented and validated, and on what data flows to and through the merchant environment. If the integration reduces or removes handling of cardholder data at the merchant, it may reduce scope, but this must be confirmed against the current PCI DSS and the specific integration, not assumed from the Click to Pay label.

Click to Pay authenticates the cardholder and therefore eliminates card-not-present fraud.

Click to Pay is a checkout and credential-delivery experience and is not itself a cardholder authentication standard. It may be combined with authentication controls such as 3-D Secure, but no single control eliminates fraud, and liability outcomes are governed by card brand and network rules that vary by region and change over time.

Best practices

Document the actual data flows for your Click to Pay integration, identifying exactly what payment data (raw PAN, network token, or other credential) reaches your systems, and validate any resulting PCI DSS scope reduction against the current published standard rather than assuming it from the branding.

Do not assume Click to Pay provides cardholder authentication; where authentication is required, integrate it with an appropriate mechanism such as 3-D Secure and confirm which transactions invoke it under your implementation and applicable network rules.

Confirm how sensitive authentication data is handled in your flow and ensure that such data is not stored after authorization by any component under your control, regardless of encryption.

Distinguish the credential you receive (for example a network token versus a raw PAN) and design storage, transmission, and truncation or masking controls accordingly, since these transformations affect scope only when correctly implemented and validated.

Coordinate with your acquirer, processor, and the relevant card networks to understand current liability, chargeback, and dispute rules for Click to Pay transactions in your region, recognizing these rules vary and change.

Maintain clarity about role boundaries (SRC Initiator, SRC System, Digital Card Facilitator, merchant, processor) so that responsibility for enrollment, credential storage, and authorization data is unambiguous and reflected in your compliance documentation.