3DS v2: Workflow descirption

3DS v1 vs 3DS v2 – what’s different

Frictionless-first: 3DS2 allows issuers to authenticate silently when they have sufficient data. The cardholder is challenged only when necessary.
Richer data model: 3DS2 relies on device/browser metadata and risk indicators supplied by the merchant to improve approval rates.
Modern UX: In 3DS2, the challenge renders in an in‑page iframe or an app view rather than legacy page redirects.
Versioning: 8B supports 3DS 2.x. The protocol version is returned to you together with 3DS method parameters when applicable.

Practical outcome: you must be ready to collect browser metadata and, when instructed, post a hidden iframe to the issuer’s 3DS Method URL before starting authentication.

Roles & Terminology

Term	Description
Frictionless Flow (FF)	Issuer authenticates without a visible challenge
Challenge Flow (CF)	Issuer requires a cardholder challenge (OTP, app confirm, etc.).
Method URL / 3DS Method	A lightweight background call in a hidden iframe that helps the issuer collect device data.
cReq / cRes:	Challenge request/response payloads exchanged with the issuer’s ACS during CF.

End‑to‑end Sequence Overview

Download in high resolution

Statuses

❗️
All challenge-related actions will be carried out during the "AUTHORIZATION_REQUESTED" status.

Magic numbers

TBC

Steps Description

Pre-Authorization Stage

Step	Name	Extra Details
[1.1]	Initiate payment - input Bank Card Details	--
[1.2]	Submit the order and card details	--
[1.3]	Create a New Intent with payment   POST /processing/api/v1/intents	Intent must contain at least one Payment object `payments[].paymentInstrument.incomingDetails` must follow to the Bank Card Requirements
[1.4]	Create new Intent Create separate payments	Our API supports the creation of the multiple payment transactions Processing sequence runs for each separate payment independently
[1.5]	Verify whether collecting data via a hidden iframe is necessary	During this step we request the Bank-Issuer if they need to collect a metadata performing a pre-authorization action sequence
[1.6]	Return the decision about gathering the data via the hidden iframe	If the Bank-Issuer requires to collect the metadata, then we will provide the the data for performing POST request to the ACS side via the hidden iframe If the Bank-Issuer doesn't require to collect the metadata, then we will proceed to the authorization automatically
[1.7]	[NO IFRAME] Return the response on 1.3 step request without/without the hidden iframe parameters	This step is the direct response for step 1.3 It contains the information about the created intent and all included payment transactions If the Bank-Issuer DOES NOT require metadata gathering then you WON'T receive any related details such as ACS URL and 3DS Method Data If the Bank-Issuer DOES require metadata gathering then you WILL receive related details such as ACS URL and 3DS Method Data to send a POST Request directly to ACS via the hidden iFrame
[1.8]	Transfer the hidden iframe details to the store	In case you received the ACS/3DS details in the Intent creation response, then the store (you or your client) must: to collect user's metadata to send a POST request to the ACS To do so, they need to be provided with the data from the intent response
[1.9]	Create a hidden iframe.  Gather the required metadata	The store must collect the following metadata: browserAcceptHeader browserIp browserLanguage browserUserAgent browserJavaEnabled browserColorDepth browserScreenHeight browserScreenWidth browserTZ browserJsEnbaled
[1.10]	Send a POST request to MethodUrl with the "threeDsMethodData": "base64-encoded-string"	The store must send a direct POST request to the ACS URL, sending "`threeDsMethodData`": "`base64-encoded-string`"
[1.11]	Record the result of result of the iframe loading and gather the metadata	The result of sending the POST request must be recorded and be returned to us There is a specific dedicated field for this `MethodCompInd`, the value of this field must be a single letter `Y` or `N`: 'Y' - Hidden iframe post request executed successfully; 'N' - Hidden iframe post request failed;
[1.12]	Return the result of the iframe loading and the gathered metadata	The store must return all the gathered metadata and the correctly filled `MethodCompInd`
[1.13]	Return the result of the iframe loading and the gathered metadata POST .../initiate-authentication	You must return all the gathered metadata and the correctly filled `MethodCompInd` to us We will provide this data to the Bank-Issuer and proceed to the authorization stage

Authorization Stage

Step	Name	Extra Details
[FF:2.1]	Initiate the payment authorisation	We initiate the funds authorization
[FF:2.2]	The issuer has enough payer's data and they do not need to challenge them.   The issuer authorizes the transaction	Bank-issuer received the information about the transaction Match transaction details with the metadata and pre-auth POST request data Make a decision if they trust this payment or they want to challenge the payer
[FF:2.3]	Return the latest 8B Payment Authorisation Status via Webhook	In case the Bank-Issuer selects the Frictionless Flow, then the transaction will be authorized without any other user actions The payment status will be changed into AUTHORIZED A separate callback (webhook) will be send to your endpoint with the transaction status change.
	CHALLENGE FLOW
[CF:2.1]	Initiate the payment authorisation	We initiate the funds authorization
[CF:2.2]	The issuer doesn't have enough payer's data and they need to challenge them.  Return the 3DS form data (including cReq)	Bank-issuer received the information about the transaction Match transaction details with the metadata and pre-auth POST request data Make a decision if they trust this payment or they want to challenge the payer
[CF:2.3]	Transfer 3DS information via Webhook  (including cReq)	In case the Bank-Issuer selects the Challenge Flow, then the transaction will be kept in the same status and the challenge flow sequence will be initiated A separate callback (webhook) will be send to your endpoint with the 3DS data (including cReq).
[CF:2.4]	Transfer 3DS information (including cReq)	The 3DS information must be transferred to the store for the payer to conduct the authentication
[CF:2.5]	Render an iframe and auto-POST  `cReq` and `threeDSSessionData` to `acsURL` inside it.  Load the issuer’s challenge UI for the cardholder.	The store must render an iframe The store must auto-POST  `cReq` and `threeDSSessionData` to `acsURL` inside it, to get the 3DS form The store must load the issuer’s challenge UI for the cardholder.
[CF:2.6]	Conduct the Authentication	The payer must pass the authentication
[CF:2.7]	Submit the Authentication form with the user's data	The form must be submitted
[CF:2.8]	Return of the cRes	In positive scenario the bank Issuer will return the cRes cRes must be returned to us to complete the 3DS session
[CF:2.9]	Resend the cRes to 8B	cRes must be returned from the store to the PSP
[CF:2.10]	Resend the cRes to 8B   `POST /processing/api/v1/payments /{id}/3ds/complete-cf-authentication`	cRes must be returned to us using the dedicated POST method
[CF:2.11]	Complete 3DS providing the completion confirmation (including cRes)	We provide cRes to the Bank Issuer to complete the 3DS session
[CF:2.12]	Return the 3DS completeness result and the authorization status	Bank-Issuer will validate the information and make a decision about the transaction authorization
[CF:2.13]	Return the latest 8B Payment Authorisation Status via Webhook	In case of the successful pass of the Challenge flow, the transaction will be authorized The payment status will be changed into AUTHORIZED A separate callback ( webhook ) will be send to your endpoint with the transaction status change.