{"id":2830,"date":"2026-07-16T12:07:15","date_gmt":"2026-07-16T02:07:15","guid":{"rendered":"https:\/\/www.gpayments.com\/blog\/?p=2830"},"modified":"2026-07-16T12:34:05","modified_gmt":"2026-07-16T02:34:05","slug":"secure-payment-confirmation-spc-webauthn-3ds","status":"publish","type":"post","link":"https:\/\/www.gpayments.com\/blog\/article\/secure-payment-confirmation-spc-webauthn-3ds\/","title":{"rendered":"Secure Payment Confirmation (SPC) and WebAuthn: Is Your ACS Ready for Passwordless 3DS?"},"content":{"rendered":"\n

One-time passwords sent by SMS remain the default challenge method for most 3D Secure deployments, despite being phishable, dependent on carrier delivery, and a well-documented source of cardholder drop-off. Secure Payment Confirmation (SPC) is the protocol-level answer: a W3C web standard, built on WebAuthn and developed jointly with FIDO and EMVCo, that lets a cardholder confirm a transaction using a passkey (device biometrics, a PIN, or a security key) instead of typing anything at all.<\/p>\n

GPayments has developed 3D Secure technology since 1999 and provides ActiveAccess (ACS)<\/a>, ActiveServer (3DS Server)<\/a>, ActiveSDK, and TestLabs<\/a> to issuers and acquirers across 33 countries. This is a technical breakdown of what SPC actually requires from an ACS, why standard WebAuthn can’t be used directly inside a 3DS flow, and what to ask vendors before committing to a passwordless roadmap.<\/p>\n

Why Standard WebAuthn Doesn’t Work Inside 3DS<\/h2>\n

WebAuthn passkeys are bound to the web origin, the Relying Party domain, where they were registered. In a standard login flow, that’s not a problem: the same site that registered the passkey is the one verifying it. A 3DS challenge breaks this model immediately. The merchant’s domain is where the cardholder is checking out, but the passkey needs to be verified against the issuer’s domain, since the issuer’s ACS is the Relying Party for payment authentication, not the merchant. Standard WebAuthn has no mechanism for this kind of cross-origin verification, which is exactly the gap SPC was built to close.<\/p>\n

SPC resolves this by having the browser act as a trusted intermediary. The ACS sends a signed challenge and the relevant FIDO credential identifiers to the merchant’s 3DS Server; the merchant’s checkout page invokes the browser’s secure Payment Confirmation\u00a0API; the browser collects the passkey assertion against the issuer’s domain directly, inside a secure browser-controlled dialog, without redirecting the cardholder away from checkout. The cardholder sees merchant details, the payment instrument, and the transaction amount in that dialog, and the resulting cryptographic assertion proves they reviewed and accepted those specific terms.<\/p>\n

Where SPC Sits in the EMV 3DS Specification<\/h2>\n

EMVCo<\/a> formally added WebAuthn and SPC support to EMV 3DS from version 2.3, as part of a broader set of enhancements aimed at reducing friction across the challenge flow. SPC and non-SPC FIDO data structures are both usable within the 3DS challenge flow, but they serve different Relying Party models: outside SPC, the merchant typically acts as the Relying Party for its own authentication purposes, while under SPC, the issuer, or a party the issuer explicitly delegates to, is the Relying Party for payment authentication specifically. That distinction is why SPC support has to be built deliberately into ACS challenge logic; it isn’t a byproduct of generic WebAuthn or biometric OOB support already in place.<\/p>\n

Support for Secure Payment Confirmation (SPC), as distinct from broader biometric out-of-band (OOB) authentication, continues to vary across Access Control Server (ACS) vendors. Issuers evaluating vendors should ask the question directly rather than assuming 2.3-series compliance implies SPC readiness: does the ACS support the SPC browser API specifically, and is FIDO credential enrolment and cross-origin assertion handling built into the challenge flow today, or on the roadmap?<\/p>\n

How Cardholder Enrolment Works<\/h2>\n

SPC enrolment happens in two steps. First, the cardholder registers a FIDO authenticator, device biometrics, a device PIN, or a roaming security key, with the issuer, typically inside the bank’s own mobile app or online banking portal, sometimes offered as an upgrade path following a successful traditional challenge. This creates a passkey: a public key and credential identifier stored against the cardholder’s account. Second, because SPC needs to be invoked by a third party (the merchant) rather than the issuer directly, the credential must be created with explicit consent for that cross-origin use, generally via specific WebAuthn extensions set at registration time. Once enrolled, the cardholder can use the same passkey across any merchant site that triggers an SPC challenge, without re-registering per merchant.<\/p>\n

What SPC Readiness Requires From an ACS<\/h2>\n\n\n\n\n\n\n\n\n
\n

Capability<\/strong><\/p>\n<\/td>\n

\n

Why It’s Needed<\/strong><\/p>\n<\/td>\n<\/tr>\n

\n

FIDO credential enrolment flow<\/p>\n<\/td>\n

\n

Cardholders need a way to register a passkey against their issuer account before SPC can be offered as a challenge method<\/p>\n<\/td>\n<\/tr>\n

\n

Cross-origin assertion handling<\/p>\n<\/td>\n

\n

The ACS must issue signed challenges the browser can verify against the issuer domain from a merchant page<\/p>\n<\/td>\n<\/tr>\n

\n

SPC browser API integration on the merchant\/3DS Server side<\/p>\n<\/td>\n

\n

The merchant’s checkout needs to invoke securePaymentConfirmation(), not just a generic WebAuthn call<\/p>\n<\/td>\n<\/tr>\n

\n

Fallback to existing challenge methods<\/p>\n<\/td>\n

\n

Not every cardholder or device will support SPC, OTP, OOB, and biometric-via-app methods still need to work for everyone else<\/p>\n<\/td>\n<\/tr>\n

\n

Browser compatibility awareness<\/p>\n<\/td>\n

\n

SPC support varies across browsers and versions; the ACS challenge logic needs to detect support and fall back gracefully<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\u00a0<\/p>\n

\"\"<\/h2>\n

Why This Matters Beyond Security<\/h2>\n

SPC’s appeal to issuers isn’t purely about phishing resistance, though that matters. It’s about conversion. A challenge method that keeps the cardholder inside the merchant’s checkout page, with no app switch and no code to type or remember, removes one of the most reliable sources of cart abandonment in the 3DS challenge flow. As passkey adoption grows across banking apps generally, cardholders arrive at checkout already carrying credentials an SPC-ready ACS can use, rather than needing a separate enrolment step built from scratch.<\/p>\n\n\n\n
\n

Where GPayments Fits<\/strong><\/p>\n

GPayments’ ActiveAccess supports a broad range of challenge methods today, including OOB and biometric authentication via adapter-based APIs, and the EMV 3DS 2.3 specification’s SPC and WebAuthn provisions are part of GPayments’ ongoing development roadmap. Issuers evaluating passwordless authentication should confirm current SPC-specific support and rollout timelines directly with GPayments’ technical team against their own certification timeline.<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Frequently Asked Questions<\/h2>\n

What is Secure Payment Confirmation (SPC)?<\/h3>\n

Secure Payment Confirmation is a W3C web standard, built on WebAuthn and developed jointly with FIDO and EMVCo, that lets a cardholder confirm a payment transaction using a passkey, such as device biometrics, a PIN, or a security key, instead of a one-time password or typed credential. It is formally supported within the EMV 3DS specification from version 2.3.<\/p>\n

Why can’t standard WebAuthn be used directly in a 3DS challenge?<\/h3>\n

Standard WebAuthn passkeys are bound to the web origin where they were registered. In a 3DS transaction, the merchant’s checkout domain differs from the issuer’s ACS domain, and WebAuthn has no built-in mechanism for verifying a passkey across that domain boundary. SPC solves this by having the browser act as a trusted intermediary between the merchant page and the issuer’s domain.<\/p>\n

How does a cardholder enrol in SPC?<\/h3>\n

A cardholder first registers a FIDO authenticator, such as device biometrics or a security key, with their issuing bank, typically through the bank’s mobile app or online banking portal. The credential must be created with explicit consent for cross-origin use by third parties, since SPC needs to be invoked from merchant checkout pages rather than the issuer’s own site. Once enrolled, the same passkey works across any merchant site that triggers an SPC challenge.<\/p>\n

Does every ACS vendor support SPC?<\/h3>\n

No. Support for EMV 3DS 2.3 generally does not guarantee SPC support specifically, since SPC requires dedicated cross-origin assertion handling and FIDO credential enrolment built into the challenge flow, distinct from broader biometric or OOB authentication support. Issuers should confirm SPC-specific support and timelines directly with any shortlisted vendor rather than assuming it from general 2.3-series compliance.<\/p>\n

What happens if a cardholder’s device or browser doesn’t support SPC?<\/h3>\n

An ACS needs to detect SPC support at the browser and device level and fall back gracefully to existing challenge methods, such as SMS OTP, banking app push notifications, or biometric authentication via out-of-band channels, for cardholders who haven’t enrolled a passkey or whose device doesn’t support the SPC browser API.<\/p>\n

Does GPayments’ ActiveAccess support SPC?<\/h3>\n

ActiveAccess supports a broad range of challenge methods today, including out-of-band and biometric authentication via adapter-based APIs, and EMV 3DS 2.3’s SPC and WebAuthn provisions are part of GPayments’ ongoing development roadmap. Issuers should confirm current SPC-specific support and rollout timelines directly with GPayments against their own certification requirements.<\/p>\n\n\n\n
\n

Planning Your Passwordless Authentication Roadmap?<\/strong><\/p>\n

Talk to GPayments’ technical team about SPC readiness and challenge method roadmaps for your ACS: gpayments.com\/contact<\/a><\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n\n\n","protected":false},"excerpt":{"rendered":"

One-time passwords sent by SMS remain the default challenge method for most 3D Secure deployments, despite being phishable, dependent on carrier delivery, and a well-documented source of cardholder drop-off. Secure Payment Confirmation (SPC) is the protocol-level answer: a W3C web standard, built on WebAuthn and developed jointly with FIDO and EMVCo, that lets a cardholder […]<\/p>\n","protected":false},"author":13,"featured_media":2836,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[2],"tags":[37,136,137],"class_list":["post-2830","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-article","tag-acs","tag-secure-payment-confirmation","tag-spc"],"aioseo_notices":[],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/2830","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/comments?post=2830"}],"version-history":[{"count":11,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/2830\/revisions"}],"predecessor-version":[{"id":2849,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/posts\/2830\/revisions\/2849"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media\/2836"}],"wp:attachment":[{"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/media?parent=2830"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/categories?post=2830"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gpayments.com\/blog\/wp-json\/wp\/v2\/tags?post=2830"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}