Elavon Payment Gateway Developers Guide

1 About This GuideThis section outlines the purpose and aim of the guide, target audience, any source materials orterminology used, and a general document description.Please note that this document is regarded as confidential and is for customer use only. It has beensupplied under the conditions of your payment-processing contract.1.1 PurposeThe purpose of this guide is to explain in detail what is involved in integrating the redirect or Remoteservices.1.2 AudienceThe target audience for this guide is software and web developers.1.3 PrerequisitesIn order to use this guide, you should have experience with and knowledge of the following concepts:▪▪For redirect integration: A basic understanding of html and at least one server side dynamicscripting language.For a Remote integration: Creation and remote submission of XML messages1.4 Related DocumentsIn addition to this guide, you can also refer to the following documents in the Elavon PaymentGateway documentation set for information about the Elavon Auth service:▪▪Elavon Auth Response CodesElavon Auth XML Definitions

Elavon Payment Gateway documentation uses the following conventions:Note: Tips or advice for the user.Caution: Important note. Potential financial impact.The following table outlines the main formatting conventions used in this guide:Convention Description ExampleBlue Italic or Plain TypeHyperlinks and crossreferencesFor more information see Table 1.Italics Names of other guides Elavon Auth Developer’s GuideCourier NewProgram code, screenmessages,directory files, and filenamesCourier NewPlaceholder for elementnames,field values, or user inputcard_holder_nameBOLD CAPSError and warningmessages101 / REFERRAL BCopyright © 2013 Elavon, Inc.Page 5Aug-13

2 IntroductionThe Elavon Payment Gateway Auth service works under two different scenarios.2.1 The Redirect MethodThe redirect method is suitable for merchants that do not have their own secure server. Using thismethod, the customer will be redirected to the Elavon Payment Gateway secure server to enter theircredit card details.2.2 The Remote MethodThe remote method affords the merchant greater control of the transaction process but requires thatthey maintain their own secure server. Using this method, the customers’ card details will be takenby the merchant and passed to the Elavon Payment Gateway by XML messages.Your solution must integrate with our payment service at two levels – firstly, you must submitcorrectly formed requests for authorisations and secondly, you must then accept the response that isreturned by the Elavon Payment Gateway application.To determine which version of Elavon Auth you should use, consult the following feature list anddecide which one is the right choice for your situation:2.3 Elavon Auth Redirect Features List▪▪▪▪▪Merchant does not need a secure server.Can be hosted anywhere, and on any platform as long as CGI scripts are enabled.The merchant does not collect the card details, and does not have access to them.The customer is redirected to the Elavon Auth application on a secure Elavon PaymentGateway server by a script on the merchant’s website.Elavon Payment Gateway hosts a secure, merchant-branded web page. We collect the carddetails and process the payment. The customer and the results of the transaction are sentback to the merchant via another script on the merchant’s web site (Elavon PaymentGateway can provide sample scripts to get you started).Copyright © 2013 Elavon, Inc.Page 6Aug-13

2.4 Remote Features List▪▪▪▪▪Merchant needs a secure server or can integrate the service into a desktop application.Can be hosted anywhere, and on any platform as long as CGI is enabled.The card details are collected by the merchant and passed to Elavon Payment Gateway asXML messages. Elavon Payment Gateway responds with an XML message containing theresults of the transaction in a matter of seconds. Elavon Payment Gateway can providesample scripts to get you started.The merchant need not store card details, but they are available.The merchant controls full process, screen flow. Customer may never know that the ElavonPayment Gateway was involved in the process.Note:In certain circumstances the acquiring bank may need to approve your use of the Elavon Auth remoteoption and it is entirely the merchants/developers responsibility to ensure that the acquiring bankhas agreed and authorised the merchant in this regard.In order to facilitate the use of multiple web-sites and bank accounts, merchants can set up a numberof sub-accounts under their main Elavon Payment Gateway account. Each sub-account can use adifferent set of URLs/IP addresses and can channel the funds to a different bank account.The default sub-account will be 'internet' for all merchants. To have additional sub-accounts set upyou will need to contact Elavon Payment Gateway and provide us with some details.Copyright © 2013 Elavon, Inc.Page 7Aug-13

2.5 Sub-AccountsIn order to create a sub account a merchant must provide:For redirect:▪▪▪A sub-account nameReferring and response URLsBank merchant numberFor remote:▪▪▪A sub-account nameIP address of hosting serverBank merchant numberCopyright © 2013 Elavon, Inc.Page 8Aug-13

3 Elavon Auth - RedirectMerchants who do not have their own secure server can use Elavon Auth redirect. Rather thanentering their credit card number on a (non-secure) website, the customer is redirected to the ElavonPayment Gateway secure server. Here they are presented with a payment page that you cancustomise to maintain the appearance of your website. After entering their card details customersare returned to your site to continue browsing. Redirect payment pages are customised using‘templates’; these are described in the following section. Elavon Payment Gateway can supplyworking sample code in ASP, PHP, Java, .NET and Perl.Please note that this is sample code only and will need to be modified to suit individual merchants’needs. The sample code will provide guidance on how to carry out the steps required for a redirecttransaction to succeed.Copyright © 2013 Elavon, Inc.Page 9Aug-13

3.1 Redirect ExampleThe process involved for a redirect transaction is shown in the following example1. Once the full amount is known the customer is presented with a confirmation page. Thispage is hosted on the merchant’s server. If the customer chooses to continue they areredirected to Elavon Payment Gateway secure server.Copyright © 2013 Elavon, Inc.Page10Aug-13

2. On the Elavon Payment Gateway secure server, the customer is presented with the paymentform. This page uses a template to maintain the appearance of the merchant’s own website.Copyright © 2013 Elavon, Inc.Page11Aug-13

a database of orders you may wish to simply send yourself an email with this information once theorder is successful.It is worth noting that the Internet is not 100% reliable and communication errors may occur so it ispossible that the information will not make it back to your response script. We recommend that anemail with the order details and order ID be sent before the transaction is sent to the ElavonPayment Gateway application and another email with the result sent afterwards. In this way, detailsof an order that someone has actually been charged for should not be lost.Copyright © 2013 Elavon, Inc.Page13Aug-13

