---
url: 'https://www.corbado.com/blog/emv-3ds-acs-passkeys-fido-and-spc'
title: 'EMV 3DS Access Control Server: Passkeys, FIDO and SPC'
description: 'EMV 3DS ACS vendor landscape: Learn about Passkeys & FIDO data for frictionless & SPC readiness for secure payment challenges'
lang: 'en'
author: 'Vincent Delitz'
date: '2025-05-01T15:57:42.146Z'
lastModified: '2026-03-27T07:01:26.593Z'
keywords: 'EMV 3DS Access Control Server, 3DS ACS'
category: 'Passkeys Strategy'
---

# EMV 3DS Access Control Server: Passkeys, FIDO and SPC

## Key Facts

- **Safari** (all iOS devices) and Firefox have no SPC implementation as of May 2025,
  blocking mass SPC adoption; only Chromium-based browsers support baseline SPC.
- In SPC challenge flows, the **issuer acts as FIDO Relying Party** and cryptographically
  verifies the assertion; in non-SPC flows, the merchant holds that role.
- **Non-SPC FIDO data** via `threeDSRequestorAuthenticationInfo` has been supported since
  EMV 3DS v2.1, enabling merchant passkey authentications to raise frictionless approval
  rates today.
- Netcetera achieved the **first global EMV 3DS 2.3.1 certification**; Worldline and
  Entersekt confirm SPC support; Broadcom Arcot and GPayments lack public SPC
  confirmation.

## 1. Introduction

