3-D Secure (3DS) & WebAuthn for Payment Providers

E-commerce continues to grow, with credit cards still being the go-to payment method for millions of online transactions every day. Unfortunately, the convenience of typing in a few credit card digits into the payment interface of your favorite online shop to pay comes with security risks: fraud, hacking attempts, and stolen card credentials are an ever-present threat for both consumers and businesses.

To prevent these risks there exists a protocol operating in quit for a few years already: 3-D Secure (3DS). Part of it is an authentication process that tries to make sure the person using a credit card for purchase is authorized to do so. To understand how this payment protocol works we will answer the following questions in this blog post:

• What is the process behind 3DS and what does EMVCo have to do with it?

• What are the different authentication methods used in?

• How can passkeys be implemented in 3DS flows to provide best possible protection for payment transactions?

• Why are large payment providers using passkeys in their 3DS process and how does this process look like?

3-D Secure (3DS) is an online payment security protocol originally introduced by Visa to protect card-not-present transactions (i.e. payments where the physical card isn’t used, such as online, phone, or mail purchases) and reduce fraud.

The name 3DS comes from three domains it links together:

• Issuer: The issuer is the bank or financial institution that provides the payment card to the consumer and approves or declines transactions on their behalf.

• Acquirer: The acquirer is the bank or payment processor that works with the merchant to accept card payments and route them through the network.

• Interoperability: Interoperability refers to the payment network (like Visa or Mastercard) that connects issuers and acquirers, enabling secure communication and transaction processing between them.

• Merchant: Initiates the online purchase, triggers 3DS to reduce fraud and meet Strong Customer Authentication (SCA) requirements. Receives the authentication result to continue or abort checkout.

• Payment Network: Defines the 3DS rules and technical specifications, operates the Directory Server that routes authentication messages, and ensures all parties follow uniform security standards.

• Payment Service Provider (PSP): The technology platform the merchant integrates. It packages the 3DS request, interfaces with the payment network, relays challenge data to the issuer, and returns the final authentication outcome to the acquirer.

As a whole process incorporating these three domains, a typical 3DS transaction could include the following steps:

1. Customer initiates payment on a merchant’s website or app using their credit or debit card.

2. Merchant sends transaction details (like amount, device info, and user behavior data) to the payment gateway, which forwards it to the 3DS server.

3. The 3DS server contacts the cardholder’s issuing bank (via the payment network) to request authentication.

4. The issuer analyzes the risk using the provided data and follows one of the following flows:

   • Frictionless Flow: If low risk, it may approve the transaction without additional steps

   • Challenge Flow: If higher risk, the user is prompted to verify their identity (e.g., via a one-time code, app push or passkeys)

5. Once authenticated (or deemed low risk), the issuer responds with an approval or denial.

6. The merchant proceeds with the authorization request and completes the transaction.

Lookup table for the diagramms:

3-D Secure (Three-Domain Secure) was developed in response to the rapid growth of e-commerce in the late 1990s and the corresponding rise in online credit card fraud. This initiative followed earlier industry attempts such as the Secure Electronic Transaction (SET) protocol. The protocol was initially designed by Visa in 1999, with the aim of providing an extra layer of authentication for online card transactions. 3DS was then introduce in the early 2000s under the label “Verified by Visa” and was soon adopted by other major card schemes. Over time, the standard was taken under the umbrella of EMVCo (a consortium owned by major payment networks)

EMVCo (Europay, Mastercard, Visa and Co.) is a global technical body owned by major payment networks (including Visa, Mastercard, American Express, Discover, JCB, and UnionPay) that develops and manages specifications to enhance the security and interoperability of payment systems worldwide. Let’s look at the role of EMVCo in 3-D Secure:

• Development and Maintenance: EMVCo develops, publishes, and maintains the EMV 3DS specifications, ensuring they evolve to address emerging security threats, regulatory changes (such as Strong Customer Authentication requirements), and new payment channels (e.g., mobile, IoT devices)

• Industry Collaboration: EMVCo collaborates with a broad range of stakeholders, including merchants, issuers, acquirers, payment networks, technology providers, and industry bodies like the PCI Security Standards Council and the FIDO Alliance, to ensure the protocol remains robust and interoperable

• Testing and Approval: EMVCo manages the testing and approval processes for EMV 3DS products to ensure compliance and interoperability across the payment’s ecosystem

Over the years there have been several improvements of the protocol, keeping it up to date and making sure new security features are added

Launched in the early 2000s, 3D Secure 1.0 was the first attempt at securing online card payments by verifying the cardholder’s identity. It introduced a static password system and redirected users to their bank’s authentication page. While it did help reduce fraud, the user experience was often poor, especially on mobile devices, and there was limited data sharing between merchants and issuers.

Baseline features:

• Static password authentication

• Full-page redirection to issuer site

• Minimal data exchange for risk evaluation

• No mobile or in-app support