4 TemplatesIn order for the payment form to maintain the appearance of your website you will need to have atemplate page and (optionally) some images/style sheets etc. uploaded to the Elavon PaymentGateway servers. This template should be sent to Elavon Payment Gateway support via e-mail(support@elavonpaymentgateway.com).The basic structure of a template is shown below. Note the HTML comment that indicates where thepayment form should be placed; this tag must be present in the template page.Enter your credit card details.more html…more html…The template should resemble the rest of the shopping experience so that the customer does notimmediately realise that they have been redirected but, as a secure encrypted connection will beused, 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 “” tag.Simply using the general colour scheme of the other pages in your shopping cart is quite effective.Below are the full requirements for the template page:Template pages must contain the payment form tag: 1. All images/CSS used in the template must be referred locally on our server. There should beno absolute URLs to external images/CSS. This means that you will need to send the imagefiles to us along with the template page.Copyright © 2013 Elavon, Inc.Page14Aug-13

2. There can be no scripting of any kind in the template for security reasons. It should containonly basic HTML.3. The name of the file must be: template.htm4. All necessary files should be placed in a folder with the same name as the sub-account forwhich the template is intended (the default sub-account is always ‘internet’).4.1 Redirect IntegrationTo link your shopping cart to the Elavon Auth application you must insert certain hidden fields into aform that redirects to the Elavon Auth application over a secure link. The page that hosts this script isknown as the referring URL. This URL needs to be emailed tomailto:support@elavonpaymentgateway.comto be added to the whitelist of referring URLs.The minimal implementation is shown below.Note: Some form of server side programming is required to create the MD5HASH (or SHA1HASH). Allmerchants will be required to perform some script configuration on their side.Copyright © 2013 Elavon, Inc.Page15Aug-13

4.2 Redirect Request Field DefinitionsThe fields in the table below are accepted by Elavon Payment Gateway. Anything else will bereturned back to your response script (if any) along with the Elavon Payment Gateway responses.The following indicators are used to show whether or not an element is required or optional.MOCRequired for this request typeOptionalRequired depending on another optional fieldEach field has certain constraints around length and format as per below (please note that "" meansa space):Field Title Format Length R/O Field DescriptionMERCHANT_IDa-z A-Z 0-9 . 1-50 M Supplied by Elavon Payment Gateway –note this is not the merchant numbersupplied by your bank.ACCOUNT a-z A-Z 0-9 “” 0-30 O The sub-account to use for thistransaction. If not present, the defaultsub-account, ‘internet’, will be used.ORDER_ID a-z A-Z 0-9 _ - 0-40 M A unique alphanumeric id that’s used toidentify the transaction. This can be upto 40 characters long. No spaces areallowedAMOUNT 0-9 2-11 M Total amount to authorise in the lowestunit of the currency – i.e. 100 eurowould be entered as 10000. If there is nodecimal in the currency then (e.g. JPYYen) then contact Elavon PaymentGateway. No decimal points are allowed.CURRENCY a-z A-Z 3 M A three-letter code as per currency tablein Appendix A.Copyright © 2013 Elavon, Inc.Page16Aug-13

Field Title Format Length R/O Field DescriptionTIMESTAMP 0-9 14 M Date and time of the transaction.Entered in the following format:yyyymmddhhmmssMD5HASH a-f 0-9 32 M A digital signature generated using theMD5 algorithm. You have the option ofusing the MD5 hash or the SHA-1 hash(below). Elavon Payment Gatewayprefers you use the SHA-1 hash as it ismore secure. See section below onDigital Signatures.SHA1HASH a-f 0-9 40 M A digital signature generated using theSHA-1 algorithm. Elavon PaymentGateway prefers that you use a SHA-1signature rather than an MD5. The MD5option has been retained forcompatibility with older systems. Seesection below on Digital Signatures.AUTO_SETTLE_FLAG0 or 1 1 M Used to signify whether or not you wishthe transaction to be captured in thenext batch or not. If set to “1” andassuming the transaction is authorisedthen it will automatically be settled inthe next batch. If set to “0” then themerchant must use the reportingapplication to manually settle thetransaction. This option can be used if amerchant wishes to delay the paymentuntil after the goods have been shipped.Transactions can be settled for up to115% of the original amount.COMMENT1 a-z A-Z 0-9 ' ", +“” . _ - & \ / @ ! ?% ( ) * : £ $ & € #[ ] | =0-255 O A freeform comment to describe thetransaction. Up to 255 charactersCopyright © 2013 Elavon, Inc.Page17Aug-13

Field Title Format Length R/O Field DescriptionCOMMENT2 a-z A-Z 0-9 ' ", +“” . _ - & \ / @ ! ?% ( ) * : £ $ & € #[ ] | =0-255 O A freeform comment to describe thetransaction. Up to 255 charactersRETURN_TSS 0 or 1 1 O Used to signify whether or not you wanta Transaction Suitability Score for thistransaction. Can be “0” for no and “1”for yes. To maximise the usefulness ofthe RiskManager you should also supplythe next 6 fields. See below for more onRiskManager.SHIPPING_CODEa-z A-Z 0-9 “” , . -/ |0-30 O The postcode or ZIP of the shippingaddress. This can only have letters anddigits. (ie no – or /)SHIPPING_CO a-z A-Z 0-9 “” , . - 0-30 O The country of the shipping address. Thiscan only have letters and digits. (i.e. no –or /)BILLING_CODEa-z A-Z 0-9 “” , . -/ |0-30 O The postcode or ZIP of the billingaddress. This can only have letters anddigits. (i.e. no – or /)BILLING_CO a-z A-Z 0-9 “” , . - 0-30 O The country of the billing address. Thisfield can only have letters and digits. .(i.e. no – or /)CUST_NUMa-z A-Z 0-9 – “” _. , + @0-50 O The customer number of the customer.VAR_REFa-z A-Z 0-9 – “” _. , + @0-50 O A variable reference also associated withthis customer.PROD_IDa-z A-Z 0-9 – “” _. , + @0-50 O A product id associated with thisproduct.Copyright © 2013 Elavon, Inc.Page18Aug-13

Field Title Format Length R/O Field DescriptionANYTHINGELSEa-z A-Z 0-9 ' ", +“” . _ - & \ / @ ! ?% ( ) * : £ $ & € #[ ] | =0-255 O Anything else you send to ElavonPayment Gateway will be returned in theresponse (whatever other informationyou collected from the customer such asproduct or address/telephone numbersetc….)All of these field values (except for the MERCHANT_ID which will be provided by Elavon PaymentGateway) are user definable. Merchants will need to contact Elavon Payment Gateway in order to setup new subaccounts.4.3 Redirect Response Field DefinitionsResponse data is sent back to your response script for each transaction. After the customer enterstheir credit card details on the Elavon Payment Gateway hosted page, our application calls yourresponse script with the response details. You can use this response to update your own databaseand send emails to your customers based on the result of the transaction.In order to receive this data you must provide Elavon Payment Gateway with the URL of yourresponse script. The response URL is to be emailed to support@elavonpaymentgateway.com Thisapplication must only return text as output – if image tags are included there will be a popup warningabout mixed secure/insecure content on the page. The template that was used for the credit cardentry table will be used again for this page. You should include a link that continues the customersshopping experience. Again, we can provide working sample code that will make this process easier.In the case of an error whereby the Elavon Auth application is unable to contact your response script,you can set a static success/failure message. This can be changed in the administration section ofReporting.The response fields are as follows:HeadingMERCHANT_IDACCOUNTORDER_IDHeadingThis is the merchant id that Elavon Payment Gateway assigns to you.The sub-account used in the transaction.The unique order id that you sent to us.Copyright © 2013 Elavon, Inc.Page19Aug-13