The landscape of online [payment](https://www.corbado.com/passkeys-for-payment) authentication is undergoing
significant transformation, driven by the dual needs of enhancing security against
sophisticated fraud and improving the user experience to reduce friction and cart
abandonment. The EMV® [3-D Secure](https://www.corbado.com/glossary/3d-secure) (3DS) protocol, particularly its
later versions (EMV 3DS 2.x), serves as the foundational technology for authenticating
card-not-present (CNP) transactions globally. Managed by EMVCo, this protocol facilitates
data exchange between [merchants](https://www.corbado.com/glossary/merchant), [issuers](https://www.corbado.com/glossary/issuer) (via
their Access Control Server - [ACS](https://www.corbado.com/glossary/acs)), and the interoperability domain
(Directory Servers operated by [payment](https://www.corbado.com/passkeys-for-payment) schemes) to verify
cardholder identity.

Within this framework, two key technological advancements related to the FIDO (Fast
Identity Online) Alliance standards are emerging:

1. The use of FIDO authentication data generated during prior user interactions (e.g.,
   [merchant](https://www.corbado.com/glossary/merchant) login) to enrich the risk assessment for the EMV 3DS
   [frictionless flow](https://www.emvco.com/wp-content/uploads/2022/10/EMV-3DS-FIDO-FAQ.pdf).
2. The integration of [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)
   (SPC), a W3C web standard built upon FIDO/WebAuthn, as a streamlined,
   [phishing](https://www.corbado.com/glossary/phishing)-resistant "challenge" method within the EMV 3DS flow.

This article provides an overview of the global market for EMV 3DS Access Control Server
(ACS) solutions provided to issuing banks. It identifies major vendors and tries to
evaluate their current support for both non-[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) FIDO
data structures and Secure Payment Confirmation (SPC) for challenge flows. Furthermore, it
clarifies the mechanism by which [issuers](https://www.corbado.com/glossary/issuer) can leverage their own FIDO
passkeys for cryptographic verification within the 3DS challenge flow via
[SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) and discusses the global applicability of this
standard.

## 2. Overview of EMV 3DS, FIDO & SPC

### 2.1 Frictionless vs. Challenge Flows in EMV 3DS

EMV 3DS operates primarily through two distinct authentication pathways:

- **Frictionless Flow:** This is the preferred path, aiming for a seamless user
  experience. The [issuer's](https://www.corbado.com/glossary/issuer) [ACS](https://www.corbado.com/glossary/acs) performs a risk
  assessment based on a rich set of data exchanged during the transaction initiation (via
  the Authentication Request, or AReq message). This data includes transaction details,
  [merchant](https://www.corbado.com/glossary/merchant) information, device characteristics, browser data
  (potentially collected via the 3DSMethod JavaScript), and potentially prior
  authentication information. If the risk is deemed low, the transaction is authenticated
  without requiring any direct interaction or "challenge" from the cardholder. This flow
  accounts for the majority of 3DS transactions, particularly where risk engines are
  [well-tuned](https://www.w3.org/blog/wpwg/2021/02/18/an-emv-3-d-secure-view-of-emvco-fido-and-w3c-activities/).
- **Challenge Flow:** If the [ACS](https://www.corbado.com/glossary/acs) determines the transaction risk is high,
  if mandated by regulations (like [PSD2](https://www.corbado.com/blog/psd2-passkeys) SCA in Europe) or
  [issuer](https://www.corbado.com/glossary/issuer) policy, the cardholder is actively challenged to verify their
  identity. Traditional challenge methods include One-Time Passcodes (OTP) sent via SMS,
  knowledge-based questions, or Out-of-Band (OOB) authentication via a
  [banking](https://www.corbado.com/passkeys-for-banking) app. The goal of newer 3DS versions and related
  technologies like [SPC](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) is to make this challenge
  flow more secure and less cumbersome than
  [legacy methods](https://www.mastercard.com/content/dam/public/mastercardcom/globalrisk/pdf/Top-10-Things-to-Know-About-3DS.pdf).

![three domains 3DS](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/domains_3_DS_1aac4ea7f0.png)

### 2.2 Role of FIDO Data (Non-SPC) in Frictionless Flow Enhancement

EMVCo and the [FIDO Alliance](https://www.corbado.com/glossary/fido-alliance) have
[collaborated to define a standardized way](https://www.emvco.com/wp-content/uploads/2022/10/EMV-3DS-FIDO-FAQ.pdf)
for [merchants](https://www.corbado.com/glossary/merchant) to pass information about prior FIDO authentications
(where the _merchant_ acted as the [Relying Party](https://www.corbado.com/glossary/relying-party), e.g., during
user login) to the [issuer's](https://www.corbado.com/glossary/issuer) ACS within the standard 3DS AReq
[message](https://www.emvco.com/wp-content/uploads/2022/10/EMV-3DS-FIDO-FAQ.pdf). This
mechanism, first supported in
[EMV 3DS v2.1](https://www.emvco.com/wp-content/uploads/2022/10/EMV-3DS-FIDO-FAQ.pdf),
leverages specific fields within the AReq, primarily the
`threeDSRequestorAuthenticationInfo` structure, which contains subfields like
[`threeDSRequestorAuthenticationData`](https://fidoalliance.org/wp-content/uploads/2020/09/FIDO-and-EMV-3DS-Technical-Note-2020-09-01.pdf).

The
[FIDO Alliance Technical Note](https://fidoalliance.org/wp-content/uploads/2020/09/FIDO-and-EMV-3DS-Technical-Note-2020-09-01.pdf)
and related
[EMVCo white paper](https://www.emvco.com/wp-content/uploads/news/EMV-3DS-white-paper-PR_FINAL.pdf)
specify a JSON structure for this `threeDSRequestorAuthenticationData` field when
conveying prior FIDO authentication
[details](https://www.emvco.com/wp-content/uploads/2022/10/EMV-3DS-FIDO-FAQ.pdf). This
JSON object includes details such as the authentication time (`authTime`), the FIDO
[Relying Party](https://www.corbado.com/glossary/relying-party) ID (`rpId` or `appId`), and information about the
[authenticator](https://www.corbado.com/glossary/authenticator)(s) used, including the public key,
[AAGUID](https://www.corbado.com/glossary/aaguid)/AAID, and indicators of
[user presence](https://www.corbado.com/blog/webauthn-user-verification) (UP) and
[user verification](https://www.corbado.com/blog/webauthn-user-verification)
([UV](https://fidoalliance.org/wp-content/uploads/2020/09/FIDO-and-EMV-3DS-Technical-Note-2020-09-01.pdf)).

The rationale is that if a [merchant](https://www.corbado.com/glossary/merchant) has recently performed a strong
FIDO authentication (e.g., using biometrics or a passkey) for the user session initiating
the purchase, this information can serve as a valuable additional risk signal for the
[issuer's](https://www.corbado.com/glossary/issuer) ACS. By receiving and processing this standardized FIDO data,
the ACS can potentially gain greater confidence in the transaction's legitimacy,
increasing the likelihood of a frictionless approval and reducing the need for a separate
[challenge](https://www.emvco.com/wp-content/uploads/2022/10/EMV-3DS-FIDO-FAQ.pdf). It is
important to note that in this scenario, the merchant is the FIDO RP, and the
[issuer](https://www.corbado.com/glossary/issuer) consumes this data as an input to its risk engine; the
[issuer](https://www.corbado.com/glossary/issuer) does not cryptographically verify the FIDO
[assertion](https://www.corbado.com/glossary/assertion) itself within this frictionless
[flow](https://fidoalliance.org/wp-content/uploads/2020/09/FIDO-and-EMV-3DS-Technical-Note-2020-09-01.pdf).
The ACS retains the option to ignore this data if not configured to process
[it](https://www.youtube.com/watch?v=a8iGYQXmDlM).

### 2.3 Role of Secure Payment Confirmation in Challenge Flow

[Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC) represents a
distinct integration of FIDO standards within the EMV 3DS _challenge_
[flow](https://www.w3.org/blog/wpwg/2021/02/18/an-emv-3-d-secure-view-of-emvco-fido-and-w3c-activities/).
SPC is a W3C web standard, developed in collaboration with FIDO and EMVCo, built upon
WebAuthn. It is formally supported within EMV 3DS starting from version
[2.3](https://sdtimes.com/w3c-advances-technology-to-streamline-payment-authentication-secure-payment-confirmation-spc-published-as-a-candidate-recommendation/).

When SPC is used as a challenge method:

1. The **issuer** (or a party explicitly delegated by the issuer, such as a
   [payment](https://www.corbado.com/passkeys-for-payment) scheme) functions as the **FIDO Relying Party
   ([RP](https://www.w3.org/blog/wpwg/2021/02/18/an-emv-3-d-secure-view-of-emvco-fido-and-w3c-activities/))**.
   This is fundamentally different from the non-SPC FIDO data flow described earlier,
   where the merchant typically acts as the RP for its own login/authentication
   [purposes](https://fidoalliance.org/wp-content/uploads/2020/09/FIDO-and-EMV-3DS-Technical-Note-2020-09-01.pdf).
2. During the 3DS challenge, the ACS signals the need for SPC and provides the necessary
   FIDO credential identifiers and a
   [cryptographic challenge](https://www.corbado.com/glossary/cryptographic-challenge) to the merchant/3DS
   Server.
3. The [merchant's](https://www.corbado.com/glossary/merchant) system invokes the browser's SPC API, presenting
   transaction details (amount, currency, payee, instrument) to the user in a secure
   browser-controlled dialog.
4. The user authenticates using their FIDO [authenticator](https://www.corbado.com/glossary/authenticator) (e.g.,
   [device biometrics](https://www.corbado.com/blog/passkeys-local-biometrics), PIN,
   [security key](https://www.corbado.com/glossary/security-key)), which signs the transaction details and the
   challenge using the private key associated with the issuer-registered passkey.
5. The resulting FIDO [assertion](https://www.corbado.com/glossary/assertion) (cryptographic proof of
   authentication and consent) is passed back through the 3DS protocol (typically via a
   second AReq message) to the issuer's ACS.
6. The ACS, as the RP, cryptographically validates the [assertion](https://www.corbado.com/glossary/assertion)
   using the corresponding public key, confirming the cardholder's identity and consent to
   the specific transaction details.

The diagram below illustrates this multi-party flow from challenge initiation to assertion
verification.

SPC aims to provide a challenge experience that is both more secure (phishing-resistant,
[dynamic linking](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) of authentication to transaction
data) and potentially lower friction (often faster than OTP entry) compared to traditional
methods.

The dual pathways for FIDO integration—one leveraging prior merchant authentication data
for frictionless risk assessment, the other using issuer-managed credentials for a direct
FIDO-based challenge via SPC—offer distinct approaches to enhancing security and user
experience within the EMV 3DS framework. Understanding vendor support for each is crucial
for [issuers](https://www.corbado.com/glossary/issuer) and
[PSPs](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) planning their authentication
strategies.

![overview emv 3ds](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/overview_emv_3ds_97db9721b6.png)

## 3. Analysis of Major EMV 3DS ACS Vendors

This section analyzes the capabilities of global providers of EMV 3DS ACS solutions,
focusing on their market presence and support for FIDO data (non-SPC) and Secure Payment
Confirmation (SPC). The matrix below provides a quick comparison before diving into
detailed vendor profiles.

### 3.1 Entersekt (incorporating Modirum) 3DS ACS

- **Market Presence:** Entersekt, particularly after its acquisition of Modirum's 3DS
  software business in December 2023, positions itself as a leading global provider of EMV
  3DS solutions, aiming for a top-five market
  [position](https://www.entersekt.com/solutions/3d-secure-acs). Modirum had over 20 years
  of experience in [3DS](https://www.entersekt.com/solutions/3d-secure-authentication).
  Entersekt highlights record growth driven by new clients, especially in North America,
  and strategic partnerships, including an expanded relationship with
  [Mastercard](https://www.corbado.com/blog/mastercard-passkeys). They claim to secure over 2.5 billion
  transactions annually (as of FY24) and are ranked #1 in ATO prevention in
  [banking](https://www.corbado.com/passkeys-for-banking) by
  [Liminal](https://www.entersekt.com/company/newsroom_old/tpost/gmmthc53z1-entersekt-closes-record-year-of-growth-a).
  Their ACS is available hosted (by Entersekt or client) or
  [on-premise](https://www.entersekt.com/solutions/3d-secure-acs). They serve issuers and
  processors [globally](https://www.entersekt.com/solutions/3d-secure-acs).
- **Non-SPC FIDO Data Support (Frictionless):** Entersekt emphasizes its Context Aware™
  Authentication, device and behavioral analytics for risk signals, and integration with
  various risk-scoring [services](https://www.entersekt.com/solutions/3d-secure-acs).
  Their ACS is FIDO EMVCo 2.2
  [certified](https://www.entersekt.com/solutions/3d-secure-acs). While they highlight
  leveraging risk and behavioral intelligence data for
  [RBA](https://www.entersekt.com/solutions/3d-secure-acs), explicit confirmation of
  _processing the standardized FIDO attestation data_ from prior merchant authentications
  within the `threeDSRequestorAuthenticationInfo` field for frictionless flow enhancement
  is not explicitly stated in online
  [materials](https://www.entersekt.com/solutions/3d-secure-acs). However, their focus on
  advanced authentication and risk signals suggests capability.
- **SPC Support (Challenge):** Strong indicators suggest Entersekt supports SPC. Modirum,
  whose 3DS business Entersekt acquired, provided components for
  [Visa's](https://www.corbado.com/blog/visa-passkeys) SPC pilot using 3DS 2.2 with
  [extensions](https://www.w3.org/2023/Talks/visa-spc-20230911.pdf). Entersekt explicitly
  lists support for SPC compliance as part of its
  [regulatory compliance](https://www.corbado.com/blog/cybersecurity-frameworks)
  [capabilities](https://www.entersekt.com/use-cases/regulatory-compliance). Their ACS
  supports biometric [authentication](https://www.entersekt.com/solutions/3d-secure-acs),
  is certified for
  [EMV 3DS 2.2](https://www.entersekt.com/use-cases/regulatory-compliance), and likely
  incorporates capabilities from Modirum's pilot involvement. The combination of the
  Modirum acquisition, explicit mention of SPC compliance, and FIDO certification strongly
  points towards SPC support in their current offering.

### 3.2 Broadcom (Arcot) 3DS ACS

- **Market Presence:** Broadcom's Arcot is a foundational player in the 3DS market, having
  co-invented the original protocol with [Visa](https://www.corbado.com/blog/visa-passkeys). They position
  themselves as a recognized global leader, serving over 5,000 financial institutions
  worldwide and processing transactions from 229 [countries](https://arcot.broadcom.com/).
  Their Arcot Network emphasizes a vast consortium data approach (claiming 600M+ device
  signatures, 150 trillion data points) to power their fraud scoring and risk
  [engines](https://www.broadcom.com/info/cybersecurity/3d-secure). They have a strong
  presence in Europe, Australia, and North
  [America](https://arcot.broadcom.com/hubfs/Broadcom%20PaySec/Resources/Arcot-TRA3DS.pdf).
- **Non-SPC FIDO Data Support (Frictionless):** Broadcom heavily emphasizes the richness
  of their data network and the use of AI/neural networks for fraud detection and
  risk-based assessment, going beyond standard EMV 3DS data
  [elements](https://www.broadcom.com/info/cybersecurity/3d-secure). They explicitly state
  their solution leverages data flowing through multiple issuers and incorporates digital
  data like device and
  [geolocation](https://www.software.broadcom.com/hubfs/Broadcom%20PaySec/Resources/ArcotNetwork_Brief.pdf).
  While not explicitly mentioning processing the _specific_ FIDO JSON structure from
  `threeDSRequestorAuthenticationData`, their focus on ingesting diverse data points for
  RBA strongly suggests they _could_ consume such data if provided, aligning with the
  intent of the EMVCo/FIDO guidance. Their platform aims to maximize frictionless
  approvals through superior risk
  [assessment](https://www.broadcom.com/info/cybersecurity/3d-secure).
- **SPC Support (Challenge):** Broadcom's documentation confirms support for FIDO
  [authenticators](https://www.corbado.com/glossary/authenticator) (Security Key, Biometric, Passkey) within
  their broader VIP Authentication Hub / Identity Security
  [suite](https://techdocs.broadcom.com/us/en/symantec-security-software/identity-security/vip-authentication-hub/3-3/Using/Authentication-services/factor-services/Fido-Microservice.html).
  Their 3DS ACS supports various challenge methods including OTPs and push notifications,
  and they mention support for
  [biometrics](https://www.broadcom.com/info/cybersecurity/3d-secure). They also offer
  [Delegated Authentication](https://www.corbado.com/blog/delegated-sca-psd3-passkeys)
  [capabilities](https://www.arcot.broadcom.com/hubfs/Broadcom%20PaySec/Resources/Arcot%20Delegated%20Authentication%20Brief.pdf)
  and have introduced post-challenge risk evaluation
  [features](https://techdocs.broadcom.com/us/en/payment-security/arcot-network/arcot-for-issuers/AFI/manage-risk/managing-rules/understanding-the-building-blocks-of-rules/ChallengeRiskEval.html).
  However, explicit confirmation that their _EMV 3DS ACS product_ currently supports _SPC_
  as a specific challenge method (requiring EMV 3DS v2.3+ capabilities and the two-AReq
  flow) is absent in the provided
  [documentation](https://www.broadcom.com/info/cybersecurity/3d-secure). While they are a
  major player likely capable of implementing it, current public-facing material focuses
  more heavily on their RBA engine and traditional/OOB challenge
  [methods](https://www.broadcom.com/info/cybersecurity/3d-secure).

### 3.3 Netcetera 3DS ACS

- **Market Presence:** Netcetera positions itself as a significant international payment
  player, particularly strong in Europe and the Middle
  [East](https://www.fime.com/blog/case-studies-16/post/ensuring-emv-3ds-compliance-with-the-latest-standards-376).
  They state their ACS is used by over 800 banks/issuers, securing 50+ million cards
  [worldwide](https://www.fime.com/blog/case-studies-16/post/ensuring-emv-3ds-compliance-with-the-latest-standards-376).
  They emphasize certifications with all major card networks (Visa,
  [Mastercard](https://www.corbado.com/blog/mastercard-passkeys), Amex, Discover, JCB, UnionPay, etc.) and
  [PCI](https://www.corbado.com/blog/pci-dss-4-0-authentication-passkeys)
  [compliance](https://thepaymentsassociation.org/article/netcetera-3ds-acs-is-discover-global-network-certified/).
  They were notably the first ACS vendor worldwide to achieve EMV 3DS 2.3.1
  [certification](https://www.netcetera.com/stories/expertise/emv-3ds-new-opportunities.html).
- **Non-SPC FIDO Data Support (Frictionless):** Netcetera's documentation highlights the
  importance of data gathered via the 3DSMethod for ACS risk assessment to increase
  frictionless
  [authentication](https://3dss.netcetera.com/3dsserver/doc/2.10.0.0/frequently-asked-questions).
  They offer integration with risk
  [tools](https://www.netcetera.com/payments/Issuing/3DS-Issuing-Service.html). However,
  specific confirmation of processing prior merchant FIDO authentication data (from
  `threeDSRequestorAuthenticationInfo`) for risk assessment is not explicitly mentioned in
  the reviewed
  [materials](https://www.netcetera.com/payments/Issuing/3DS-Issuing-Service.html).
- **SPC Support (Challenge):** Netcetera demonstrates strong support for SPC. They were
  the first vendor globally certified for EMV 3DS 2.3.1, the version incorporating SPC.
  They participated in the [Visa](https://www.corbado.com/blog/visa-passkeys) SPC pilot, providing the v2.3.1
  [components](https://www.w3.org/2023/Talks/visa-spc-20230911.pdf). Their product
  documentation explicitly defines SPC. They have conducted webinars discussing FIDO and
  SPC [integration](https://www.netcetera.com/payments/knowledge-hub.html) and published
  articles highlighting [SPC's](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)
  [benefits](https://www.netcetera.com/stories/expertise/Secure-Payment-Confirmation-meets-customer-demands.html).
  This combination of certification, pilot participation, and explicit documentation
  confirms their support for SPC challenges.

### 3.4 Worldline 3DS ACS

- **Market Presence:** Worldline positions itself as the European leader in payment and
  transactional services and a major global player (claiming #4 worldwide payment player
  [status)](https://worldline.com/en/home/main-navigation/solutions/financial-institutions/authentication-and-security/authentication-solutions/access-control-server).
  They process billions of transactions annually and emphasize guaranteed compliance,
  fraud control using AI/ML, and
  [scalability](https://worldline.com/en/home/main-navigation/solutions/financial-institutions/authentication-and-security/authentication-solutions/access-control-server).
  Their ACS is stated to be EMV 3DS certified and compliant with major schemes (Visa
  Secure, [Mastercard Identity Check](https://www.corbado.com/blog/mastercard-identity-check)) and
  [PSD2](https://www.corbado.com/blog/psd2-passkeys). They report processing over 2.4 billion 3DS transactions
  yearly for over 100 issuers.
- **Non-SPC FIDO Data Support (Frictionless):** Worldline's ACS offering includes an RBA
  rules engine allowing issuers to configure frictionless or challenge flows based on
  [risk](https://worldline.com/en/home/main-navigation/solutions/financial-institutions/authentication-and-security/authentication-solutions/access-control-server).
  Their broader "Trusted Authentication" solution leverages device intelligence and
  behavioral [analysis](https://business.worldline.com/l/130471/2025-02-04/33tlg4). While
  they support FIDO
  [generally](https://www.biometricupdate.com/202308/worldline-gets-fido-certified-vincss-makes-deal-to-boost-passwordless-authentication),
  explicit confirmation of processing prior merchant FIDO data (non-SPC) within the ACS
  for risk assessment is not detailed in the provided
  [snippets](https://worldline.com/en/home/main-navigation/solutions/financial-institutions/authentication-and-security/authentication-solutions/access-control-server).
- **SPC Support (Challenge):** Worldline shows clear indications of supporting SPC. Their
  documentation acknowledges the evolution of EMV 3DS 2.3 to include
  [SPC/FIDO](https://worldline.com/content/dam/worldline/global/documents/reports/Fraud%20Prevention%20Report%202022_Worldline.pdf).
  They explicitly market their "WL Trusted Authentication" solution as supporting FIDO
  [authentication](https://worldline.com/content/dam/worldline/global/documents/reports/Fraud%20Prevention%20Report%202022_Worldline.pdf)
  and offer a "WL FIDO Server" suitable for "3DS use cases, with emvCO2.3 and SPC.

### 3.5 GPayments 3DS ACS

- **Market Presence:** GPayments positions ActiveAccess as a "robust market leading Access
  Control Server (ACS) platform" with over 20 years in the 3D Secure
  [space](https://www.gpayments.com/solutions/3d-secure-acs-activeaccess/). They are
  certified with major card schemes (Visa Secure,
  [Mastercard Identity Check](https://www.corbado.com/blog/mastercard-identity-check), JCB J/Secure) for both
  3DS1 and EMV [3DS](https://www.gpayments.com/solutions/3d-secure-acs-activeaccess/).
  Their solution can be
  [deployed on-premise or cloud-hosted](https://www.gpayments.com/solutions/3d-secure-acs-activeaccess/).
  Market reports identify GPayments as a notable player offering ACS
  [solutions](https://www.grandviewresearch.com/industry-analysis/3d-secure-payment-authentication-market-report).
- **Non-SPC FIDO Data Support (Frictionless):** ActiveAccess supports integration with
  third-party RBA solutions and utilizes various parameters for its own risk
  [assessment](https://www.gpayments.com/solutions/3d-secure-acs-activeaccess/). However,
  the provided documentation does not explicitly mention support for ingesting or using
  prior merchant FIDO authentication data (non-SPC) for frictionless risk
  [assessment](https://www.gpayments.com/solutions/3d-secure-acs-activeaccess/).
- **SPC Support (Challenge):** The reviewed documentation for ActiveAccess does not
  explicitly mention support for
  [Secure Payment Confirmation](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) (SPC), WebAuthn
  challenges, or FIDO challenges as part of its challenge flow
  [capabilities](https://www.gpayments.com/solutions/3d-secure-acs-activeaccess/). While
  they support various authentication methods including OOB (which can encompass
  [biometrics)](https://www.gpayments.com/solutions/3d-secure-acs-activeaccess/), specific
  SPC support is unclear from the available
  [information](https://www.gpayments.com/solutions/3d-secure-acs-activeaccess/).

### 3.6 Visa (Visa Secure) 3DS ACS

- **Market Presence:** [Visa](https://www.corbado.com/blog/visa-passkeys), as a major global payment network,
  defines the [Visa Secure](https://www.corbado.com/blog/visa-secure) program based on the EMV 3DS
  [standard](https://usa.visa.com/run-your-business/small-business-tools/payment-technology/visa-secure.html).
  They pioneered the original 3DS
  [protocol](https://usa.visa.com/run-your-business/small-business-tools/payment-technology/visa-secure.html).
  Rather than primarily acting as a direct ACS _vendor_ in the same way as technology
  companies like Entersekt or Broadcom, Visa operates the program and relies on a list of
  approved 3DS vendors (including ACS providers) whose products are certified compliant
  with EMV 3DS and [Visa Secure](https://www.corbado.com/blog/visa-secure)
  [rules](https://usa.visa.com/run-your-business/small-business-tools/payment-technology/visa-secure.html).
  Issuers typically procure ACS solutions from these certified vendors. Visa itself
  focuses on the network (Directory Server), defining program rules, promoting adoption,
  and driving innovation like SPC
  [pilots](https://www.w3.org/2023/Talks/visa-spc-20230911.pdf).
- **Non-SPC FIDO Data Support (Frictionless):** [Visa Secure](https://www.corbado.com/blog/visa-secure), based on
  EMV 3DS, inherently supports the exchange of rich data for risk assessment to enable
  frictionless
  [flow](https://usa.visa.com/run-your-business/small-business-tools/payment-technology/visa-secure.html).
  The
  [EMVCo/FIDO framework](https://fidoalliance.org/wp-content/uploads/2020/09/FIDO-and-EMV-3DS-Technical-Note-2020-09-01.pdf)
  for passing prior FIDO data operates within the Visa Secure ecosystem if the chosen ACS
  vendor supports processing
  [it](https://usa.visa.com/run-your-business/small-business-tools/payment-technology/visa-secure.html).
- **SPC Support (Challenge):** Visa is actively involved in piloting and promoting SPC.
  They are working with partners (like Netcetera and Modirum/Entersekt in pilots) to test
  and refine the SPC flow within the 3DS
  [protocol](https://www.w3.org/2023/Talks/visa-spc-20230911.pdf). This strong engagement
  indicates strategic support for SPC as a challenge method within the Visa Secure
  program, contingent on ecosystem readiness (ACS, merchant, browser
  [support)](https://www.w3.org/2023/Talks/visa-spc-20230911.pdf).

### 3.7 Mastercard (Identity Check) 3DS ACS

- **Market Presence:** Similar to Visa, [Mastercard](https://www.corbado.com/blog/mastercard-passkeys) operates
  the [Mastercard Identity Check](https://www.corbado.com/blog/mastercard-identity-check) program based on EMV
  [3DS](https://www.mastercard.com/global/en/business/overview/safety-and-security/identity-check.html).
  They provide options for issuers and [merchants](https://www.corbado.com/glossary/merchant), including stand-in
  processing and potentially leveraging partners or subsidiaries like
  [NuData](https://www.mastercard.com/content/dam/public/mastercardcom/globalrisk/pdf/Top-10-Things-to-Know-About-3DS.pdf).
  Mastercard acquired NuData Security, a behavioral biometrics company, in 2017, enhancing
  its risk assessment
  [capabilities](https://www.retaildive.com/news/mastercard-acquires-behavioral-biometrics-security-firm-nudata-to-boost-iot/439407/).
  They also emphasize ongoing innovation in biometrics, RBA, and
  [AI](https://developer.mastercard.com/product/identity-check/). Like Visa, they rely on
  certified vendors for core ACS components but may offer bundled services or leverage
  acquired
  [technology](https://www.mastercard.com/content/dam/public/mastercardcom/globalrisk/pdf/Top-10-Things-to-Know-About-3DS.pdf).
- **Non-SPC FIDO Data Support (Frictionless):** Mastercard Identity Check leverages the
  rich data exchange of EMV 3DS 2.x for improved risk decisioning and frictionless
  [flow](https://www.mastercard.com/global/en/business/overview/safety-and-security/identity-check.html).
  Their acquisition of NuData suggests a strong focus on behavioral analytics as part of
  this risk
  [assessment](https://www.retaildive.com/news/mastercard-acquires-behavioral-biometrics-security-firm-nudata-to-boost-iot/439407/).
  Support for processing prior merchant FIDO data would depend on the specific ACS
  implementation used by the issuer within the Identity Check
  [program](https://www.mastercard.com/global/en/business/overview/safety-and-security/identity-check.html).
- **SPC Support (Challenge):** Mastercard is a key member of EMVCo and involved in the
  development of EMV 3DS standards, including v2.3 which supports SPC. They are also
  promoting [passkey adoption](https://www.corbado.com/blog/passkey-adoption-business-case) more
  [broadly](https://fidoalliance.org/goodbye-to-manual-card-entry-mastercard-reveals-when-the-new-era-of-one-click-online-payments-begins/).
  More details can be found
  [here](https://developer.mastercard.com/product/identity-check/). They are a strong SPC
  supporter and push towards modern authentication methods.

### 3.8 Other 3DS ACS Vendors

The EMV 3DS ACS market features numerous providers beyond those detailed above. Vendors
such as /n software, RSA, 2C2P, 3dsecure.[io](https://www.corbado.com/blog/webauthn-errors), Adyen, ACI
Worldwide, Computop, and others also offer certified solutions or play significant roles
in specific regions or segments. This analysis aims to cover prominent global players but
is not exhaustive due to the market's dynamic nature. Vendor capabilities, particularly
regarding emerging standards like SPC, evolve rapidly. If you notice any inaccuracies or
have updated information on vendor support for FIDO data or Secure Payment Confirmation,
please reach out so we can ensure this overview remains current and accurate.

## 4. Issuer Passkey Authentication via Secure Payment Confirmation

### 4.1 Mechanism Explained: Issuer as Relying Party

A core principle of using Secure Payment Confirmation (SPC) within the EMV 3DS challenge
flow is that the **card issuer** (or a party explicitly delegated by the issuer, such as a
payment scheme) functions as the **FIDO Relying Party
([RP](https://www.w3.org/blog/wpwg/2021/02/18/an-emv-3-d-secure-view-of-emvco-fido-and-w3c-activities/))**.
This is fundamentally different from the non-SPC FIDO data flow described earlier, where
the merchant typically acts as the RP for its own login/authentication
[purposes](https://fidoalliance.org/wp-content/uploads/2020/09/FIDO-and-EMV-3DS-Technical-Note-2020-09-01.pdf).

For SPC to function in a 3DS challenge, the following steps are involved:

1. **Enrollment:** The cardholder must first register a FIDO
   [authenticator](https://www.corbado.com/glossary/authenticator) (e.g.,
   [device biometrics](https://www.corbado.com/blog/passkeys-local-biometrics) like
   fingerprint/[face ID](https://www.corbado.com/faq/is-face-id-passkey), device PIN, or a roaming
   [security key](https://www.corbado.com/glossary/security-key)) with their issuing bank. This process creates a
   passkey, where the public key and a unique credential identifier are stored by the
   issuer and associated with the cardholder's account or specific payment
   [card](https://www.w3.org/blog/wpwg/2021/02/18/an-emv-3-d-secure-view-of-emvco-fido-and-w3c-activities/).
   Enrollment might occur within the bank's mobile app, online
   [banking](https://www.corbado.com/passkeys-for-banking) portal, or potentially offered after a successful
   traditional 3DS
   [challenge](https://fidoalliance.org/white-paper-secure-payment-confirmation/).
   Crucially, for SPC to be invoked by a third party like a merchant website, the
   credential must typically be created with explicit user consent allowing its use in
   such contexts, often involving specific WebAuthn extensions during
   [registration](https://www.w3.org/TR/secure-payment-confirmation/).
2. **Authentication (during 3DS Challenge):**
    - When a 3DS transaction triggers a challenge, and the issuer/ACS supports and selects
      SPC, the ACS identifies the relevant FIDO
      [credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle)(s) linked to the cardholder and
      [device](https://fidoalliance.org/white-paper-secure-payment-confirmation/).
    - The ACS includes these [credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle)(s), along
      with a unique [cryptographic challenge](https://www.corbado.com/glossary/cryptographic-challenge) and
      transaction details (amount, currency, payee name/origin, instrument icon/display
      name), in the Authentication Response (ARes) sent back to the 3DS
      Server/[Requestor](https://www.nsoftware.com/kb/entries/04252301).
    - The [merchant's](https://www.corbado.com/glossary/merchant) 3DS Requestor component uses this information
      from the ARes to invoke the browser's SPC API.
    - The browser presents a standardized, secure dialog displaying the transaction
      details provided by the ACS.
    - The user confirms the transaction and authenticates using their registered FIDO
      authenticator (e.g., touching a fingerprint sensor, facial recognition, entering
      device PIN, tapping a [security key](https://www.corbado.com/glossary/security-key)). This action unlocks
      the private key stored securely on the device/authenticator.
    - The authenticator signs the presented transaction details and the cryptographic
      challenge received from the ACS.
    - The browser returns the resulting FIDO assertion (the signed data payload) to the
      [merchant's](https://www.corbado.com/glossary/merchant) 3DS Requestor.
    - The 3DS Requestor transmits this assertion back to the Issuer ACS, typically
      encapsulated within a second AReq message.
    - The Issuer/ACS, acting as the authoritative
      [Relying Party](https://www.corbado.com/glossary/relying-party), uses the cardholder's previously stored
      public key to cryptographically verify the signature on the assertion. Successful
      verification confirms that the legitimate cardholder, using their registered
      authenticator, approved the specific transaction details presented.

### 4.2 EMV 3DS Protocol Flow with SPC Challenge

The integration of SPC into the EMV 3DS challenge flow necessitates modifications to the
standard message sequence, typically involving two AReq/ARes exchanges:

1. **Initial Authentication Request (AReq #1):** The merchant/3DS Server initiates the 3DS
   process by sending an AReq containing transaction and device data. To signal capability
   for SPC, the request may include an indicator like `threeDSRequestorSpcSupport` set to
   'Y' (or similar, depending on the ACS vendor's implementation).
2. **Initial Authentication Response (ARes #1):** If the ACS determines a challenge is
   required and opts for SPC, it responds with an ARes indicating this. The `transStatus`
   might be set to 'S' (indicating SPC required) or another specific value. This ARes
   contains the necessary data payload for the SPC API call.
3. **SPC API Invocation & FIDO Authentication:** The merchant's 3DS Requestor component
   receives ARes #1 and uses the payload to invoke the browser's SPC API. The user
   interacts with their authenticator via the browser's secure UI.
4. **FIDO Assertion Return:** Upon successful user authentication, the browser returns the
   FIDO assertion data to the 3DS Requestor.
5. **Second Authentication Request (AReq #2):** The 3DS Requestor constructs and sends a
   _second_ AReq message to the ACS. This message's primary purpose is to transport the
   FIDO assertion data. It typically includes:
    - `ReqAuthData`: Containing the FIDO assertion.
    - `ReqAuthMethod`: Set to '09' (or the designated value for SPC/FIDO assertion.
    - Potentially the `AuthenticationInformation` value from ARes #1 to link the requests.
    - Optionally, an `SPCIncompletionIndicator` if the SPC API call failed or timed out.
6. **Final Authentication Response (ARes #2):** The ACS receives AReq #2, validates the
   FIDO assertion using the cardholder's public key, and determines the final
   authentication outcome. It sends back ARes #2 containing the definitive transaction
   status (e.g., `transStatus` = 'Y' for Authentication Successful, 'N' for Failed).

The following diagram shows the complete message exchange between parties, highlighting
the additional round trip introduced by SPC.

This two-AReq flow represents a deviation from traditional 3DS challenge methods (like OTP
or OOB handled via CReq/CRes or RReq/RRes messages) which typically complete within the
initial AReq/ARes cycle after a `transStatus` = 'C' is received. While the user
interaction part of SPC (biometric scan, PIN entry) is often significantly faster than
typing an [OTP](https://www.w3.org/2024/Talks/w3c-in-europe/fime-payments-spc.pdf), the
introduction of a second full AReq/ARes round trip adds network latency between the 3DS
Server, Directory Server, and ACS. Implementers and vendors must carefully optimize this
flow and handle potential timeouts to ensure the overall end-to-end transaction time
remains competitive and meets user expectations.

## 5. Ecosystem Considerations for SPC

### 5.1 SPC as a Global Standard (W3C/EMVCo)

Secure Payment Confirmation is positioned for global adoption due to its dual
standardization. It is formally defined as a web standard by the World Wide Web Consortium
(W3C), having reached Candidate Recommendation status in mid-2023 with ongoing work
towards becoming a full
[Recommendation](https://www.w3.org/2023/Talks/visa-spc-20230911.pdf). Simultaneously, SPC
has been integrated into the EMV® [3-D Secure](https://www.corbado.com/glossary/3d-secure) specifications
starting with version 2.3, managed by EMVCo, the global technical body for payment
[standards](https://www.w3.org/2024/Talks/w3c-in-europe/fime-payments-spc.pdf). This
integration ensures that SPC functions within the established global framework for
[CNP](https://www.corbado.com/glossary/cnp) transaction authentication. The collaboration between W3C, FIDO
Alliance, and EMVCo underscores the industry-wide effort to create interoperable standards
for secure and
[user-friendly online payments](https://www.w3.org/2024/Talks/w3c-in-europe/fime-payments-spc.pdf).

### 5.2 Applicability Beyond Regulatory Mandates (e.g., US, Canada)

While [SPC's](https://www.corbado.com/blog/dynamic-linking-passkeys-spc) design, particularly its ability to
cryptographically link user authentication to specific transaction details
("[dynamic linking](https://www.corbado.com/blog/dynamic-linking-passkeys-spc)"), helps satisfy
[Strong Customer Authentication](https://www.corbado.com/faq/sca-psd2-importance) (SCA) requirements under
regulations like Europe's Payment Services Directive (PSD2), its utility is not confined
to these mandated regions. SPC is a global technical standard applicable in any market,
including the United States and Canada, provided the necessary ecosystem components are in
[place](https://www.w3.org/2023/Talks/visa-spc-20230911.pdf).

In markets without explicit SCA mandates for every transaction, the primary drivers for
adopting SPC are:

- **Improved User Experience:** Offering a potentially faster and more convenient
  challenge method (e.g., using [device biometrics](https://www.corbado.com/blog/passkeys-local-biometrics))
  compared to traditional OTPs or knowledge-based questions, potentially reducing
  [cart abandonment](https://www.corbado.com/blog/ecommerce-authentication). Pilots have shown significant
  reductions in authentication time compared to traditional
  [challenges](https://sdtimes.com/w3c-advances-technology-to-streamline-payment-authentication-secure-payment-confirmation-spc-published-as-a-candidate-recommendation/).
- **Enhanced Security:** FIDO-based authentication inherent in SPC is resistant to
  [phishing attacks](https://www.corbado.com/blog/3ds-authentication-failed),
  [credential stuffing](https://www.corbado.com/glossary/credential-stuffing), and other common threats targeting
  passwords and OTPs.

Therefore, issuers and merchants in regions like North America may choose to implement SPC
strategically to enhance security and provide a better customer experience, even without a
regulatory requirement to do so for all transactions.

### 5.3 Ecosystem Dependencies and Readiness for SPC & FIDO/Passkeys

The successful deployment and widespread adoption of Secure Payment Confirmation (SPC)
depend heavily on coordinated readiness across multiple components of the payment
ecosystem. While the underlying FIDO standards and passkey technology are maturing
rapidly, specific browser-level support for the SPC API and full integration across the
payment chain remain critical hurdles. Other ecosystem players are generally advancing
well.

**Ecosystem Readiness Summary (Status May 2025)**

| Ecosystem Actor                   | SPC Readiness  | FIDO/Passkey Readiness (General) | Key Notes (May 2025)                                                                                                                                                                                                                                             |
| :-------------------------------- | :------------- | :------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **User Devices & Authenticators** | ❌ Not used    | ✅ Ready                         | Virtually every modern laptop, phone, and security key ships with FIDO2/WebAuthn authenticators. Billions are already available to consumers. Hardware is not the bottleneck.                                                                                    |
| **Web Browsers (Software)**       | ❌ Bottleneck  | ✅ Ready                         | **SPC:** Chromium (Chrome/Edge ≥ 95) supports baseline SPC v1, but advanced features are experimental. **Safari (macOS & iOS) and Firefox offer NO SPC support.** **General FIDO/Passkey:** Full WebAuthn support across major browsers for login, etc.          |
| **Issuers & ACS Vendors**         | ⚠️ Advancing   | ✅ Advancing                     | **SPC:** Market leaders certified for EMV 3DS 2.3.1 can run SPC; others moving from pilot to production. **General FIDO:** Many support FIDO for app auth/OOB; RBA data ingestion capability exists but adoption varies. Requires FIDO server/RP infrastructure. |
| **Merchants**                     | ❌ No support  | ✅ Advancing                     | **SPC:** Requires EMV 3DS v2.3+ stack & browser logic. Early adopters report benefits. **General FIDO:** Growing use for login by adopting passkeys; can pass data via `threeDSRequestorAuthenticationInfo`. Integration effort needed.                          |
| **PSPs / 3DS Servers**            | ⚠️ Rolling-out | ✅ Advancing                     | **SPC:** Requires EMV 3DS v2.3+ stack & browser logic. Early adopters report benefits. **General FIDO:** Growing use for login; can pass data via `threeDSRequestorAuthenticationInfo`. Integration effort needed.                                               |
| **Scheme Directory Servers**      | ✅ Ready       | ✅ Ready                         | Infrastructure (Visa, Mastercard, etc.) updated for EMV 3DS 2.3/2.3.1 messages (incl. SPC & FIDO data fields) since 2021 way before passkeys have become mainstream.                                                                                             |

**What this means in practice (May 2025)**

The primary gating factor for **SPC adoption** is the
[user-agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) (browser) layer:

- **Safari (macOS & iOS):** ❌ WebKit still lacks the `secure-payment-confirmation`
  Payment Request method. Any site visited in Safari must fall back to other
  authentication methods (OTP, OOB, potentially non-SPC WebAuthn experiences). Apple has
  not expressed interest to implement the extension.
- **Chrome / Edge (Chromium):** ⚠️ Baseline SPC (credential creation + authentication) is
  stable, but keys are not yet stored in hardware
  [authenticators](https://www.corbado.com/glossary/authenticator) and have only be used in pilots. Implementers
  should expect potential breaking changes and be prepared to gate functionality based on
  API availability checks (e.g., `canMakePayment()`) or feature flags.
- **Firefox:** ❌ The team has signalled interest but has no committed implementation
  timeline; merchants must plan for graceful fallback paths.

Because issuer infrastructure (ACS, FIDO servers) and scheme directory servers are largely
ready or advancing rapidly, and
merchant/[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) tools are becoming
available, **the main barrier to widespread SPC usage is browser support.** Once browser
coverage improves, the remaining tasks primarily involve
merchant/[PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk) integration (upgrading to
EMV 3DS v2.3+, adding SPC invocation logic, handling the two-AReq flow) and scaling up
issuer enrollment of passkeys specifically for payment contexts.

**For now, expect SPC to appear only for a limited slice of transactions. Until Safari
(and thus the entire iOS ecosystem) ships support, SPC cannot achieve market support.**

![overview secure payment confirmation](https://s3.eu-central-1.amazonaws.com/corbado-cloud-staging-website-assets/overview_secure_payment_confirmation_e92645aa7f.png)

## 6. Conclusion and Strategic Recommendations

### 6.1 Summary: Frictionless Focus Now, SPC Preparation for Later

The analysis reveals a clear divergence in the readiness of the two primary FIDO
integrations within EMV 3DS as of May 2025. While the foundational elements for **Secure
Payment Confirmation (SPC)** as a challenge method are advancing – particularly issuer/ACS
capabilities and scheme readiness – its widespread adoption is significantly hampered by
the **critical bottleneck of browser support**, most notably the lack of implementation in
Apple's Safari (blocking all [iOS](https://www.corbado.com/blog/webauthn-errors)/iPadOS devices) and Firefox,
along with limitations in current Chromium implementations. SPC remains a promising future
state, but it is not a practical, ubiquitous solution today.

### 6.2 Recommendations for Key Participants

Based on the current ecosystem state we following recommendations are in place:

- **Merchants:**
    - **Prioritize Passkey Adoption:** Implement passkeys for user login and
      authentication. Beyond improving your own security and user experience (factors not
      detailed here), this creates the data needed for 3DS frictionless flows.
    - **Pass FIDO Data:** Ensure your 3DS integration correctly populates the
      `threeDSRequestorAuthenticationInfo` field with details of successful prior passkey
      authentications during the checkout session. Work with your
      [PSP](https://www.corbado.com/blog/payment-provider-passkeys-third-party-sdk)/3DS Server provider to enable
      this.
- **Issuers:**
    - **Enroll User Passkeys:** Begin offering and encouraging cardholders to enroll
      passkeys directly with you (for banking app access, future SPC, etc.). Build the
      necessary FIDO Relying Party infrastructure.
    - **Leverage Merchant Passkey Data Now:** Instruct your ACS vendor to ingest and
      utilize the FIDO data passed by merchants (`threeDSRequestorAuthenticationInfo`) as
      a strong positive signal within your RBA engine. Maintain records of trusted
      merchant passkeys associated with users where possible. Aim to significantly
      increase frictionless approvals for transactions preceded by a strong merchant
      passkey authentication.
    - **Prepare for SPC, Monitor Actively:** Ensure your ACS roadmap includes full EMV 3DS
      v2.3.1+ SPC support, but treat it as a future enhancement. Continuously monitor
      browser developments (especially Safari) to gauge when SPC might become viable at
      scale.
- **ACS Vendors:**
    - **Enhance RBA with Passkey Intelligence:** Heavily invest in your RBA engine's
      ability to process and trust merchant-provided
      FIDO/[passkey data](https://www.corbado.com/blog/passkeys-privacy). Develop logic to track passkey usage
      across merchant purchases for a given user/device. Store public keys (from direct
      issuer enrollment) to verify the cryptographic integrity of merchant authentication
      data if provided. Tie successful passkey usage directly to higher frictionless
      approval rates.
    - **Build Robust SPC Capabilities:** Continue developing and certifying full SPC
      challenge flow support (EMV 3DS v2.3.1+) in readiness for future market adoption.
- **Payment Schemes/Networks:**
    - **Champion Frictionless FIDO Data:** Actively promote and potentially incentivize
      the passing and utilization of merchant FIDO authentication data
      (`threeDSRequestorAuthenticationInfo`) within the 3DS flow. Provide clear guidance
      and support to issuers and ACS vendors on leveraging this data effectively for RBA.
    - **Continue SPC Advocacy & Browser Engagement:** Maintain efforts to standardize and
      promote SPC, critically engaging with browser vendors (Apple, Mozilla, Google) to
      encourage full, interoperable implementation of the SPC API standard.

### 6.3 Overall Strategic Direction

The immediate, tangible opportunity lies in enhancing the **frictionless flow** by
leveraging the growing adoption of passkeys at the merchant level. All ecosystem
participants should prioritize enabling the creation, transmission, and intelligent
consumption of this prior authentication data within the existing EMV 3DS framework. This
path offers near-term benefits in reducing friction and potentially fraud without waiting
for universal SPC browser support. Concurrently, preparing the groundwork for SPC –
particularly issuer [passkey enrollment](https://www.corbado.com/blog/passkey-creation-best-practices) and ACS
readiness – ensures the ecosystem is positioned to adopt this superior challenge method
once the browser bottleneck is resolved.

## Frequently Asked Questions

### How does an issuer-registered passkey get used during an EMV 3DS SPC payment challenge?

In SPC, the issuer is the FIDO Relying Party. During a 3DS challenge the ACS provides
credential IDs and a cryptographic challenge to the merchant, which invokes the browser's
SPC API. The user authenticates via device biometric or PIN, the authenticator signs the
transaction details and the ACS cryptographically verifies the resulting FIDO assertion
against the stored public key to confirm cardholder consent.

### What does the two-AReq message flow mean for merchants implementing SPC in EMV 3DS?

SPC requires two full AReq/ARes round trips through the Directory Server to the ACS
instead of the single exchange used by traditional challenge methods. The first ARes
delivers the SPC payload and credential IDs; a second AReq carries the FIDO assertion back
for verification. This adds network latency, though biometric or PIN authentication is
typically faster than manual OTP entry.

### Why can't SPC be used for payments on iOS devices or in Firefox today?

Safari on macOS and iOS does not implement the secure-payment-confirmation Payment Request
method, and Apple has not expressed interest in adding it. Firefox has signalled interest
but has no committed implementation timeline. Because Safari controls the entire iOS and
iPadOS browser environment, SPC cannot reach market-wide scale until Apple ships support,
regardless of how ready issuers and ACS vendors are.

### Which ACS vendors have confirmed Secure Payment Confirmation support as of 2025?

As of May 2025, Netcetera, Worldline and Entersekt have confirmed SPC support. Netcetera
was the first ACS vendor globally certified for EMV 3DS 2.3.1 and participated in Visa's
SPC pilot alongside Modirum (now part of Entersekt). Broadcom Arcot and GPayments have not
publicly confirmed SPC-specific challenge support in their EMV 3DS ACS products.

### How should a merchant configure their 3DS integration to improve frictionless approval rates using passkeys?

Merchants should populate the `threeDSRequestorAuthenticationInfo` field with data from
successful passkey authentications during the checkout session. Supported since EMV 3DS
v2.1, this passes details including authentication time, FIDO Relying Party ID and
authenticator indicators to the issuer's ACS as a positive risk signal, increasing
frictionless approval likelihood without requiring a separate challenge step.