Introduction
3D Secure is the new protocol being developed by the main players in the credit card payments business; its purpose is to provide a more robust level of security by verifying the identity of a card holder. This will be achieved by prompting the card holder to provide a password during the card verification process, thereby introducing a ‘personal’ element of security.
3D Secure will effectively deal with many forms of Card Not Present (CNP) fraud. So what could be possibly wrong with it?
If everyone were singing from the same hymn sheet then it would be a great idea. As things stand right now, however, it appears that the choreography that one might hope for in a project like this simply is not present. MasterCard estimates that we are a year away from complete coverage. Many companies that are supposed to be implementing it are dithering for one reason or another. Sometimes the hesitation is for business process reasons, but mostly it is because the latter arrivals to the table can benefit from the hard lessons learned by the early adopters.
Paul Baker of Master Card gave us a clear update on the status of SecureCode, the Master Card version of 3DSecure:
‘With over 40,000 merchants live in Europe and some 11.8m cardholders live and participating in SecureCode at the end of 2005 MasterCard believes that adoption has been very positive. Further merchants and cardholders will go live as the UK Debit market adopts SecureCode for its Maestro card base. MasterCard undertook extensive advertising of SecureCode in the UK in last quarter 2005 with significant increase in awareness and cardholder adoption experienced. MasterCard will continue to actively progress SecureCode adoption in support of both Credit and Debit products in 2006’.
Let’s take a look at the 3D Secure landscape to get a handle on the key concepts.
The Great (Invisible…) Chargeback Gravy Train
Chargebacks are a big pain in the butt for online merchants. Right now the card holder (you or I) has considerable latitude in refusing to pay for anything that is bought in a shop, especially online. This is not going to be a tutorial on consumer rights, but the fact is that most people do not actually realize just how much power they have under law when seeking to nullify a payment made by credit card. When a card holder does this, it is called a “chargeback” to the merchant.
With CNP transactions, especially over the Internet, the risk to the merchant is considerable. Recall from an earlier article how easy it is to generate sufficient credit card details to enable an opportunity for a fraudulent transaction. It is for this reason that merchants are very cautious in what they make available for online purchase.
Say you purchase some music online and download it. Subsequently you contact your credit card issuing bank and claim that the payment on your bill is fraudulent. The payment is then charged back to the merchant, who is at a loss for the transaction, and you are refunded for the purchase. This is ideally what 3DS is designed to solve, and in that there is a kicker for the cardholder. If you do actually get hit by a fraudulent charge on your credit card, you’re going to have a helluva time getting a refund for it. Why?
Let us imagine that everyone associated with credit card payments is signed up to 3DS. You have your PIN, and during each payment transaction, you personally verify your payment with this PIN. The added security means that under 3DS, you must be who your PIN verifies, so you cannot charge back for a fraudulent transaction. Under 3DS, the issuing bank and card holder are responsible for fraudulent payments that may appear on your bill.
Now for this to work fairly, you would think that within this new mandated protocol there would be a provision saying that the process of verifying such PINs should adhere to the rules laid out for 2 Factor Authentication in FFIEC guidelines. Think again – the banks are free to employ whatever system of verification that they see fit. If you read the previous article on verification schemes for online banking, then you know that all is not well in that sphere. A spokesperson from MasterCard absolutely agreed with this point, and there is no real reason why issuing banks could not implement higher levels of authentication for users.
So in this new world order of 3DS, if you are hacked and fraudulent transactions appear on your bill, then you and the bank that issued the card to you are going to have to sort it out. You will not be able to charge the fee back to the merchant.
3DS Explained
Of course the world is not ideal, and not everyone wants to subscribe to 3DS. In my opinion, for 3DS to be completely effective, there needs to be a straight changeover from one system to the other. In the Euro zone, countries switching from their native currencies to the Euro currency did so overnight. The same occurred when Euro countries changed from imperial to decimal currency formats. However, you have to feel a little sorry for Visa and Master Card, because they are not governments, and there are limits to what they can force through banking and purchasing systems.
Is it the consumers that are holding up the transition to 3DS? Not likely, as they will be instructed to comply with whatever policy is adopted by their card issuing banks, and won’t have much of a say in the matter. Nope, the problem is more in the merchant, banking and payments gateway world.
To help you understand the problem a little better, I need to explain at a high level how both the current system and 3DS work. Let’s start with a highly summarized description of the current process.
Right now, when you purchase an item online, you are routed to the checkout page where you enter your details. The payment is then routed to a payments gateway that runs a slide rule over risk and verification. On a successful outcome, the payment is sanctioned, and recorded with the merchants own bank. During an overnight process, the merchant bank forwards the payment request to the card holder’s issuing bank, and the transaction is satisfied. You in turn get the transaction on your next monthly bill.
For 3DS to work, it is necessary to carve up that process into logical domains that intercommunicate in a manner laid down by the 3DS Protocol. There are three 3DS domains:
- The Issuing Domain, consisting of the Issuing Bank and Credit Card Holder;
- The Acquiring Domain, containing the Merchant, Payments Gateway and Merchant Bank; and
- The Interoperability Domain, which consists of routing servers, software and other interconnecting devices that allow all the elements to communicate in real time.
The following diagram is available on Visa’s information site:
3DS Explained, Continued
Below is my edited explanation of the steps above; I’ve attempted to keep the discussion at level sufficiently simple for all to understand. If you require precise technical information regarding 3DS, then both Visa and MasterCard have downloadable documentation that is very detailed.
| Step-1 | The Shopper browses at merchant site, adds items to the shopping cart, then finalizes purchase. |
| Step-2 | The Merchant Server sends information to the Directory Server; this acts as a traffic director that examines the initial number sequence of the credit card, and figures out which issuing bank is responsible for it. |
| Step-3 | The Directory Server identifies the payer’s issuing bank and queries that bank’s Access Control Server (ACS) to determine if 3DS authentication is available. That is, has the payer enrolled in 3DS and been issued with a PIN or other pass phrase. |
| Step-4 | The Banking ACS responds to the Directory Server. |
| Step-5 | The Directory Server forwards the ACS response to the MPI-a plug-in piece of code on the merchant’s site-to verify that the card holder is enrolled in 3DS. If not, then a traditional payment is processed. |
| Step-6 | If the payer is enrolled in 3DS, then a Payer Authentication Request is made to the Issuing Bank’s ACS via the shopper’s browser. |
| Step-7 | The ACS receives the Payer Authentication Request. |
| Step-8 | The ACS authenticates the Shopper. |
| Step-9 | The ACS returns the Payer Authentication Response to the MPI via the Shopper’s browser device. The ACS sends the selected data to the Authentication History Server. |
| Step-10 | The MPI receives the Payer Authentication Response. |
| Step-11 | The MPI validates the Payer Authentication Response signature. |
| Step-12 | The Merchant proceeds with authorization exchange with its acquirer. |
Okay, so what does this all really mean?
In a nutshell, the card holder will be issued with a personal ID Code that is either a PIN or a passphrase. Having submitted the credit card information for validation, a screen will appear that requires the card holder to enter that ID Code. Their card’s issuing bank will verify that the entered code is correct, and the payment process will continue.
For the card holder, 3DS will not mean a complete usability upheaval. For everyone else who is engaged in managing that process, however, the headaches are considerably bigger. Software development design and implementation is costly, and when you require that many organizations to intercommunicate, the process gets really difficult. There are Internet technologies that allow different systems to communicate and exchange data in real time. The number of possible technical glitches is huge, however, and the potential for such systems to go out of synch during transaction processing is considerable.
If you are a credit card holder who shops on the Internet, you should be feeling a bit nervous right now. All is not lost, however. 3D Secure is a merchant-oriented protocol, and it will certainly prompt merchants to put much more merchandise onto the Internet, but there is a price to pay. The fact is that 2 Factor Authentication must become the normal standard for card holder security. 3D Secure still does not eliminate fraud that may occur as a result of session hijacking and other techniques described in previous articles in this series.