HeadingAUTHCODERESULTMESSAGECVNRESULTPASREFBATCHIDECICAVVXIDMD5HASHSHA1HASHTSSTSS_idnumANYTHING ELSEHeadingWill contain a valid authcode if the transaction was successful. Will beempty otherwise.The outcome of the transaction. Will contain “00” if the transaction wasa success or another value (depending on the error) if not. See theresult codes table in Appendix A.Will contain a text message that describes the result code above.The result of the Card Verification check (if enabled):M: CVV Matched.N: CVV Not Matched.I: CVV Not checked due to circumstances.U: CVV Not checked – issuer not certified.P: CVV Not Processed.A unique reference that Elavon Payment Gateway assign to yourtransaction.This is the Elavon Payment Gateway batch that this transaction will bein. (This is equal to “-1” if the transaction was sent in with the autosettleflag off. After you settle it (either manually or programmatically) theresponse to that transaction will contain the batch id.)This is the ecommerce indicator (this will only be returned for 3DSecuretransactions).Cardholder Authentication Verification Value (this will only be returnedfor 3DSecure transactions).Exchange Identifier (this will only be returned for 3DSecuretransactions).An MD5 digital signature created using the above fields and your sharedsecret. Needs to be sent in lowercase.A SHA-1 digital signature created using the above fields and your sharedsecret. Needs to be sent in lowercase.The Transaction Suitability Score for the transaction.The RiskManager is comprised of various distinct tests. Using theReporting application you can request that Elavon Payment Gatewayreturn certain individual scores to you. These are identified by numbers- thus TSS_1032 would be the result of the check with id 1032. You canthen use these specific checks in conjunction with the RiskManagerscore to ascertain whether or not you wish to continue with thesettlement.Anything else you sent to us in the request will be returned to you.All of these field values (except for the MERCHANT_ID which will be provided by Elavon PaymentGateway) are user definable. Merchants will need to contact Elavon Payment Gateway in order to setup new sub-accounts.Copyright © 2013 Elavon, Inc.Page20Aug-13

4.4 Digital Signature for RedirectTo ensure that the request comes from you we require that you send us a hash of certain elements(specifically the TIMESTAMP, MERCHANT_ID, ORDER_ID, AMOUNT, and CURRENCY) using a sharedsecret. This can be an MD5 hash or preferably a SHA-1 hash. If required we can also provide code forthis.MD5 and SHA-1 algorithms are secure hash functions. They take a string as input, and produce a fixedsize number - 128 bits for MD5; 160 bits for SHA-1. This number is a hash of the input, and a smallchange in the input results in a substantial change in the output. The functions are thought to besecure in the sense that it requires an enormous amount of computing power and time to find astring that hashes to the same value. In others words, there's no way to decrypt a secure hash. Giventhe larger key size, we prefer that you use a SHA-1 hash, but we have retained the MD5 forcompatibility with older systems.Here is a sample request:To construct the hash follow this procedure:• Form a string by concatenating the above fields with a period (“.”) in the following order( TIMESTAMP.MERCHANT_ID.ORDER_ID.AMOUNT.CURRENCY )Like so:( 20120926112654.thestore.ORD453-11.29900.EUR )• Get the hash of this string (SHA-1 shown below).(b3d51ca21db725f9c7f13f8aca9e0e2ec2f32502)Copyright © 2013 Elavon, Inc.Page21Aug-13

It is important that you convert this to lowercase letters. SHA1 and MD5 will give different answers inthe next step if you use uppercase letters.• Create a new string by concatenating this string and your shared secret using a period.(b3d51ca21db725f9c7f13f8aca9e0e2ec2f32502.mysecret )• Get the hash of this value. This is the value that you send to Elavon Payment Gateway.(3c3cac74f2b783598b99af6e43246529346d95d1)When Elavon Payment Gateway receive the request, we perform the same procedure on the fivepieces of information and your shared secret (which we have stored in our database). If the resultinghash is the same as the one that you sent us then the data could only have been sent by someonethat had your shared secret. Thus it is very important to keep this shared secret protected.When Elavon Payment Gateway are responding, we will send you a hash of the response elements inthe same way so that you can confirm that the response came from Elavon Payment Gateway. (Thiswill be a hash of the TIMESTAMP, MERCHANT_ID, ORDER_ID, RESULT, MESSAGE, PASREF andAUTHCODE with your secret key (see below for more on the Elavon Payment Gateway responsefields). If you sent us an MD5 hash you will receive an MD5 hash in the response and similarly for aSHA-1 hash).The response hash is constructed as follows:• Form a string by concatenating the above fields with a period (“.”)(20120926112654.thestore.ORD453-11.00.Successful.3737468273643.79347)• Get the hash of this string (SHA-1 shown below).(a111135ea464bcd343c0f23db395fa1cf12a6837)• Create a new string by concatenating this string and your shared secret using a period.(a111135ea464bcd343c0f23db395fa1cf12a6837.mysecret)Copyright © 2013 Elavon, Inc.Page22Aug-13

Get the hash of this value. This should be the same as the value you receive from Elavon PaymentGateway.(368df010076481d47a21e777871012b62b976339).4.5 Address Verification Service: RedirectThe Address Verification Service (AVS) verifies the cardholders address by checking the informationprovided by at the time of sale against the issuing bank's recordsNote: This service only works for UK cardholders as it uses the street address and postcodes of thecardholders. The Elavon Auth redirect service supports AVS where it is supported by the merchant’sacquiring bank and the cardholder’s issuing bank. If a transaction fails an AVS check it will notautomatically be declined by your bank. It is an advisory service and requires that the details of nonmatchedtransactions be checked by the merchant.AVS data must be passed in the BILLING_CODE field.This data should be formatted as follows:|For example, if the billing address is:382, The RoadThe TownWB1 A42UKThe corresponding AVS data will be:Copyright © 2013 Elavon, Inc.Page23Aug-13

