From the first moment that humanity started to identify its primary needs, it was clear that many tasks required more than one individual to complete them. The first humans had to make teams, organize, and eventually, exchange with other teams… So began payment transactions.
Many years later, money was invented; and many (many, many) years later, credit cards came to market, first with pure physical vouchers and then with that “strange black stripe” on their back.
Since then, the payments ecosystem has become more complex. Those cards we started to see a few decades ago now have a chip, and some of them can do transactions without even touching the terminal. If only those early humans could see it; pure magic!
Wall-less Mart
But technology, not magic, changes it all. Computers have evolved enormously make payments easier and faster.
The Internet became the most powerful tool, changing almost everything except for the purchase experience: Go to the store, explore all the aisles, find what you needed, await in line at the cashier and pay (with money or card or even a check).
Then, a new experience opened our minds: Sales on TV. At first, these orders were cash only at the point of receipt, but with the advent of the credit card, consumers could pay for their goods over the phone…
What? You want me to give you my credit card data?
“Humans can’t be trusted, they can cheat, they can rob, they can steal,” said the consumer, “As much as I like the idea of getting them at my front door, I need a new way to buy things without leaving my house.”
Internet companies soon entered into the goods-selling market, allowing consumers to search, compare prices, apply coupons and find deals. Many merchants reduced costs and yielded better statistics of consumption and sales, thus increasing earnings.
While consumers still had to provide credit card data, the transfer of data became secure: SSL, HTTPS and other security acronyms were mentioned by the websites to indicate that cryptographic measures were put in place to secure payment data. Some peace of mind for consumers, at last.
Cards, EMV and Beyond
The rise of online sales came along with the implementation of EMV in many places in the world (not the U.S.), which meant more security for the people who visited the stores, but there was no real security improvement for those who were buying online. A new element joined the equation years later: Remote mobile payments.
In terms of payment security, initially everything was the same for online sales,. EMV Co. then decided to start participating more actively in the security of Card Not Present transactions, specifically for app-based purchases on cell phones and other smart devices.
Visa created 3D-Secure, an online authentication protocol for shopping on PC web browsers. Its goal was to support new and emerging technologies for remote transactions. In 2015, EMV Co. announced they would oversee improving the protocol and releasing the 3D-Secure 2.0.
By the third quarter of 2016, the EMV® 3DS 2.0 Specification was released. The messaging protocol is said to enable consumers to authenticate themselves with their card issuers (banks) when making CNP (Card-Not-Present) purchases, and even identifying themselves for other non-payment activities, such as adding a card to their preferred wallet (Apple Pay® or Google Pay®).
The task for 3DS is simple: It must authenticate the cardholder with the issuer before the transaction is sent and continue only if that authentication is positive; after that, the purchase authorization will be completed at the issuer systems.
One of the greatest advantages of 3DS 2.0 over 1.0 is the number of data elements which are considered in the protocol[1]:
| 3DS 1.0 | 3DS 2.0 |
| Acquirer Merchant ID | Browser Time Zone |
| DS URL | Merchant Country Code, Category Code, Name, Risk Indicator (Delivery timeframe, Re-order, Pre-order, Gift card), Category Type |
| Message, Extension, Version | Cardholder Account Number, Shipping Address, Account Identifier, Email Address, Home Phone Number, Mobile Phone Number, Work Phone Number, Name, Account Information (Account Age, Password Change, Number of Transactions per day/year, Shipping Name Indicator, Suspicious Activity, Payment Account Age…) |
| Browser User-Agent | 3DS Requestor Name, Non-Payment Indicator, Prior Transaction Authentication information, Requestor URL, Server Reference Number, Operator ID, Transaction ID, URL, 3DS Requestor Authentication Information (Methods, Challenge Indicator, ID, Initiated Indicator). |
| Acquirer BIN | Account type |
| Account Number (from Cardholder) | Message Category, Extension, Version |
| Billing Address | |
| SDK Reference Number, SDK Transaction ID, | |
| Purchase amount, Currency, Date & Time | |
| Browser Accept Headers, Time Zone | |
| IP Address | |
| Device Channel, Device Information, Rendering Options Supported |
Having more data elements to leverage in the protocol allows the data to flow in much more frictionless fashion; a key benefit of the new 3DS.
The other key benefits are:
- Enabling merchants to integrate cardholder authentication into their checkout process for app and browser purchase experiences
- Minimized checkout abandonment during authentication
- Ability to perform merchant-initiated authentications
- Reduction of potential fraud-related chargebacks
- Improved authorization rates (statistical data is not clearly defined yet)
- Reduced risk of fraud for issuers
- New devices and channels supported
- Variety of authentication methods supported
- Cardholders can make purchases using their preferred medium (i.e., phone, watch, tablet)
- Most of the authentications will not be noticed by consumers
- Enhanced online security
- Consumer experience is improved and consistent
The process for 3DS could be explained as follows:
- The cardholder initiates the transaction at the merchant site
- The merchant’s 3DS server sends the authentication request to the issuer
- Based on all the data received from the merchant, the issuer decides whether the transaction can be approved with or without cardholder interaction
- The authentication response is sent to the merchant. If more data from the cardholder is needed, the issuer will start a challenge Request/Response with the cardholder
- The merchant and the issuer proceed with the purchase
- The cardholder is informed by the merchant app/website if the purchase was successful or not
3DS Depot
In order to offer the 3DS service to your consumers, there are certain components you must incorporate into your infrastructure:
- 3DS ACS: Access Control Server is in the issuer domain. Each card issuer is required to maintain an ACS which is used to support cardholder authentication. The cardholder will identify itself against the ACS and the result will throw a signature which will be passed through the customer’s browser/app and to the…
- MPI: Merchant Plug-In is installed in the acquirer domain to activate the cardholder interface during the authentication process. MPI will identify the account number and query card issuer servers to determine if it is enrolled in a 3DS program, it will then return to the website of the ACS.
- 3DS Server: The main processor at the merchant level. This server will provide the primary infrastructure for holding together all the pieces.
- 3DS SDK: Licensed software which will work as the front end to the cardholder and will integrate the other participants in the 3DS solution.
As you can see, the purchase and payment technologies have evolved very much since those ancient times. 3DS is only the latest in a long line of payment innovations. The future is today.
For questions about EMV 3DS, its implementation and implications, please contact Victor Madera at [email protected].
[1] US Payments Forum (Producer). (2019). EMV 3-D Secure Data Elements [Webinar].
