EMV 3-D Secure (3DS) - Payment Authentication Protocol V.2: V.2 3DS Requestor Initiated (3RI) flow: account confirmation, recurring and instalment payments

The 3RI channel (Device Channel 03) serves two uses with the cardholder absent: confirming account information (steps 1 to 6) and authenticating the cardholder (steps 1 to 13, decoupled only). The 3RI Indicator names the purpose: 01 recurring, 02 instalment, 03 adding a card, 04 keeping stored card details current, 05 checking the account, 06 shipment in parts or later, 07 topping up, 08 mail and 09 phone orders, 10 checking Trust List status, 11 any other payment, 12 a billing agreement, 13 checking device binding status, 14 checking card security code status, 15 later shipment, 16 payment in parts, 17 removing and 18 registering a FIDO credential, 19 fallback to decoupled authentication. The requestor supplies the earlier authentication in the Prior Transaction Authentication Information (prior DS Transaction ID, prior ACS Transaction ID as reference, prior method 01 frictionless, 02 ACS challenge, 03 AVS, 04 other issuer method or 05 SPC, and its UTC timestamp), and recurring data: amount and frequency each fixed or variable, recurring amount, currency and exponent when the amount is fixed, the date a new amount takes effect after a first or promotional payment, the expiry date and the fewest days allowed between two authorisations (1 to 9999); instalments carry the maximum number of authorisations (above 1, required for indicator 02). The 3DS Server protects a separate requestor link with mutual authentication, obtains its identifiers, routes on the BIN and sends the AReq; the DS validates it, checks version, 3DS Server reference number, MCC and account range participation, and stores the 3DS Server URL for a later RReq; the ACS returns Y, D, N, A, U, R or I, never C or S, with ECI and Authentication Value for Y or A in payments. No cardholder UI exists for a recurring 3RI; the 3DS Server passes any Cardholder Information Text on.