The possible responses that can be returned for the Address Verification Service are asfollows:▪▪▪▪▪M (Matched)N (Not Matched)I (Problem with check)U (Unable to check (not certified etc))P (Partial Match)These will be returned in the following fields in the response:AVSADDRESSRESULTAVSPOSTCODERESULTCopyright © 2013 Elavon, Inc.Page24Aug-13

5 Remote AuthorisationMerchants should use remote if they have a secure server or if their site is hosted internally (such asan intranet application for a call centre – a secure server isn’t necessary in that case as the cardnumbers will never travel outside of the internal network).Remote can also be used if you are developing an application in Visual Basic or Java etc. (i.e. not aweb application but a desktop application). Elavon Payment Gateway can supply working samplecode in Perl, Java, ASP, VB, PHP, .NET and server side JavaScript.Note:In certain circumstances the acquiring bank may need to approve your use of the Elavon Auth remoteoption and it is entirely the merchants/developers responsibility to ensure that the acquiring bankhas agreed and authorised the merchant in this regard.5.1 Remote Authorisation ExampleRemote is ideal for any application that needs real time authorisation of credit cards. Information issent between the merchant and Elavon Payment Gateway in the form of XML messages. This servicecan be incorporated into any application that is capable of generating XML messages.Copyright © 2013 Elavon, Inc.Page25Aug-13

1. Once the full amount is known, the customer can be asked to enter their card details. Thesedetails are then sent to Elavon Payment Gateway as XML messages using a secureconnection. A reply is then sent as an XML message back from Elavon Payment Gateway thatcontains the result of the transaction (approved/declined etc).Copyright © 2013 Elavon, Inc.Page26Aug-13

2. The merchants’ application receives the response XML and extracts the information. It thendisplays the appropriate messages for the customer. One of the main advantages of theremote version is that the merchant can control the entire shopping experience.5.2 Application Based CheckingIt is highly advisable to build in pre-authorisation checking for all data fields. This will eliminate manyproblems early on and rapidly improve response times. If any field contains an error, the transactionwill fail. All mandatory fields must be included correctly and optional fields must contain valid data ifincluded.Validation information can be found in Appendix C of this document.The following are some checks that should be put in place:Copyright © 2013 Elavon, Inc.Page27Aug-13

▪▪▪▪▪▪▪Card expiry date should be checked. The date itself should be valid and formatted correctly.The card length should be 12, 13, 14, 15, 16, 18 or 19 digits depending on the card type, noalpha characters should be included. (12 num_digits 19 will do).The card number should pass the Luhn check (see Appendix A) to ensure that it is a valid cardnumber.There should be at least two words in the cardholder's name (this is recommended but willnot cause transactions to fail) and it must contain no unusual characters.If CVN checking is to be enforced the corresponding value for the ‘presind’ field will need tobe set. The possible values are listed in the XML definitions guide.The CVN itself will need to be sent in correctly. It should be 3 or 4 digits depending on thecard type.Illegal characters cannot be present in any field. Each field should be checked to ensure thatthis is not the case as illegal characters cause the transaction to fail. The allowed charactersfor all fields are detailed in the XML definitions guide and in Appendix C - Data ValidationRules.5.3 Remote Authorisation IntegrationFull details of the XML messages for each request type can be found in the Elavon Auth XMLdefinitions guide, which is available from the online resource centre or by e-mailingsupport@elavonpaymentgateway.com.You will need to consult this guide in order to successfully complete a remote integration.Elavon Payment Gateway can supply sample code to aide with integration, however this is samplecode only and will need to be modified to suit individual merchants’ needs. The sample code willprovide guidance on how to carry out the steps required for a remote transaction to succeed.These steps are:▪Create the XML message for the request.Connect to Elavon Auth (https://remote.elavonpaymentgateway.com/remote).▪Send the message.Copyright © 2013 Elavon, Inc.Page28Aug-13

▪▪Wait for Elavon Payment Gateway to reply with XML.Parse the reply and provide access to the information.5.4 Remote Authorisation Request MessageAlthough the sample code available provides a simple interface to the system, more compleximplementations will require some knowledge of how the system works. Again, the Elavon Auth XMLdefinitions guide should be consulted for full details on the messages required.Below is a sample of an auth request followed by a line-by-line analysis. The auth request is theprimary request used with Elavon Auth.Copyright © 2013 Elavon, Inc.Page29Aug-13

YourMerchantIDaccount to useorder id20004903034000057189020403John DoeMC4531a commentanother commentcustomer numberproduct idvariable reference1.2.3.4zip/postal codecountryzip/postal codecountry4dc4f20acc….30314758a1bc67dcc….787307The following indicators are used to show whether or not an element is required or optional.Each field has certain constraints around length and format as per below (please note that ““means aspace):Copyright © 2013 Elavon, Inc.Page30Aug-13

Line per line description M/O/ Format Length DetailsM 0-9 14 Top-level element. Must havetimestamp and type attributes.If the timestamp is more thana day (86400 seconds) awayfrom the server time then therequest is rejected.merchant id usedaccount usedorderidM a-z A-Z 0-9 .O a-z A-Z 0-9 “”M a-z A-Z 0-9 _ -1-50 This is your Elavon PaymentGateway assigned merchant id0-30 This is the Elavon PaymentGateway sub-account to use. Ifyou omit this element then wewill use your default account.1-40 The unique order id of thistransaction. Must be uniqueacross all of your accounts.2000M a-z A-Z0-932-11The currency and amount ofthe transaction.“Appendix B - Codes” on page35 of the Elavon Authdeveloper's guide specifies thecurrency codes. The amountshould be in the smallest unitof the required currency (i.e.2000 = £20, $20 or €20) M There must be a card elementin auth requests490303400005 M 0-9 12-19 The card number.7189020403M 0-9 4 The card expiry date. Theformat is mmyy.JohnDoeM a-z A-Z 0-9 - +"" , ' + . _- ; &\ /MC M SeeDetails1-100 The card holder's name.The card type. The legal valuesare: VISA, MC,LASER, SWITCH, AMEX,DINERS, UATPCopyright © 2013 Elavon, Inc.Page31Aug-13

