Skip to main content
Commerce Security Authority
Category: 3-D Secure

Secure Payment Confirmation

Also known as:
Simply put

Secure Payment Confirmation (SPC) is a web standard that lets a customer confirm their identity with their card issuer, bank, or other payment service during an online purchase. It is designed to make this authentication step smoother while using strong authentication methods. It is one tool intended to help support secure payments and does not by itself eliminate fraud.

Formal definition

Secure Payment Confirmation (SPC) is a Web API designed to support streamlined authentication during a payment transaction, building on the WebAuthn / FIDO strong authentication model to allow a customer to authenticate with their card issuer, bank, or other payment service provider. It is intended to facilitate the use of strong authentication and to scale authentication across payment flows, and it has been referenced in the context of EMV 3-D Secure challenge flows. SPC is an authentication mechanism at a specific point in a transaction; it addresses customer authentication and does not, on its own, replace other controls or guarantee prevention of fraud. Practitioners should confirm current specification status and scope against the published standards, as the referenced material describes SPC as a proposed or evolving web standard.

Why it matters

Customer authentication during online payments involves a persistent tension between security and usability. Strong authentication challenges can reduce certain forms of card-not-present fraud, but poorly designed or friction-heavy challenge flows can lead to abandoned carts and inconsistent user experiences. Secure Payment Confirmation (SPC) is intended to help address this tension by building on the WebAuthn / FIDO strong authentication model to provide a more streamlined authentication step during a payment transaction.

SPC is relevant because it aims to bring a standardized, browser-supported authentication mechanism to payment flows, and it has been referenced in the context of EMV 3-D Secure challenge flows. This positions it as one potential building block within a broader authentication ecosystem rather than a standalone solution. For teams evaluating authentication options, understanding where SPC fits, and where it does not, matters for accurate scoping of controls.

It is important to treat SPC as an authentication mechanism at a specific point in a transaction. It addresses customer authentication and does not, on its own, replace other controls or guarantee the prevention of fraud. Because the referenced material describes SPC as a proposed or evolving web standard, practitioners should confirm current specification status, browser support, and scope against the published standards rather than assuming a fixed or finalized behavior.

Who it's relevant to

Payment Service Providers, Issuers, and Banks
Card issuers, banks, and other payment service providers are the parties with whom customers authenticate under SPC. Teams evaluating how to offer strong authentication that customers can complete during checkout should understand how SPC builds on the WebAuthn / FIDO model and how it may fit into existing authentication offerings. Because SPC is described as a proposed or evolving standard, these teams should confirm current specification status and support before relying on it.
3-D Secure and Authentication Engineering Teams
SPC has been referenced in the context of EMV 3-D Secure challenge flows, so teams designing or integrating challenge experiences may consider it as one mechanism for completing customer authentication. These teams should note that EMV 3-D Secure and SPC are distinct: 3-D Secure defines the broader messaging and challenge framework, while SPC provides a streamlined, WebAuthn-based authentication step. Neither, on its own, eliminates fraud.
Fraud and Risk Analysts
Fraud and risk teams evaluating controls for card-not-present transactions should treat SPC as a customer-authentication mechanism at a specific point in the transaction, not a complete fraud-prevention solution. Strong authentication may help reduce certain fraud types, but it does not address every risk vector and must be considered alongside other detection and prevention controls.
Web and Front-End Developers
As a Web API, SPC is implemented in the browser environment and depends on platform and browser support. Developers integrating payment authentication should verify current implementation status, availability, and behavior against the published specification and browser documentation, since the standard is described as proposed or evolving.

Inside SPC

Web Authentication (WebAuthn) foundation
SPC is built on the W3C Web Authentication API and FIDO-based credentials, using public-key cryptography and authenticators (such as platform biometrics or security keys) to authenticate a payer rather than shared secrets.
Payer authentication ceremony
A browser-mediated authentication flow in which the user consents to a specific payment using a registered FIDO credential, intended to demonstrate cardholder presence and intent at the point of a transaction.
Transaction-bound assertion
The cryptographic assertion produced during the ceremony is bound to displayed transaction details (such as amount and payee), so the signed response reflects what the payer was shown and approved.
Relationship to 3-D Secure
SPC is intended to serve as an authentication method that can be invoked within or alongside a 3-D Secure flow; it addresses the authentication step and does not by itself constitute the full 3DS protocol or authorization.
Enrollment and credential registration
Before SPC can be used, a FIDO credential typically must be registered and associated with the payer, often coordinated between the issuer, the relying party, and the payer's device.
Scope boundary
SPC handles the authentication interaction and evidence of payer consent; it does not process, store, or transmit cardholder data such as the PAN as part of its core ceremony, and it does not replace authorization or clearing.

