EMV 3-D Secure 2 testing requirements
EMV 3-D Secure 2 (3DS2) is the EMVCo protocol that lets a card issuer authenticate a cardholder during an online card payment. EMV 3DS applies to merchants, payment service providers, acquirers, and issuers that send or answer 3DS messages. FintechAssuranceLabs tests frictionless and challenge flows against the specification version in use and delivers message logs as evidence.
- Jurisdiction
- Global (EMVCo specification; card scheme rules; SCA mandate in the EEA under PSD2)
- Primary source
- emvco.com
Engineering interpretation of testing requirements, not compliance advice.
What EMV 3-D Secure requires
EMVCo owns the EMV 3-D Secure Protocol and Core Functions Specification. The EMVCo 3-D Secure page (checked on 2026-09-16) lists versions 2.2.0 to 2.3.1.1 as the production versions and a v2.4.0 draft whose comment period ended on 1 July 2026. EMVCo published v2.3.1.1 with Specification Bulletin No. 294 in May 2023. Version 2.3.1, released on 29 September 2022, added data elements for Secure Payment Confirmation and out-of-band authentication.
Older versions no longer process. Visa stopped support of 3DS 1.0.2 on 15 October 2022 (Visa Business News AI10745, 4 February 2021). The card schemes stopped processing version 2.1.0 in September 2024: Mastercard Identity Check on 24 September and Visa Secure on 25 September (Visa Acceptance Support KA-04311, checked on 2026-09-16).
The specification defines four components and the messages between them:
- The 3DS Server of the merchant or payment provider sends the authentication request (AReq) and receives the response (ARes).
- The 3DS SDK collects device data and shows the challenge inside a mobile app.
- The Directory Server (DS) of each card scheme routes messages and holds the card ranges and versions that issuers support.
- The Access Control Server (ACS) of the issuer decides the outcome, runs the challenge (CReq and CRes), and sends the final result in a results request (RReq).
Each AReq carries a device channel: 01 app, 02 browser, or 03 3DS Requestor Initiated (3RI) for merchant-initiated payments. The message category is 01 for a payment or 02 for a non-payment authentication, such as adding a card. Version 2.2.0 defines eight transaction status (transStatus) values: Y, N, U, A, C, D, R, and I. Each AReq also carries the card account number, which is account data under PCI DSS and sets how test data and logs are handled.
EMVCo approval gives a Letter of Approval to ACS, DS, 3DS Server, and 3DS SDK products. The approval does not cover the merchant integration, and card schemes set their own requirements on top. In the EEA, EMV 3DS is the usual way to apply strong customer authentication to card payments. Commission Delegated Regulation (EU) 2018/389 Article 5 requires dynamic linking of the authentication code to the amount and the payee. The PSD2 SCA testing requirements page covers the exemptions in detail.
What testing verifies
| Requirement | What we test | Evidence produced |
|---|---|---|
| Message version per card range | The AReq uses a messageVersion that the issuer's card range supports. No request uses version 2.1.0. | Version matrix per test card range, with AReq and ARes excerpts |
3DS Method completion (threeDSCompInd) | The indicator is Y after a completed 3DS Method, N after a method that did not complete within 10 seconds, and U when the card range has no method URL. | Browser network logs and AReq field values for each case |
| Transaction status handling | Checkout continues on Y and A, starts a challenge on C, waits on D, and stops or falls back as configured on N, R, and U. | Outcome table with one row per transStatus value and the authorisation request that followed |
| Challenge result before authorisation | The merchant sends the authorisation only after the RReq result arrives. Cancelled and abandoned challenges do not authorise as authenticated. | Recorded challenge sessions with matched RReq and RRes pairs |
| App channel through the 3DS SDK | The SDK shows the challenge, survives app backgrounding, and uses an sdkMaxTimeout of at least 05 minutes. | Device and OS test matrix with SDK logs |
| Merchant-initiated payments (3RI) | Recurring and instalment payments send device channel 03 with the correct threeRIInd value. | 3RI message log for each merchant-initiated payment type |
Error message handling (Erro) | A missing or malformed field returns an Erro message with errorCode and errorComponent. Checkout does not treat an error as an authentication. | Negative test cases with the Erro payloads |
| Dynamic linking (EEA, Regulation 2018/389 Article 5) | The amount and payee on the challenge screen match the authorisation. A basket change after authentication starts a new authentication. | Amount comparison log across AReq, challenge screen, and authorisation |
Exemption requests (threeDSRequestorChallengeInd) | Low-value requests follow Article 16 limits: EUR 30 per payment, and EUR 100 or five payments since the last SCA. An ACS challenge overrides the requested exemption. | Exemption decision table with the ARes outcome for each request |
The 3DS2 challenge flow testing guide shows the requests and test cards behind these 3D Secure test cases.
Artifacts acquirers, schemes, and assessors request
- EMVCo Letter of Approval for the 3DS Server or 3DS SDK in production, with the approved specification version.
- Card scheme or acquirer integration test results, with one result per required test case.
- Specification version configuration for each card scheme and card range.
- Mapping from each
transStatusvalue to the authorisation fields sent: ECI and authentication value. - Exemption log with amount, exemption reason, and ARes outcome for each exempted payment.
- Dynamic linking evidence that shows the amount and payee from authentication to authorisation.
- Retained authentication results for fraud disputes. Visa Business News AI10745 lists ECI 05 for a fully authenticated Visa Secure transaction, with fraud liability on the issuer.
- PCI 3DS Core Security Standard attestation for an entity that runs ACS, DS, or 3DS Server functions (PCI SSC, checked on 2026-09-16).
Common findings
- Stale authentication value. A customer edits the basket after authentication, and the authorisation reuses the old authentication value with the new amount. This breaks Regulation 2018/389 Article 5(1)(d), which invalidates the code on any change to amount or payee.
- Status
UorRauthorised as authenticated. The checkout sends an authenticated ECI after a failed or rejected authentication. The payment has no valid authentication value, so the fraud liability shift that the merchant reports does not apply. threeDSCompIndhardcoded toY. The 3DS Method iframe never posts its notification, but the AReq reports completion. The ACS receives no browser data and challenges more customers, which lowers checkout conversion.- Unhandled
DandIstatus values. Code written for the 2.1.0 value set has no path for decoupled authentication or informational-only results, so the checkout hangs or fails. - Authorisation before the RReq. The merchant authorises on the ARes status
Cinstead of the challenge result. A cardholder who abandons the challenge still gets charged without authentication. - Version 2.1.0 still configured. A hardcoded
messageVersionof 2.1.0 produces errors after the September 2024 scheme sunset, and every authentication through that path fails. - Exemption counter not reset. The low-value counter keeps counting after a successful SCA, or never counts at all. Both break the cumulative limits in Article 16(b) and 16(c).
- Full card number in 3DS Server logs. The AReq is logged with an unmasked account number. PCI DSS v4.0.1 requirement 3.5.1 requires a stored PAN to be unreadable; see the PCI DSS testing requirements.
How we cover EMV 3DS
On the merchant and payment provider side, payment flow testing covers the 3DS step inside the full payment flow from authorisation to refund. The payment flow map shows each transStatus branch, and the defect log states the financial impact of each 3DS defect, such as a payment authorised without liability shift. We test these flows for payment acquiring platforms, subscription billing with merchant-initiated payments, and remittance products funded by card.
On the issuer side, card issuing and processing testing verifies ACS configuration through the processor: card range enrolment, challenge methods, and authorisation rules that read the authentication result. This work applies to neobanks, spend management platforms with corporate cards, business banking, and Banking-as-a-Service card programmes. For chargeback management products, we verify that the authentication result reaches the dispute evidence.
For EEA payments, we test exemption requests against the Article 16 and Article 18 conditions together with the scheme response. The SCA exemptions testing guide lists the request fields for each exemption.
Related
Segments
Questions
What is 3DS2?
Difference between 3DS1 and 3DS2
Is 3-D Secure 2.0 required in the US?
How does 3-D Secure authentication work?
Scope your testing
Send FintechAssuranceLabs your product, segment, money flows, and the standards that need evidence, and get a proposed test scope with its deliverables.
Scope your testing