Line per line description M/O/ Format Length Details M 0-9 0-3 The issue number of the cardin the case of a Switch card.Only required if the card typeisSWITCH O The card verification detailselement. If you usethis then the next twoelements are required.453 M 0-9 3-4 The Card Verification Number.This is the 3 digitnumber on the reverse of thecard. (the CVC forVISA and the CVV2 forMasterCard) 3 digits onVisa and MC, 4 digits on Amex.1 M SeeDetailsMM M SeeDetails1 This is the presence indicator.It can take 4values:1: cvn present2: cvn illegible3: cvn not on card4: cvn not requestedThe auto-settle indicator. If "1"then thetransaction is sent to the bankfor settlementtonight. If set to "0" then thetransaction sits inthe Elavon Payment Gatewaydatabase until someonemanually submits it forsettlement.Copyright © 2013 Elavon, Inc.Page32Aug-13

Line per line description M/O/ Format Length DetailsC SeeDetailsIf you are configured forrecurring/continuousauthority transactions, youmust set thesefields. type can be either fixedor variabledepending on whether you willbe changing theamounts or not. sequencemust be first forthe first transaction for thiscard, subsequentfor transactions after that, andlast for the final transaction ofthe set. Only supported bysome acquirers. O You can associate up to 2comments with anytransaction for your ownpurposes.acommentacommentO a-z A-Z 0-9 ' ",+ "" . _ -& \ /@ ! ? % () * :£ $ & € #[ ] | =O a-z A-Z 0-9 ' ",+ "" . _ -& \ /@ ! ? % () * :£ $ & € #[ ] | =O0-255 Free-text comment0-255 Free-text commentCopyright © 2013 Elavon, Inc.Page33Aug-13

Line per line description M/O/ Format Length Details O As part of the Elavon PaymentGateway service we offera RiskManager. This is a realtime transactionscreening and data checkingsystem to assistthe merchant with theidentification ofpotentially high-risktransactions.customernumberproductidvariablereference1.2.3.4O a-z A-Z 0-9 - ""_ . , + @O a-z A-Z 0-9 - ""_ . , + @O a-z A-Z 0-9 - ""_ . , + @O 0-9IPAddressinX.X.X.Xformat0-50 The number you assign to thecustomer. Thiscan allow checking of previoustransactions bythis customer.0-50 The product code you assign tothe product.0-50 Any reference you also wouldlike to assign to the customer.This can allow checking, usingRiskManager, of previoustransactions by this customer.[1-3].{1-3}.{1-3}.{1-3}The IP address of thecustomer. O The billing address of thecustomer.zip|postalcodecountryO a-z A-Z 0-9 "" ,. - / |O a-z A-Z 0-9 "" ,. -0-30 The ZIP|Postal code of thebilling address. This can bechecked (in conjunction withthecountry) against a table ofhigh-risk area codes. This fieldis used address verificationwith certain acquirers.0-30 The country of the billingaddress. This can bechecked against a table ofhigh-risk countries.Copyright © 2013 Elavon, Inc.Page34Aug-13

Line per line description M/O/ Format Length DetailsOThe shipping address of thecustomer.zip|postalcodecountry7384ae67....ac7d7d34e7....a77dO a-z A-Z 0-9 "" ,. - / |O a-z A-Z 0-9 "" ,. -0-30 The ZIP|Postal code of theshipping address.This can be checked (inconjunction with thecountry) against a table ofhigh-risk area codes.0-30 The country of the shippingaddress. This canbe checked against a table ofhigh-riskcountries.M a-f 0-9 40 The SHA-1 hash of certainelements of therequest. The details of this areto be found inthe Elavon Auth developer'sguide. Either this orthe MD5 may be used.M a-f 0-9 32 The MD5 hash of certainelements of the request. Thedetails of this are to be foundinthe Elavon Auth developer'sguide.5.5 Remote Authorisation Response MessageThe full version of the response is shown below, followed by the short version and a linebylinedescription.Response Format - Long VersionCopyright © 2013 Elavon, Inc.Page35Aug-13

YourMerchantIDaccount to useorder id from requestauthcode received00message returned from system Elavon Payment Gateway referenceMbatch id for this transaction (if any)Issuing Bank NameIssuing Bank CountryIssuing Bank Country CodeIssuing Bank Region8999…7384ae67....ac7d7d34e7....a77dResponse Format - Short Version508message returned from systemThe following indicators are used to show whether or not an element is required or optional.Each field has certain constraints around length and format as per below (please note that ““means aspace):Copyright © 2013 Elavon, Inc.Page36Aug-13

Line per line description M/O/ Format Length DetailsM 0-9 14 Top-level element. Must havetimestamp and type attributes.If the timestamp is more thana day (86400 seconds) awayfrom the server time then therequest is rejected.merchant id usedaccount usedorderidauthcode received00message returned fromsystem Elavon PaymentGatewayreferenceM a-z A-Z 0-9 .O a-z A-Z 0-9 “”M a-z A-Z 0-9 _ -M a-z A-Z 0-91-50 This is your Elavon PaymentGateway assigned merchant id0-30 This is the Elavon PaymentGateway sub-account to use. Ifyou omit this element then wewill use your default account.1-40 The unique order id of thistransaction. Must be uniqueacross all of your accounts.0-10 If successful an authcode isreturned from the bank. Usedwhen referencing thistransaction in refund and voidrequests.M 0-9 0-3 The result codes returned bythe Elavon Payment Gatewaysystem.M a-z A-Z 0-9 ' ", + ""._ - & \ /@ ! ? % ()* : £ $ &€ # [ ] | =M a-z A-Z 0-90-100 The text of the response.Contains the authcode ifsuccessful or the errormessage if not.0-50 The Elavon Payment Gatewayreference for the transaction.Used when referencing thistransaction in refund and voidrequests.Copyright © 2013 Elavon, Inc.Page37Aug-13

Line per line description M/O/ Format Length DetailsMDetailsVerification check:batchidM: CVV MatchedN: CVV Not MatchedI: CVV Not checked due tocircumstancesU: CVV Not checked - issuernot certifiedP: CVV Not ProcessedM 0-9 0-20 The batch id of the transaction.Returned in the case of authand refund requests. This canbe used to assist with thereconciliation of your batches. M The Details of the cardholder'sbank (if available)IssuingBank NameM a-z A-Z 0-9 _0-30 The Bank Name (e.g. First DataBank)IssuingBank CountryIssuing Bank CoCodeIssuingBank RegionM a-z A-Z 0-9 "" , . -0-30 The Bank Country in English(e.g. UNITED STATES)M a-z A-Z 2 The country code of the issuingbank (e.g. US)M a-a A-Z 0-9 /0-20 The region the card was issued(e.g. US) Can be MEA (MiddleEast/Asia), LAT (Latin America),US (United States), EUR(Europe), CAN (Canada), A/P(Asia/Pacific)M O The results of RiskManager67M 0-9 0-3 The weighted total score ofRiskManager. You may adjustthe weights in the Reportingapplication.9M 0-90-941The result of the RiskManagercheck number xxxx. You canchoose which checks to returnusing the Reportingapplication.Copyright © 2013 Elavon, Inc.Page38Aug-13

