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.