Frictionless or challenge?

A card payment online is authenticated before it is authorised. The shop’s 3DS Server sends an AReq, through the card scheme’s directory server, to the access control server of the bank that issued the card. The ACS answers with an ARes: Y, through without the cardholder doing anything; C, a challenge; N, not authenticated; or R, rejected, so that the shop should not even ask for the authorisation.

A challenge goes through the cardholder’s browser. The CReq opens the ACS’s page, the cardholder types the code their bank texted, and the ACS tells the 3DS Server how it ended with an RReq through the directory server, before the final CRes takes the cardholder back to the shop.

First the check: an AReq without what its channel and category require, or with an element in a format the specification does not give, is answered with an Erro that names the elements. Then the rules, a chain of responsibility asked in order until one decides: what ends authentication outright, such as a stolen card; what forces a challenge, such as the requestor’s mandate or a high risk score; the exemptions from strong customer authentication of the EU’s Regulation 2018/389, for trusted beneficiaries, low value and transaction risk analysis; and last the law’s default, which always decides: authenticate strongly.

Low value covers up to €30 while the card’s payments since its last strong authentication stay within five, or within €100. The regulation lets an issuer keep either count; this one, cautiously, keeps both, and counts the payment at hand. Risk analysis goes up to a threshold set by the issuer’s fraud rate: €250 at this issuer’s 0.05%.

An authenticated payment gets an authentication value, which the shop passes on with the authorisation, and the issuer checks it there. Card schemes compute theirs with algorithms and keys of their own. This ACS takes an HMAC over the transaction’s id, the card, the amount, the currency, the outcome and the ECI, cut to the 20 bytes the element holds: it checks out for the amount authenticated, and not for a cent more.

The ACS’s own work is timed on the JVM: well under a millisecond of a frictionless answer in the recordings, against 160 ms for the four legs of the network, assumed at 40 ms each. A production ACS does far more in its part: it reads card records, signs with keys kept in hardware security modules, and often asks a risk service.

I spent three and a half years at Worldline on 3-D Secure 2.x components for online card payments: challenge and frictionless authentication, liability shift, exemptions and soft declines under PSD2 and SCA, integrations with acquirers and issuers, and PCI DSS around all of it.

Nothing on this page comes from Worldline’s code or documents. The simulator follows the public EMV 3-D Secure specification, version 2.2.0, and the regulation; its rules illustrate how an issuer may decide, not how any issuer does. Retries on the other side of a payment are in the idempotency experiment.