Latinofare adds 3D Secure 2.0 to safeguard customers from card misuse

Context

EMV® Three-Domain Secure (3DS) is a messaging protocol developed by EMVCo. It allows consumers to authenticate themselves with their card issuer.

Our solution uses 3DS check to:

• Protect merchants from exposure to fraud and prevent unauthorized transactions.
• Shift liability for chargebacks for fraudulent transactions from merchants onto the card issuer.
• Help merchants (in UK) wanting PSD2 compliant Strong Customer Authentication (SCA) management and exception handling.

3D Secure 2 is an extra security layer defined by EMVCo and major credit card schemes for CNP (card-not-present) transactions. As an e-commerce authentication protocol, it enables the secure processing of payment, non-payment, and account confirmation of card transactions.

Using 3D Secure 2, the issuer inspects over 100 data parameters to:

• verify the cardholder’s authenticity
• assess the risk level of the transaction

It acts as a protocol to authenticate a cardholder or verify an account during an e-commerce transaction:

• When the issuer determines the authentication is successful, the merchant can process the transaction without any cardholder interaction.
• If the issuer classifies the transaction as risky it challenges the customer to confirm their identity using Strong Customer Authentication (SCA) mechanisms.

This is a working document created for functioning of a standalone plug-in system for 3DS2 Authentication.

Features

Authentication workflows

• Frictionless
• challenge
• 3RI

Server Integration

• Use the Web SDK to handle the 3D Secure check on your behalf

Workflow

Implementation

A lightweight javascript to be placed on the website. Basic data related to payment is to be passed in the Javascript SDK. The SDK will return Authentication Tokens, Directory Server Transaction IDs & ECI (Electronic Commerce Indicator) to be passed to the Payment Processor to get the Liability Shift on the Transaction.

Information Fields

The information that is sent to the 3DS2 system for authentication is as below

1. purchaseAmount
   Amount to be authenticated For eg. 295.98
2. acctNumber
   Credit Card Number. For eg. 4111111111111111
3. cardExpiryDate
   Credit Card Expiry Date in YYMM Format. For eg. 2502
4. cardholderName
   Full Name of the card holder. For eg. Frida Samuels
5. billAddrLine1
   Billing Address Line. For eg. 931 Beverly Dr.
6. billAddrCity
   Billing Address City. For eg. Corpus Christi
7. billAddrState
   Billing Address State Code. For eg. TX
8. billAddrCountry
   Billing Address Country Code. For eg. US for United States
9. billAddrPostCode
   Billing Address Postal Code. For eg. 78413
10. deliveryEmailAddress
    Customer Email Address. For eg. fridasamuel@yahoo.com
11. purchaseCurrency
    Purchase Currency. For eg. USD for United States Dollar
12. browserIP
    Customer’s IP address. For eg. 166.205.209.43
13. homePhone
    1. cc
       This is a calling country code of the user’s home phone. For eg. 1 for US
    2. subscriber
       This is for sending the customer’s phone number. For eg. 2131231231
14. mobilePhone
    1. Cc
       This is a calling country code of the user’s mobile phone. For eg. 1 for US
    2. subscriber
       This is for sending the customer’s mobile phone number. For eg. 2131231231

Sample Request and Response

The request looks something like below:

The response generated by 3DS2 Authenticator looks something like below:

In the response, the fields that needs to be sent to the payment processor are:

1. authenticationValue
2. dsTransID
3. eci

Presence of transStatus value as Y or A represents the Liability Shift.