Frictionless Flow Versus Challenge Flow

The frictionless flow and the challenge flow are the two outcomes of EMV 3D Secure version 2, and the choice between them decides the customer experience of every online card payment. In the frictionless flow the issuer authenticates the transaction using data alone, and the customer sees no extra screen. In the challenge flow the issuer needs more evidence, and the customer must complete an extra step. Both flows give the same protection and the same liability shift, but they feel very different at checkout, so the analyst must understand what drives the issuer to choose one or the other. Step one is the data the merchant sends, and it is far richer than in the first version of 3D Secure. When the customer checks out, the merchant sends an authentication request, called AReq, to the issuer through the 3D Secure server and the directory server. The request carries the card number, the amount, the merchant details, and more than a hundred data fields about the transaction: the device, the browser, the delivery address, the billing address, the customer history with the merchant, and whether the purchase is a first order or a repeat. The issuer uses this data to score the risk before deciding how to authenticate. Step two is the issuer risk decision, and it is the fork in the road. The issuer runs the data through fraud scoring, checks the cardholder history, and looks for signals such as a new device, an unusual amount, or a delivery address that does not match the billing address. If the risk is low, the issuer returns an authentication response, called ARes, that approves the frictionless flow, and the payment proceeds to authorisation without the customer doing anything extra. Step three, in the frictionless path, is the silent completion. The merchant receives the authentication result, includes it in the authorisation request to the issuer, and the authorisation proceeds as normal. The customer sees only the usual checkout confirmation. The benefit is invisible but real: the transaction was authenticated, the liability for fraud shifts from the merchant to the issuer, and the customer never had to type a code. The analyst must still ensure the authentication result is stored with the transaction record, because it is the evidence that proves the liability shift if a fraud chargeback arrives later. Step three, in the challenge path, is the extra step the customer must complete. The issuer returns an ARes that requests a challenge, and the merchant presents the challenge screen, called CReq, to the customer. The challenge method depends on what the customer has enrolled for: a one time passcode by text message, a push approval in the banking app, or a biometric such as a fingerprint or face scan. The customer completes the step, the result, called CRes, goes back to the issuer, and the issuer returns the final authentication result, called RReq and RRes. The screen is designed for the device, so a mobile customer sees a native style prompt, not a desktop page squeezed onto a phone. Step four is the outcome, and a failed challenge has a defined path. If the customer completes the challenge correctly, the transaction is authenticated and proceeds to authorisation with the liability shift. If the customer fails the challenge, abandons it, or the passcode expires, authentication fails and the merchant should not proceed to authorisation, because the liability shift does not apply and a fraud chargeback would fall on the merchant. The analyst must design the abandonment path: a clear message, an offer to try another payment method, and a log entry that records the challenge outcome for reconciliation and for fraud analysis. Exemptions allow some transactions to skip 3D Secure entirely, and they must be applied carefully. The main exemptions under European regulation and scheme rules are low value transactions below a threshold set by the regulator, recurring payments where the first payment was authenticated, transactions assessed as low risk under a transaction risk analysis exemption, payments to a trusted beneficiary the customer has whitelisted, and secure corporate payments made with a dedicated corporate process.