Elavon Payment Gateway - Redirect Integration Guide

Transcription

1 Elavon Payment Gateway - Redirect Integration Guide Version: v1.1

2 Table of Contents 1 About This Guide Purpose Audience Prerequisites Related Documents 3 2 Elavon Payment Gateway Redirect Integration A note on PCI DSS Compliance 4 3 The Hosted Payment Page Process Flow Sending the Authorisation Request Processing the Authorisation Response Styling the Payment Page 10 4 Testing Required to Go Live Testing Different Transaction Results 12 5 Additional Services D Secure Multi-Currency SecureDataVault RiskManager 16 Page 2

3 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 paymentprocessing contract. 1.1 Purpose The purpose of this document is to outline the steps required to set your Elavon Payment Gateway account live, and to provide an estimation of the timelines involved. 1.2 Audience The target audience for this guide is merchants who will be using the Elavon Auth Redirect Integration to take Ecommerce Transactions 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 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 Payments documentation set for information about the Elavon Auth service: Reporting User Guide Elavon Payment Gateway Resource Document Page 3

4 2 Elavon Payment Gateway Redirect Integration Thank you for choosing Elavon Payment Gateway as your Payment Services Provider. Your account is currently in test mode you can use the test account to familiarise yourself with the system and to complete the integration into your Elavon Payment Gateway account to allow you to take payments from your customers online. This document outlines the steps required to activate the account so that you can begin to take live payments. Where merchants have a requirement to take payments from their customers online, Elavon Payment Gateway provide a payment page hosted on the Level 1 PCI Compliant Elavon Payment Gateway servers which can be used to take payments without having to handle or store sensitive card details. This is advantageous as it allows you to skirt most of the rigid PCI DSS compliance requirements enforced by the card schemes (see below) and means that you do not have to SSL secure your website (which can be expensive and technically challenging). The hosted payment page can be styled to fit seamlessly into your own website so that the experience of being redirected to a third party site is not disorientating for your customer. 2.1 A note on PCI DSS Compliance The Payment Card Industry Data Security Standard (PCI DSS) is a worldwide information security standard which dictates how sensitive details such as credit card numbers should be handled, stored and transmitted. The standard applies to all organisations that handle, store, process or exchange cardholder information from any card branded with the logo of one of the card brands (such as Visa and Mastercard amongst others). PCI DSS rules are administered by the card schemes and enforced by the acquiring banks who are members of said schemes. Page 4

5 Adherence to the PCI DSS is mandated by the merchant services agreement that you have signed with your acquiring bank, and is a condition of that agreement. Elavon Payment Gateway are a Level 1 PCI Compliant organisation, and submit to frequent audits of all of our systems and processes to ensure that this compliant status is upheld. Elavon Payment Gateway compliant status extends to those merchants who use the Hosted Payments Page to take payments and do not handle, store or otherwise transmit card details in any other way. For more information on PCI DSS and your obligations as outlined under those rules, please refer to the PCI Council website - Page 5