Common questions

Answers to the questions practitioners most commonly ask about SPC.

Does Secure Payment Confirmation (SPC) replace 3-D Secure?
No. SPC is not a replacement for 3-D Secure; it is a web-based mechanism intended to work alongside authentication flows, and it is commonly used in conjunction with 3-D Secure to help carry out cardholder authentication using platform authenticators. The two operate at related but distinct points in the authentication process, and SPC does not by itself perform the risk assessment or messaging that 3-D Secure defines. Confirm the specific relationship and integration details against current specifications from the relevant standards body and card brand or network rules, as these vary and change over time.
Does using SPC by itself eliminate card-not-present fraud?
No single control eliminates fraud. SPC is intended to help strengthen the authentication step for card-not-present transactions by binding a cryptographic authenticator to the payment confirmation, which may help mitigate certain account takeover and unauthorized-use scenarios. It does not address all fraud types, such as first-party or friendly fraud, synthetic identity fraud, or fraud arising outside the authentication moment. Detection and authentication controls involve trade-offs, including potential false positives and false negatives, so SPC should be treated as one layer within a broader risk strategy rather than a guarantee.
How does SPC interact with strong customer authentication (SCA) requirements?
SPC can be used as a technical means to help satisfy authentication objectives, including those associated with strong customer authentication where such requirements apply by region. However, whether a given SPC implementation meets a specific regulatory SCA obligation depends on how it is deployed, what authentication factors are used, and the applicable regional rules. Verify against the current regulatory text and any relevant card brand or network guidance rather than assuming SPC alone constitutes compliant SCA.
What authentication factors does SPC rely on?
SPC typically leverages platform or roaming authenticators consistent with the underlying web authentication technology, which commonly involve a possession factor (a registered device or authenticator) combined with a user verification step such as a biometric or device PIN. The exact factors depend on the authenticator and device capabilities in use. Confirm which factors your implementation actually exercises, since the mapping to multi-factor authentication depends on configuration rather than on the SPC label alone.
Does implementing SPC change my PCI DSS scope?
SPC concerns the authentication of a transaction and does not itself store, process, or transmit cardholder data in a way that inherently reduces or expands PCI DSS scope. Any scope impact depends on how the surrounding payment environment is architected, including where cardholder data flows and how it is handled. Assess scope based on your actual data flows and validation, and confirm against the current published PCI DSS rather than assuming SPC changes scope by default.
What should teams consider before enrolling users in SPC?
Consider enrollment and credential lifecycle management, including how authenticators are registered, recovered, and revoked, and how users without a compatible device or browser are handled through fallback flows. Also consider the user experience trade-offs, potential friction, and the detection trade-offs involved in relying on device-bound authenticators. Coordinate with applicable card brand or network rules, which govern liability and vary by region and change over time, and validate the end-to-end flow against current specifications before broad deployment.

Common misconceptions

SPC prevents payment fraud.
SPC is intended to strengthen payer authentication and provide cryptographic evidence of consent, which may help reduce certain card-not-present fraud and unauthorized-use disputes. It does not eliminate fraud and does not address risks such as first-party or friendly fraud, account takeover before credential registration, or fraud outside the authenticated flow.
SPC is a replacement for 3-D Secure or handles the entire transaction.
SPC is an authentication mechanism that can be used within or alongside 3-D Secure. It does not perform authorization, clearing, or settlement, and the governing card brand and network rules for authentication and any liability considerations remain separate and vary by region and version.
SPC brings the merchant environment into or out of PCI DSS scope on its own.
SPC concerns payer authentication using FIDO credentials, not the storage or transmission of cardholder data. Any effect on PCI DSS scope depends on the overall implementation and how cardholder data is handled elsewhere, and must be assessed against the current published standard rather than assumed from the use of SPC.

Best practices

Treat SPC as one layer of authentication and combine it with other controls, and confirm how it integrates with your 3-D Secure flow rather than assuming it replaces that protocol.
Ensure the transaction details presented during the SPC ceremony (such as amount and payee) accurately match the actual transaction, since the assertion is bound to what the payer was shown.
Define and secure the credential enrollment and registration process, coordinating responsibilities between issuer, relying party, and payer device to reduce the risk of fraudulent registration.
Validate any assumptions about PCI DSS scope, requirement wording, and version-specific details against the current published standard, and do not rely on fixed requirement numbers.
Confirm applicable card brand and network rules, including any authentication and liability provisions, for each region where you operate, as these rules change and vary.
Monitor for authentication failures, fallback behavior, and residual fraud vectors not addressed by SPC, and document known limitations and false-positive or false-negative trade-offs in your risk assessment.