# 3-D Secure (3DS) Source: https://ordergroup.co/glossary/3d-secure/ Last updated: 2026-10-10 > 3-D Secure (3DS) for lenders and card issuers: how EMV 3DS works, how it carries PSD2 strong customer authentication and what the app and backend handle. [Fintech](https://ordergroup.co/glossary/fintech/) 5 min read # 3-D Secure (3DS) Also known as: 3DS, 3D Secure, 3DS2, EMV 3-D Secure Definition 3-D Secure (3DS) is the card schemes' protocol for authenticating the cardholder in an online card payment. The merchant's side sends transaction and device data to the card issuer, which approves the payment without friction or asks the cardholder for strong customer authentication. Cite this entry Text "3-D Secure (3DS)". Order Group, Software glossary, 10 October 2026. https://ordergroup.co/glossary/3d-secure/ HTML `3-D Secure (3DS) - Order Group` Reviewed by [Mateusz Widenka](https://ordergroup.co/authors/mateusz-widenka/), Head of Delivery Last reviewed 10 October 2026 ## How 3-D Secure works 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. ## What 3-D Secure means for your software 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](https://ordergroup.co/glossary/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. Writing the specification? Add 3-D Secure (3DS) to your requirements checklist Collect the terms your project touches and get their system requirements in one e-mail, ready for an RFP. Rules that shape a 3-D Secure flow in a lending app RuleSourceWhat the system needs SCA for a remote electronic payment, linked to amount and payeePSD2 Art. 97(1)(b) and 97(2); RTS Art. 5Approval screen with amount and merchant; code invalid after any changeAt most five consecutive failed attemptsRTS 2018/389 Art. 4(3)(b)Attempt counter, blocked state in the app, unblock pathLow-value exemption: EUR 30, cumulative EUR 100 or five paymentsRTS 2018/389 Art. 16Per-card counters reset after each authenticationTransaction risk analysis exemption up to EUR 100, 250 or 500RTS 2018/389 Art. 18 and AnnexFraud rate monitoring that decides which threshold appliesChallenge result arrives asynchronouslyEMV 3DS (CReq, CRes, RReq)Pending payment state, timeout handling, reason shown on failureLoss rules when SCA is not appliedPSD2 Art. 74(2)3DS outcome stored with each transaction for disputes ## Rules and regulation 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](https://ordergroup.co/glossary/card-issuing/). ## From our projects 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](https://ordergroup.co/glossary/card-issuing/). We are adding 3-D Secure to Aasa24; as of October 2026 the work is in progress. ## Related terms - [Card issuing](https://ordergroup.co/glossary/card-issuing/) Card issuing is the payment service of giving a customer a payment card and processing the transactions made with it. Under PSD2 only a licensed provider can issue cards, so a lender can offer a card in its app through an issuing partner and attach its own credit limit. - [Device fingerprinting](https://ordergroup.co/glossary/device-fingerprinting/) Device fingerprinting is the collection of technical attributes of a phone or browser to recognize the same device across sessions. Lending apps use it for fraud checks at login, registration and the loan application. In the EU it falls under the GDPR and Article 5(3) of the ePrivacy Directive. - [Open banking](https://ordergroup.co/glossary/open-banking/) Open banking is regulated third-party access to a customer's payment account, with the customer's consent. In the EU it rests on PSD2, which defines account information services (AIS) and payment initiation services (PIS). ## Sources 1. [EMV 3-D Secure](https://www.emvco.com/emv-technologies/3-d-secure/) - EMVCo 2. [Directive (EU) 2015/2366 on payment services in the internal market (PSD2), Articles 74, 97 and 98](https://eur-lex.europa.eu/eli/dir/2015/2366/oj) - EUR-Lex 3. [Commission Delegated Regulation (EU) 2018/389, RTS on strong customer authentication and common and secure communication, Articles 4, 5, 16 and 18](https://eur-lex.europa.eu/eli/reg_del/2018/389/oj) - EUR-Lex 4. [EBA publishes Opinion on the deadline and process for completing the migration to strong customer authentication (SCA) for e-commerce card-based payment transactions](https://eba.europa.eu/publications-and-media/press-releases/eba-publishes-opinion-deadline-and-process-completing-migration-strong-customer-authentication-sca-e) - European Banking Authority 5. [Payment services deal: more protection from online fraud and hidden fees (PSD3 and PSR provisional agreement)](https://www.europarl.europa.eu/news/en/press-room/20251121IPR31540/payment-services-deal-more-protection-from-online-fraud-and-hidden-fees) - European Parliament Mateusz Widenka reviewed this entry. Ask how it applies to your project. [Ask an engineer](https://ordergroup.co/contact-us/) ## FAQ ![Mateusz Widenka](https://ordergroup.co/media/images/T02DHCC1Z-U039G6G3JS1-8e7d2cd80ccb-512.format-webp.webp) Mateusz Widenka Head of Delivery [Talk to an engineer](https://ordergroup.co/contact-us/) ### Is 3-D Secure the same as strong customer authentication? No. Strong customer authentication is the legal requirement in PSD2 and the RTS. 3-D Secure is the protocol card schemes use to carry that authentication in online card payments. ### Does every online card payment need a challenge? No. The issuer can approve a payment without interaction when its risk analysis allows it, and the RTS exempt low-value payments and payments that pass transaction risk analysis within set limits. ### Who pays for a fraudulent payment made without strong customer authentication? If the payer's provider did not require it, the payer bears no loss unless they acted fraudulently (PSD2 Article 74(2)). If the merchant or its provider did not accept it, they refund the damage to the payer's provider. ### Does a lender that offers a card need its own Access Control Server? The ACS belongs to the issuer's side and is usually run by the issuer or its processor. Whether the lender's app becomes the place where the cardholder approves payments is agreed with the issuer. Building a system that depends on 3-D Secure (3DS)? See how we build software for this domain, with case studies and the stack we use. [See Fintech Software Development Services](https://ordergroup.co/fintech-software-development/) Requirements checklist For each term we send the definition and what it requires from your software. Free, no sales call needed. Your checklist is empty. Use the plus next to a term to add it.