3DS 2.0, introduced in 2016 by EMVCo, was a complete switch up of the protocol to address UX challenges and support modern devices. It moved away from static passwords, enabling biometric and risk-based authentication, and allowed merchants to send rich contextual data for smarter risk decisions, reducing friction for legitimate users.

Key improvements over 1.0:

• Risk-based authentication using up to 100 data points

• Frictionless flow support for low-risk transactions

• Support for biometrics, OTP, and device-bound credentials

• Mobile-first design and in-app authentication support

3DS 2.1 enhanced the usability and technical capabilities of 2.0. It focused on strengthening mobile experiences, improving SDKs for app-based authentication, and standardizing biometric flows. This version also included better tools for UI rendering and error handling.

Key improvements over 2.0:

• Enhanced SDKs for native mobile apps (iOS & Android)

• More consistent biometric authentication support

• Improved error handling and UI feedback mechanisms

• Better issuer-side integration for smoother UX

3DS 2.2 added critical features to help issuers and merchants comply with Europe’s PSD2 regulation. It enabled delegated authentication (allowing trusted merchants to handle identity checks) and added support for various SCA exemptions to minimize user friction in compliant scenarios. Also, from version 2.2 onwards it is possible to use FIDO information in the frictionless flow, therefore if merchant has recently performed a strong FIDO authentication (e.g., using biometrics or a passkey) for the user session initiating the purchase, this information serves as a additional risk signal for the issuer's ACS.

Key improvements over 2.1:

• Support for PSD2 Strong Customer Authentication (SCA)

• Support of FIDO Information about prior authentications

• Delegated authentication support for trusted merchants

• Handling of exceptions (e.g. low-risk, recurring transactions)

• Expanded frictionless authentication capabilities

The latest update, 3DS 2.3, continues refining the protocol by expanding device support (including IoT and wearables), enhancing the data passed for risk evaluation, and improving the performance of frictionless flows. While adoption is still growing, it represents the most flexible and device-agnostic version yet.

Key improvements over 2.2:

• Broader support for non-browser and emerging devices

• Richer contextual and device data exchange

• Optimized frictionless authentication paths

• Improved support for embedded and low-power platforms

A crucial phase in any 3DS flow is the authentication step, during which the Issuer verifies that the person initiating the transaction is indeed the legitimate cardholder.

• Password-based: Historically, password-based prompts represented the earliest solution, but they came with usability drawbacks and weaker security, as passwords are regularly forgotten or phished from the user without him even realizing. Password-based authentication has been around for the longest time of all these authentication methods making it easy to implement in a short time. With that passwords do also have several drawbacks which make them worse than other authentication methods: The security aspect is weak as passwords can be phished and users tend to reuse them all the time. From a UX perspective passwords are also not optimal since they are cumbersome to remember, and users have to manage keeping track of them for lots of accounts

• SMS OTP: Over time, many Issuers shifted to SMS one-time passcodes (OTP) for their familiarity and near-universal availability, though SMS has its own downsides, such as interception or user inconvenience in areas of poor mobile service. Also costs tend to be high, especially if the user base is as big as it is with most banks.

• App-based push notifications: More recently, authentication with mobile apps provided by the bank of the customer (often paired with device biometrics) has grown in popularity. After initiating a payment, the customer gets a push notification that allows him to approve transactions in real time. This approach improves security by tying authentication to a trusted device. However, an app needs to be installed most of the time.

• FIDO-based authentication: Finally, passkeys, are emerging as a robust, password-free and phishing-resistant alternative that pairs public-key cryptography with an intuitive user experience that does not interfere with a quick checkout and payment. Cu, they are not included in the 3D Secure flow therefore if passkeys want to be used the authentication with them will happen outside the typical 3DS process. This is the case because of Relying Party (RP) Domain Restrictions: For passkeys a tie is created from a credential to the web domain (the Relying Party or RP) where it was registered. In a typical e-commerce transaction using 3DS, the user interacts primarily with the merchant domain, while the entity ultimately responsible for authentication and risk decisioning is the issuer (e.g., bank). Directly using an issuer's passkey on the merchant's domain, or vice-versa, violates this same-origin principle inherent in standard WebAuthn. An alternative that is also based on FIDO standards that is gaining in popularity is the Secure Payment Confirmation in the Challenge Flow

We already noticed that passkeys / WebAuthn are built on a strict same-origin model: the page that asks for the credential must belong to the web origin that issued it. 3-D Secure already defines an “Access Control Server” (ACS) page that lives on the bank’s domain and can pop up during checkout. By re-using this existing ACS step, we simply let the browser redirect to (or go via iframe to) `bank.com` for a moment. Because the origin now matches, the standard WebAuthn API can call the user’s passkey. For the customer, this would look like a short jump (or a snug little window) with the bank’s logo and a biometric prompt where the passkeys could be used.

Redirect/iFrame flow:

1. Shopper hits “Pay” on website `merchant.com`.

