3-D Secure (3DS)

3-D Secure is the protocol card schemes use to check that the person paying online is the cardholder. EMVCo, the standards body of the card schemes, publishes it as EMV 3-D Secure and describes it as "an e-commerce fraud prevention protocol that enables consumer authentication for CNP purchases", where CNP means card not present. The first generation worked only in the browser and has been retired. EMV 3DS (version 2.x) works in browsers and inside mobile apps. Version 2.1 already supports strong customer authentication, and EMVCo recommends version 2.2 or higher.

A 3DS check involves three domains. On the merchant's side, the 3DS Server (and, in a mobile app, the 3DS SDK) collects data about the transaction and the device. The card scheme runs the Directory Server, which routes the message to the right issuer. On the issuer's side, the Access Control Server (ACS) decides whether the cardholder has to do anything.

The merchant's side sends an authentication request (AReq). The ACS weighs the risk and answers with an authentication response (ARes) carrying a transaction status. Status Y in the ARes means the cardholder is authenticated without any interaction, which is the frictionless flow. Status C means a challenge is required: the cardholder confirms the payment with a one-time code, in the issuing bank's app or with biometrics, and the ACS reports the final result in a results request (RReq). Other statuses cover a denied authentication (N), a rejection with a request not to authorize (R), an authentication that could not be performed (U) and an attempt without full authentication (A). Version 2.2 added decoupled authentication (D), where the cardholder confirms outside the merchant's session. The result travels into the authorization message, so the issuer sees at authorization whether and how the cardholder was authenticated.

The work depends on which side of the payment your system sits on. A lender that takes card repayments in its app is on the merchant's side. A lender that offers its own card through an issuing partner, as described under card issuing, is on the issuer's side, and its app often becomes the place where the customer approves online payments.

On the merchant's side, the payment gateway runs 3DS for you, but the app has to handle the challenge. The challenge screen opens inside the app through the 3DS SDK or in a web view, and the app has to wait for the result, keep the payment in a pending state, and handle a customer who closes the screen or never comes back. A repayment that ends in status N or R should show a reason the customer understands, not a generic error.

On the issuer's side, the work is in the approval channel. PSD2 ties the authentication code for a remote card payment to the amount and the payee (dynamic linking). Under Article 5 of the RTS (Delegated Regulation 2018/389), the payer must see the amount and the payee, and any change to either invalidates the code. When approval happens in your app, the push notification opens a screen with the amount and the merchant, the customer confirms with a PIN or biometrics, and the app sends the answer back before the ACS timeout. Article 4 caps consecutive failed authentication attempts at five within a set period, after which the action is blocked, so the app needs a visible blocked state and a path to unblock.

How often the customer sees that screen depends on the exemptions in the RTS. Under Article 16 a remote payment of up to EUR 30 can skip strong customer authentication until the cumulative amount since the last authentication passes EUR 100 or five payments have been made. Article 18 allows an exemption after transaction risk analysis, up to EUR 100, 250 or 500 for remote card payments, depending on the provider's fraud rate. The issuer's side has to keep those counters per card and reset them after each authentication.

When a card payment fails, the customer and the support team both need to know why. Storing the 3DS outcome with each card transaction lets the history in the app tell a failed authentication apart from a lack of funds or a blocked card.

Article 97(1) of PSD2 (Directive (EU) 2015/2366) requires strong customer authentication when the payer accesses a payment account online, initiates an electronic payment, or carries out any action through a remote channel that may imply a risk of payment fraud or other abuses. Article 97(2) adds dynamic linking for remote electronic payments. Article 98 mandated the regulatory technical standards, which became Delegated Regulation 2018/389, applied from September 14, 2019. The European Banking Authority gave the industry until December 31, 2020 to migrate e-commerce card payments to strong customer authentication. The RTS do not name 3-D Secure. They are technology neutral, and card payments meet them through EMV 3DS. In November 2025 the European Parliament and the Council reached a provisional agreement on PSD3 and a Payment Services Regulation (PSR) that will replace PSD2 and move most of its rules into a directly applicable regulation. As of October 2026 the new rules do not yet apply: they start after formal adoption, publication in the Official Journal and a transition period, so PSD2 and the RTS remain the rules to build against today.

Article 74(2) of PSD2 sets who carries the loss. If the payer's provider does not require strong customer authentication, the payer bears no financial loss unless they acted fraudulently. If the payee or its provider does not accept strong customer authentication, it refunds the damage to the payer's provider. Why the card number and CVV cannot act as an authentication factor is covered under card issuing.

In Aasa24, the lending app we have built for Aasa Polska since May 2023, customers manage a Visa credit card issued through a licensed partner, as described under card issuing. We are adding 3-D Secure to Aasa24; as of October 2026 the work is in progress.