Line per line description M/O/ Format Length Details7384ae67....ac7d7dM a-f 0-9 40 The SHA-1 hash of certainelements of the response. Thedetails of this are to be foundin the Elavon Auth developer'sguide34e7....a77dM a-f 0-9 32 The MD5 hash of certainelements of the response. Thedetails of this are to be foundin the Elavon Auth developer'sguide.5.6 Digital Signatures for RemoteTo ensure authentication (that the request comes from you) we require that you send us a hash ofcertain elements (specifically the timestamp, merchant id, order id, amount, currency and cardnumber) using a shared secret. This can be a MD5 hash or preferably a SHA-1 hash. If required wecan also provide code for this.MD5 and SHA-1 algorithms are secure hash functions. They take a string as input, and produce a fixedsize number - 128 bits for MD5; 160 bits for SHA-1. This number is a hash of the input, and a smallchange in the input results in a substantial change in the output. The functions are thought to besecure in the sense that it requires an enormous amount of computing power and time to find astring that hashes to the same value. In others words, there's no way to decrypt a secure hash. Giventhe larger key size, we prefer that you use a SHA-1 hash, but we have retained the MD5 forcompatibility with older systems.Copyright © 2013 Elavon, Inc.Page39Aug-13

Here’s a fragment of a sample XML message: thestore theaccount ORD453-11 29900 5105105105105100 0302 John Smith VISA To construct the hash follow this procedure:• Form a string by concatenating the above fields with a period (“.”)(20120926112654.thestore.ORD453-11.29900.EUR.5105105105105100)• Get the hash of this string (SHA-1 shown below).(f7fa584d2f8d642c1a17e9ead6061e8beeffe308)• Create a new string by concatenating this string and your shared secret using a period.(f7fa584d2f8d642c1a17e9ead6061e8beeffe308.mysecret )• Get the hash of this value. This is the value that you send to Elavon Payment Gateway.(1537570e5f1d2aba5cad67ff5108ad3ff1d56c32) 1537570e5f1d2aba5cad67ff5108ad3ff1d56c32 When Elavon Payment Gateway receive the request, we perform the same procedure on the sixpieces of information and your shared secret (which we have stored in our database) If the resultinghash is the same as the one that you sent us then the data could only have been sent by someonethat had your shared secret. Thus it is very important to keep this shared secret protected.We will send you a hash of the response elements in the same way so that you can confirm that theresponse came from Elavon Payment Gateway.Copyright © 2013 Elavon, Inc.Page40Aug-13

This will be a hash of the TIMESTAMP, MERCHANT_ID, ORDER_ID, RESULT, MESSAGE, PASREF andAUTHCODE. This will be combined with your shared secret in the same way as the request hash.If you sent us an MD5 hash you will receive an MD5 hash in the response and similarly for a SHA-1hash).The response hash is constructed as follows:• Form a string by concatenating the above fields with a period (“.”)( 20120926112654.thestore.ORD453-11.00.Successful.3737468273643.79347)• Get the hash of this string (SHA-1 shown below).(a111135ea464bcd343c0f23db395fa1cf12a6837)• Create a new string by concatenating this string and your shared secret using a period.(a111135ea464bcd343c0f23db395fa1cf12a6837.mysecret)•Get the hash of this value. This is the value that you send to Elavon Payment Gateway.(368df010076481d47a21e777871012b62b976339).5.7 Address Verification ServiceThe Address Verification Service (AVS) verifies the cardholders address by checking the informationprovided by at the time of sale against the issuing bank's records.Note: This service only works for UK cardholders as it uses the street address and postcodes of thecardholders. The Elavon Auth service supports AVS where it is supported by the merchants acquiringbank and the cardholders issuing bank. If a transaction fails an AVS check it will not automatically bedeclined by your bank. It is an advisory service and requires that the details of non -matched bechecked by the merchant.AVS data must be passed in the billing code field.Copyright © 2013 Elavon, Inc.Page41Aug-13

This data should be formatted as follows:|For example, if the billing address is:382, The RoadThe TownWB1 A42UKThe corresponding AVS data will be:

6 Steps Required To Go LiveAll accounts remain in test mode until it is specifically requested to switch the account live. Thisrequest must come from the billing or commercial contact for the account.Before live cards can be processed you will also need to provide Elavon Payment Gateway with abank merchant number by email to support@elavonpaymentgateway.com. This number referencesan Internet Merchant Service Agreement (MSA), which you must set up with your acquiring bank.Once you have requested the system to go live and have provided your merchant number, pleaseallow 24 hours for the account to be fully enabled. When the account has been fully set live themerchant will be advised of this by Elavon Payment Gateway support. At this point the merchantshould attempt a number of live transactions to ensure that the integration has been completedsuccessfully.The main steps involved in setting an account live are summarised below:1. Secure merchant service agreement with acquiring bank.2. Provide merchant numbers to the Elavon Payment Gateway via email.3. Integrate website/application with Elavon Payment Gateway service.4. Conduct testing using approved test card numbers to confirm successful integration.5. Contact Elavon Payment Gateway and request account be set live.6. Receive confirmation that account is live from Elavon Payment Gateway support.7. Process live transactions.If further testing is required after an account has been set live it is still possible to send transactionsto the test environment. This can be done by appending ‘test’ to the name of the sub-accountspecified in the ACCOUNT field. For example, where the sub-account is called ‘internet’ the testtransaction would use ‘internettest’.Copyright © 2013 Elavon, Inc.Page43Aug-13

7 Appendix A – Sample Code7.1 Luhn checkBelow is code in JavaScript that carries out Luhn checking on all card numbers. Code in otherlanguages is widely available on the internet.var number = "4444333322221111";var i, sum, weight;sum=0;for (i = 0; i < number.length - 1; i++) {weight = number.substr(number.length - (i + 2), 1) * (2 - (i % 2));sum += ((weight < 10) ? weight : (weight - 9));}if (parseInt(number.substr(number.length-1)) == ((10 - sum % 10) % 10)) {return true;} else {alert("Card Number Fails LUHN Test");return false;}In brief, the Luhn check is used to validate numbers such as credit cards, account numbers, and socialsecurity numbers. It works like this:1. Double the value of every second digit beginning with the second-last right-hand digit.2. Add the individual digits comprising the products obtained in step 1 to each of the otherdigits in the original number.3. Subtract the total obtained in step 2 from the next higher number ending in 0.4. This number should be the same as the last digit (the check digit). If the total obtained in step2 is a number ending in zero (30, 40 etc.), the check digit is 0.For example: credit card number 36484554852358553 6 4 8 4 5 5 4 8 5 2 3 5 8 5 5x2 x2 x2 x2 x2 x2 x2 x2Copyright © 2013 Elavon, Inc.Page44Aug-13