2. Merchant’s 3-D Secure system says “Bank needs extra verification.”

3. Browser loads a page from `bank.com` (redirect or iframe).

4. Bank page pops the passkey sheet and shopper uses Face ID / fingerprint to confirm.

5. Bank OKs the payment and the browser returns to `merchant.com`.

Because redirects hurt UX, payment and browser vendors designed Secure Payment Confirmation (SPC) to delegate passkey use across origins in a controlled way. The issuer’s ACS still decides whether extra auth is needed, but it sends back a signed challenge and credential IDs. The browser acting as a trusted intermediary, displays a native sheet on the merchant’s page, collects the passkey assertion for `bank.com`, and hands it to the merchant to forward. This keeps the user in context while still respecting the bank’s ownership of the credential.

Secure Payment Confirmation flow:

1. Shopper hits “Pay” on `merchant.com`.
2. Merchant’s 3-D Secure request comes back with bank passkey details (credential ID + challenge).
3. Merchant calls the browser API securePaymentConfirmation() and says, “Please authenticate for `bank.com`.”
4. Browser shows the passkey sheet; shopper confirms.
5. Browser returns a signed message; merchant forwards it to the bank; payment approved.

In the financial services world, user security remains the top priority, as card fraud and data breaches pose a constant threat. At the same time, a smooth user experience is essential, since customers now demand frictionless payment flows that don’t compromise their safety while still making payment online easy.

Major payment providers like Mastercard and Visa have already turned to passkeys as they see their benefits firsthand from collaboration with FIDO:

Mastercard has steadily expanded its card security strategies beyond conventional methods like SMS OTPs, largely due to rising fraud threats and changing customer expectations. In fact, the company notes that 80% of confirmed data breaches are related to weak or stolen passwords, explaining the need for a stronger security model. Recognizing that its existing platform, often referred to as Identity Check, needed a more advanced, user-friendly approach, Mastercard began incorporating passkeys into its Token Authentication System (TAS) workflows. This move allows consumers to authenticate with a tap or biometric input, completely bypassing passwords or code entry, while still benefiting from Mastercard’s global fraud protections. It also reflects the statistic that 90% of users believe biometrics are more secure and convenient than passwords, making passkeys a natural fit. As a result, users experience fewer interruptions, and the Issuers see stronger validation signals thanks to FIDO-based public key cryptography. Differently to 3DS, TAS is triggered my Mastercard as the issuer and not the merchant during check-out.

Visa’s well-known Verified by Visa program evolved significantly over the years, embracing new technologies to balance security with a frictionless checkout. Passkeys emerged as a standout solution for addressing both issues. In Visa’s deployment of Verified by Visa (now called Visa Secure), passkeys replace vulnerable passwords and cut down on abandoned transactions caused by cumbersome log-in prompts. The result is a faster yet highly secure approval flow. Visa and its Issuers gain cryptographically verified confirmations of cardholder identity, and cardholders can get through checkout without worrying passwords or SMS codes. Again, it is important to mention that Visa Secure is an umbrella name for the secure authentication that Visa provides. The authn with passkeys is therefore not part of 3DS but an own implementation by Visa.

When paying online often you can choose to go for a PayPal payment instead of using your banks debit/credit card. Let’s look at how the process and the underlying protocols used here are different to 3-D Secure:

1. Selecting PayPal at checkout instead of credit card payment and getting redirected to PayPal
2. Authentication with passkeys as the primary phishing-resistant method (you will be prompted for biometrics in most cases to use your passkey)
3. Choosing your funding source (balance or bank)
4. Reviewing payment details and confirming the payment

• 3D Secure + Passkeys:
  The authentication is happening between you and your card issuer (e.g., your bank). The card issuer decides what authentication method is used and whether to approve the transaction

• PayPal Passkeys:
  The authentication is between you and PayPal, using a passkey stored on your device. PayPal verifies your identity to grant access to your account. You can then use the funds of your bank account which is connected to your PayPal account

In this blog post we took a closer look at 3-D Secure (3DS) the protocol used in ecommerce to secure payments and prevent fraud. We answered the following questions:

• What is the process behind 3DS and what does EMVCo have to do with it? 3-D Secure is a global authentication protocol developed by EMVCo that enables card issuers to verify a cardholder’s identity during online payments, adding a security layer between merchant and bank.

• What are the different authentication methods used in 3DS and why are passkeys the best of them? 3DS supports various authentication methods including SMS OTPs, banking apps, and biometrics as well as passkeys which are superior because they are phishing-resistant, frictionless, and meet Strong Customer Authentication (SCA) requirements seamlessly.

• Why are big payment providers using passkeys in their 3DS process and how does it look like? Major payment providers use passkeys in their 3DS flow to reduce fraud, improve conversion, and meet regulatory standards, typically prompting the user for a biometric passkey confirmation directly within the issuer’s challenge screen during checkout.