6 3 The Hosted Payment Page The Elavon Payment Gateway hosted payment page is a hosted application which allows you to redirect customers from your website to our secure payment environment, where the customer can enter their card details to complete the payment. Once the transaction has been processed, Elavon Payment Gateway will return the response of the transaction to a nominated response page on your servers so that your system can automatically update with the details of the transaction. The customer can then be returned to a page on your servers. To fully integrate your website into our systems using the Redirect Integration method, the following steps must be completed: 1. You must ensure that a correctly formatted authorisation request is sent to the hosted payment page ( from a known referring URL 2. You must ensure that your website can receive and process the authorisation response 3. You should provide a payment page template to style the hosted payment page (optional, but strongly recommended) The sections below offer a high level overview of the integration process for informational purposes only for technical details on how to integrate into the hosted payment page please see the Elavon Auth Developers Guide available for download at Page 6

7 3.1 Process Flow The process is outlined step by step below: 1. The customer makes a purchase on your website, and goes to check out. 2. The customer is redirected to the Elavon Payment Gateway Hosted Payment page ( 3. The customer enters their card details, which are validated for correctness 4. The card details are forwarded to your acquiring bank, and the customer s issuing bank, for authorisation 5. The result of the authorisation is returned to Elavon Payment Gateway, who return these results to a nominated page on your website so that your systems can be updated. 6. The customer is informed of the result and given the option to return to your site to continue shopping. Page 7

8 3.2 Sending the Authorisation Request Authorisation requests are sent (using the HTTP POST method) to the payment gateway The authorisation request must identify your merchant account on our servers and must provide the information necessary to process the transaction. The customer s card details do need to be sent in the authorisation request the payment page provides a form for the customer to enter these details securely. Further details on correctly formatting and sending the authorisation request can be found in the Elavon Auth Developers Guide available for download at All authorisation requests must include a digital signature which is provided to ensure the integrity of the transaction data and to authenticate the sender as being the legitimate account holder. The digital signature is created using the shared secret passed to you by your account manager when your account was first configured it is very important that this information only be divulged to authorised account contacts. The shared secret will only be passed to you over the phone, and it is strongly recommended that the shared secret not be sent by as this is not a secure channel of communication. The creation and submission of digital signatures is discussed in more detail in the Elavon Auth Developers Guide available for download at Elavon Payment Gateway maintain a white list of URLs from which authorisation requests for your account may come this is a security measure which prevents unauthorised transactions from being processed through your account. Allowed URLs are known as referring URLs. Multiple referring URLs may be provided for a single merchant account or sub-account. Elavon Payment Gateway can configure your account to allow transactions from any URL from within a specific domain if required. Transactions which originate at an unknown URL will be automatically blocked by Elavon Payment Gateway no payment will be taken. To configure the referring URLs on your account please the details to support@elavonpaymentgateway.com or to a member of the support desk. Please note that all changes must be submitted by by an authorised contact on your account. Please allow 24 hours for any account configuration changes. Page 8

9 3.3 Processing the Authorisation Response Authorisation responses are sent (using the HTTP POST method) to a nominated URL on your server. Elavon Payment Gateway will return a response code indicating whether the transaction has been successful or not, along with an authorisation code for successful transactions and any text messages returned by the bank in response to the authorisation request. This response should be used to update your own databases. Your customer is not redirected back to the nominated response URL following a transaction they will remain on the secure payment page ( for the duration of the transaction. Your response page is instead called by the payment page (much like a web browser calls a remote page on the internet) and the output is displayed to them. A simple message informing the customer of the transaction result, along with a link to click to continue shopping, should be returned from the response page this response will be displayed within the payment page template hosted by Elavon Payment Gateway. If Elavon Payment Gateway is unable to connect to your response URL to deliver the transaction response, a generic message will be displayed to the customer. An alert will be generated on the Elavon Payment Gateway systems and will be forwarded to you by a member of the support team. Only one response URL may be configured per sub-account. The response URL must be an absolute URL on your server. It is not possible to set separate success or failure pages the response should be handled by the response page and an appropriate message should be returned to the customer. To configure the response URL on your account please the details to or to a member of the support desk. Please note that all changes must be submitted by by an authorised contact on your account. Please allow 24 hours for any account configuration changes. Page 9

10 All authorisation responses will include a digital signature which is provided to ensure the integrity of the transaction data and to authenticate the sender as Elavon Payment Gateway. The digital signature is created using the shared secret passed to you by your account manager when your account was first configured. It is left to your discretion to check the digital signature returned by Elavon Payment Gateway as part of the transaction response. 3.4 Styling the Payment Page To ensure that the experience of being redirected to a third party site is not disorientating for your customer, Elavon Payment Gateway provide a facility whereby you can style the payment page to appear as a seamless part of your payment page. The only difference that the customer should notice is that they have been redirected to the secure payment gateway The template should resemble the rest of the shopping experience so that the customer does not immediately realise that they have been redirected but, as a secure encrypted connection will be used, there should be as few images as possible. A typical template page consists of: a 'header' image, a plaintext message for the customer and the required "<!--E-PAGE TABLE HERE-->" tag. Simply using the general colour scheme of the other pages in your shopping cart is quite effective. Elavon Payment Gateway can provide you with a sample template to work from if required. Below are the full requirements for the template page: The template page must contain the payment form tag: <!--E-PAGE TABLE HERE--> All images/css used in the template must be referred locally on our server. There should be no absolute URLs to external images/css. This means that you will need to send the image files to us along with the template page. There can be no scripting of any kind in the template for security reasons. It should contain only basic HTML. The name of the file must be: template.htm All necessary files should be placed in a folder with the same name as the sub-account for which the template is intended (the default sub-account is always 'internet'). Page 10

11 This folder should then be placed in a zip file of the same name and submitted for upload. Please note that if the requirements above are not met, you will be asked to resubmit the template with the necessary changes made. To configure the template on your account please the zipped package to or to a member of the support desk. Please note that all changes must be submitted by by an authorised contact on your account. Please allow 24 hours for any account configuration changes. Page 11

12 4 Testing Required to Go Live Your account is currently in test mode. One of the requirements for activating your account to allow you to process live transactions is that adequate testing be completed. It is very important that you test each card type that you intend on processing, and that you test each possible result that may arise (outlined below). Exhaustive testing of your account will minimise account issues in the live environment which may affect your customers. You can request test card numbers by ing or a member of the support team. The Test Card numbers provided allow you to test each card type that you may take through the system. 4.1 Testing Different Transaction Results There are a number of possible responses to a card authorisation request, which are outlined below. Test card numbers are provided to simulate each of the possible responses. It is recommended that you test each response for each card type you intend to accept in a live environment, so that you can ensure that your system is robust enough to handle each possible response appropriately. 00: Transaction Authorised Successfully. Transactions that return a result of 00 have been authorised by the bank and will be funded to the merchant once the transaction has been settled. 101: Transaction Declined. Transactions that return a result of 101 have been declined by the bank. While the most common cause of a declined transaction would be where insufficient funds exist to cover the cost of the transaction, other reasons may apply. The issuing bank cannot divulge the reasons for a declined transaction to anyone other than the cardholder themselves. No funds will be Page 12

13 received for declined transactions. 102: Transaction Declined Pending Offline Authorisation. The transaction in question has been declined by the bank, but the merchant is given the opportunity to complete the transaction by contacting their acquiring bank s offline authorisation centre to get an authorisation code, which can be entered via Reporting to complete the transaction. No funds will be received unless this step is completed. 103: Card Reported Lost or Stolen. The transaction in question has been declined because the card number provided has been reported as lost or stolen. No funds will be received for the transaction. 200/205: Bank Communication Error. Elavon Payment Gateway have been unable to connect to the bank to carry out the authorisation. This is not a reflection of the customer s credit status the transaction may be tried later and may succeed. No funds will be received for a transaction which returns a 200 or 205 results. Page 13

14 5 Additional Services Elavon Payment Gateway provides a number of additional services for which you may have a requirement. These additional services may require additional configuration, and as such appropriate timelines should be allowed for implementation. Note that additional charges may apply for the implementation of any of the services below D Secure 3D Secure is an implementation of 3D secure, the cardholder authentication service developed by Visa and Mastercard and released as Mastercard SecureCode and Verified by Visa. Implementing 3D secure will minimise your liability in the event of chargebacks that arise due to fraudulent activity on your account. You may be able to avail of a lower merchant services fee from your acquiring bank with 3D Secure implemented. It is strongly recommend that you consider the implementation of 3D Secure if selling high value goods in a Customer Not Present environment. 3D Secure can usually be implemented for Redirect Merchants with no additional development work required (depending on your server configuration). Please note that implementing 3D secure requires that your merchant number be registered for the service with the card schemes, a process that can take up to 10 working days. This process can only begin once your merchant services application has been completed. Please contact or a member of the support team for more information on this service. Implementing 3D Secure requires some configuration work once the merchant numbers have been confirmed as registered please allow 24 hours for this configuration. 5.2 Multi-Currency Multi-Currency is a Dynamic Currency Conversion (DCC) service which allows you to offer international customers an exchange rate from your base currency to theirs at the point of sale (rather than at the Page 14

15 point of settlement). This allows the customer to know exactly what they will be charged for their transaction without having to worry about fluctuations in the currency markets. Merchants who have implemented DCC can also share in the commission charged by the Currency Conversion Processor used, and can represent a significant stream of revenue. Processing DCC transactions requires that you have an agreement with a Currency Conversion Processor who can facilitate the provision of exchange rates. Your Currency Conversion Processor may provide you with a merchant ID number specific for this purpose this number should be forwarded to or a member of the support team for configuration. This process will take at least 24 hours. Please note that this service is only supported for customers of certain acquiring banks. Elavon Payment Gateway do not charge for the implementation of Multi-Currency. Implementing Multi-Currency will require some configuration and so appropriate timelines should be allowed. 5.3 SecureDataVault Elavon Payment Gateway provide a card storage system called SecureDataVault which can be used to securely store card details on the Level 1 PCI Compliant Elavon Payment Gateway system. Once the card numbers have been added to SecureDataVault, you can no longer view any of the sensitive card details themselves however, using tokens, you can raise payments against these stored card details at a later date. The hosted payment page can be used to capture customer card details to be stored in the SecureDataVault system. Card numbers and payments can then be managed either via Reporting or via the Remote submission of XML messages. Note that SecureDataVault is an additional service and carries additional monthly charges please contact support@elavonpaymentgateway.com or a member of the support team for more information on the charges applicable. Implementing SecureDataVault requires some configuration work please allow 24 hours for the activation of this service. Page 15

16 5.4 RiskManager RiskManager is Elavon Payment Gateway Payment s proprietary Transaction Suitability Scoring (TSS) system. A transaction suitability score is a score assigned to a transaction based on rules configured by you, highlighting potentially suspicious transactions which can be flagged for review. RiskManager can also be implemented with automatic transaction checking, where transactions which break certain predefined rules or which return a low score can be automatically declined. RiskManager is provided to all merchants free of charge, and can be configured via Reporting. RiskManager with autocheck is a chargeable service which carries a monthly charge this service is primarily designed for merchants who process large volumes of transactions. Implementing RiskManager may require some additional development work on your own systems if to be used with the Hosted Payment Page. This will require additional configuration on your account please contact support@elavonpaymentgateway.com or a member of the support team for more information on the charges applicable. Implementing RiskManager with autocheck requires some configuration work please allow 24 hours for activation of this service. Page 16

17 Elavon Financial Services Limited is registered in Ireland Number 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 BR 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 17