How 3D Secure Works: Behind the Scenes of Card Payment Authentication
Most people who pay online have encountered an extra verification step involving an SMS code, a banking app notification, or biometrics. This step is usually handled by 3D Secure - the standard protocol used to authenticate cardholders during online transactions. From a shopper's perspective, the entire process takes just a few seconds; however, behind the scenes, an online merchant, payment gateway, acquirer, card scheme, processor, and card issuer are all working together.
Table of Contents:
What is 3D Secure?
3D Secure (3DS) is an additional layer of security designed primarily for online card transactions (Card Not Present / CNP). Its main purpose is to verify that the person attempting the payment is genuinely authorized to use the card. Simply entering a card number, expiration date, and CVC code is not always enough. Users may be asked to enter a One-Time Passcode (OTP) received via SMS, approve the payment in a mobile app, or confirm the operation using biometrics.
In Mastercard’s ecosystem, this solution operates as Mastercard Identity Check, while Visa labels it Visa Secure. Both build upon the EMV 3-D Secure standard.
The "3D" in the name refers to the three domains involved in the process: the Domain of the Merchant and Acquirer, the Issuer Domain, and the Interoperability Domain provided by the card scheme.
Who Participates in the 3DS Process?
Several entities participate in the authentication process:
Cardholder – The user making the payment.
Merchant – The online store or service provider accepting the payment.
Payment Gateway or PSP – The payment gateway handling the checkout process on the merchant’s side.
Acquirer – The acquiring bank processing transactions for the merchant.
Issuer – The bank or financial institution that issued the card.
Access Control Server (ACS) – The system responsible for managing the authentication process on the issuer's side.
Operating between these entities are the 3DS Server and the card scheme’s Directory Server. The merchant does not communicate directly with the customer’s bank. Instead, information flows through the payment gateway, acquirer, card scheme, and the card processor servicing the issuer.
How Does the 3D Secure Process Work?
In simplified terms, the step-by-step process flows as follows:
The user enters their card details and submits the purchase.
The merchant forwards the payment details to the payment gateway or PSP.
The 3DS system routes an authentication request through the card scheme to the card issuer.
The issuer analyzes data regarding the transaction, device, user, and merchant.
The issuer decides whether the transaction can be authenticated seamlessly in the background or if the user must perform an explicit challenge step.
The authentication result is returned to the merchant.
The actual transaction authorization takes place, during which the issuer checks available balance, limits, card status, and other security rules.
Note: It is crucial to distinguish between authentication and authorization. Passing 3DS authentication successfully does not guarantee that the payment will be approved. A transaction can still be declined later due to insufficient funds, exceeded limits, or a blocked card.
Frictionless Flow vs. Challenge Flow
Under the modern 3D Secure 2 (3DS2) standard, users are not forced to type a code or open an app every single time. Transactions are handled through one of two flows:
Frictionless Flow
In this scenario, the user performs no extra steps. The issuer analyzes data transmitted during the transaction to assess risk. Evaluated parameters may include transaction amount and currency, device and browser fingerprint, IP address, purchase history, previous transactions with this merchant, and general card usage patterns.
If the risk is deemed low, authentication completes silently in the background. For the user, it feels like a standard card payment, even though a full 3DS evaluation occurred.
Challenge Flow
If the issuer requires additional verification, a Challenge Flow is triggered. The user may be prompted to enter an SMS OTP, approve the payment in a mobile app, or authenticate via biometrics. Once completed, the ACS transmits the authentication result to the remaining payment participants.
Payment Confirmation via SMS
The SMS-delivered OTP is one of the most recognizable 3DS methods. The processor displays a frame containing transaction details and an input field. The bank or payment institution sends a single-use code to the phone number registered to the account, and the system validates the input.
Advantages: Straightforward implementation without requiring a fully fledged mobile app payment workflow. It also supports customers who do not use mobile banking apps.
Limitations: Every SMS incurs a cost that varies by destination country and carrier. Messages can be delayed, fail to deliver, or be inaccessible if the user is out of coverage or roaming. This issue is particularly acute in international card programs, where sending messages to certain countries can cost several currency units per text, and delivery success depends heavily on local telecom infrastructure. Furthermore, SMS is inherently less resilient to modern attack vectors compared to secured mobile app authentication.
Payment Confirmation via Mobile App
An increasing number of modern banks and fintechs rely on Out-of-Band (OOB) authentication, where users approve transactions directly within a mobile application.
Upon initiating checkout, the cardholder receives a push notification displaying key transaction metadata, such as merchant name, amount, currency, and timestamp. The user approves the transaction using their app PIN, fingerprint, or facial recognition.
While integration is more complex and requires iOS and Android client support, backend orchestration, push infrastructure, and ACS communication, it eliminates per-SMS costs and functions anywhere the user has internet access. Crucially, presenting full transaction context prevents users from blindly approving abstract codes.
Which Authentication Method Is Best?
The optimal strategy is usually a hybrid model combining push notifications and SMS fallback. Mobile app push serves as the primary route, while SMS acts as a failover if the user lacks the app, the device fails to receive push tokens, or connectivity drops.
Channel routing can be automated based on issuer data - checking active app usage, recent login activity, push delivery status, and phone number validity. Alternatively, if supported by the processor and ACS, the 3DS interface can let the cardholder choose their preferred authentication method directly on screen.
Who Decides When to Apply 3D Secure?
A merchant or PSP can request 3DS authentication and express preferences. However, they do not unilaterally dictate the authentication flow. The final decision to run a Frictionless Flow or a Challenge Flow rests primarily with the card issuer.
Within the European Economic Area (EEA), many transactions fall under Strong Customer Authentication (SCA) mandates enforced by PSD2. Specific exemptions may apply, such as low-value transactions, low-risk payments, trusted beneficiaries, recurring payments, and certain merchant-initiated transactions (MITs). However, even when a merchant or PSP requests an exemption, the issuer retains the authority to demand full step-up authentication.
Enterprise merchants frequently leverage risk analysis engines and available exemptions to streamline checkout friction, balancing fraud reduction against conversion rate optimization.
Why Do Merchants Rely on 3DS?
The primary driver is fraud reduction through liability shift. If a cardholder disputes a transaction as fraudulent, they can file a chargeback with their bank. When 3DS authentication is successfully performed, liability for specific fraud-related chargebacks typically shifts from the merchant to the card issuer.
Important: Liability shift is not universal protection. 3DS does not shield merchants from non-fraud chargebacks, such as non-delivery of goods, product description mismatches, duplicate processing, processing errors, improper subscription cancellations, or missing refunds. 3DS specifically mitigates risks associated with unauthorized card usage.
Is 3D Secure Free for Merchants?
There is no universal fee structure. Pricing depends on commercial agreements with PSPs, acquirers, and 3DS vendors. Some providers bundle 3DS processing into standard payment processing fees, while others charge a separate per-attempt fee — regardless of whether the transaction culminates in a completed payment.
For instance, Stripe's standard pricing model in Poland includes 3DS processing within its baseline rate, whereas custom enterprise pricing may invoice 3DS attempts separately. Merchants should clarify whether fees apply per attempt or only on successful authentications, whether Frictionless and Challenge flows are billed differently, and if failed attempts incur charges.
In almost all cases, 3DS costs are a fraction of the expense associated with fraud, chargeback processing fees, operational overhead, and lost inventory.
How Is 3DS Implemented on the Issuer Side?
For a card-issuing bank or financial institution, implementing 3DS extends far beyond embedding an OTP input form. The issuer or its processing partner must:
Register the card program within card scheme directories.
Configure network communication with the Access Control Server (ACS).
Map BIN ranges to appropriate authentication flows.
Set up risk engine rule sets and scoring algorithms.
Configure supported authentication channels.
Set up SMS gateways or mobile app OOB integration.
Design UI/UX frames displayed to end users during challenges.
Pass mandatory card scheme testing and compliance certification.
Depending on processor capability, 3DS challenge UI elements can be co-branded or custom-styled for specific card programs, displaying logos for white-label issuers, affinity partners, or cobranded entities. To render the correct interface variant dynamically, card programs must be properly segmented and mapped to distinct configuration profiles.
Summary
3D Secure provides a vital authentication layer for online card payments. It enables issuers to verify cardholder identity, mitigating fraud for both consumers and merchants. Modern 3DS2 frameworks eliminate unnecessary friction through background Frictionless Flows, reserving step-up Challenge Flows (SMS, push, or biometrics) for higher-risk scenarios.
For merchants, the primary advantage remains the liability shift on fraud chargebacks. For issuers, implementation requires coordinating processors, ACS systems, card schemes, push services, and mobile applications.
At Sparados, we navigate this architecture hands-on. We assist partners with card program launches, 3DS authentication integration, OTP delivery pipelines, and event-driven 3DS notification routing to external core systems.
Related Articles & Resources:
