3D Secure authentication
Understand 3D Secure (3DS) authentication and its role in preventing fraud and enhancing security.
What is 3D Secure (3DS)?
3D Secure (3DS) is a secure authentication protocol designed to add an extra layer of security to card transactions to help prevent fraud. It applies to card-not-present transactions.
During the payment process, the card issuer verifies the cardholder's identity based on factors, such as cardholder data, the device used, or the customer's previous purchases. Suppose the issuer cannot verify the identity. In that case, they will redirect the user to a verification page where they might enter a one-time passcode received via SMS, use biometric methods, or use other forms of authentication.
One crucial benefit of 3DS authentication is the liability shift: when a transaction is authenticated, the liability for chargebacks transfers from the merchant to the issuer. This means merchants are not responsible for chargebacks on transactions authenticated through 3DS.
How does it work
When a transaction happens, its details are handled by different specialized systems within the 3DS protocol. Here’s a breakdown of the key components involved:
- 3DS Server. This is the initial system that ensures all the necessary information is collected during a transaction. It serves as the entry point in the 3DS process, capturing transaction data and cardholder information to initiate authentication.
- 3DS Directory Server. This system acts as a router, directing the authentication request to the appropriate card issuer. It determines which server to send the authentication request to by identifying the card issuer. The 3DS Server and the Directory Server perform mutual authentication, ensuring secure data exchange between them.
- 3DS Access Control Server (ACS). Often referred to as the issuer domain, this is the environment controlled by the card issuer, with whom the cardholder has a direct relationship. Each issuer's ACS has its own unique set of rules and tolerance for transactional threats, based on its risk assessment.
When the risk tolerance is met, meaning the transaction is considered safe, the data is sent back to the payer for confirmation. However, if the ACS identifies a potential risk concerning the payer's identity, it issues a challenge. This challenge is sent back to the payer, who must then verify their identity using an established authentication method (e.g., entering a PIN, answering a security question, or using biometric verification).
Upon successful verification by the payer, the transaction is completed. If the verification fails, the transaction is declined to prevent potential fraud.
Why is 3D Secure important?
3DS ensures that only the legitimate cardholder can complete a transaction, significantly reducing fraud risk and complying with regional mandates.
3D Secure authentication options
Third-party authentication
Use authentication data from a third-party provider when submitting a payment. This method integrates external security measures into the dLocal payment process.
See more information
dLocal authentication
Perform the authorization using dLocal as the provider when submitting a payment. This ensures secure and verified transactions, integrating seamlessly.
See more information
Third-party authentication
Submit a payment, using authentication data from a third-party 3DS provider.
To authorize a 3DS authenticated payment, you need to include the three_dsecure object in your payment request.
Example request
curl -X POST \
-H 'X-Date: 2018-02-20T15:44:42.310Z' \
-H 'X-Login: {X-Login}' \
-H 'X-Trans-Key: {X-Trans-Key}' \
-H 'Content-Type: application/json' \
-H 'X-Version: 2.1' \
-H 'User-Agent: MerchantTest / 1.0 ' \
-H 'Authorization: V2-HMAC-SHA256, Signature: 1bd227f9d892a7f4581b998c21e353b1686a6bdad5940e7bb6aa596c96e0a1aa' \
-d '{body}'
https://api.dlocal.com/secure_payments
{
"amount": 120.00,
"currency": "BRL",
"country": "BR",
"payment_method_id": "CARD",
"payment_method_flow": "DIRECT",
"payer":{
"name": "Thiago Gabriel",
"email": "[email protected]",
"document": "53033315550",
"user_reference": "12345",
"address": {
"state": "Rio de Janeiro",
"city": "Volta Redonda",
"zip_code": "27275-595",
"street": "Servidao B-1",
"number": "1106"
},
"ip": "179.27.83.210",
"device_id": "2fg3d4gf234"
},
"card":{
"holder_name": "Thiago Gabriel",
"number": "4111111111111111",
"cvv": "123",
"expiration_month": 10,
"expiration_year": 2040,
"capture": false
},
"three_dsecure":{
"mpi": true,
"three_dsecure_version": "2.2.0",
"cavv": "3q2+78r+ur7erb7vyv66vv\/\/\/\/8=",
"eci": "05",
"enrollment_response": "Y",
"authentication_response": "Y"
},
"order_id": "657434343",
"notification_url": "http://merchantsite.com/notifications"
}
{
"id": "D-4-cf8eef6b-52d5-4320-b5ea-f5e0bbe4343f",
"amount": 120,
"currency": "BRL",
"payment_method_id": "CARD",
"payment_method_type": "CARD",
"payment_method_flow": "DIRECT",
"country": "BR",
"card": {
"holder_name": "Thiago Gabriel",
"expiration_month": 10,
"expiration_year": 2040,
"brand": "VI",
"last4": "1111"
},
"three_dsecure": {
"eci": "05"
},
"created_date": "2018-12-26T20:26:09.000+0000",
"approved_date": "2018-12-26T20:26:09.000+0000",
"status": "AUTHORIZED",
"status_detail": "The payment was authorized",
"status_code": "600",
"order_id": "657434343",
"notification_url": "http://merchantsite.com/notifications"
}
dLocal authentication
dLocal can handle all the authentication process in case the merchant has doubts of the identity of the cardholder avoiding a fraudulent transaction which will incur in a chargeback or in case the region mandates 3DS authentication.
In such a scenario, the Create Payment function will return a payment with status = PENDING (status_code = 101). The response will include a three_dsecure object, containing a redirect_url. Users need to be redirected to this URL to complete the authentication. After a successful authentication, the payment will be processed, and the user will be directed to the callback_url. In case the authentication failed, a REJECTEDpayment notification will be received and the user will be redirected to the callback_url.
Force 3D Secure authentication
To force a 3DS authenticated payment, you need to create a payment with the parameter force = TRUE within the three_dsecure object.
Example request
curl -X POST \
-H 'X-Date: 2018-02-20T15:44:42.310Z' \
-H 'X-Login: {X-Login}' \
-H 'X-Trans-Key: {X-Trans-Key}' \
-H 'Content-Type: application/json' \
-H 'X-Version: 2.1' \
-H 'User-Agent: MerchantTest / 1.0 ' \
-H 'Authorization: V2-HMAC-SHA256, Signature: 1bd227f9d892a7f4581b998c21e353b1686a6bdad5940e7bb6aa596c96e0a6ec' \
-d '{body}'
https://api.dlocal.com/secure_payments
{
"amount": 120.00,
"currency": "BRL",
"country": "BR",
"payment_method_id": "CARD",
"payment_method_flow": "DIRECT",
"payer":{
"name": "Thiago Gabriel",
"email": "[email protected]",
"document": "53033315550",
"user_reference": "12345",
"address": {
"state": "Rio de Janeiro",
"city": "Volta Redonda",
"zip_code": "27275-595",
"street": "Servidao B-1",
"number": "1106"
},
"ip": "2001:0db8:0000:0000:0000:ff00:0042:8329",
"device_id": "2fg3d4gf234"
},
"card":{
"holder_name": "Thiago Gabriel",
"number": "4111111111111111",
"cvv": "123",
"expiration_month": 10,
"expiration_year": 2040
},
"three_dsecure":{
"force": true
},
"order_id": "657434343",
"notification_url": "http://merchantsite.com/notifications"
}
curl -X POST \
-H 'X-Date: 2018-02-20T15:44:42.310Z' \
-H 'X-Login: {X-Login}' \
-H 'X-Trans-Key: {X-Trans-Key}' \
-H 'Content-Type: application/json' \
-H 'X-Version: 2.1' \
-H 'User-Agent: MerchantTest / 1.0 ' \
-H 'Authorization: V2-HMAC-SHA256, Signature: 1bd227f9d892a7f4581b998c21e353b1686a6bdad5940e7bb6aa596c96e0a6ec' \
-d '{body}'
https://api.dlocal.com/secure_payments
{
"amount": 120.00,
"currency": "BRL",
"country": "BR",
"payment_method_id": "CARD",
"payment_method_flow": "DIRECT",
"payer":{
"name": "Thiago Gabriel",
"email": "[email protected]",
"document": "53033315550",
"user_reference": "12345",
"address": {
"state": "Rio de Janeiro",
"city": "Volta Redonda",
"zip_code": "27275-595",
"street": "Servidao B-1",
"number": "1106"
},
"ip": "2001:0db8:0000:0000:0000:ff00:0042:8329",
"device_id": "2fg3d4gf234"
},
"card":{
"holder_name": "Thiago Gabriel",
"number": "4111111111111111",
"cvv": "123",
"expiration_month": 10,
"expiration_year": 2040,
"capture": false
},
"order_id": "657434343",
"notification_url": "http://merchantsite.com/notifications",
"callback_url": "http://merchantsite.com/callback"
}
{
"id": "D-4-cf8eef6b-52d5-4320-b5ea-f5e0bbe4343f",
"amount": 120,
"currency": "BRL",
"payment_method_id": "CARD",
"payment_method_type": "CARD",
"payment_method_flow": "DIRECT",
"country": "BR",
"card": {
"holder_name": "Thiago Gabriel",
"expiration_month": 10,
"expiration_year": 2040,
"brand": "VI",
"last4": "1111"
},
"three_dsecure": {
"redirect_url" : "http://api.dlocal.com/three-ds/M-64356345634587b3495"
},
"created_date": "2018-12-26T20:26:09.000+0000",
"status": "PENDING",
"status_detail": "The payment is pending 3D Secure authentication.",
"status_code": "101",
"order_id": "657434343",
"notification_url": "http://merchantsite.com/notifications"
}
Additional information
Electronic Commerce Indicator (ECI) Value
The ECI is a value that indicates the level of security used when the cardholder provides payment information to the merchant. The value generally ranges from 0 to 7, though this can vary slightly depending on the card network.
The primary purpose of the ECI value is to signal the level of security present in a transaction. This helps to manage risks and understand the context of payment authorization.
brand | ECI | Description |
|---|---|---|
VI, VD | 05 | Authenticated by Issuer - Chargeback risk shifted to Issuer. |
VI, VD | 06 | Authentication attempted but not completed. |
VI, VD | 07 | Authentication is either failed or could not be attempted; possible reasons being both the card and Issuing Bank are not secured by 3DS, technical errors, or improper configuration. |
MC, MD, MS | 00 | Not authenticated. |
MC, MD, MS | 01 | Authentication attempted but not completed. |
MC, MD, MS | 02 | Authenticated by Issuer - Chargeback risk shifted to Issuer. |
MC, MD, MS | Other | Not authenticated. |
EL | 05 | Authenticated by Issuer - Chargeback risk shifted to Issuer. |
EL | 06 | Authenticated by Network - Chargeback risk shifted to Issuer. |
EL | 07 | Not authenticated. |
AE | 05 | Authenticated by Issuer - Chargeback risk shifted to Issuer. |
AE | 06 | Authenticated by Network - Chargeback risk shifted to Issuer. |
AE | 07 | Not authenticated. |
DI | 05 | Authenticated by Issuer - Chargeback risk shifted to Issuer. |
DI | 06 | Authenticated by Network - Chargeback risk shifted to Issuer. |
DI | 07 | Not authenticated. |
Let’s collaborate to create a better experience.
Give feedbackUpdated about 1 month ago