6.2. 3DS Overview

Payneteasy 3DS Flow

Reference:

EMV® 3-D Secure Protocol and Core Functions Specification

3-D Secure is a protocol designed to be an additional security layer for online credit and debit card transactions.
3-D Secure protocol has two main versions.
1.0 – which was introduced in 2001 and is still used by some acquirers (Services based on this protocol were adopted by different card schemes giving it different names: Verified by Visa or Visa Secure used by Visa, SecureCode used by Mastercard, ProtectBy used by Discover, J/Secure used by JCB International, American Express SafeKey used by American Express.
2.X – which was introduced in 2016 to strengthen and supersede the version 1.0 and it was aimed at complying with the new EU authentication requirements and resolving some short-comings of the original protocol.

Despite low level message exchange differences in the essence protocol version 2.X differs from 1.0 by introducing and option for the issuer of the card to perform an automatic risk assessment based on the additional contextual data sent from the payer browser or mobile app, whereas 1.0 version always requires payer to pass an authentication challenge. Correspondingly (and according to EMVCo spec) protocol version 2.X includes Frictionless flow (gathering contextual data and performing risk assessment) and Challenge flow (passing authentication challenge). The normal Payer’s web flow which passes 3DS 2.X Authentication can be illustrated as below.

  1. Payers fill out a payment form provided by Connection Party or Payment Gateway side and sends data.

Payment Form

Note

For Transfer transactions, payment form might look as described below.

Payment Form

  1. Contextual data is gathered and sent to the Issuer in a hidden process within the browser (Frictionless flow).

Wait Form

  1. If Issuer finds the transaction risky Payer’s browser gets redirected to the Issuer web page to pass authentication challenge (Challenge flow).

3DS

  1. When Payer passes checks the payment authorization is made saving the details related to the 3DS Authentication on the acquirer side.

Wait Form

  1. Payer’s browser gets redirected to the Connecting Party website to the resultant page.

Finish Form

Due to the fact that both protocol versions still used the Connecting party have to deal with both of them as well as specific integrations when acquirer handles 3D Secure communication on its end. For this purpose, Payment Gateway provides universal/generic approach based on the API commands which allow the Connecting party to handle all mentioned cases. The Connecting Party has to start with the 3DS Decision Making Schema of the relevant Use-Case which in turn refers to the more detailed diagram describing specifics of the data handling and Payer’s browser redirects related to the corresponding 3DS flow.

3DS Implementation Scenarios

Implementation Scenario

Instructions

3DS is not initiated (non3D).

3DS Authentication is not initiated. Follow 3DS Decision Making Schema of relevant Use-Case and implement Non3D Flow.

3DS is initiated and performed by Connecting Party (for PSPs and Acquirers).

3DS Authentication is initiated and performed by Connecting Party, results are uploaded to Payment Gateway in initial request. Follow 3DS Decision Making Schema of relevant Use-Case and implement Non3D Flow (3DS is performed before the initial request to Payment Gateway).

3DS is initiated by Payment Gateway and performed on Connecting Party side.

3DS Authentication is initiated by Payment Gateway. For 3DS 1.0.2, Payer Authentication is performed on Connecting Party side, results are uploaded to Payment Gateway. For 3DS 2.x, 3DS Method and Challenge are performed on Connecting Party side, results are uploaded to Payment Gateway. Additional fields for 3DS Method can be provided by Connecting Party in initial request to speed up the process for 3DS 2.x (tds_status=MethodUrlFrame will be skipped if 3DS Method is not supported by ACS). Follow 3DS Decision Making Schema of relevant Use-Case and implement all 3DS Flows.

3DS is initiated and performed by Payment Gateway.

3DS Authentication is initiated by Payment Gateway, all 3DS scenarios are performed on Payment Gateway side. Follow 3DS Decision Making Schema of relevant Use-Case, implement Simplified Authentication Flow (ignore tds_status parameter presence, use html or redirect-to parameters to redirect the Payer to Payment Gateway) and Non3D Flow (if Payer’s card is not enrolled or processing is Non3D).

Alternative cardholder authentication

Payment Gateway supports alternative methods for cardholder authentication if card is not enrolled to 3DS (negative 3DS enrollment response). One of such methods is random sum check. In this method, Payment Gateway initiates an additional preauthorization transaction to hold a random small amount on cardholder’s account and sends a special form for the Payer to enter the amount being held. If the amount is correct, Payment Gateway continues to process the initial transaction. The small amount hold is cancelled automatically.

General diagram for form transactions

skinparam roundcorner 20 skinparam sequenceArrowThickness 2 skinparam ParticipantPadding 30 actor Payer as Customer participant "Connecting Party" as Merchant participant "Payment Gateway" as g autonumber Customer -> Merchant: Checkout activate Merchant == Purchase payment request == Merchant -> g: Request Initiating activate g g --> Merchant: Redirect-url, Order ID deactivate g Merchant -> Customer: Provide redirect-url to Payer's browser activate Customer Customer -> g: GET redirect-url deactivate Customer activate g g -> Customer: Payment Form deactivate g activate Customer Customer -> g: Submit Form deactivate Customer activate g g -> g: Transaction processing g -> g: 3DS Enrollment g -> g: Random Sum Processing g -> Customer: Redirecting to the Random Sum Check html form deactivate g activate Customer Customer -> g: The cardholder provides auth data deactivate Customer activate g g -> g: Auth Data Validating group alt == Receive Connecting Party Callback == Merchant <- g: Сallback with final status g <-- Merchant: HTTP 200 deactivate g == Order Status Request == Merchant -> g: api/v2/status activate g g --> Merchant: Response \nstatus, order-stage deactivate g end Merchant --> Customer: Show result deactivate Merchant deactivate Customer

(2) See relevant Use-Case to get details about the exact API command to initiate transaction.
(13) To implement callback with final status handling see Connecting Party Callbacks.
(15) Please see Status List to get more information about Final Statuses.

General diagram for direct integrations

skinparam roundcorner 20 skinparam sequenceArrowThickness 1 skinparam maxmessagesize 1200 skinparam sequenceParticipant underline actor Payer participant "Connecting Party" as A participant "Payment Gateway" as B autonumber Payer -> A: Checkout activate A A -> B: Payment Initiating activate B B --> A: Order ID B -> B: Transaction processing group loop A -> B: Status Request B --> A: Non-Final Status end B -> B: 3DS Enrollment B -> B: Random Sum Processing A -> B: Status Request B -> A: Response with Random Sum Check html form A -> Payer: Redirecting to the Random Sum Check html form deactivate B activate Payer Payer -> B: Cardholder provides auth data deactivate Payer activate B B -> B: Auth Data Validating group alt group Get Final Status == Receive Connecting Party Callback == A <- B: Callback with Final Status A --> B: HTTP 200 deactivate B == Order Status Request == A -> B: Get Status by Order ID activate B B --> A: Response status, \norder-stage deactivate B end A --> Payer: Show result deactivate A

(2) See relevant Use-Case to get details about the exact API command to initiate transaction.
(9) Status Request continues in parallel all the time starting from step 5.
(11) To implement callback with final status handling see Connecting Party Callbacks.
(13) Please see Status List to get more information about Final Statuses.