3D Secure (Secure Code or Verified by Visa), is all about call back protection and making sure card holders are who they say they are. The Illustration and process that follows, shows 3D secure in use as implemented by Merchants using iVeri Enterprise and not iVeri Lite. Illustrating the process in this way, helps to show how each entity is involved even if certain functions are performed on behalf of Merchants using iVeri Lite.
Process Flow of a 3D Secure Transaction
Entities Involved in a 3D Secure Transaction
- An Association, i.e. Visa or Master Card, resides between the Acquiring and Issuing financial institutions (Banks). The Association has links and agreements between the respective banks, so by virtue of the Issuer having an agreement with the Association they in effect have an agreement with the Acquire who also has an agreement with the Association.
- In addition to the Associations, South Africa has an entity called BANKSERV which processes local card transactions on behalf of certain South African banks. All local transactions are sent through BANKSERV but as far as the Merchant is concerned, his interaction with BANKSERV is transparent.
BANKSERV also hosts the Access Control System and Directory Service on behalf of curtain banks in South Africa.
BANKSERV operates in the space of cooperation between the banks in terms of clearing and settlement and is non-competitive to its shareholders and customers. Merchants need to register their Merchant ID with BANKSERV. The Internet is used to network most of the entities needed for a 3D Secure transaction. When a Merchant integrates 3D Secure into their Website, they need to integrate a 3D Secure API as well as an Enterprise API.
Understanding the Process Flow
- When the Card Holder is at the point where he has chosen a basket of goods and is on the brink of paying for it, he is presented with, amongst others, a Credit Card Number field, Expiry Date field and CVV field which he completes
- After clicking Apply the Card Holders details are sent to the Merchant's 3D API thereby starting a conversation between the Merchant and Card Holder. The Merchant wants to protect himself against charge backs so he will perform a 3D secure transaction as opposed to a normal transaction.
If the Merchant did not want the protection, he would simply send the form variables / tag names straight to Enterprise API and from there it would (following the green flow lines) go to the Payment Gateway – Acquire – Association – Issuer and back with an approved response but without any charge back protection. - To Continue through with an Enterprise 3D transaction (following the red flow lines), the Merchant now has, amongst others, the Card Holders Credit Card Number, Expiry Date and CVV number. He uses the 3D API to send a message to the Directory service (who governs the charge back domain) asking two questions.
Firstly, is the Issuer of the card enrolled for 3D secure? If NO, the API gets an immediate response. - If Yes, the Directory Service will ask the Access Control System (ACS) of the Issuing Bank if the specific card is enrolled for 3D secure.
- If YES, the Directory Service will respond to the Merchant with the URL of the issuing banks ACS. if NO, it will respond to the Merchant's 3D API with, “The Card Holder is not enrolled but he should be”.
The Merchant now needs to make two decisions - does he stop the transaction since he now knows the card is completely uncovered or does he takes a chance? - Let's say he doesn't want to take any chances; he uses the ACS URL to redirect the Card Holders browser from the Merchant's website to the actual ACS website of the Issuing Bank. From the Card Holders perspective, he has gone from being on the merchant’s website to being on his bank's ACS website.
There are 2 situations that may occur here:
Firstly, the Card Holder is enrolled, in which case he will be asked if he would like to continue with the transaction, if so, to enter his password and press submit. If the Card Holder is not enrolled, he will be asked to fill in specific details to which his bank will respond with a sms to validate that the Card Holder is who he says he is. The Card Holder will then use the password received in the sms and press submit if he elects to continue with the transaction. - Clicking submit will do another redirect back to the Merchants website with 1 of a few responses.
1. The Card Holder canceled so stop the transaction.
2. If the Card Holder has entered his password and been validated by the issuing bank, the Merchant will get a certificate and other pertinent information in the response. - The Merchant then sends the information to the directory service again, requesting it to validate that the information is not fraudulent. This normally checks out fine, but it needs to be done none the less.
- The form variables / tag names and information added when the ACS issued the validation certificate are sent to the Enterprise API and (following the green flow lines) onto the The Payment Gateway – The Acquirer – The Association – The Issuer – and back.
Since every entity has validated that the Card Holders details are correct and that funds are available, the risk of charge back is greatly reduced. Effectively where the risk of a card not present scenario would lie with the Merchant it now lies with the Card Holder, this is due to the Merchant taking the trouble to integrate 3D secure to verify the Card Holders details through a certificate received from the Issuer that has been validated by the Directory Service and the Merchant is assured that the Card Holder has funds (by the green flow lines). This way the Merchant is almost 100 % assured against card not present fraud.