3‑D Secure authentication
Overview
3‑D Secure (Three-Domain Secure) customer authentication is aimed to increase secure processing of online card payments. This authentication procedure is essential for processing purchases and can be carried out in a variety of ways: the customer may be required to perform certain actions to confirm their identity or their involvement can be bypassed altogether.As a rule, this authentication procedure is essential for processing purchases and can be carried out according to the following authentication flows:
3‑D Secure supports the following authentication flows:
- Frictionless flow—authentication that does not involve interaction with the customer. Frictionless authentication helps increase acceptance rates and enhances customer experience.
- Challenge flow—authentication that requires the customer to perform certain actions in order to confirm their identity. Customers can be authenticated with the use of one-time code or biometric data if this capability is supported by the issuer.
The merchant cannot select the authentication flow. While the merchant can indicate which flow selection is preferable, the final decision is made by the issuer. In addition to specifying the preferred flow, the merchant can pass a range of optional parameters in the request for opening the payment form which increases the possibility of the frictionless flow selection. The information about these parameters is presented in the sections that follow.
User scenarios
The following are the steps the customer takes when making a purchase that involves the 3‑D Secure authentication.
- The customer selects the option to make a purchase on the side of the merchant's web service.
- The payment form is displayed to the customer in accordance with the parameters passed in the request. The customer performs the required actions and confirms the purchase following which they are shown the Payment Page preloader.
- If the issuer selects the challenge flow, the customer is shown the authentication page (ACS). The customer completes the required steps and is shown the Payment Page preloader.
- The customer is shown the page with the payment result information.
The number and sequence of steps in this scenario may slightly change: for example, if the authentication involves the provider, the customer is redirected first to the provider's page and then to the ACS page.
Implementation
3‑D Secure is implemented when the ecommpay specialists add card payments to the merchant's project. Other than that, the merchant is not required to take any additional steps.
Data formats
Requests for processing card payments must contain one of the following parameters.
Parameters | Description |
---|---|
|
Customer's email. Required if the customer's phone number is not passed. |
|
Customer's phone number. Required if the customer's email is not passed. |
These parameters are not required in requests for payment instrument verification (Card Verify Payment Page operation mode).
To increase the possibility of the frictionless flow selection, it is recommended that you pass additional payment and customer data in the request for opening the payment form. Such data can include the indication of the preferred authentication flow, the selected shipping method, the customer's billing address and contact information. This information can be collected in whatever way is deemed most convenient, including via the payment form (using the capability of collecting additional customer data), and passed in the following parameters:
Parameter | Description | tree |
---|---|---|
|
Details of the customer's purchase and the indication of the preferred authentication flow. A Base64 string converted from the |
2 |
|
Indicates whether the challenge flow is preferred. Possible values:
|
2-12 |
|
The dimensions of a window in which the authentication page opens. Possible values:
|
2-22 |
|
The date the preordered merchandise or service will be available in the DD-MM-YYYY format. |
2-32 |
|
Indicates whether the purchase is a preorder. Possible values:
|
2-42 |
|
Indicates whether the customer is buying the merchandise or the service for the first time or it is a repeat purchase. Possible values:
|
2-52 |
|
Object with information about a purchase made with a prepaid or gift card. | 2-62 |
|
The amount of the purchase made with a prepaid or gift card in the smallest units of currency. | 2-6-12-6 |
|
Currency of the purchase made with a prepaid or gift card in the ISO 4217 alpha-3 format (for example, GBP). | 2-6-22-6 |
|
Total number of prepaid or gift cards used for making a purchase. | 2-6-32-6 |
|
Customer's account details and contact information kept on file on the side of the web service. A Base64 string converted from the |
3 |
|
Indicates whether the customer's billing address matches the address specified in the Possible values:
|
3-13 |
|
Customer's home phone number, contains between 4 and 24 digits (for example, 44991234567 ). |
3-23 |
|
Customer's work phone number, contains between 4 and 24 digits (for example, 44997654321 ). |
3-33 |
|
Object with the customer's account information kept on file by the merchant. | 3-43 |
|
Additional information about the customer's account in free text, for example, its identifier. Can contain up to 64 characters. | 3-4-13-4 |
|
Number of payment attempts in the last 24 hours, 3 characters maximum (999 ). |
3-4-23-4 |
|
Number of payment attempts in the last 365 days, 3 characters maximum (999 ). |
3-4-33-4 |
|
Number of days since the customer account was created. Possible values:
|
3-4-43-4 |
|
Additional login information in free text, can contain up to 255 characters. | 3-4-53-4 |
|
Indicates how the customer was authenticated during their most recent login to the web service. Possible values:
|
3-4-63-4 |
|
Date and time of the customer's most recent account login in the DD-MM-YYYYhh:mm format. |
3-4-73-4 |
|
Account creation date in the DD-MM-YYYY format. |
3-4-83-4 |
|
Date of the most recent change to the account, except for the password change or password reset, in the DD-MM-YYYY format. |
3-4-93-4 |
|
Number of days since the most recent change to the account, except for the password change or password reset. Possible values:
|
3-4-103-4 |
|
Date of the most recent password change or reset in the DD-MM-YYYY format. |
3-4-113-4 |
|
Number of days since the most recent password change or reset. Possible values:
|
3-4-123-4 |
|
Card record creation date in the DD-MM-YYYY format. |
3-4-133-4 |
|
Number of days since the payment card details were saved to a customer's account. Possible values:
|
3-4-143-4 |
|
Number of attempts to save new card details to a customer's account in the last 24 hours, 3 characters maximum (999 ). |
3-4-153-4 |
|
Number of purchases made via the customer's account in the last 6 months, 4 characters maximum (9999 ). |
3-4-163-4 |
|
Indicates the presence of suspicious activity. Possible values:
|
3-4-173-4 |
|
Purchase shipping information. A Base64 string converted from the |
4 |
|
Object with shipping details. | 4-14 |
|
Shipping address, can contain up to 150 characters. | 4-1-14-1 |
|
Date when the specified shipping address was used for the first time, in the DD-MM-YYYY format. |
4-1-24-1 |
|
Number of days since the specified shipping address was used for the first time. Possible values:
|
4-1-34-1 |
|
Shipping city, can contain up to 50 characters. | 4-1-44-1 |
|
Shipping country code in the ISO 3166-1 alpha-2 format (for example, GB ). |
4-1-54-1 |
|
The email to deliver purchased digital content to if the customer chooses email delivery. Can contain up to 255 characters. | 4-1-64-1 |
|
Delivery time. Possible values:
|
4-1-74-1 |
|
Indicates whether the customer's name matches the recipient's name. Possible values:
|
4-1-84-1 |
|
Shipping postal code, can contain up to 16 characters. | 4-1-94-1 |
|
State, province, or region code in the ISO 3166-2 format, for example, DOR for Dorset.If you specify this parameter, you also need to specify and populate the |
4-1-104-1 |
|
Delivery option selected by the customer. Possible values:
|
4-1-114-1 |
|
Information about the previous authentication attempt of the customer. A Base64 string converted from the |
5 |
|
Object that contains information about the previous authentication attempt of the customer. | 5-15 |
|
The identifier that the issuer assigned to the previous operation of the customer and returned in the acs_operation_id parameter of the callback with payment processing result. Can contain up to 36 characters. |
5-1-15-1 |
|
The flow used by the issuer to authenticate the cardholder when processing the previous operation. It is a value of the Possible values:
|
5-1-25-1 |
|
Date and time of the previous successful customer authentication as returned in the mpi_timestamp parameter of the callback with payment processing result. |
5-1-35-1 |
|
Street of the customer's billing address. | 6 |
|
City of the customer's billing address. | 7 |
|
Country of the customer's billing address in the ISO 3166-1 alpha-2 format. | 8 |
|
Postal code of the customer's billing address. | 9 |
|
State, province, or region code in the ISO 3166-2 format, for example, DEV for Devon.If you specify this parameter, you also need to specify and populate the |
10 |
|
Customer's email. | 11 |
|
Customer's phone number, contains between 4 and 24 digits. | 12 |