6 6 8 8 8 5 10 4 16 5 4 3 10 8 106+6+8+8+8+5+1+0+4+1+6+5+4+3+1+0+8+1+0 = 7580 – 75 = 5 (correct)Copyright © 2013 Elavon, Inc.Page45Aug-13

8 Appendix B – Codes8.1 Currency CodesEUREuroGBPPound SterlingUSDUS DollarSEKSwedish KronaCHFSwiss FrancHKDHong Kong DollarJPYJapanese Yen(Further codes available on request.)8.2 Card TypesVISAMCSWITCHAMEXLASERDINERSVisa/DeltaMastercardSwitch/SoloAmerican ExpressLaserDinersCopyright © 2013 Elavon, Inc.Page46Aug-13

9 Response CodesThe Table below details the current set of result codes returned by the Elavon Payment Gatewaysystem.Additions and changes to the specific text of these messages can occur without notice!The best practise is to treat the codes in the following manner.Code Description00 Successful – the transaction has processed and you may proceed with the sale.1xxA failed transaction. You can treat any 1xx code as a failed transaction and inform yourcustomer that they should either try again or try another payment method.If you wish you may provide alternate flows based on the specific codes as follows:101 Declined by Bank – generally insufficient funds or incorrect expiry date.102 Referral by Bank (treat as decline in automated system such as internet)103 Card reported lost or stolen107 Your fraud checks blocked the transaction.1xx Other reason, rare. Treat as a decline like 101.2xx3xx5xxError with bank systems – generally you can tell the customer to try again later. Theresolution time depends on the issue.Error with Elavon Payment Gateway systems – generally you can tell the customer to tryagain later. The resolution time depends on the issue.Incorrect XML message formation or content. These are either development errors,configuration errors or customer errors. There is a large list below, but in general:508 Development issue – check the message and correct your integration.509 Customer issue – check the message and ask the customer to confirm theirpayment details and try again.5xx Configuration issue – check the message. You may need to contact Elavon PaymentGateway support to fix these issues.666 Client deactivated – your Elavon Payment Gateway account has been suspended.Contact Elavon Payment Gateway support for further information.Copyright © 2013 Elavon, Inc.Page47Aug-13

9.1 Current List of Error Results and MessagesRESULT MESSAGE00 AUTH CODE: nnnnnn101 CANCELLED CARD101 CARD EXPIRED101 DECLINED101 INVALID AMOUNT101 INVALID CARD NO.101 INVALID CURRENCY101 INVALID EXP DATE101 INVALID MERCHANT101 INVALID TRANS101 NOT AUTHORISED101 RETAILER UNKNOWN101 UNABLE TO AUTH102 CALL AMEX102 CALL AUTH CENTRE102 REFERRAL102 REFERRAL B103 REFERRAL A103 PICK UP CARD103 RETAIN CARD104 UNABLE TO AUTH106 Auth Failed - Contact Auth Centre (Generally Switch Card issue number is incorrect)107 Fails RiskManager Fraud Checks108 Using test system. Please use pre-approved test cards ONLY109 Comms Error – scheduled bank maintenance200 Unspecified bank error202 Network error: cannot connect to EPoS205 Comms Error – bank connection error.301 Cannot connect to Database302 Configuration error with your bank details (acquiring bank) - please contact Elavon PaymentGateway payments303 There is no default merchant account set. Please contact Elavon Payment Gatewaypayments if you continue to experience this problem.303 Error in configuration - merchant has more than one config for this currency/cardcombination303 Somehow more than one transaction matches these parameters.304 Can't find transaction details in database305 Elavon Payment Gateway are currently updating the system. We apologise for theinconvenience.501 This transaction has already been processed.Copyright © 2013 Elavon, Inc.Page48Aug-13

RESULT MESSAGE508 Can't settle a settled transaction.508 Can't settle for more than 115% of that which you authorised.509 NonNumeric in Credit card number.509 Invalid credit card length509 NonNumeric in issue number.509 Invalid issue number length509 Only Switch cards have issue numbers509 Card number fails Luhn Check509 Invalid expiry date509 Card Expiry date in past509 Expiry month invalid509 That Card Number does not correspond to the card type you selected509 An ECI value must be included for MPI enabled accounts.509 Length of CVV data is incorrect510 That amount is greater than the max allowed511 Unable to connect to the merchant response url512 This transaction has already been rebated and cannot be rebated again.512 Original transaction not found512 You may only refund the original cardnumber.512 You can't refund a delayed transaction that has not been sent for settlement. (You arerefunding money to a customer that has not and never will be charged!)512 Original account was not [account]512 Original transaction currency was not [currency]512 You may only refund 115% of the value of the original transaction.512 This transaction has already been refunded through the epage remote interface and cannotbe refunded again.513 Can't void a settled transaction.514 Original Transaction Failed! If you just want to give money to the customer use the refundterminal in emerchant.514 Original Transaction was Successful!514 Can't settle a settled transaction.514 Can't settle a transaction already settling.666 This account has been deactivated. Please contact Elavon Payment Gateway for furtherdetails.Copyright © 2013 Elavon, Inc.Page50Aug-13

9.2 Country CodesCertain RiskManager checks require you to submit the country as data to be checked against. Toensure that the country names we use are the same, Elavon Payment Gateway use the following ISO3166-1 country codes. The common use of these is in a dropdown list from which the customer canselect their billing and shipping countries.Copyright © 2013 Elavon, Inc.Page51Aug-13

codecountry nameAD ANDORRAAE UNITED ARAB EMIRATESAF AFGHANISTANAG ANTIGUA AND BARBUDAAI ANGUILLAAL ALBANIAAM ARMENIAAN NETHERLANDS ANTILLESAO ANGOLAAQ ANTARCTICAAR ARGENTINAAS AMERICAN SAMOAAT AUSTRIAAU AUSTRALIAAW ARUBAAZ AZERBAIJANBA BOSNIA AND HERZEGOVINABB BARBADOSBD BANGLADESHBE BELGIUMBF BURKINA FASO

