3-D Secure 2.0
Requests are processed differently with 3-D Secure 2.0 authentication than with the first version of the 3-D Secure protocol. The key feature of 3-D Secure 2.0 and its main difference from the first version is support for Frictionless authentication.
- Frictionless Flow — 3-D Secure authentication without cardholder involvement. For the Customer, the payment looks like a payment without 3DS, while for the Merchant the payment remains protected by 3-D Secure.
- Challenge Flow — 3-D Secure authentication with cardholder verification. For the Customer, the verification looks the same as with 3DS 1.0.
The issuing bank decides whether to perform Frictionless or Challenge authentication based on an analysis of the transaction parameters, including information about the Customer's browser.
The browser parameters are collected by the Merchant and passed before the payment is made. However, the issuer may request to collect the browser parameters itself. For this purpose, the 3-D Secure 2.0 protocol uses the 3DS Method: a hidden iframe is opened in the Customer's browser to collect the browser parameters.
Pre-authentication
Pre-authentication is performed to check the 3-D Secure protocol version and whether the 3DS Method is required. Pre-authentication uses the api/PreAuth (Payture API) or vwapi/PreAuth (Payture eWallet) request. The methods are described in the 3‑D Secure 2.0 on the Merchant side (in Russian) and 3‑D Secure 2.0 with a template (in Russian) documents.
Performing the 3DS Method
If the PreAuth response contains the ThreeDSServerTransId, ThreeDSMethodURL and ThreeDSMethodNotificationURL parameters, the 3DS Method must be performed: a hidden iframe is opened in the Customer's browser, through which the browser data is automatically sent to the issuing bank's server.
Otherwise (if the PreAuth response does not contain the ThreeDSServerTransId, ThreeDSMethodURL and ThreeDSMethodNotificationURL parameters, or at least one of them has no value), you do not need to open the hidden iframe — proceed to the next step.
Examples of apim/PreAuth (Payture InPay) and vwapi/PreAuth (Payture eWallet) responses are provided in the 3‑D Secure 2.0 on the Merchant side (in Russian) and 3‑D Secure 2.0 with a template (in Russian) documents.
Making a payment (adding a card)
The following methods are used to make a payment or add a card:
- On the Merchant side — api/Pay , api/Block , api/MobilePay , api/MobileBlock , vwapi/Pay — Merchant side or vwapi/Add — Merchant side
- On the Payture side — apim/PaySubmit, vwapi/PaySubmit or vwapi/AddSubmit. The methods are described in the 3‑D Secure 2.0 with a template (in Russian) document
If the issuing bank allows the operation to proceed via the Frictionless Flow, the payment is made without verifying the Customer. The response to the payment (card addition) request contains “Success=True” and no 3DS parameters, which means the funds on the Customer's card have been charged or held. The payment process is complete.
If the Customer must be verified, the operation follows the Challenge Flow. The next steps depend on which side processes the card data. More details are available in the 3‑D Secure 2.0 on the Merchant side (in Russian) and 3‑D Secure 2.0 with a template (in Russian) documents.
Customer verification (Challenge Flow only)
If authentication is required, the Merchant redirects the Customer to the issuing bank's page. The issuing bank's page verifies the Customer, usually by asking them to enter an SMS code.
The redirect uses a POST request to the URL specified in the ACSUrl parameter. Parameters passed:
| Parameter | Description |
|---|---|
| threeDSSessionData | Unique transaction ID Matches the ThreeDSSessionData parameter from the response to the Pay, Block, Add, MobilePay or MobileBlock request |
| creq | Matches the CReq parameter from the response to the Pay, Block, Add, MobilePay or MobileBlock request |
When the operation is performed on the Payture side, after the check the ACS redirects the Customer with a POST request to the Payture return template. From the return template, the Customer is returned to the Merchant's website (as in the 3DS 1.0 flow).
When the operation is performed on the Merchant side, after the check the ACS returns the Customer with a POST request to the URL specified in the ChallengeNotificationUrl parameter. The request includes the following parameters:
| Parameter | Description |
|---|---|
| threeDSSessionData | Unique transaction ID Matches the value passed in the request |
| cres | Base64-encoded string containing the 3-D Secure authentication results |
Example HTML form
<html><head><title></title></head>
<body onload="setTimeout(document.forms['form'].submit(), 10000)">
<form name='form' action='{ACSUrl}' method='post'>
<input type='hidden' name='creq' value='{CReq}'>
<input type='hidden' name='threeDSSessionData' value='{ThreeDSSessionData}'>
</form>
</body></html>Completing the payment (Challenge Flow on the Merchant side only)
To complete the charge or hold of funds on a card protected by 3-D Secure, the Merchant must pass the authentication results received from the ACS to the payment gateway.
For the Payture API interface, the results are passed in the Pay3DS or Block3DS request. For Payture eWallet, they are passed in PaySubmit3DS or AddSubmit3DS. The methods are described in the 3‑D Secure 2.0 on the Merchant side (in Russian) document.
3-D Secure 1.0
To make payments more secure, most bank cards are protected by the 3-D Secure authentication mechanism.
Payment widget
An embeddable pop-up window for accepting payments on the Merchant's website. Includes secure payment data fields and an email field for sending an electronic receipt under Federal Law No. 54-FZ.
