Elavon Payment Gateway Integration Guide 3D Secure Version: v1.1
Table of Contents 1 About This Guide 3 1.1 Purpose 3 1.2 Audience 3 1.3 Prerequisites 3 1.4 Related Documents 3 2 Introduction 4 3 3D Secure 5 4 3D Secure Redirect Process 8 4.1 The Scenarios 8 4.2 The sequence of events 11 4.3 3D Secure redirect response message 13 Page 2
1 About This Guide This section outlines the purpose and aim of the guide, target audience, any source materials or terminology used, and a general document description. Please note that this document is regarded as confidential and is for customer use only. It has been supplied under the conditions of your payment-processing contract. 1.1 Purpose The purpose of this guide is to give an overview of the 3D Secure Redirect service available from Elavon Payment Gateway. 1.2 Audience The target audience for this guide is merchants and developers who have signed up for and are implementing the 3D Secure Redirect Service. 1.3 Prerequisites In order to use this guide, you should have experience with and knowledge of the following concepts: Correct use of the Elavon Auth Redirect service, as outlined in the Elavon Auth Developer's Guide 1.4 Related Documents In addition to this guide, you can also refer to the following documents in the Elavon Payment Gateway documentation set for information about the 3D Secure service: 3D Secure Outline Elavon Auth Developer s Guide Page 3
2 Introduction In order to use the 3D Secure Redirect service you must advise Elavon Payment Gateway of the scenarios, outlined within this guide, under which you would like to continue with an authorisation. By default, Elavon Payment Gateway will only allow a transaction to continue for authorisation when a shift in liability will be possible. Page 4
3 3D Secure 3D Secure is the generic name given to the cardholder authentication scheme developed by the card schemes. Visa branded their implementation "Verified by Visa" (or VbyV) and MasterCard branded theirs "SecureCode". The process involved is identical for both. There are two important parts to an online payment using a credit card - authorisation and authentication. Before the advent of 3D Secure, the only part implemented online was authorisation - this is where the credit card account is checked to see if there are funds. No authentication of the cardholder was performed. In the customer present world (i.e. not online, but actually in-person at a checkout) the cardholder is required to also sign a receipt or enter their PIN. This process protects the merchant from fraud as they have a physical piece of paper to prove the customer made the purchase. Online, the merchant has no proof the cardholder actually made the purchase - if the cardholder repudiates the transaction (i.e. claims it wasn't them) then the merchant is fully liable and must refund the customer. This is known as a chargeback. 3D Secure aims to eliminate this risk of repudiation. By forcing the cardholder to log onto their own bank's website before each online transaction, they push the liability for the transaction back to the cardholder. They can no longer claim it wasn't them, because only they are supposed to know their own passphrase. This process involves several new pieces of software to be put in place. On the merchant's site an MPI is required. This is the Merchant Plug In - it is the component that communicates with the other components during the actual transaction. 3D Secure is the Elavon Payment Gateway MPI - it is a hosted service, meaning that the merchant does not need to install software on their websites as Elavon Payment Gateway hosts it for you, unlike most other MPI vendors. Visa and MasterCard created new systems called the Visa Directory and MasterCard Directory where information about which banks have implemented the 3D Secure process is held. The cardholder's bank (the "issuing bank") needs to set up software called the ACS (Access Control Server) that allows the cardholder to enter their passphrases while shopping online. They also need to allow their cardholders a way to enrol themselves (set up their Page 5
passphrases). The cardholders need to set up their passphrases. This seems like a lot of new processes that need to be in place, but it has been implemented in such a way that all the pieces are not required for the merchant to see the benefit. Once the merchant has implemented an MPI, and the acquiring bank is able to accept the new data in the messages, then the merchant is no longer liable for repudiation chargebacks. The liability is pushed back to the issuing bank, putting pressure on them to implement their own ACS so that they can push the liability back to the cardholder where it should belong. The diagram below shows the circle that is completed once the 3D Secure process is implemented. The Customer shops online, enters their card details. The merchant sends these details to 3D Secure which forwards them to the Visa/MasterCard Directory. The directory knows that the cardholder's bank is implementing the process, so it checks to see if the cardholder is enrolled with a passphrase. They are, so the location of the ACS website is sent all the way back to the merchant's website. The merchant redirects the cardholder to this website; there they are presented with the familiar login to their bank. Once they log in successfully, the information is sent back through the merchant website to 3D Secure for validation. If successful, some information is passed back to the merchant so that they can now authorise the card as normal, safe in the knowledge that the transaction cannot be charged back due to repudiation. Page 6
If the cardholder is not enrolled with a passphrase, the Directory will let 3D Secure know, and the merchant can proceed with the authorisation - still safe in the knowledge that the transaction cannot be charged back. This is the main benefit gained from implementing 3D Secure. Page 7
4 3D Secure Redirect Process With 3D Secure the transaction goes through 2 different stages: Authentication Authorisation 3D Secure adds the first stage, authentication, to the transaction process. There are 2 main events that happen in the authentication stage: Enrolled - Check if the cardholder is enrolled in 3dsecure. Authentication - If they are enrolled, then prompt the user for their passphrase. Once the cardholder has gone through the authentication stage, you can decide to continue with the authorisation or not depending on the outcome. There are 10 scenarios that can occur at the authentication stage. Some of these scenarios allow you to avail of the liability shift in the event of a chargeback arising from a fraudulent transaction. This means that the issuing bank would be liable for the chargeback. 4.1 The Scenarios Below is a table of the scenarios, this shows where you can avail of the liability shift in the event of a chargeback arising from a fraudulent transaction. These scenarios occur in the authentication stage when attempting to authenticate the cardholder, before the authorisation process. You will need to advise Elavon Payment Gateway under which scenarios you will proceed with an authorisation. Elavon Payment Gateway strongly recommends that you only proceed with transactions where the full shift in liability is afforded to you. Please contact Elavon Payment Gateway to discuss the 3D Secure configuration options. Page 8
Scenario Title Description Action Scenario Title Description Action 1 Cardholder Not Enrolled The card holder is not enrolled in the 3dsecure service. 2 Unable to Verify Enrolment The bank's enrolment server is temporarily down, so Elavon Payment Gateway cannot check if the cardholder is enrolled. Shift in liability No Shift in liability 3 Invalid Response from Enrolment Server The bank's enrolment server has sent back an No Shift in liability invalid response to Elavon Payment Gateway. Elavon Payment Gateway cannot check if the card holder is enrolled. 4 Enrolled, but invalid response from ACS(Access ControlServer) The card holder is enrolled but the response from the banks website has been tampered with. This should be treated as a fraudulent transaction. No Shift in liability 5 Successful authentication The card holder is Shift in liability enrolled and has entered their passphrase correctly. Page 9
Scenario Title Description Action 6 Authentication Attempt Acknowledged The card holder is enrolled but the bank Shift in liability doesn't have the facility to check the passphrase and so acknowledge the authentication attempt. 7 Incorrect Password Entered The card holder is enrolled but has entered No shift in liability the incorrect password. The card holder has not been authenticated. 8 Authentication Unavailable The card holder is enrolled but the bank s No shift in liability website is temporarily unavailable. Cannot continue with the authentication. 9 Invalid response from ACS The card holder is enrolled, but the banks No shift in liability website has sent back an invalid response to Elavon Payment Gateway. Cannot continue with the authentication 10 3D Secure Fatal error The 3D Secure service is temporarily down. No shift in liability Page 10
4.2 The sequence of events This is the sequence of events that happens at the authentication stage. This outlines where the above scenarios occur. 1. The Cardholder enters their card details. If the card is a Visa or MasterCard continue to step 2, otherwise for Laser/American Express/Diners etc which are not 3D Secure compatible - go to step 4c. 2. Elavon Payment Gateway checks to see if the card holder is enrolled in 3dsecure i.e. if they have a passphrase set up with their bank. Depending on the response the following action is taken: If the cardholder is enrolled in 3D Secure then they are redirected to their banks website and asked to enter their pass phrase. Go to Step 3. If the card holder is not enrolled in 3D Secure then skip to step 4a. You are not liable for the chargeback. (Scenario 1) 3. The cardholder enters their passphrase into their bank's website, and is then redirected back to the merchant's website. Depending on the result of the authentication, the following happens: If the 3D Secure message has been tampered with, then treat this as a fraudulent transaction, continue at your own risk to step 4c. If you continue you cannot avail of the liability shift, i.e. you are liable for the chargeback. (Scenario 4) If the cardholder enters their passphrase correctly, then the cardholder has been authenticated. You are not liable for chargeback's. Go to step 4b. (Scenario 5) If the cardholder enters the passphrase incorrectly, then they have not been authenticated, continue at your own risk to step 4c. If you continue you cannot avail of the liability shift, i.e. you are liable for the chargeback. (Scenario 7) Page 11
If the issuing bank acknowledges the attempt made by the merchant and accepts the liability. You are not liable for chargeback's. Continue to step 4a. (Scenario 6) If the cardholder's issuing bank is temporarily unavailable and unable to check the passphrase, the cardholder has not been authenticated. Continue at your own risk to step 4c. If you continue, you cannot avail of the liability shift, i.e. you are liable for the chargeback. (Scenario 8) If there is an invalid response from the cardholder's issuing bank then continue at your own risk to 4c. There is no shift in liability i.e. you are liable for the chargeback. (Scenario 9) If the 3D Secure service is temporarily unavailable, then continue at your own risk to step 4c. If you continue you cannot avail of the liability shift, i.e. you are liable for the chargeback. (Scenario 10) 4. Depending on the outcomes above, Elavon Payment Gateway does the following: a) The cardholder is not enrolled or the bank acknowledges the attempt made so continue with a normal authorisation. The merchant is not liable for the chargeback. b) The cardholder has been fully authenticated, so continue with a normal authorisation. The merchant is not liable for the chargeback. c) The cardholder has not been authenticated. The merchant is liable for the chargeback Page 12
4.3 3D Secure redirect response message Once 3D Secure is enabled on your account some additional 3DSecure fields (eci, xid and CAVV) will be passed back in the redirect response. Please see the Elavon Auth Developers Guide for the details of these fields. If you decide not to go ahead with authorisation for any of the above scenarios, Elavon Payment Gateway passes back a new response "" and also a new message depending on the scenario that the transaction was stopped at. You may wish to add extra error handling to your redirect response script to process this '' result, although for most merchants this will not be necessary as the existing handling will generally cover any result that is not successful (not '00'). Please note that these messages are only passed back if you decide not to continue with the authorisation for any particular scenario. Where you decide to continue with the authorisation, the normal authorisation responses are received (see Elavon Auth Developer s Guide). Page 13
5 Scenario Results and Messages Scenario Result Message 1 Card not 3D Secure enrolled, transaction halted. Please contact the merchant. 2 Unable to establish cardholder enrolment status, transaction halted. Please contact the merchant. 3 4 5 6 7 8 9 10 Invalid response from Enrolment Server, transaction halted. Please contact the merchant. Invalid response from Elavon Payment Gateway Authentication gateway. Please contact the merchant. Transaction blocked by merchant configuration. Please contact the merchant. Transaction blocked by merchant configuration. Please contact the merchant. Transaction blocked by merchant configuration. Please contact the merchant Transaction blocked by merchant configuration. Please contact the merchant. Transaction blocked by merchant configuration. Please contact the merchant. Elavon Payment Gateway internal error, transaction halted. Please contact the merchant Page 14
Elavon Financial Services Limited is registered in Ireland Number 418442. Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland. Elavon Financial Services Limited is regulated by the Central Bank of Ireland. United Kingdom branch registered in England and Wales under the number BR009373. Elavon Merchant Services is a trading name of Elavon Financial Services Limited. Directors: Kurt Adams (USA), John Collins, Craig Gifford (USA), Bryan Calder (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Page 15