codecountry nameCI COTE D'IVOIRECK COOK ISLANDSCL CHILECM CAMEROONCN CHINACO COLOMBIACR COSTA RICACU CUBACV CAPE VERDECX CHRISTMAS ISLANDCY CYPRUSCZ CZECH REPUBLICDE GERMANYDJ DJIBOUTIDK DENMARKDM DOMINICADO DOMINICAN REPUBLICDZ ALGERIAEC ECUADOREE ESTONIACopyright © 2013 Elavon, Inc.Page53Aug-13

codecountry nameGN GUINEAGP GUADELOUPEGQ EQUATORIAL GUINEAGR GREECEGS SOUTH GEORGIA AND THE SOUTHSANDWICH ISLANDSGT GUATEMALAGU GUAMGW GUINEA-BISSAUGY GUYANAHK HONG KONGHM HEARD ISLAND AND MCDONALDISLANDSHN HONDURASHR CROATIAHT HAITIHU HUNGARYID INDONESIAIE IRELANDILISRAELCopyright © 2013 Elavon, Inc.Page54Aug-13

codecountry nameLA LAO PEOPLE'S DEMOCRATIC REPUBLICLB LEBANONLC SAINT LUCIALILIECHTENSTEINLK SRI LANKALR LIBERIALS LESOTHOLT LITHUANIALU LUXEMBOURGLV LATVIALY LIBYAN ARAB JAMAHIRIYAMA MOROCCOMC MONACOMD MOLDOVA, REPUBLIC OFMG MADAGASCARMH MARSHALL ISLANDSMK MACEDONIA, THE FORMER YUGOSLAVREPUBLIC OFML MALIMM MYANMARCopyright © 2013 Elavon, Inc.Page55Aug-13

codecountry nameNO NORWAYNP NEPALNR NAURUNU NIUENZ NEW ZEALANDOM OMANPA PANAMAPE PERUPF FRENCH POLYNESIAPG PAPUA NEW GUINEAPH PHILIPPINESPK PAKISTANPL POLANDPM SAINT PIERRE AND MIQUELONPN PITCAIRNPR PUERTO RICOPS PALESTINIAN TERRITORY, OCCUPIEDPT PORTUGALPW PALAUPY PARAGUAYCopyright © 2013 Elavon, Inc.Page56Aug-13

codecountry nameST SAO TOME AND PRINCIPESV EL SALVADORSY SYRIAN ARAB REPUBLICSZ SWAZILANDTC TURKS AND CAICOS ISLANDSTD CHADTF FRENCH SOUTHERN TERRITORIESTG TOGOTH THAILANDTJ TAJIKISTANTK TOKELAUTM TURKMENISTANTN TUNISIATO TONGATP EAST TIMORTR TURKEYTT TRINIDAD AND TOBAGOTV TUVALUTW TAIWAN, PROVINCE OF CHINATZ TANZANIA, UNITED REPUBLIC OFCopyright © 2013 Elavon, Inc.Page57Aug-13

codecountry nameZW ZIMBABWECopyright © 2013 Elavon, Inc.Page58Aug-13

10 Appendix C - Data Validation RulesField Valid Data CommentsMerchant ID a-z A-Z 0-9 Elavon Payment Gateway assignedAccount a-z A-Z 0-9 Elavon Payment Gateway assignedOrder ID a-z A-Z 0-9 - _ Max 50 charactersAmount 0-9 No decimal pointCurrency A-Z a-z See Currency CodesTimestamp 0-9 Must be a legal timestamp, 14 digits long in theform yyyymmddhhmmss and within 24 hoursof the current time.SHA1Hash/MD5Hash a-f 0-9 40 or 32 digitsAutosettle Flag 0 or 1Billing Code a-z A-Z 0-9Billing Country a-z A-Z 0-9 Should be taken from the Error! Referencesource not found. if you are using theRiskManager checksShipping Code a-z A-Z 0-9Shipping Country a-z A-Z 0-9 Should be taken from the Error! Referencesource not found. if you are using theRiskManager checksCustomer Number a-z A-Z 0-9 “ ” - _ Max 50 charactersVariable Reference a-z A-Z 0-9 “ ” - _ Max 50 charactersProduct ID a-z A-Z 0-9 “ ” - _ Max 50 charactersComments a-z A-Z 0-9 “ ” - _ Max 255 charactersCard type a-z A-Z See Card Types.Cardnumber 0-9 Must pass Luhn check, and be properlymatched with the card type.Cardholder name See note. Max 50 characters. Most 506 errors(malformed XML error) that you will receivewill be because the cardholder has “funny”characters in their name. These characters (e.g.ß, or ä) are encoded using the ISO-8859-1standard and not UTF-8 (which is the defaultfor the parser used by Elavon PaymentGateway Therefore you should ensure that theencoding set in the top line of the XML yousend to Elavon Payment Gateway is correct. Inmost cases ISO-8859-1 will suffice but as moreand more international customers use yoursite, Unicode (or UTF-8) encoding may beencountered (which allows for many morecharacters such as Japanese or Hebrew words).Further information will follow as the UTF-8standard is finalised.Issue Number 0-9 0, 1, or 2 digits – only SWITCH cardsExpiry Date 0-9 4 digits, mmyy, valid (i.e. 4598 is illegal)

11 Appendix D – Elavon Payment GatewayGuidesTitle Target DescriptionElavon Auth XMLDefinitions GuideDevelopers This guide provides details of the XML messagesrequired for each type of transaction. This will berequired for any Remote integration.3D Secure Redirect Guide Merchants 3D Secure is the 3DSecure service available throughElavon Payment Gateway. Elavon Payment Gatewaywill carry out the integration work for redirectimplementations, so this guide provides an overviewof the service with fewer technical details.3D Secure Remote Guide Developers For remote implementations of 3D Secure there willbe some development work required by themerchant. This guide provides the technical detailsneeded by developers.SecureDataVault PaymentsGuideAllElavon Payment Gateway also provide a recurringpayments solution. This allows merchants to raisepayments by storing card details on our secureservers and then passing a reference in the place ofthe card number. This guide provides both anoverview and the details required to integrate theservice.Multi-Currency Guide Developers Multi-Currency is the Dynamic Currency Conversionservice provided by Elavon Payment Gateway. DCCallows merchants to provide customers with theoption of making purchases in their native currency,with exchange rates retrieved in real time.Copyright © 2013 Elavon, Inc.Page60Aug-13

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 thenumber 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 TowlsonCopyright © 2013 Elavon, Inc.Page61Aug-13