SENTRY Payment Gateway

Merchant Developer Guide Date: 3 September 2013 Version: 3.3 Status: Release

Document Information Copyright TSYS 2013. All rights reserved. Copyright in the whole and every part of this document belongs to TSYS, with the exception of proprietary material and the brand or product names of other parties for which the rights in such material or trademarks remain with their respective owners. Names and data used in examples herein are fictitious unless otherwise noted. Disclaimer This document and the TSYS software it describes are furnished by TSYS under a Software Licensing Agreement, Consultancy Agreement, Variation Order or Confidentiality Agreement, and may be used or copied only in accordance with the terms of such Agreement. Neither this document nor the TSYS software it describes may be used, sold, transferred, copied, translated, reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, in whole or in part, other than in accordance with the terms of such Agreement, or otherwise without prior written consent of TSYS. This document describes a generic product or service and should be read in conjunction with other documents relevant to the configuration of any specific system. The licensee of TSYS software or user of TSYS services is responsible for ensuring that the product or service described herein meets its own requirements. The information contained in this document is subject to change without notice and should not be taken as a commitment by TSYS. TSYS assumes no responsibility for any errors that may appear in this document. Confidentiality The information contained herein is the property of TSYS. This document contains confidential information that is produced solely for the benefit of the receiving party named on the front page of this document. The recipient should keep all information contained herein confidential, and on no account should the information, in whole or in part, be used, sold, transferred, copied, translated, reproduced or transmitted in any form or by any means, electronic or mechanical, or disclosed or disseminated to any third party, without the express written permission of TSYS. Document Publication Details Area Description Title SENTRY Payment Gateway Subject Released Date 02/05/2011 Version 3.3 (Release) Author SENTRY Team Document Version Control Version Date Comments 3.0 04/07/2013 Update document layout, review content for clarifications and corrections, enhanced appendix B, added appendix E 3.2 17/7/2013 Update Appendix E for latest versions of IE10, Opera, Chrome & Firefox 3.3 03/09/13 Add error code & description for custom MCBA checkout page timeout Page 2 of 72

Contents Contents... 3 List of figures... 6 1. Introduction... 7 1.1 Purpose of the Developer s Guide... 7 1.2 Intended audience... 7 1.3 SENTRY Basics and Requirements... 7 1.3.1 What is SENTRY?... 7 1.3.2 What is Credit Card Processing?... 8 1.3.3 What is the 3-D Secure protocol?... 9 1.3.4 Processing your first Test Transaction... 12 1.3.5 Sample Checkout Page... 13 1.3.6 Mandatory Fields... 15 1.3.7 Basic submission of a Merchant Order... 16 1.4 Data Integrity and Security using a Hash Signature... 17 1.4.1 Example of order signature generation... 17 1.4.2 Merchant Response Page... 19 1.4.2.1 A simple Response listener example... 20 1.4.3 Conclusion... 21 2. Getting Started with Merchant Administration... 22 2.1 The Merchant Menu... 22 2.2 Merchant Account... 22 2.3 What s next?... 23 3. Processing Methods... 24 3.1 SENTRY PG Integration Methods... 24 3.2 Virtual POS and MOTO transactions... 25 3.3 Connecting with SENTRY PG... 25 3.3.1 Overview of SENTRY PG Handler Methods... 25 3.4 Choosing a method... 26 3.5 Overview of SENTRY Direct Link... 26 3.5.1 Example Minimum requirements for Direct Link Method... 27 3.5.1.1 Displaying the ACS authentication window... 31 3.6 Overview of SENTRY Redirect Link... 34 3.6.1 Example - Minimum Requirements for Redirect Link... 34 3.7 SENTRY Batch Transaction Processing... 37 3.7.1 Uploading batch files... 37 3.7.2 Data Validation... 37 3.7.3 Batch file processing... 37 3.7.4 Checking the status of an uploaded batch file... 37 3.8 File Format... 37 3.8.1 Sample Batch File... 38 Page 3 of 72

3.8.2 Merchant Details MDET... 38 3.8.3 Authorization Request AUTH... 38 3.8.4 Refund Request REF... 38 3.8.5 Reversal Request REV... 39 3.8.6 Capture CAPT... 39 3.8.7 Authorization Request/Capture AUTHC... 40 3.8.8 Instalments INST... 41 3.8.9 Sending Order Details with merchant request... 43 3.8.10 Sending Additional Order Details with merchant request... 44 3.8.11 Airline Ticket Order Updates... 44 3.8.12 Recurring Transactions... 44 3.8.13 Instalment Transactions... 45 3.8.14 Handler Details... 45 3.8.14.1 DirectAuthLink... 45 3.8.14.2 DirectAuthztpLink... 46 3.8.14.3 DirectAVSLink... 47 3.8.14.4 DirectAuthzLink... 47 3.8.14.5 RedirectLink... 48 3.8.14.6 FinancialLink... 48 3.8.15 Incoming/Outgoing Signature or Response Fields Customization... 48 4. Appendix A Transaction Fields... 50 4.1 Form Fields... 50 5. Appendix B Response Codes... 61 5.1 System Response Codes... 61 5.1.1 Data Sent with Response Codes... 61 5.2 Customized Incoming Signature Fields... 62 5.3 Customized Outgoing Signature Fields... 62 5.4 Customized Response Codes Fields... 63 5.5 System Response Codes... 63 5.6 System Response Reason Codes for Response Code 1... 63 5.7 System Response Reason Codes for Response Code 2... 64 5.8 System Response Reason Codes for Response Code 3... 64 5.9 System Response Reason Codes for 3D-Secure Errors... 65 5.10 System Response Reason Codes for Airline Data Update... 65 5.11 System Error Codes for Store Front Services... 66 6. Appendix C AVS Result Codes... 69 6.1 VISA Transactions... 69 6.2 MasterCard Transactions... 69 6.3 AMEX Transactions... 70 7. Appendix D CVV2 Result Codes... 71 8. Appendix E Browser Compatibility... 72 Page 4 of 72

8.1 Test platform... 72 8.2 Legend... 72 Page 5 of 72

List of figures Figure 1: BASE I overview... 9 Figure 2: Authentication and Authorization overview Verify Enrolment... 10 Figure 3: Authentication and Authorization overview Payment Authentication... 11 Figure 4: Authentication and Authorization overview Authorization... 12 Figure 5: SENTRY PG cycle overview... 13 Figure 6: Sample Merchant Checkout Page... 14 Figure 7: Sample SENTRY PG Checkout Page... 15 Page 6 of 72

1. Introduction The Internet represents a tremendous opportunity for business regardless of the size of an organization. But selling goods and services on the Internet presents its own set of challenges. How can a business set up and maintain a secure, reliable, cost-effective system for processing credit cards and managing transactions? You want to sell your products in an easy to use and secure method but do not want to bother with the complexities that are involved in the card processing business. The SENTRY Payment Gateway (SENTRY PG for short) is a platform built with the goal to remove the complexity and effort involved with conducting e-commerce business on the Internet. From a merchant s perspective, all that is needed to process and manage transactions over the World Wide Web is a merchant account with an Acquirer running SENTRY PG, and a computer with an Internet connection and a Web browser. 1.1 Purpose of the Developer s Guide This guide s purpose is to provide information that will enable merchant developers to understand the functionality offered by SENTRY Payment Gateway, and allow them to choose the right integration options to suit the merchant s technical capabilities and business environment. The guide does not dictate coding techniques for integration. It only provides guidelines to understanding the basics of integrating a web application with the SENTRY Payment Gateway. It does not provide a complete solution to merchant developers on how to build an ecommerce web site. 1.2 Intended audience This guide is addressed towards e-commerce Merchants and the web developers tasked with integrating the Merchant s website/checkout system with SENTRY PG and MPI. It is assumed that readers are familiar with web development, web application security and the technologies supporting the World Wide Web. In order to fully benefit from this document, readers should ideally possess a basic understanding of card payments processing and related infrastructure, as well as a basic understanding of the 3D-Secure authentication protocol. 1.3 SENTRY Basics and Requirements 1.3.1 What is SENTRY? SENTRY PG is a Web-facing, real-time transaction processing system that serves as a payment gateway switch, using a secure connection to a Web server on the Internet. Merchants with a valid, enabled merchant account can use the system to submit, authorize and capture card transactions without the need for a separate transaction terminal. In addition to the normal e-commerce functionality, SENTRY supports 3D-Secure transactions, file based batch transactions, web-service based transactions and several other mechanisms, utilities and applications to help you process and manage e-commerce transactions. SENTRY PG is made up of four main modules: the Checkout Application, the Merchant Plug-In, the Bank Administration application and the Merchant Administration application. The Checkout Application is the module responsible for e-commerce transaction processing. The Merchant Plug-In, or MPI for short, is fully integrated with the Checkout Application and is responsible for handling cardholder authentication (3-D Page 7 of 72

Secure). The Merchant Administration application is a Web-facing front-end application that provides a user friendly interface that can be used by Merchants to manage their transactions. Although processing credit cards can be a complex and error-prone exercise, the whole family of SENTRY products has been designed to provide a user-friendly experience to both the merchant and the Cardholder, and at the same time provide a highly secure and stable platform that ecommerce merchants can depend on to run their business. The following section explains the basic e-commerce processing flow. The section after that discusses the 3-D Secure protocol which is considered the most secure credit card authentication protocol for Internet transactions. If you are familiar with the methodology used for processing e-commerce transactions you can jump right to the Processing your First Test Transaction section which explains the easiest and fastest method of connecting your ecommerce web site with the SENTRY Payment Gateway. 1.3.2 What is Credit Card Processing? Credit card processing sounds and can be a relatively difficult process that can take a lot of effort and money if a merchant chooses to implement it independently. Thankfully SENTRY PG provides the means to process e-commerce transactions much easier. The following is an outline of the steps involved in processing a credit card transaction: 1. SENTRY takes over from the point where the customer is ready to checkout (and pay with the credit card). SENTRY PG provides the means for doing both the Authentication cycle (3-D Secure Protocol) and the Authorization cycle. 2. After securely providing the credit card details, an electronic request is submitted to the processing network for authorization and capture from the cardholder's credit card account for the amount of the purchase. In a brick and mortar merchant, one would submit this request by swiping a credit card through an electronic transaction terminal provided by the acquiring bank. This request is provided electronically to SENTRY Payment Gateway, which then routes the request to the Provider s Payment System Host. In case Authentication is required by the SENTRY provider before step 3 takes place (Authorization Cycle), SENTRY Payment Gateway will authenticate the cardholder using 3-D Secure protocol (Authentication Cycle). 3. The authorization cycle, via SENTRY and the provider s acquiring host, is passed through the credit card interchange system to the credit card issuer. The credit card issuer determines if the cardholder's account is valid and if the funds are available. If they are, the processing network returns an electronic response to your terminal or computer. This response is called an authorization code, and is your guaranteed authorization to capture the funds. Typically, this code is a six-digit number. The transaction and its associated authorization are stored in a batch, where other currently unsettled transactions for that day reside. This entire authorization process typically takes 3 to 4 seconds, but this can vary depending on network and payment system traffic. 4. At the end of the business day (scheduled by the SENTRY provider to a default time), the SENTRY server or the Acquirer s banking host automatically creates batch files of your transactions that were flagged as captured. This is called settlement or settling your batch. With a traditional physical credit card swipe terminal, this settlement process must be initiated manually. One of the key advantages of SENTRY PG is that this settlement process is initiated automatically every day. 5. The SENTRY Provider will transmit the transaction batches to the Credit Card Interchange System, which, in turn, passes the batch onto the Credit Card Issuer. A settlement report can be printed showing the grand totals by card type (Visa, MasterCard, American Express, etc.) for the settled batch. Note: any corrections to the merchant s batch, such as voiding a transaction, must be made prior to settlement. Page 8 of 72

6. Within 48 to 72 hours (usually), the funds associated with the batch settled will be deposited electronically into the merchant s bank account. 7. At the end of the month, your provider will mail a statement to the merchant, detailing the credit card activity for the month and the associated fees the merchant has been charged for. The following diagram shows the authorization cycle that occurs during the first part of the credit card processing (BASE I), which occurs from the point when the cardholder enters the card information to the point when a response is received from the card holder s Issuer. Figure 1: BASE I overview 1.3.3 What is the 3-D Secure protocol? Since the first e-commerce credit card processing it was apparent that the possibility of fraudulent transactions is much higher than the traditional POS model of processing. The Payment Systems have recognised this and they have jointly developed the 3-D Secure protocol which is a highly secure protocol that was designed from scratch with the purpose to reduce ecommerce fraud as much as possible. The protocol is called 3-D Secure because during its cycle it involves three Domains: the Acquirer (Merchant) Domain, the Interoperability Domain (Payment System) and the Issuer (Card Holder) Domain. The main premise of the protocol is to generate a digital signature which will otherwise be impossible to generate, unless all three parties are authenticated properly within the context of an individual transaction. This digital signature is generically called the Card Authentication and Verification Value (CAVV) and is generated by the Issuer only after the Card Holder enters a password or secret phrase, during the 3-D Secure cycle. This signature is included in the authorization message that will be sent by the Acquirer and at the end of the process it will be verified by the same Issuer. Page 9 of 72

In order to process credit cards using this protocol from beginning to end, all three parties must participate in the program. If the Merchant is 3-D Secure enabled, the processing cycle changes at the point where the Payment Gateway sends the request to the Acquirer. Before this step is taken the Payment Gateway will have to check if the transaction can be performed with 3-D Secure. To do that, the Payment Gateway (or the Merchant) will contact the MPI (Merchant Plug In) and inquire if this card holder s Issuer and the card itself support the protocol. The details of the protocol are explained in a later section but in simple words this is what happens: 1. The Payment Gateway will send the card number to the MPI to check if the card and the Issuer are both enrolled in this program. The MPI will send a request (VeReq, Verification of Enrolment Request), to the Payment System s Directory Server (VISA, MasterCard etc). 2. The Directory Server will respond to the MPI with a Y or N response indicating if the card and the Issuer are enrolled. 3. If the answer is Y then the MPI will inform the Payment Gateway that the card holder has to be redirected to his/hers Issuer s web site (PaReq, Payer Authentication Request). 4. The card holder will be redirected to the Issuer to enter their 3D Secure password for authentication. After this is done, the Issuer will send a response back to the MPI (PaRes, Payer Authentication Request). 5. If the password was correct, the MPI will receive a Y in the PaRes and the verification value (CAVV). 6. The Payment Gateway will take the CAVV and insert it into the authorization message that will be sent to the Acquirer. From there on, the cycle is the same, except that the Issuer before checking that there are enough funds in the card, it will check that the CAVV value is valid. The following diagrams show a simplified version of the Authorization cycle together with the Authentication Cycle (3-D Secure). Figure 2: Authentication and Authorization overview Verify Enrolment Page 10 of 72

The Credit Card Holder enters the card information, the Payment Gateway requests from the MPI to check if the card is enrolled from the Directory Server. The Directory Server will locate the Issuer and request this information and send the results back to the MPI. The MPI will inform the Payment Gateway of the status of the request. This all happens behind the scenes and is transparent to the cardholder. Figure 3: Authentication and Authorization overview Payment Authentication Page 11 of 72

Figure 4: Authentication and Authorization overview Authorization The Acquirer will send the transaction for authorization to the Credit Card s Issuer including the CAVV in the authorization request. The Issuer will receive the request, validate the CAVV, then check for funds availability and finally respond back to the Acquirer. The Acquirer will forward the response back to the Payment Gateway and from there the Merchant will receive the response and inform the Card Holder. 1.3.4 Processing your first Test Transaction Processing transactions using the SENTRY is easy. However, it is important that the developer assigned with the task of integrating the Merchant s Checkout system with SENTRY has basic knowledge of Internet technology (HTML, SSL, scripting etc). Let s go through a simple transaction flow and how you can start sending test transactions as soon as possible. The flow begins when a potential customer arrives at the merchant s web store. The customer will select which items he/she wants to purchase, prepare the shopping basket and proceed to checkout. The following diagram shows the customer selecting to proceed to the checkout and what happens from there. Page 12 of 72

Figure 5: SENTRY PG cycle overview 1. Merchant s web site will create the request a send it to SENTRY. 2. SENTRY will ask the cardholder to enter the card information. 3. The authorization will be sent to the cardholder s bank. 4. And finally a response will be sent to the merchant s Web Site informing them if the authorization was successful or not. From a merchant s perspective, the process is simple, despite the high amount of processing taking place behind the scenes. The benefit for merchants of using SENTRY is that as long as you have an account with an Acquirer, and you are set up correctly in SENTRY Payment Gateway, the merchant s part is trivial. The only thing that is needed is a way to program the merchant Checkout system in order to send order requests to SENTRY for processing. Let s see what is actually required from the merchant s side in order to accomplish this. 1.3.5 Sample Checkout Page The way SENTRY works is that it waits for the merchant to request a particular listener, and provide the required data. As soon as it receives a request for that listener SENTRY will validate the order data that the merchant provided, and will start processing the transaction. Below is a simple page that can be stored in your web server and when loaded will show only a checkout button. As soon as you press that button, the request will be sent to SENTRY and the processing will initiate (If you would like to experiment by using this example note that some of the fields values will have to change according to the data that your Acquirer will provide otherwise the request will be rejected. You will also need to calculate the signature correctly). Here is the HTML code of the web page: <HTML> <body> Page 13 of 72

<form id='frmhtmlcheckout' name='frmhtmlcheckout' action=''https://sentry_host/sentry/paymentgateway/application/redirectlink.aspx'' method='post'> <input id='version' type='hidden' name='version' value='1.0.0'> <input id='merid' type='hidden' value='0009999012' name='merid' > <input id='acqid' type='hidden' value='459889' name='acqid' > <input id='merrespurl' type='hidden' value='https://your_server.com/sentryresponse.aspx' name='merrespurl'> <input id='purchasecurrency' type='hidden' value='196' name='purchasecurrency'> <input id='purchasecurrencyexponent' type='hidden' value='2' name='purchasecurrencyexponent'> <input id='orderid' type='hidden' value='20050201162457147' name='orderid' > <input id='signaturemethod' type='hidden' value='sha1' name='signaturemethod'> <input id='purchaseamt' type='hidden' value='000000000075' name='purchaseamt'> <input id='signature' type='hidden' value='w25b1ism517imsnpuumfkweze9m=' name='signature'> <input style="z-index: 101; LEFT: 264px; POSITION: absolute; TOP: 152px" type="submit" action="https://sentry_host/sentry/paymentgateway/application/redirectlink.aspx" </HTML> </body> </form> value="submit"> The above rudimentary sample defines a form (FrmHtmlCheckout) containing the necessary order fields that are to be sent to the SENTRY PG listener. Notice the form method is set to post, indicating the sender must use HTTP POST to send the data to SENTRY. The MerRespURL field must be present otherwise SENTRY will reject the request. Figure 6: Sample Merchant Checkout Page Page 14 of 72

By pressing the Submit button, the request will be sent to SENTRY PG for authorization. In a few fractions of a second the checkout page (similar to the one below) will appear in the browser. After the card details have been entered, the transaction can be submitted for processing. Figure 7: Sample SENTRY PG Checkout Page In the next section we will go over the mandatory fields that the merchant is required to send, in order for the transaction to take place. We will also look at how to send our first test transaction. 1.3.6 Mandatory Fields As in most applications, certain fields are optional and others are mandatory. In the case of SENTRY PG there are only few mandatory fields that the system will expect to receive in order to continue the transaction. Most of these are fixed (per Merchant) and some depend on the transaction. In the sample Web Page above the following fields were used: 1. Version This is the version of the SENTRY PG - currently set to 1.0.0 2. MerID This is your Merchant ID as set in SENTRY (will be provided by your SENTRY Provider) 3. AcqID This is your Acquirer ID (will be provided by your SENTRY Provider) 4. MerRespURL This is the fully qualified URL of a Web Page on the merchant s server where the final response will be sent 5. PurchaseCurrency This is the standard ISO code of the currency used for this transaction 6. PurchaseCurrencyExponent This is the number of decimal places used in the amount (usually 2) Page 15 of 72

7. OrderID This is the Order ID that will be used to match a merchant s submitted Orders with SENTRY transactions. This Order ID must be a unique value. 8. SignatureMethod This is the signature method used to calculate the merchant order s signature (explained below) 9. PurchaseAmt This is the total amount of the purchase 10. Signature This is a digital signature that will verify that the contents of this Web Page have not been altered while in transit. (SENTRY will verify this signature) Most of the mandatory fields will always be the same or will rarely change. The only fields that will almost always change are the OrderID, PurchaseAmt and Signature. Note Note Note The Order ID MUST be a unique number because it will be easier for you to track the Orders that you have on the Web Site with the actual transactions in SENTRY. A unique order id will also guarantee that even if the cardholder presses the back or submit button several times the transaction will only be processed once. The PurchaseAmt is straight forward, it is basically the normal amount e.g. 134.78, but without the decimal place and left padded with zeros in order to make the number twelve characters long. Therefore the amount 134.78 should be 000000013478. The signature is a little more complicated and is discussed later on. 1.3.7 Basic submission of a Merchant Order The HTML page shown above has a single submit button, that when pressed will POST the HTTP form from section 1.2.5 to the URL defined in the Submit button s action tag. This basically instructs the Checkout page to redirect the browser to the action URL, sending all the data in the form fields with the request. When the SENTRY listener picks up this request, it will read all the data in the input fields, validate the data and process the request accordingly. There are several other options that can be used to submit the page for processing to SENTRY and one of them is by using some JavaScript. The page below uses a JavaScript function wired to the Submit button s onclick event (onclick ="Checkout"). The JavaScript function called Checkout() will do the same thing as before; that is it will POST the page and its form data to the SENTRY Web Server. <HTML> <body> <form id='frmhtmlcheckout' name='frmhtmlcheckout' action='' method='post'> <input id='version' type='hidden' name='version' value='1.0.0'> <input id='merid' type='hidden' value='0009999012' name='merid' > <input id='acqid' type='hidden' value='459889' name='acqid' > <input id='merrespurl' type='hidden' value='https://your_server.com/sentryresponse.aspx' name='merrespurl'> </form> <input id='purchasecurrency' type='hidden' value='196' name='purchasecurrency'> <input id='purchasecurrencyexponent' type='hidden' value='2' name='purchasecurrencyexponent'> <input id='orderid' type='hidden' value='20050201162457147' name='orderid' > <input id='signaturemethod' type='hidden' value='sha1' name='signaturemethod'> <input id='purchaseamt' type='hidden' value='000000000075' name='purchaseamt'> <input id='signature' type='hidden' value='w25b1ism517imsnpuumfkweze9m=' name='signature'> <input style="z-index: 101; LEFT: 264px; POSITION: absolute; TOP: 152px" type="submit" onclick ="Checkout" value="submit"> Page 16 of 72

<script language='javascript'> </body> </script> function CheckOut(){ document.frmhtmlcheckout.action = 'https://sentry_host/sentry/paymentgateway/application/redirectlink.aspx'; document.frmhtmlcheckout.submit(); } </HTML> In addition to these two samples shown above, merchant developers are free to use other programming approaches to collect and submit the data to SENTRY. Implementation is up to the merchant developer. 1.4 Data Integrity and Security using a Hash Signature A hash signature is required when using either of the methods. The MD5/SHA1 hash is a security feature that enables your script to identify that the results of a transaction are actually from the appropriate authorization source and also for the Payment Gateway Server to make sure the integrity of data received on a transaction request. Using either MD5 or SHA1 algorithm, a unique signature or fingerprint of the transaction can be created. The mathematical algorithm used to construct this signature is designed in such a way that any change to the information used in the calculation of the signature will cause a different signature to be created. The information used in the calculation of the signature cannot be discovered through any analysis of the signature itself. Signature calculation is done by using information from the merchant SENTRY account. Every transaction that is processed through the system has a corresponding hash signature, created during the transaction process. This signature must be computed and included in every submitted transaction. The signature for a request is a hash of the following six fields: 1. Password (This is the password included in the mailer that your provider supplied) 2. Merchant Id 3. Acquirer Id 4. Order Id (The unique Order Id that your system generates) 5. Purchase Amount 6. Purchase Currency The fields must be set in the following order, (Password & MerchantID & AcquirerID & OrderID & Purchase Amount & PurchaseCurrency) 1.4.1 Example of order signature generation If your password was "orange", your Merchant Id was "45877687", your Acquirer Id was 459999, the Order Id was "SENTRYORD01154321", the amount was "12.00", and Purchase Currency was 840. The request s hash would be calculated based on the following string: orange45877687459999sentryord01154321000000001200840 Page 17 of 72

The resulting hash signature value equals to (using SHA1 algorithm in this case) U50GMpLO3fQ764kYILbqIcV5uAg= If the authorization request is successful, SENTRY will create a second hashed signature using the SHA1 hashing algorithm, and include it in the response message. Therefore when you receive the response data you can verify that the values were not modified in transit. The hash signature for the response is a hash of the following fields: 1. Password (This is the password included in the mailer that your provider supplied) 2. Merchant Id 3. Acquirer Id 4. Order Id (The Order Id that you included in the request) The fields must be set in the following order, (Password & MerchantID & AcquirerID & OrderID) For example: If your password was "orange", your Merchant Id was "45877687", your Acquirer Id was 459999 and the Order Id was "SENTRYORD01154321". The response s hash would be calculated on the following string: orange45877687459999sentryord01154321 The resulting hash value equals to: (note that only SHA1 is currently supported for the response) WbwSWEBzPqgo9C4nZmGwHhd/FBQ= When SENTRY Payment Gateway receives the request of the merchant order, it will compute the Hash value and check if it matches the hash value you have included in your order request. When the merchant s checkout system receives the results of the transaction from SENTRY, it will compute the hash and compare it to the one sent by SENTRY, to be sure that both are the same. The merchant s system already knows the hash seed values (password, merchant ID, etc), and will receive back the order ID sent in the initial request to SENTRY. Please note that the Signature in the response will only be present if the transaction passed the order validation stage. Responses for transactions which do not pass the order validation stage, or suffer an error during validation processing will not carry a signature value. A developer would receive the results of the transaction AFTER it was returned to the merchant server, and run the hash algorithm on the fields mentioned above. The only way that the results of a developer s processing can match the signature included with the transaction results is if the password used in the hash on the developer s end MATCHES the one used to compute the hash of the initial order request. The SENTRY listener password is a shared secret between the merchant and the Acquirer or Processor, and is one of the key pieces of information in the hash. One can be assured that if the signature generated on the merchant end matches the one sent with the transaction, then the transaction has in fact been Page 18 of 72

processed by the legitimate system, and has not been posted back to the merchant s server from any other location. The SENTRY password is generated by SENTRY during merchant account creation, and is sent securely to the merchant. This is also used to authenticate your server to our server during transaction posting. It is only known by the merchant and the SENTRY system. All sensitive data and passwords are stored under AES encryption. Also note that the merchant has the ability to choose which hashing algorithm to use on every order request (MD5, SHA1). If no hashing algorithm is specified in the order request, SENTRY will default to SHA1 (recommended). More information about the SHA1 hash algorithm, including sample implementation code, can be found in RFC 3174 in The Internet Engineering Task Force web site. More information about the MD5 hash algorithm, including sample implementation code, can be found in RFC 1321 in The Internet Engineering Task Force web site. The following VB.NET sample shows how to use the.net libraries to perform signature computation. The key argument passed to the function is a concatenation of the mandatory fields illustrated above. Public Shared Function ComputeHash(ByVal Key As String) As String Dim objsha1 As New SHA1CryptoServiceProvider() objsha1.computehash(system.text.encoding.utf8.getbytes(key.tochararray)) Dim buffer() As Byte = objsha1.hash Dim HashValue As String = System.Convert.ToBase64String(buffer) Return HashValue End Function Apart from the hashing algorithm described above, there is an extra layer of security with the use of bitmaps. See section Incoming/ Outgoing Signature or Response field s customization. 1.4.2 Merchant Response Page By this point the merchant s web developer should have all the information needed to submit an order request to SENTRY PG. However, you need a way to catch SENTRY s response to your order submission. SENTRY expects a Response URL to be passed in the POSTed page, which will point to a web listener on the merchant s server. When the authorization request completes, SENTRY PG will send a response to this URL, in order for the merchant to parse and interpret the results of the order request. The SENTRY response is made of several parts. The first is the Response Code which is the most important part of the equation. This will equal to 1, 2 or 3. Response code Response code meaning 1 Transaction was approved 2 Transaction was declined Page 19 of 72

Response code Response code meaning 3 Error during transaction processing By reading this value you can determine whether the payment was accepted or not. There are several other values that can be returned when a transaction is completed, which include the Reason Code, which is a numeric value that maps to the reason why a particular transaction was declined. There is a Response Description which carries a textual description of the result of the transaction. There are also other response fields like the Authentication response, the AVS response codes etc, depending on the type of transaction requested and the acquiring host that responded. For a complete list of these values, readers should refer to Appendix B (Response Codes). Response codes are returned inside hidden form fields inside the HTML posted back to the merchant s Response URL. In order to receive the SENTRY response you will need the following: A simple Web Page that will show the response details to the card holder. A way to read the data from the response and use it to update the order of the customer. A simple Web Page that will accept the response from SENTRY Usually the first and last points are the same Web Page. This Web Page will read the response codes from the SENTRY response, and update the record of the order request. The merchant s response page can be developed to show a message indicating to the customer if the transaction was successful or not. The method used to update the order and display the information to the client is up to the merchant s developer and there are several methods of achieving this, which can range from very simple to very complex depending on how your business logic will be enforced and the complexity of your Web Site. 1.4.2.1 A simple Response listener example The following VB.Net snippet will simply read the values from the request page and display them on a placeholder (label) on the form that the customer will see. This method is usually too simple to be used in a Production environment but can nevertheless form the basis of a more complex one. Private Sub Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load If Page.IsPostBack = False Then Dim FormKey As String Dim FormValue As String lblallformitems.text = "" lblallformkeys.text = "" For Each FormKey In Request.Form Next End If End Sub FormValue = Request.Form.Item(FormKey) If FormValue <> String.Empty Then lblallformkeys.text &= "<br><b>" & FormKey & ": </b> " lblallformitems.text &= "<br>" & FormValue End If Page 20 of 72

When the SENTRY response arrives at the response URL, the page_load event is fired. The event handler extracts the HTML form from the returned HTTP response, iterates over the form fields and prints the response field names and their associated values inside a ASP.NET web forms Label control. 1.4.3 Conclusion Readers should now understand the basic concepts of how to submit a transaction to SENTRY PG. If developers already have a Merchant Account, they should be able to send test transaction requests successfully. In the following sections readers will find information on all the functionality of SENTRY, such as selecting and using Direct or Redirect method, passing Airline or Order Details data to SENTRY PG, performing AVS checking (only if supported by Acquiring Host), recurring transactions, instalments, submit batch files, etc. Page 21 of 72

2. Getting Started with Merchant Administration Every merchant has access to the Merchant Administration module of SENTRY PG that can be viewed and edited. The system designed for ease of use. Each merchant user that uses the system has a unique login id and password used to access the system. The merchant s Processor/Acquirer will provide the merchant with an administrative user login id and password once the merchant account has been created in SENTRY PG. Upon logging in for the first time, users are prompted to change their password to an alphanumeric value. Merchant users must keep the login ID and password in a secure place and refrain from distributing it to anyone who does not need access to the merchant account interface. To log in to the system, users must first have access to the World Wide Web on the Internet. Once a user is online, they can open their Internet browser and login to the Merchant Administration application by accessing the following URL: https://<your Provider URL>/SENTRY/PaymentGateway/Merchant/Administration The <your provider URL> is the fully qualified domain name of the merchant s Processor/Acquirer. The channel is secured using 128-bit encryption with HTTPS over TLS or SSL3. 2.1 The Merchant Menu The first time a users logs on to the system, they are be required to change your password from the one that the provider has given you. Once the user modifies the password, they will have full access to the system, which starts with the Merchant Menu. The Merchant Menu is the central area from which users can access the system s configuration, reporting, and processing features. Please refer to the Merchant Administration s User Guide available from your provider. This document contains all the information users need in order to understand the various options available inside the Merchant Administration application. The remainder of this document will be primarily concerned with technical implementation and integration of a merchant s Web site with the SENTRY PG system. 2.2 Merchant Account Note The terms and conditions of the Merchant Account must be kept strictly confidential between the merchant and the processor and they should be consulted for specific information related to the merchant s account. A Merchant Account is required to accept credit cards through the application. A Merchant Account is a special account with an Acquiring Institution (or Processor), which must be a member of the payment association (e.g. VISA, MasterCard) for which the merchant wishes to process transactions. The Acquiring Institution (or Processor) will: Assign the merchant a Merchant Account Number (Merchant Id) Set up the merchant s SENTRY account Assign the merchant an Administrator Login Id and password for the Merchant Administration Web application. Act as the merchant s main point of contact for issues regarding the Merchant Administration access, and SENTRY account. Work with the merchant to configure the merchant s account. Page 22 of 72

Once the Merchant s Account is set up and becomes live on the system, the merchant can begin to accept credit Production transactions from customers. 2.3 What s next? At this point, merchant developers should have: 1. A merchant account able to process test transactions (if you don t yet have a SENTRY account, contact your Acquirer/Processor). 2. Familiarity with how credit card processing works. 3. A basic understanding of SENTRY architecture. 4. Access to the Internet. The guide will help merchant developers determine how SENTRY can best be integrated into the merchant s checkout environment. Basically, if the merchant does not operate a web-based checkout from which users can purchase products, then they can use the Virtual POS or the Batch File options. If a merchant operates a website from which cardholders can purchase products, then developers are invited to use either SENTRY Direct Link or SENTRY Redirect Link methods, depending on the agreement the merchant has made with their Processor/Acquirer. Page 23 of 72

3. Processing Methods SENTRY PG offers a number of methods for integration with the merchant s checkout system. The method of integration depends on your developer(s) skills and environment you want to build. 3.1 SENTRY PG Integration Methods As was mentioned above SENTRY PG supports several methods of processing e-commerce transactions and for each method there are a number of optional fields that can be used to customize each request to your individual needs. The main transaction engine is made up of several request listeners, implemented as HTTP handlers within SENTRY Checkout Application. The application also supports other transaction entry points like Web Services, and batch files (plain text files that carry many transactions, processed as a batch). The supported interfaces are listed below. Virtual POS (Merchant Administration module web screens) HTTP Handlers (Handlers are explained in more detailed in Section Hander Details ) o Redirect Link (Authorization with 3D Secure (SENTRY MPI) or Authorization only. Depending whether merchant is enrolled for 3Dsecure). URL to post is RedirectLink.aspx o Direct Link with 3D Secure (SENTRY MPI). URL to post to is DirectAuthLink.aspx o Direct Link without 3D Secure (Authorization Only, no 3D Secure). Offers high-throughput, low latency processing. URL to post is DirectAuthzLink.aspx. o Direct Link with 3D Secure (using an external MPI). URL to post is DirectAuthztpLink.aspx o Financial Link handler. Offers an HTTP-based interface for merchants to submit reversals, refunds and captures for existing original transactions. URL to post is FinancialLink.aspx. Web Services o Available Store Front Services List transactions Refund transactions Reverse transactions Capture transactions Batch Files o Authorization o Capture o Authorization + Capture (single action) o Refund o Reversal o Installment o Recurring These methods can be used on their own or in combination. For example the merchant can use the Redirect Link for all your transactions, 3-D Secure or not. Alternatively you can use the Redirect Link to complete the 3-D Secure Authentication cycle and then depending on the response you can decide whether to send the authorization using the Direct Method. Another combination could be to use the Direct Link with 3-D Secure for authentication only and then follow with the Direct without 3-D Secure to do the authorization. Another approach for Merchants operating their own MPI is to send authorizations through one host but use another host for their 3-D Secure Authentication. This works by using an external MPI to perform the 3D-Secure Authentication, and Page 24 of 72

then use the Direct Link with external MPI handler to pass the authentication data (ECI, CAVV) to initiate the Authorization with SENTRY. The supported interfaces are detailed in the following sections. 3.2 Virtual POS and MOTO transactions The Virtual POS is used for manual key entry of transactions using the Merchant Administration web interface. The effect of the Virtual POS is similar to the normal Point of Sale of a Credit Card terminal. You might need to use the Virtual POS for cases such as if: You received an order by phone, fax, or mail and need to process the transaction. You previously received a voice authorization by phone and now need to submit the transaction for capture. This type of transaction is known as a Mail Order/Telephone Order transaction (MOTO). The Virtual POS allows the merchant to either authorize only and capture later, or to do a full authorization and funds capture with a single transaction. This option does not require the merchant to have a Web site to use Virtual POS. The merchant can log in to the Merchant Administration web site and choose MOTO option on the Merchant Menu. 3.3 Connecting with SENTRY PG 3.3.1 Overview of SENTRY PG Handler Methods Sending order requests to the SENTRY PG Checkout Application is done over two different types of connectivity; both types require familiarity with Web Programming: 1. Direct Link 2. Redirect Link The capabilities offered under each method are listed below: Channel 3D-Secure Authentication supported Plain Authorization supported 3D-Secure Authorization supported (using SENTRY MPI) 3D-Secure Authorization supported (using 3 rd party MPI) Direct Link Yes Yes Yes Yes Redirect Link Yes Yes Yes No Under the Direct Link, a customer's Web browser makes a secure connection to the merchant s server and transmits all of the information necessary to process the transaction (including credit card details) when the shopper is ready to checkout. The merchant s server connects securely to the SENTRY PG web server, and transmits all of the transaction information in a Web Request (via HTTPS) by POSTing an HTML form to the gateway for processing. The gateway server returns the results of the transaction processing to the merchant s server over a secure connection. The merchant can then determine an appropriate response to the customer by interpreting the results of the transaction. Under the Redirect Link, the customer's interaction takes place with the SENTRY Payment Gateway web server. The merchant s Web page initiates a transaction by posting an HTML form to the SENTRY PG server with the required transaction information (amount, currency, item description, and so on), but without any card details. The cardholder is presented with a Checkout Page, and provides card details (number, expiry date, CVV2) to the SENTRY Payment Gateway server. The SENTRY PG server processes the transaction, and then transmits the results of the transaction to the merchant s server over HTTPS. Page 25 of 72

3.4 Choosing a method Both methods provide ways for developers to integrate transaction processing into whatever programs or databases they desire. However, one method might be better suited for certain environments than another. The main factor that determines which method to use will be the merchant s ability to make secure encrypted connections, and to a lesser degree the security requirements of the Acquirer/Processor. The Direct Link method will generally be more suitable than the Redirect Link method because of the greater control it gives developers over the whole transaction process flow. However, a developer won't be able to implement the Direct Link method unless they can provide a secure server side connection and initiate a secure client side connection when they send the transaction information to the gateway server (mutual SSL). This connectivity type requires the merchant s web server to be configured with a server SSL certificate, in order to secure the channel between the cardholder s browser and the merchant s checkout page. Also, an outgoing request from the merchant s server needs to carry a client SSL certificate to establish mutual SSL with the SENTRY PG web server. Implementing client side secure connections is made easier by using some of the readily available tools and libraries for implementing protocols like SSL. However, if it's not possible to create a secure connection on both the server and client sides of the link, the Redirect Link method provides an alternative where sensitive data such as credit card numbers is only transmitted across the secure link between the SENTRY gateway server and the cardholder's browser. To summarize: 1. If you can write a script that can process information sent via an HTTP form POST, then you might want to consider using Redirect Link method. 2. If you can write a script that can process information sent via an HTTPS form POST, AND you can provide a secure server side connection and initiate a secure client side connection, then you might want to consider using Direct Link Response. Please note that the Acquirer/Processor may not allow you to use the Direct Link method. Also, in the case of 3-D Secure, the Redirect Link method is most likely going to be used. Before choosing an integration method, check with your Payment Provider. 3.5 Overview of SENTRY Direct Link The most flexible way to integrate the merchant s Web site with SENTRY PG is by using the Direct Link method. In order to integrate a merchant s checkout system with SENTRY PG using the Direct Link method, a developer must be able to provide server-side as well as client-side security for the connection. A developer would also need to be able to write scripts or develop programs for their Web server to provide the necessary integration. As seen from the Integration Methods Section, there are a number of different Direct Handlers for different operations. To implement the simplest of the Direct Link methods (authorization only, non-3ds): 1. A developer would design a checkout system that can securely obtain all of the information needed to process a transaction. 2. The developer would initiate a secure HTTPS form POST from their server to SENTRY Direct Link Web Handler (DirectAuthZLink.aspx). 3. The SENTRY Checkout Application would process the transaction and respond with the results to the merchant s checkout system, which will then display the appropriate results to the cardholder. The fields contained in the posted form would be all of the information necessary to process a transaction, plus a couple of additional fields. Page 26 of 72

3.5.1 Example Minimum requirements for Direct Link Method The minimum information present in the script the merchant developer needs to produce for using Direct Link is listed below. The SENTRY PG checkout screen is not available under Direct Link, therefore the merchant must capture the Card Number and Expiration Date on their side before submitting the order request. Note that the merchant response listener URL is not contacted by SENTRY when responding with processing results. Therefore, the MerRespURL field is not mandatory in the order request for a Direct non-3ds Authorization. Depending on the Payment Processor s requirements, the merchant might need to capture the card s CVV/CVC2/CID code and also AVS or IAVS data. The Merchant must be able to establish an SSL connection and provide both client-side and server-side encryption when using this method. The merchant order request typically includes the following name/value pairs. All fields are mandatory unless otherwise stated. Name Value Version 1.0.0 MerID The Merchant ID assigned by the Acquirer/Processor AcqID PurchaseAmt PurchaseCurrency PurchaseCurrencyExponent OrderID Signature CardNo CardExpDate CardCVV2 * The ID of your Acquirer supplied by the Acquirer/Processor. Purchase Amount as calculated by merchant s checkout system The currency value of the purchase in ISO Numeric value. Only values permitted by acquirer are allowed. The number of decimal digits of the purchase currency. The transaction ID of the order that uniquely identifies the transaction in the merchant s system. The hash signature computed for the order request Customer s card account number Customer s card expiration date. Customer s card code value. * Presence of this field is conditional, depending on Provider s requirements/settings. Please check with Acquirer/Processor. The following code sample shows how a developer can connect the merchant s host to the SENTRY Payment Gateway. The first example is a.net Framework code is using VB.NET on an ASPX page s Submit button, and assumes that the merchant is not enabled for 3-D Secure Processing. Page 27 of 72

Example 1 (Authorisation only) (DirectAuthZLink.aspx) Private Sub Send_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Send.Click Dim ReqString As String = Nothing Dim MerchantHash As String = String.Empty ReqString = "Version=1.0.0 ReqString &= "&MerID=0009999012 ReqString &= "&AcqID=459898 ReqString &= "&PurchaseCurrency=196 ReqString &= "&PurchaseCurrencyExponent=2 ReqString &= "&OrderID=SEN898989 ReqString &= "&SignatureMethod=SHA1 ' DIRECT METHOD, CARDS DETAILS ARE REQUIRED ReqString &= "&CardNo=4040888800008989" ReqString &= "&CardExpDate=0115 ReqString &= "&CardCVV2=345 ReqString &= "&PurchaseAmt=000000008000 MerchantHash = MERCHANTPWD & MERCHANTID & ACQUIRERID & ORDERID & PURCAMNT & PURCHCURRENCY ' Calculate the Hash with SHA... Dim Signature = ComputeHash(MerchantHash) Dim EncodedSignature As String = String.Empty EncodedSignature = System.Web.HttpUtility.UrlEncode(Signature) ReqString &= "&Signature=" & EncodedSignature ReqString &= "&CaptureFlag=M SendPOST(System.Web.HttpUtility.HtmlEncode(ReqString), HostUrl.Text.Trim, 15000, False, 4) End Sub Inc. and TSYS are federally registered service marks of Total System Services, Inc., in the United States. Total System Services, Inc., are trademarks or registered trademarks of their respective companies. Page 28 of 72

Public Function SendPOST(ByVal Data As String, ByVal HostUri As String, ByVal HostTimeout As Integer, ByVal IncludeLengthSize As Boolean, ByVal LengthSize As Integer) As String Dim ResultHTTPResponse As HttpWebResponse ServicePointManager.CertificatePolicy = New clscertpolicy() Dim Request As HttpWebRequest Dim RequestStream As Stream Dim ReceiveStream As Stream Dim encode As Encoding Dim sr As StreamReader If IncludeLengthSize = True Then End If Data = Data.Length.ToString.PadLeft(LengthSize, "0") & Data Request = WebRequest.Create(HostUri) Request.Method = "POST" Request.Timeout = HostTimeout Dim contype As String = "application/x-www-form-urlencoded" Request.ContentType = contype Dim SomeBytes() As Byte SomeBytes = Encoding.UTF8.GetBytes(Data) Request.ContentLength = SomeBytes.Length RequestStream = Request.GetRequestStream() RequestStream.Write(SomeBytes, 0, SomeBytes.Length) RequestStream.Close() ResultHTTPResponse = Request.GetResponse() Dim ResultString As String If ResultHTTPResponse.StatusCode = HttpStatusCode.OK Then ReceiveStream = ResultHTTPResponse.GetResponseStream() encode = System.Text.Encoding.GetEncoding("utf-8") sr = New StreamReader(ReceiveStream, encode) Inc. and TSYS (sample are federally continued registered service on next marks page) of Total System Services, Inc., in the United States. Total System Services, Inc., are trademarks or registered trademarks of their respective companies. Page 29 of 72

ResultString = sr.readtoend Else ' Error receiving response Throw New Exception("Unable to Send Request") End If Return ResultString 'Return back to parse message, check signature and result of the response End Function Inc. and TSYS are federally registered service marks of Total System Services, Inc., in the United States. Total System Services, Inc., are trademarks or registered trademarks of their respective companies. Page 30 of 72

In the second example (see next page), the merchant is using 3-D Secure to authenticate the cardholder. In this case the MerRespURL value is required in order to return back the result to the merchant. This is required because in order to do 3-D Secure Authentication the cardholder must be redirected to the Issuer s ACS for authentication, and after that is completed must somehow return back to the merchant s site (MerRespURL) in order to inform the merchant of the results of the transaction. 3.5.1.1 Displaying the ACS authentication window SENTRY supports two options for displaying the Issuer s ACS Authentication page (where the cardholder will enter their ACS password). The first option is inline, meaning the ACS authentication page in the same window as the rest of the web store or checkout page. The second one is by opening a pop-up window which is automatically closed when the Authentication is completed. Note that due to payment system requirements, only the inline method is allowed. The Acquirer/Processor will configure the SENTRY for inline display of the ACS authentication page. For the sake of completion, both options are illustrated. In the following code sample, the second method is used first (pop-up), and the necessary change for inline is described at the end of the sample. In order for this method to work properly and for the pop-up window to close automatically the name of the window has to be set to Merchant, as can be seen in the example. Inc. and TSYS are federally registered service marks of Total System Services, Inc., in the United States. Total System Services, Inc., owns a number of service marks that are registered in the United States and in other countries. All other products and company names are trademarks or registered trademarks of their respective companies. Page 31 of 72

Example 2 (DirectAuthLink.aspx) Popup method <HTML> <body> <form id= Merchant name= Merchant action= method= post > <noscript> <br> <br> </noscript> <h1 align= center >Processing your Transaction</h1> <h2 align= center >JavaScript is currently disabled or is not supported by your browser.</h2> <br> <h3 align= center >Please click on the Submit button to continue processing.</h3> <input type= submit value= Submit > <input id= Version type= hidden name= Version value= 1.0.0 > <input id= MerID type= hidden value= 0009999012 name= MerID > <input id= AcqID type= hidden value= 459889 name= AcqID > <input id= MerRespURL type= hidden value= https://www.acme.com/sentry/store/responsepage.aspx name= MerRespURL > <input id= PurchaseAmt type= hidden value= 000000001200 name= PurchaseAmt > <input id= PurchaseCurrency type= hidden value= 840 name= PurchaseCurrency > <input id= PurchaseCurrencyExponent type= hidden value= 2 name= PurchaseCurrencyExponent > <input id= OrderID type= hidden value= 307094242 name= OrderID > <input id= SignatureMethod type= hidden value= SHA1 name= SignatureMethod > <input id= Signature type= hidden value= L5H9kcZHgWXpXRguKKwVsxno6E4= name= Signature > <input id= CardNo type= hidden name= CardNo value= 4012001011000771 > <input id= CardExpDate type= hidden name= CardExpDate value= 0808 > Inc. and TSYS are federally registered service marks of Total System Services, Inc., in the United States. Total System Services, Inc., are trademarks or registered trademarks of their respective companies. Page 32 of 72

<input id= CaptureFlag type= hidden value= A name= CaptureFlag > </form> <script language= javascript > CheckOut(); function CheckOut(){ window.name = Merchant ; popupname = MPI ;childwin = window.open( about:blank, popupname, width=390, height=400, status=yes, scrollbars=yes, resizable=no, toolbar= no, location = no, directories = no, menubar = no ); </HTML> </body> </script> document.merchant.target = popupname; document.merchant.action = https://www.acme.com/sentry/paymentgateway/application/directauthlink.aspx ; document.merchant.submit(); } Inline method When the inline method is used, the window name should not be set to Merchant because this might cause the browser to close the checkout window. The only difference when using the Inline method would be in the Checkout() function in JavaScript, which should be: <script language='javascript'> CheckOut(); function CheckOut(){ document.merchant.action = 'https://www.acme.com/sentry/paymentgateway/application/directauthlink.aspx'; document.merchant.submit(); } </script> Inc. and TSYS are federally registered service marks of Total System Services, Inc., in the United States. Total System Services, Inc., are trademarks or registered trademarks of their respective companies. Page 33 of 72

3.6 Overview of SENTRY Redirect Link To implement the Redirect Link method, a developer would need to create an HTML form that would post all of the information needed to process a transaction to the system. The fields contained in the posted form would be all of the information necessary to process a transaction, minus the card detail fields. Once the gateway server receives all of the transaction information, the transaction is processed. Once the transaction is processed, an HTTPS form POST is sent to the MerRespURL specified, along with the results of the transaction. The receiving script or program at the merchant side listens for the results at the specified MerRespURL, and then decides what type of response to display to the cardholder s browser. 3.6.1 Example - Minimum Requirements for Redirect Link The following are the minimum requirements for an ADC Relay Response transaction. It assumes the merchant is using the generic Payment Form defined by the SENTRY provider. If the merchant does not wish to use the generic payment form, the merchant would then need to customize the Checkout page through a Variation Order. Name Value Version 1.0.0 MerID The Merchant ID supplied by the Acquirer/Processor AcqID MerRespURL PurchaseAmt PurchaseCurrency PurchaseCurrencyExponent OrderID Signature The ID of the merchant supplied by the Acquirer/Processor. The response URL for sending the result back to the merchant Purchase Amount as calculated by the merchant s checkout system The currency value of the purchase in ISO Numeric value. Only values permitted by acquirer are allowed. The number of decimal digits of the purchase currency. The transaction ID of the order that uniquely identifies the transaction in the merchant s system. The hash signature for the order request The following code sample is written in VB.NET. It prepares a String containing all the necessary HTML code to place an order request: it contains the mandatory Redirect fields and their values, along with a Javascript function that submits the HTML form to the SENTRY PG listener URL (in the sample, the URL comes from a textbox located on the webpage). The string containing the HTML form and javascript is then written directly to the output stream of a.net HttpResponse object and is flushed to the browser, which then executes the javascript and submits the HTML form to SENTRY PG for processing. NOTE: The limitation of this approach is that if browser has disabled javascript, this code will not function properly. It is assumed that the merchant developer is aware of the appropriate coding approach to use. Inc. and TSYS are federally registered service marks of Total System Services, Inc., in the United States. Total System Services, Inc., owns a number of service marks that are registered in the United States and in other countries. All other products and company names are trademarks or registered trademarks of their respective companies. Page 34 of 72

Private Sub Send_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Send.Click Dim ReqString As String = Nothing Dim PurcAmount As String = GetAmtFillZeros(PurchaseAmount.Text.Trim) Dim GOrderId As String = GenerateOrderId() ' Calculate the Hash with SHA... Dim MerchantHash As String MerchantHash = MerchantPassword.Text.Trim & MerchantId.Text.Trim & AcquiredId.Text.Trim & GOrderId.Trim & PurcAmount.Trim & PurchaseCurrency.Text.Trim Dim Signature = Me.ComputeHash(MerchantHash) ReqString = "<HTML><body><form id='frmhtmlcheckout' name='frmhtmlcheckout' action='' method='post'>" & vbnewline ReqString &= "<input id='version' type='hidden' name='version' value='" & Version.Text.Trim & "'> " & vbnewline ReqString &= "<input id='merid' type='hidden' value='" & MerchantId.Text.Trim & "' name='merid' > " & vbnewline ReqString &= "<input id='acqid' type='hidden' value='" & AcquiredId.Text.Trim & "' name='acqid' > " & vbnewline ReqString &= "<input id='merrespurl' type='hidden' value='" & MerRespUrl.Text.Trim & "' name='merrespurl'> " & vbnewline ReqString &= "<input id='purchaseamt' type='hidden' value='" & PurcAmount.Trim & "' name='purchaseamt'> " & vbnewline ReqString &= "<input id='purchasecurrency' type='hidden' value='" & PurchaseCurrency.Text.Trim & "' name='purchasecurrency'> " & vbnewline ReqString &= "<input id='purchasecurrencyexponent' type='hidden' value='" & PurchaseCurrencyExponent.Text.Trim & "' name='purchasecurrencyexponent'> " & vbnewline ReqString &= "<input id='orderid' type='hidden' value='" & GOrderId.Trim & "' name='orderid' > " & vbnewline ReqString &= "<input id='signaturemethod' type='hidden' value='" & SignatureMethod.Text.Trim & "' name='signaturemethod'> " & vbnewline ReqString &= "<input id='signature' type='hidden' value='" & Signature & "' name='signature'> " & vbnewline vbnewline ReqString &= "<input id='captureflag' type='hidden' value='" & CaptureFlag.Text.Trim & "' name='captureflag' > " & (sample continued on next page) Inc. and TSYS are federally registered service marks of Total System Services, Inc., in the United States. Total System Services, Inc., are trademarks or registered trademarks of their respective companies. Page 35 of 72

ReqString &= "</form>" & vbnewline ReqString &= "<script language='javascript'> " & vbnewline ReqString &= " CheckOut(); " & vbnewline ReqString &= "function CheckOut(){" & vbnewline ReqString &= "document.frmhtmlcheckout.action = '" & SentryHostUrl.Text.Trim & "'; " & vbnewline End If End Sub ReqString &= "document.frmhtmlcheckout.submit();" & vbnewline ReqString &= "}</script></body></html>" & vbnewline Response.Write(ReqString) Response.Close() Page 36 of 72

3.7 SENTRY Batch Transaction Processing SENTRY PG supports transaction processing in offline batch mode. Merchants have the option to submit batch files to the SENTRY PG web server using the Merchant Administration Site. The Web Server parses the batch file and if there is no parse error, the resulting data is passed to the Application Server for further processing & validation. Both parsing and processing of the file is done in a scheduled time defined by the Acquirer/Processor, typically this is during off-peak hours. If validation is successful, then transaction processing begins. If there is an error during parsing or validation, an error report is produced in order to inform both the merchant and the Acquirer about the batch file errors encountered. The status and result of a batch file can be viewed from the both the Merchant Administration Application. The batch file parser currently supports six different types of records which offer merchants the ability to: Submit authorization request Capture authorization request Reverse authorization request Refund authorization request Submit and Capture authorization request (using a single message) Submit instalment request Submit recurring request 3.7.1 Uploading batch files The process of uploading a batch transaction file is initiated from the Batch File Upload to Acquirer option in the Merchant Administration option tree. Please refer to Merchant Administration User Guide for further details. 3.7.2 Data Validation When a batch file is uploaded to the system various validations are performed to determine that the file contains correct transaction data. The system will check to make sure that the file format is correct, and also validate the batch file s signature (optional). If any errors in the file or signature are encountered, the Batch File Parser will create a report on which lines had errors so that the file can be corrected and reuploaded. 3.7.3 Batch file processing Upload files will be queued to be processed at a scheduled time set by the provider. Transactions that require authorization are authorized during this process. When processing is finished, the system inserts the transactions in the database as part of the current batch of unsettled transactions. 3.7.4 Checking the status of an uploaded batch file From the Merchant Administration site, the merchant has the capability to check on the status of a file uploaded previously. Please refer to the Merchant Administration User Guide for further details. 3.8 File Format SENTRY PG Batch Files must be saved with the extension, ubf. The Batch File must start with the MDET record and must end with an EOF record. Record fields are pipe-delimited ( ). Page 37 of 72

3.8.1 Sample Batch File MDET 99999948 409638 99999948033502 AUTH 4012001012000754 1212 456 000000001200 978 54784215 AUTH 4012001012000754 1212 456 000000008900 978 78945412 AUTH 4012001012000754 1212 456 000000004500 978 45421123 EOF 3.8.2 Merchant Details MDET This record is mandatory and must be the first line of the batch file supplying the necessary information about the merchant. Field Name Type Description MDET char(4) Record Type merid Numeric(15) Merchant Id supplied from Acquirer acqid Numeric(11) Acquirer Id supplied from Acquirer fileid char(18) fileid must be unique per file. 3.8.3 Authorization Request AUTH This record is used for sending an offline authorization request. This type of authorization is not captured automatically. Field Name Type Description AUTH char(4) Record Type cardnumber numeric(25) Account performing the transaction cardexpirydate numeric(4) Date in format MMYY cardcvv2 numeric(3) CVV2/CVC2 as printed on the back of the card below the magnetic stripe if provided by cardholder transactionamount numeric(12) Transaction amount, decimals implied, i.e. for $ 12.34, the field will be set to 000000001234 transactioncurrency Char(3) ISO Alpha code for the transaction currency used during the transaction orderid alphanumeric (150) A unique value identifying the transaction in the merchant checkout system. 3.8.4 Refund Request REF This record is used for sending Refund transactions on an original authorization. This transaction will give a credit to the cardholder s account. Page 38 of 72

Field Name Type Description REF char(3) Record Type cardnumber numeric(25) Account to offer the refund cardexpirydate numeric(4) Date in format MMYY cardcvv2 numeric(3) CVV2/CVC2 as printer on the back of the card below the magnetic stripe if provided by cardholder. transactionamount numeric(12) Transaction amount decimals implied, i.e. for $ 12.34, the field will be set to 000000001234 transactioncurrency char(3) ISO Alpha code for the transaction currency used during the transaction orderid alphanumeric (150) A unique value identifying the transaction in the merchant checkout system. authorizationnumber char(6) The authorization Id of the original authorization. 3.8.5 Reversal Request REV This record is used for reversing (voiding) a previously approved authorization. This transaction will cause a credit to the cardholder s account. Field Name Type Description REV char(3) Record Type cardnumber numeric(25) Account used during authorization. cardexpirydate numeric(4) Date in format MMYY cardcvv2 numeric(3) CVV2/CVC2 as printer on the back of the card below the magnetic stripe if provided during authorization transactionamount numeric(12) Transaction amount decimals implied, i.e. for $ 12.34, the field will be set to 000000001234 transactioncurrency char(3) ISO Alpha code for the transaction currency used during the transaction reversalamount numeric(12) Amount to be reversed with decimals implied. orderid alphanumeric(150) A unique value identifying the transaction in the merchant system. This must be the same as the original authorization orderid. authorizationnumber char(6) The authorization Id of the original authorization. If reversalamount is equal to transactionamount we have a full reversal. The reversalamount must be less than, or equal to transactionamount. 3.8.6 Capture CAPT This record is used to settle a previous authorization. Upon shipping of goods, merchant can submit records for capturing using this record. Page 39 of 72

Field Name Type Description CAPT char(4) Record Type cardnumber numeric(25) Account used during authorization. cardexpirydate numeric(4) Date in format MMYY cardcvv2 numeric(3) CVV2/CVC2 as printer on the back of the card below the magnetic stripe if provided during authorization transactionamount numeric(12) Transaction amount decimals implied, i.e. for $ 12.34, the field will be set to 000000001234 transactioncurrency char(3) ISO Alpha code for the transaction currency used during the transaction captureamount numeric(12) Captured amount decimals implied, i.e. for $ 12.34, the field will be set to 000000001234 captureclose char(1) If set to 1, the transaction will be captured and closed for further processing. orderid alphanumeric (150) A unique value identifying the transaction in the merchant system. This must be the same as the original authorization orderid. authorizationnumber char(6) The authorization Id of the original authorization. If captureamount is equal to transactionamount, then the transaction will be captured and closed. If these values are not the same, then if captureclose is set to 1, the authorization will be partially reversed and the remaining amount will be captured for settlement. Otherwise, the transaction will remain for further processing. The captureamount must be less than, or equal to the transactionamount. If the values are equal it implies the current total amount captured. 3.8.7 Authorization Request/Capture AUTHC This record is used to send an offline authorization request and flag it for automatic (immedaiate) capture. Also with this record, a merchant can schedule a recurring transaction. If recurrence is required, and no datetorecurr is provided, then SENTRY PG will use the batch file submission date. For example, if a file was submitted on 15-07-2013 (DD-MM-YYYY) then this will be the recurrence date for the subsequent transactions. Also, SENTRY will check if the card will not expire before the last execution. If the card expires before all recurrings have completed, the transaction will be rejected. Field Name Type Description AUTHC char(5) Record Type cardnumber numeric(25) Account performing the transaction cardexpirydate numeric(4) Date in format MMYY cardcvv2 numeric(3) CVV2/CVC2 as printer on the back of the card below the magnetic stripe if provided by cardholder transactionamount numeric(12) Transaction amount decimals implied, i.e. for $ 12.34, the field will be set to 000000001234 captureamount numeric(12) Captured amount decimals implied, i.e. for $ 12.34, the field will be set to 000000001234 Page 40 of 72

Field Name Type Description transactioncurrency char(3) ISO Alpha code for the transaction currency used during the transaction orderid alphanumeric (150) A unique number identifying the transaction in the merchant system. numberofrecurrences numeric(3) Present if recurrence is required. This indicates how many times this transaction will be executed. frequency char(1) Present if recurrence is required. This indicates how recurrence will occur. D daily W weekly F fortnight M monthly E every other month Q - quarterly Y yearly executiondate Numeric(8) Date in format YYYYMMDD 3.8.8 Instalments INST This record is used to send an instalment request. If the installment is to be handled by the Acquirer, then SENTRY will use the batch file submission date for the installment. Also, SENTRY will check if the card will not expire beyond the requested period of execution, otherwise, the transaction will be rejected. If the installment is not offered by the Acquirer, then the full amount will be authorized and submitted for capture. Field Name Type Description INST char(4) Record Type cardnumber numeric(25) Account performing the transaction cardexpirydate numeric(4) Date in format MMYY cardcvv2 numeric(3) CVV2/CVC2 as printer on the back of the card below the magnetic stripe if provided by cardholder netamount numeric(12) Purchase amount plus the calculated interest with decimals implied. installmentamount numeric(12) Installment amount decimals implied. This is basically the total amount divided by the number of installments transactioncurrency char(3) ISO Alpha code for the transaction currency used during the transaction orderid alphanumeric (150) A unique number identifying the transaction in the merchant system. amounttouse char(1) 1 - Acquirer handles the installment 2 Issuer handles the installment Page 41 of 72

Field Name Type Description If set to 1, then a recurrence will be created by the system numberofinstallments numeric(3) This indicates the number of installments. frequency char(1) Present if recurrence is required. This indicates how recurrence will occur. D daily W weekly F fortnight M monthly E every other month Q - quarterly Y yearly executiondate numeric(8) Date in format YYYYMMDD Page 42 of 72

Advanced Topics 3.8.9 Sending Order Details with merchant request SENTRY PG allows merchants to send informative items associated with an order such as order line items, unit price, quantity etc, at the same time the order is submitted. Merchants can send this extra information in their order request and SENTRY PG will store them. In order to send these values, there are some special fields that have to be populated correctly by the merchant. First the OrderDetails field expects a Y or an N, which indicates whether or not there are Order Details in the request. Secondly there is the number of Order Detail lines which is read from the NoOfItems fields. This has to be set to the number of items purchased in the request. Finally the actual line information is stored in several other fields, namely: ItemDescriptionx, ItemQuantityx, ItemUnitPricex, and ItemTotalPricex. The x at the end of these fields must be replaced with the number of the particular order detail line. For example, the third line item sent by the merchant should have the following fields set: ItemDescription3, ItemQuantity3, ItemUnitPrice3 and ItemTotalPrice3. Let s take an example to make this clearer. A customer visits the merchant s webstore and buys three books: Book A which costs $10, Book B which costs $20, Book C which costs $60. The merchant must set the order fields as follows: For BookA: For BookB For BookC the OrderDetails field to Y, the NoOfFields to 3, the ItemDescription1 to Book A, the ItemQuantity1 to 1, the ItemUnitPrice1 to 10, the ItemTotalPrice1 to 10, the ItemDescription2 to Book B, the ItemQuantity2 to 1, the ItemUnitPrice2 to 20, the ItemTotalPrice2 to 20, the ItemDescription3 to Book C, the ItemQuantity3 to 60, the ItemUnitPrice3 to 60, the ItemTotalPrice3 to 60. The items in tabular form look like this: Name Value OrderDetails Y NoOfItems 3 ItemDescription1 Book A ItemQuantity1 1 ItemUnitPrice1 10 ItemTotalPrice1 10 ItemDescription2 Book B ItemQuantity2 1 ItemUnitPrice2 20 ItemTotalPrice2 20 ItemDescription3 Book C ItemQuantity3 1 ItemUnitPrice3 60 ItemTotalPrice3 60 Please notice that x the number after each field in the first set for Book A is set to 1 the second is set to 2 and so on. This has to be done in order to distinguish the different lines in the Order Details. Page 43 of 72

Therefore if you have 9 lines in the Order Details that you want to submit you have to send the ItemDescriptionx and ItemQuantityx etc for lines 1 through 9 (where is x will be 1 for the first item 2 for the second and 9 for the last). 3.8.10 Sending Additional Order Details with merchant request SENTRY allows merchants to send additional details about the order, such as special comments or requests for the particular order, at the same time the order is submitted. The possibility exists to view Additional Details data for a given merchant s orders, through the Merchant Administration application (available upon request). To send this data, a merchant needs to populate certain order fields correctly. First the AdditionalDetails field expects a Y or an N, which indicates whether or not there are Additional Details in the request. Secondly there is the number of Additional Detail lines which is read from the NoOfFields field. This has to be set to the number of lines that are included in the request. These items are sent as key/value pairs. The actual line information is stored in two fields, the FieldDescription and the FieldValue. The FieldDescription holds the field s name (used as a key) for that particular line and the FieldValue is the actual value or comment for example. As with the previous interface for the Order Details, here too there is a number following each FeildDescription/FieldValue that is used to differentiate between lines. Please note that after the FieldDescription and FieldValue the number that follows is the number of the particular line item. This number should start at 1 and be continuous up to the number of lines of additional details, just like the Order Details format. 3.8.11 Airline Ticket Order Updates SENTRY PG offers an HTTP listener interface, used to update a previously submitted order with data related to an airline ticket. The request is submitted using a secure HTTPS form POST from the merchant server to the SENTRY PG AirlineTicketOrderUpdate Web Handler. The method is similar to the second Direct Link example above with no need for a MerRespURL, since the result is posted and an immediate response is received. SENTRY will process the request, associate the relevant order with the airline ticket information submitted, and respond to the merchant with the result of the operation. The necessary airline fields required in the order request are presented in Appendix A. A hash signature is required for authenticating the request to the SENTRY system. 3.8.12 Recurring Transactions Recurring transactions are basically Authorization and Capture requests that occur multiple times. For example if you sell magazine subscriptions, then you can use recurring transactions to enable recurring payment of the subscription fee. A recurring transaction has an expiry date and a frequency period. If the magazine subscription from the above example is monthly and the subscription duration is yearly, then you can send a recurring transaction requests for the monthly fee, with an expiry date a year from today and a frequency of one month. These transactions are sent like normal transaction requests, except the appropriate order fields be sent with the initial request. For a list of the required fields for submitting recurring transactions, please refer to Appendix A. After a recurring transaction is recorded, it can be maintained and monitored from the Merchant Administration application. Note Recurring Transactions are not supported by all processors, acquirers or issuers. Merchants interested in this type of functionality should consult their SENTRY provider on availability. Page 44 of 72

3.8.13 Instalment Transactions Instalment transactions are similar to loan instalments. Basically there is an authorization for the full amount at the initial authorization request, and every so often there is a capture transaction that occurs in order to collect the particular instalment amount. For a list of the required fields for submitting instalment transactions, please refer to Appendix A. By sending these extra fields, a merchant informs SENTRY Payment Gateway that this transaction is an instalment transaction, for the particular amount and particular frequency (default is monthly). Note Instalment Transactions are not supported by all processors, acquirers or issuers. Merchants interested in this type of functionality should consult their SENTRY provider on availability. 3.8.14 Handler Details Throughout the Developer s Guide, references have been made to listeners (or handlers), which are responsible for processing merchant orders and requests. This section lists the available handlers and describes what they do, as well as when and how they are used. An HTTP Handler (also referred to as Listener) in the SENTRY world is essentially a web page. When loaded, it will read all the data contained in the HTTP request that it received, and will process the particular request as per the logic programmed into it. The SENTRY PG handlers expect HTTP requests to be POSTed to them. The incoming requests have to include the various order fields as form fields. The following fields are mandatory for all Handlers: Name Value Version 1.0.0 MerID AcqID PurchaseAmt PurchaseCurrency PurchaseCurrencyExponent OrderID Signature Merchant Id (As given by your provider) Acquirer Id (As given by your provider) Purchase Amount Currency of the purchase amount. (ISO Numeric Value) Purchase currency decimal digits. Order Id that uniquely identifies the transaction is the Merchant System. Hashed Signature Supported handlers are described below, along with usage scenarios and the extra fields that they expect. 3.8.14.1 DirectAuthLink The DirectAuthLink can be used to process authorization requests without 3-D Secure. Being a Direct Link handler, it expects to receive all the necessary transaction information and card details (card number, expiry date, CVV2 if required). When it completes processing, it returns the basic response fields such as Page 45 of 72

the response code, the auth. Code, among others. In order to process transactions through this Handler, merchants need to include the following fields in addition to the mandatory Direct Link fields: Name CardNo CardExpDate CardCVV2 Value The Card Number The Card Expiry Date in MMYY format The card verification value is optional if allowed by your provider, or mandatory if required by your provider 3.8.14.2 DirectAuthztpLink The DirectAuthztpLink can be used to process 3-D Secure authorization requests with 3-D Secure data collected outside of SENTRY PG before the order request is submitted, with a 3 rd party MPI. It works just like the DirectAuthLink but it expects the extra 3-D Secure data to be passed to it as well. Name CardNo CardExpDate CardCVV2 * TransactionStain ECIIndidator AuthenticationResult CAVVValue Value The Card Number The Card Expiry Date in MMYY format The presence of card verification value is conditional, depending on the SENTRY provider s requirements The Transaction Stain or XID is a number generated by MPI to track the PaReq messages. The ECI (Electronic Commerce Indicator) is a code used to indicate the status of the Authentication (3-D Secure) to the Authorization host. This is the response received by the MPI during the VeRes or PaRes response. It can be set to A, N, Y or U The CAVVValue is the Card Authentication and Verification Value generated by the cardholder s Issuer to prove that Authentication (or Attempt Authentication) occurred. Depending on the status of the messages that MPI sends during the Authentication phase, the values in the table above might not exist. Also there are only a few combinations of the fields allowed since the rest are not valid. The following table explains the different possible combinations: VISA ECI Mastercard ECI AuthenticationResult Explanation 05 02 Y This means that the Authentication was completed successfully since the card holder entered the correct password on the Issuer. The CAVV and XID should be present in the order request. 06 01 A This means that the card was set up for Attempt Authentication on the Issuer and no card holder s interaction was required. The CAVV and XID should be present in the order Page 46 of 72

VISA ECI Mastercard ECI AuthenticationResult Explanation request. 06 01 N This means the merchant attempted to do 3-D Secure Authentication but the card holder or the Issuer was not participating in the program (card or bin not enrolled). Since no PaReq was ever send then there is no CAVV or XID available, and they should not be present in the request. 07 00 U This means that there was a problem somewhere in the Authentication cycle and the MPI received an ECI value of 07/00. The CAVV and XID can be included depending on where in the cycle the process failed and whether the MPI returned these values. 3.8.14.3 DirectAVSLink Address Verification Service is used mainly in the US to verify the address information of the card holder as an additional verification measure before proceeding to the authorization. This handler can be used to perform AVS-only checks and depending on the response, a merchant can choose whether or not to proceed with authorization or not. The DirectAVSLink is very similar to the DirectAuthLink handler, but instead of authorization it performs an Address Verification check. The main difference in the order request is that the merchant has to set the PurchaseAmt to 000000000000 and also include the Billing Address information (see Appendix A). Please note that the Acquirer/Processor authorization host must support AVS functionality, otherwise this handler cannot be used. Name CardNo CardExpDate CardCVV2 * Value The Card Number The Card Expiry Date in MMYY format The presence of card verification value is conditional, depending on the SENTRY provider s requirements 3.8.14.4 DirectAuthzLink The DirectAuthzLink can be used to process authorization requests with 3-D Secure Authentication using the SENTRY MPI. The handler can also be used to carry out only the 3-D Secure Authentication cycle (set AuthenticationOnly order field to Y ). This Handler expects to receive the card s details, and unlike the Direct Authorization-Only handler, this handler expects to receive the MerRespURL value. Name CardNo Value The Card Number CardExpDate The Card Expiry Date in MMYY format Page 47 of 72

Name CardCVV2 * MerRespURL Value The presence of card verification value is conditional, depending on the SENTRY provider s requirements The merchant s response page where the SENTRY Payment Gateway will redirect the card holder after the transaction is completed. 3.8.14.5 RedirectLink The Redirect Link can be used to process non-3dsecure Authorization requests, Authentication requests (3-D Secure) or a combination of both (full 3D-Secure Authorization), by using the SENTRY Checkout Page instead of the merchant s own checkout system. The merchant is not required to submit the card details in the order request; the card details will be supplied by the cardholder. Name MerRespURL Value The merchant s response page where the SENTRY Payment Gateway will redirect the card holder after the transaction is completed. 3.8.14.6 FinancialLink The FinancialLink is a special Handler that can Capture, Refund or Reverse already submitted transactions. It was intended as an interface for merchants wishing to integrate with a pure HTTP-based API instead of the Store Front Web Services. To choose between the actions to be performed on the transaction, merchants set the value of the Action field. The Action field can be set to Capture, Refund or Reverse. There is also an extra field called Amount which is the amount of the action to be performed. Decimals are implicit for this field. For example if a merchant wishes to refund $20 for a particular transaction, they can set the request s Action field equal to Refund, and the Amount field to 000000002000. Name Action Amount Value This is the action to perform on the transaction. Allowed values are Capture, Reverse or Refund. This is the amount of the action to be performed on the transaction. It has the same 12 digit format as the Purchase Currency. Decimals are implicit 3.8.15 Incoming/Outgoing Signature or Response Fields Customization Just as SENTRY PG expects certain fields in the incoming order request, it responds to requests with similar fields. All incoming requests must have a signature, used to validate the data provided in the order request. Outgoing responses also carry a signature that merchants can use to validate the response data for legitimacy (i.e. that it comes from the legitimate Acquirer/Processor). In order to provide the most flexible and secure system available, SENTRY allows merchants to specify both incoming and outgoing signatures, and decide which fields to receive in the response. This functionality is controlled using Bitmaps. A bitmap is basically the summation of several specific numbers that encode which fields are present in a particular message. Page 48 of 72

Please refer to the BitMapSIn field description in Appendix A to see the available fields for composing the incoming signature seed value. The signature consists of some mandatory fields that cannot be left out (Password, Merchant ID and Acquirer ID) and the signature bitmap fields. If you choose to build your signature using the Password, MerID, AcqID, PurchaseAmt, CardNo and CardCVV2, then the signature bitmap would be 1 + 16 + 64 = 83. (1 is the number associated with the PurchaseAmt, 16 is the number associated with the CardNo and the 64 is the number associated with the CardCVV2 field, there are no numbers associated with the mandatory fields). Therefore, to inform the SENTRY Payment Gateway what fields were used in the calculation of the incoming order signature, the merchant has to pass the extra field BitMapSIn = 83. When the Payment Gateway receives the request, it will try to validate the incoming order s signature using the merchant s stored password, along with any mandatory fields in contained the request, as well as the fields specified by the BitMapSIn field. This extra field (BitMapSIn) is generated by the merchant and is not stored anywhere in SENTRY. Merchants are free to send a different bitmap (along with a valid signature computed on the bitmap s fields) with every transaction. This bitmap serves as an additional security feature to the hashing of the signature, which guarantees that the message is not tampered while in transit between the merchant s site and SENTRY PG. SENTRY PG also supports Bitmaps for the Outgoing Signature, and for the Response Fields returned to the merchant in the response message. These two bitmaps can help determine if a response message has been tampered while being transmitted from SENTRY to the merchant s system. The Outgoing Signature and Response Fields Bitmaps can only be set by the SENTRY provider after the bitmap structures are agreed in advance with the merchant. The bitmap elements kept by the merchant must match the ones configured at the Acquirer/Processor side. The benefit of using Bitmaps is enhanced security, since as both merchant and Acquirer can verify the provenance of incoming messages. If the Outgoing Signature fails validation at the merchant side, then there is a high likelihood that the incoming message has been tampered with, and the merchant should stop further processing and reverse the action responded upon. Similarly, Acquirers/Processors will reject any incoming requests whose fields do not match the Bitmap received. Page 49 of 72

4. Appendix A Transaction Fields This section provides a reference to all the information that can be sent to the system and all of the things that could be expected in return. All integration with the system is done by performing an HTTP(S) form POST to the URL provided to you by tour provider. 4.1 Form Fields The following table provides an alphabetical list of all of the possible values that will be recognized by the system when sent in an HTML form. This table specifies which fields and which values are needed for each of the different connection types. Legend Method D Direct R U Redirect Update Link Flow I Input O Output Presence M Mandatory O C Optional Conditional Page 50 of 72

Method Flow Presence SENTRY Payment Gateway 1. Field Name Format Value D/R/U 2. I/O M Version AN(5) 1.0.0 D/R/U 3. I/O M MerID N(15) Your Merchant Account (Merchant Id) as it was send to you by the provider. Length of field may vary depending on provider merchant id format. D/R/U 4. I/O M AcqID N(11) The ID of your Acquirer that was supplied to you. Length of field may vary depending on provider merchant id format. D/R 5. I M MerRespURL AN(250) The URL system should return. This should be a valid public URL value. D/R/U 6. I M PurchaseAmt N(12) Amount of purchase calculated on your end. This is the final amount for getting an authorization request. This will be the amount right justified with leading zeroes, with the decimals implied. D/R/U 7. I M PurchaseCurrency N(3) The purchase currency value in ISO Numeric value. Only values permitted by acquirer are allowed. D/R/U 8. I M PurchaseCurrencyExponent N(1) Purchase Currency no. of decimals. Valid values are 0, 2, 3 D/R/U 9. I/O M OrderID AN(150) The transaction ID of the order that uniquely identifies the transaction in the merchant s system. D/R/U 10. I/O C Signature AN(28) The hash value that is produced using either MD5 or SHA1 hash algorithm on the fields described earlier. The produced value is the value calculated either by the merchant if it is incoming or by the system if it is outgoing. Since the result of the Hash is an array of bits, the system will expect the value to be transmitted using Base-64 encoding, making a 28 character string. In case a response is in error, or declined, the Signature might not be present. D/R/U 11. I/O O SignatureMethod AN(4) Either MD5 or SHA1 is the valid values in the current release. Default value if not present is SHA1 D/R 12. I/O O TestFlag A(5) Valid values are : True : Current message is a test message. False : Default Value if not present. This is only used if the merchant is in the NORM, live mode and it is available in order to cater for any future testing required by the merchant. Page 51 of 72

D/R 13. I O CaptureFlag A(1) Valid values are: A : Automatic capture if approved M : Manual capture if approved. Merchant will indicate later from either batch file or through the Merchant Admin site. If not present, system will use the selected option from the database. Make a note that if the Merchant is set to NEW, then the system will ignore the fields as all transaction are not captured on the live system. D 14. I M CardNo N(19) Customer's card number. Card number can have a length of either 11, 13, 16, or 19 D 15. I M CardExpDate N(4) Customer's card expiration date. Format of the date is of MMYY. D 16. I C CardCVV2 N(3) Customer s card verification value 2 as it appears on the back of his/her card. D/R 17. I/O C TransactionStain AN(28) In case 3-D Secure process took place prior to linking into SENTRY, this field is required to send a 3-D Secure authorization request to the payment systems. In case SENTRY has performed 3-D Secure authentication, this field will be returned back in the response to the merchant. This value can be saved by merchant for reference to 3-D Secure message during a dispute. D/R 18. I/O C ECIIndicator N(2) In case 3-D Secure process took place prior to linking into SENTRY, this field is required to send a 3-D Secure authorization request to the payment systems. In case SENTRY has performed 3-D Secure authentication, this field will be returned back in the response to the merchant. D/R 19. I/O C AuthenticationResult A(1) In case 3-D Secure process took place prior to linking into SENTRY, this field is required to send a 3-D Secure authorization request to the payment systems. In case SENTRY has performed 3-D Secure authentication, this field will be returned back in the response to the merchant. Valid values are Y, N or A. If value is N, authorization will not take place and process is terminated. If the value is Y, authorization will proceed and result of the authorization is given in the final response. If value is A, then the acquirer will decide if system will proceed to authorization. Value A, means that an attempt authentication was performed. Refer to 3-D Secure protocol for further explanation. Page 52 of 72

D/R 20. I/O C CAVVValue AN(28) In case 3-D Secure process took place prior to linking into SENTRY, this field is required to send a 3-D Secure authorization request to the payment systems. In case SENTRY has performed 3-D Secure authentication, this field will be returned back in the response to the merchant. D/R/U 21. O C ResponseCode N(1) Indicates the result of the transaction. The result can be an approval, decline, or error. D/R/U 22. O C ReasonCode N(3) This is a code that can give you more information about the transaction, such as what particular error occurred. D/R/U 23. O C ReasonCodeDesc AN(100) This is a text string that will briefly explain the type of response encountered D/R 24. O C AuthCode AN(6) A valid Authorization Code in case transaction was approved. D/R 25. O C ReferenceNo AN(12) A reference no that uniquely identifies the authorization in SENTRY system. D/R 26. O C PaddedCardNo AN(19) This value will only be present if the transaction was successful. It will contain the last 4 digits of the card used padded with leading X characters. The length will vary according the card used, i.e. it can be 11, 13, 16, 19 or 25 characters. D/R 27. O C CVV2Result AN(1) CVV2/CVC2/CID Result as indicated by Issuing bank in case data were submitted in the request. D/R 28. O C AVSResult AN(1) AVS Result in case the Billing address information were supplied and passed for verification. D/R 29. I/O C ShipToFirstName AN(30) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 30. I/O C ShipToLastName AN(30) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 31. I/O D ShipToMiddleName AN(30) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 32. I/O C ShipToAddress1 AN(50) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. Page 53 of 72

D/R 33. I/O C ShipToAddress2 AN(50) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 34. I/O C ShipToCity AN(30) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 35. I/O C ShipToState AN(2) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 36. I/O C ShipToCountry N(3) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 37. I/O C ShipToPostCode AN(10) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 38. I/O C ShipToCounty AN(15) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 39. I/O C ShipToEMail AN(100) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 40. I/O C ShipToTelephone N(20) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 41. I/O C ShipToFax N(20) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. Page 54 of 72

D/R 42. I/O C ShipToMobile N(20) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 43. I/O C BillToFirstName AN(30) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 44. I/O C BillToLastName AN(30) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 45. I/O D BillToMiddleName AN(30) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 46. I/O C BillToAddress1 AN(50) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 47. I/O C BillToAddress2 AN(50) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 48. I/O C BillToCity AN(30) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 49. I/O C BillToState AN(2) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 50. I/O C BillToCountry N(3) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. Page 55 of 72

D/R 51. I/O C BillToPostCode AN(10) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 52. I/O C BillToCounty AN(15) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 53. I/O C BillToEMail AN(100) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 54. I/O C BillToTelephone N(20) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 55. I/O C BillToFax N(20) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 56. I/O C BillToMobile N(20) If field is supplied, then SENTRY will display the contents in the Payment form. If field is not supplied and field is set as required in the Payment Form, system will ask the customer to complete it and SENTRY will return it back in the response. D/R 57. I O Recurring A(1) In order to indicate that this transaction order is a recurring transaction, then set this value to Y. If value is not present, N is assumed. D/R 58. I C ExecutionDate N(8) This is the date of the first transaction to occur if it as an installment or a recurring transaction. The format of the field is YYYYMMDD, where YYYY is the year value, MM is the month and DD is the day of the month. If transaction is a recurring, or installment, then this field is mandatory. Page 56 of 72

D/R 59. I C Frequency A(1) Denotes the frequency of the installment, recurring transaction. D : daily W : Weekly F : Forthright M : Monthly E : Every other month Q : Quarterly Y : Yearly. If the value is not specified, Monthly will be assumed. D/R 60. I C NumberOfRecurrences N(3) The number of recurrences to execute. This field is mandatory if the transaction order is flagged as recurring. D 61. I C Installment A(1) In order to indicate that this transaction order is an installment transaction, then set this value to Y. If value is not present, N is assumed. D 62. I C Installments N(3) The number of installments to execute. This field is mandatory if the transaction order is flagged as recurring. D 63. I C Amount N(12) The Installment amount, This field is required only when transaction is flagged as an Installment. D/R 64. I O OrdersDetails A(1) In order to indicate that this transaction contains order detail fields, set the flag to Y. If value is not present, N is assumed. The order details can be used by the merchant to display an itemized Invoice/Order on the Checkout Page in case the Payment Processor supports this feature. The current version will store the order details and displaying them during checkout, but it will not display the related information on the Merchant Administration site. Order details are not returned back on the response from the system D/R 65. I O customerid AN(150) If OrderDetails are set to Y, you can pass a customerid with the order. The id can be anything you want. D/R 66. I O IsItemised A(1) This flag will indicate that the OrderDetails contains Itemized Data for the order if set to Y. If not present, N will be assumed. D/R 67. I O NoOfItems N(2) This will indicate how many different items are present in the order. Maximum number of different items supported currently is 10. D/R 68. I O ItemDescriptionN AN(50) N a value from 1 to 10, i.e. ItemDescription1 to ItemDescription10. This will contain a description of the item. Page 57 of 72

D/R 69. I O ItemQuantityN N(3) N a value from 1 to 10, i.e. ItemQuantity1 to ItemQuantity10. This will contain the number of items for the specific product D/R 70. I O ItemUnitPriceN N(12) N a value from 1 to 10, i.e. ItemUnitPrice1 to ItemUnitPrice10. This will contain the price for this product. This will be right justified with leading zeroes, with the decimals implied based on PurchaseCurrency and PurchaseCurrencyExponent. D/R 71. I O ItemTotalPriceN N(12) N a value from 1 to 10, i.e. ItemTotalPrice1 to ItemTotalPrice10. This will contain the total price for the product. This will be right justified with leading zeroes, with the decimals implied based on PurchaseCurrency and PurchaseCurrencyExponent. D/R 72. I O ShippingCost N(12) This is the cost for shipping the current order. This will be right justified with leading zeroes, with the decimals implied based on PurchaseCurrency and PurchaseCurrencyExponent. D/R 73. I O VATCost N(12) This is the cost assigned for VAT. This will be right justified with leading zeroes, with the decimals implied based on PurchaseCurrency and PurchaseCurrencyExponent. D/R 74. I O DeliveryDate N(8) The expected Shipping Date in the format of YYYYMMDD. D/R I O AdditionalDetails A(1) In order to indicate that this transaction contains additional detail fields, set the flag to Y. If value is not present, N is assumed. The additional details can be used by the merchant to store extra fields not supported by default. Contact your Payment Processor if this functionality is available. The additional fields are not returned back and in current version are not displayed on the Merchant administration site. D/R 75. I O FieldDescriptionN AN(20) If additional details are supported, then field description can be passed using this. Maximun number of fields is 20, for example field 1 will be FieldDescription1=SSNo (Social security Number) and field 12 will be set to FieldDescription12=Passport No D/R 76. I O FieldValueN AN(50) If additional details are supported, then the field value can be passed using this. Make sure that the number of fields for description and value match. For the examples above, the values would be something like this: FieldValue1=636975 and FieldValue12=C898945 U 77. I M UpdateIndicator N(1) 1= Airline Data Update U 78. I M PassengerName AN(25) This is the passenger name as it appears on the ticket. If not supplied, system will put value, Not Supplied Page 58 of 72

U 79. I O CustomerCode AN(17) U 80. I O IssueDate N(8) The date the ticket was issued. U 81. I O TravelAgencyCode AN(8) U 82. I O TravelAgencyName AN(25) U 83. I O TicketNumber AN(60) U 84. I O IssuingCarrier AN(4) Format YYYYMMDD U 85. I O TotalFare N(12) This will be the amount right justified with leading zeroes, with the decimals implied based on the purchase currency. U 86. I O TotalFees N(12) This will be the amount right justified with leading zeroes, with the decimals implied based on the purchase currency. U 87. I O TotalTax N(12) This will be the amount right justified with leading zeroes, with the decimals implied based on the purchase currency. U 88. I O NationalTax N(12) This will be the amount right justified with leading zeroes, with the decimals implied based on the purchase currency. Page 59 of 72

D/R 89. I O BitMapSIn N(4) This is a bitmap of the optional fields that are included in the signature that the Merchant sends. It can be used to enhance the security level for the particular function (signature verification for the transaction request). The default Signature includes all the Mandatory Fields plus the OrderID, PurchaseAmt and PurchaseCurrency. The Mandatory fields are: 1. Password 2. MerID 3. AcqID The Merchant can include more fields in the signature and in order for SENTRY to know which fields to include for validation this bitmap must be built correctly. The available fields are: 1 PurchaseAmt 2 PurchaseCurrency 4 PurchaseCurrencyExponent 8 MerRespURL 16 CardNo 32 CardExpDate 64 CardCVV2 128 SendDateTime The bitmap is basically the sum of the numbers next to each field. For example if the Signature has the Password, MerID, AcqID, PurchaseAmt, CardNo and CardCVV2, then the signature bitmap would be 1 + 16 + 64 = 83 In the above example the string that will be hashed to produce the signature will contain the compalsury fields concatenated with PurchaseAmt&CardNo&CardCVV2 in this order. I.e. Password & Merchantid & AcqId & OrderID & Purchase Amount & PurchaseCurrency& PurchaseAmt&CardNo&CardCVV2 Please note that there are similar Bit Maps that are used to build the response signature and the response fields. These can only be controlled by the SENTRY Administrator, through Bank Admin and different values can be set per Merchant. 4. D/R I O AuthenticationOnly A(1) This is a flag (Y or N) that will control whether this particular transaction will be also authorized or whether the Authentication will be performed only. Page 60 of 72

5. Appendix B Response Codes The system will always attempt to provide information about the status of a transaction. In the case of a Virtual POS transaction, the system will report the status of the transaction in your browser. In the case of a SENTRY Direct and/or Redirect Link Method, the response that is returned to the merchant s server will include the information in the Response and Reason code fields and also a brief description in the Reason Code description field. 5.1 System Response Codes Response Code Description 1 Approved. 2 Declined. 3 Error. 5.1.1 Data Sent with Response Codes Response Code 1 Response Code Reason Code Reason Description Merchant Id Acquirer Id Merchant Order Id Signature Reference Number Card Number (padded) Authorization Code Billing Address Shipping Address Response Code 2 Response Code Reason Code Reason Description Response Code 3 Response Code Reason Code Reason Description Merchant Order Id Page 61 of 72

5.2 Customized Incoming Signature Fields Fields Password MerID AcqID OrderID PurchaseAmt PurchaseCurrency PurchaseCurrencyExponent MerRespURL CardNo CardExpDate CardCVV2 SendDateTime Required/Optional Required Required Required Required Optional Optional Optional Optional Optional Optional Optional Optional 5.3 Customized Outgoing Signature Fields Fields Password MerID AcqID OrderID ResponseCode ReasonCode ReasonCodeDesc ReferenceNo PaddedCardNo AuthCode CVV2Result AVSResult AuthenticationResult CAVVValue ECIIndicator TransactionStain OriginalResponseCode Required/Mandatory Required Required Required Required Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Page 62 of 72

5.4 Customized Response Codes Fields Fields MerID AcqID OrderID ResponseCode ReasonCode ReasonCodeDesc ReferenceNo PaddedCardNo AuthCode CVV2Result AVSResult AuthenticationResult CAVVValue ECIIndicator TransactionStain ShipAddressDetails BillAddressDetails OriginalResponseCode Required/Mandatory Required Required Required Required Required Required Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional Optional 5.5 System Response Codes Response Code Description 1 Approved. 2 Declined. 3 Error. 5.6 System Response Reason Codes for Response Code 1 Reason Code Reason Text Note 1 Transaction is approved. Page 63 of 72

5.7 System Response Reason Codes for Response Code 2 Error Code Name Description 2 Transaction is declined. Normal Decline 3 Transaction is declined Referral. Call for further details on this transaction. 4 Transaction is declined. Pick up card (if possible) or report to authorities. 35 Unable to process your request. Please try later. 38 Transaction processing terminated. Please try again later. 39 Issuer or switch not available. Please try again later Merchant exceeds allowed amount. Transaction is not permitted to merchant. Issuing bank or switch not available. Transaction has timed-out. 5.8 System Response Reason Codes for Response Code 3 Reason Code Reason Text Note 5 Connection not secured. Connection was not secured. 6 HTTP Method not POST HTTP Method not POST 7 Field is missing. Field is missing 8 Field format is invalid. Field format is invalid. 10 Invalid Merchant Not such merchant. 11 Authentication Failed (Signature computed incorrectly). Merchant was found but computed signature does not match one included in the request 12 Merchant is inactive. Merchant is not enabled for processing 14 Merchant is not allowed to process this currency Currency supplied is not permitted. 15 Merchant settings are not valid. Merchant record is not correctly setup in the system. 16 Unable to process transaction Unable to authenticate merchant now. Try later. 36 Credit Card holder canceled the request. Credit Card holder canceled the request. 37 Card Entry Retry Count Exited Allowed Limit. Card Entry Retry Count Exited Allowed Limit. 40 Duplicate Order Not Allowed Merchant order identification numbers must be unique 41 Card Holder Session Expired. Card Holder s Session expired while performing a 3DS Transaction. Possibly because he/she closed the window, or pressed the back button in the middle of the transaction. 42 Illegal Operation by Card holder. Check Order Status. Card Holder Pressed the back button while the transaction was processing. Check the status of that order. 60 Duplicate Order Not Allowed FAC Custom based on amount 90 General Error during processing. Please try again later. An unexpected error occurred in the system. Page 64 of 72

Reason Code Reason Text Note 91 Cardholder did not submit checkout page in time Returned when the MCBA Checkout page timeout has elapsed 96 Merchant URL is Missing Merchant URL is Missing 98 System is temporarily down. Try later. System is temporarily down. Try later. 401 Cycle interrupted by the user or client/browser connection not available. Cycle interrupted by the user or client/browser connection not available. 5.9 System Response Reason Codes for 3D-Secure Errors Reason Code Reason Text Note 13 Merchant is not allowed to process cards in this Payment system. Merchant is blocked. 17 Unable to process transaction System cannot process a Card Range Request 18 Unable to process transaction System cannot build a Verify Enrollment Request. 19 Unable to process transaction System cannot contact Visa Directory. 20 Unable to process transaction. System cannot build a Payment Authentication. 21 Unable to process transaction System could not contact Issues ACS Server. 22 Unable to process transaction Issuer ACS responded with invalid data or returned data failed. 23 Unable to process transaction System cannot process a Verify Enrollment Request. 31 Authentication successful 3-D Secure Payment Authentication successful 32 Authentication failed 3-D Secure Payment Authentication failed. 33 Authentication successful with attempt. Attempt authentication was performed. 34 Authentication failed with error. Authentication result not expected. 50 Verify Enrollment Response Unavailable The VeRes message came back from the MPI as a U. This may be returned during an Authentication only request. 51 Bin not Enrolled The VeRes message came back from the MPI as an N bin not enrolled. This may be returned during an Authentication only request. 52 Card not Enrolled The VeRes message came back from the MPI as an N card not enrolled. This may be returned during an Authentication only request. 53 Payer Authentication Response Unavailable The PaRes message came back from the MPI as U. This may be returned during an Authentication only request. 5.10 System Response Reason Codes for Airline Data Update Reason Code Reason Text Note Page 65 of 72

Reason Code Reason Text Note 100 Successful in updating order. Order data have being updated successfully. 101 Field is missing Field is missing. 102 Field format is invalid. Field format is invalid. 103 Order has been updated before. Order has been updated before. 104 Unable to update order at the moment. Try later. System cannot update the order. Contact your acquirer. 5.11 System Error Codes for Store Front Services Error Number Description 0 Failed 1 Success 2 AuthenticatorSoapHeaderMissing 3 AuthenticatorAcquirerIDMissing 4 AuthenticatorAcquirerIDInvalid 5 AuthenticatorMerchantIDMissing 6 AuthenticatorMerchantIDInvalid 7 AuthenticatorPasswordMissing 8 AuthenticatorPasswordInvalid 9 AuthenticateHeaderGeneralError 10 GeneralParamError 11 CaptureTrxnAmount_TrxnHasBeenClosed 12 CaptureTrxnAmount_CaptureAmtGreaterThanTrxnAmt 13 CaptureTrxnAmount_CaptureAmtGreaterThanLeftOverAmt 14 CaptureTrxnAmount_NonAuthorizedOrder 15 CaptureTrxnAmount_NonApprovedOrder 16 CaptureTrxnAmount_TestOrder 17 CaptureTrxnAmountSuccess 18 CaptureTrxnAmountGeneralError 19 CaptureTrxnAmountAuthenticationProcessGeneralError 20 CaptureTrxnAmountAuthenticationProcessingError 21 CaptureTrxnAmountAuthenticationUnknownError 22 CaptureTrxnAmountAuthenticationFailure 23 CaptureTrxnAmountAuthenticationInvalid 24 CaptureTrxnAmountOrderIdInvalid Page 66 of 72

Error Number Description 25 CaptureTrxnAmountInvalidMerchantStatus 26 CaptureTrxnAmountCaptureCutOffExpired 27 CaptureTrxnAmountPartialCaptureNotAllowed 28 RefundAmountGeneralError 29 RefundAmountAuthenticationProcessGeneralError 30 RefundAmountAuthenticationProcessingError 31 RefundAmountAuthenticationUnknownError 32 RefundAmountAuthenticationFailure 33 RefundAmountAuthenticationInvalid 34 RefundAmountOrderIdInvalid 35 RefundAmountInvalidMerchantStatus 36 RefundAmountRefundNotAllowed 37 RefundAmountRefundCutOffExpired 38 ReverseAmountReversalAmtGreaterThanTrxnAmt 39 ReverseAmountNonAuthorizedOrder 40 ReverseAmountNonApprovedOrder 41 ReverseAmountAlreadyReversed 42 ReverseAmountPartialReversalOnTestOrder 43 ReverseAmountGeneralError 44 ReverseAmountAuthenticationProcessGeneralError 45 ReverseAmountAuthenticationProcessingError 46 ReverseAmountAuthenticationUnknownError 47 ReverseAmountAuthenticationFailure 48 ReverseAmountAuthenticationInvalid 49 ReverseAmountOrderIdInvalid 50 ReverseAmountInvalidMerchantStatus 51 ReverseAmountReversalNotAllowed 52 ReverseAmountReversalCutOffExpired 53 ReverseAmountPartialReversalNotAllowed 54 CaptureTrxnAmountOrderInProcessing 55 RefundAmountOrderInProcessing 56 ReverseAmountOrderInProcessing 57 CaptureTrxnAmountCaptureReversedNotAllowed 58 CaptureTrxnAmountIsZero 59 ReverseAmountOnInstallment Page 67 of 72

Error Number Description 60 CaptureTrxnAmount_CaptureAmtLessThanPreviousCapture 61 RefundTrxnAmountIsZero Page 68 of 72

6. Appendix C AVS Result Codes 6.1 VISA Transactions Code A B C D E F G I M N P R S W X U Y Z Definition Street addresses match. The street addresses match but the postal/zip codes do not, or the request does not include the postal/zip code. (IAVS) Street addresses match. Postal code not verified due to incompatible formats. (Acquirer sent both street address and postal code.) (IAVS) Street address and postal code not verified due to incompatible formats. (Acquirer sent both street address and postal code.) (IAVS) Street addresses and postal codes match. Transaction ineligible. Error response for Merchant Category Code. Street address and postal code match. Applies to U.K. only. Address information not verified for international transaction. (IAVS) Address information not verified. Street address and postal code match. No match. Acquirer sent postal/zip code only, or street address only, or both postal code and street address. (IAVS) Postal code match. Acquirer sent both postal code and street address, but street address not verified due to incompatible formats. Retry: System unavailable or timed out. Issuer ordinarily performs its own AVS but was unavailable. Available for U.S. issuers only. Not applicable. If present, replaced with U (for domestic) or G (for international) by V.I.P.1 Available for U.S. issuers only. 9-digit Zip/postal code matches, address does not match. Address and 9-digit Zip/postal code match. Address not verified for domestic transaction. Visa tried to perform check on issuer s behalf but no AVS information was available on record, issuer is not an AVS participant, or AVS data was present in the request but issuer did not return an AVS result. Exact: Address and Zip code are an exact match. Postal/ZIP matches; street address does not match or street address not included in request. 6.2 MasterCard Transactions Code X Y A Definition Address and 9 digit zip code match. Address and 5 digit zip code match Address matches, zip code does not match. Page 69 of 72

Code W Z N U R S Definition 9 digit ZIP code matches, address does not match 5 digit zip code matches; address does not match. Address and zip code do not match. Address information is unavailable. System unavailable or timeout Service not supported: AVS not supported at this time. 9 Address Verification Data contains EDIT ERROR 0 Issuer has chosen not to perform Address Verification for an authorization that was declined. 6.3 AMEX Transactions Code Y N A Z R U S Definition Address and zip code are correct. Address and zip code are not correct. Address correct, zip code incorrect. Zip code correct; address incorrect. Retry, system unavailable or timeout. Address information is unavailable; account number is not US or Canadian. Address Verification Service not valid. 9 Address Verification Data contains EDIT ERROR Page 70 of 72

7. Appendix D CVV2 Result Codes Code M P S U N Definition Match Not Processed. Should be on card but was not provided (Visa only) Issuer not participating or certified. No match. Inc. and TSYS are federally registered service marks of Total System Services, Inc., in the United States. Total System Services, Inc., owns a number of service marks that are registered in the United States and in other countries. All other products and company names are trademarks or registered trademarks of their respective companies.

8. Appendix E Browser Compatibility The SENTRY Payment Gateway Checkout Page, ACS Authentication Window and SENTRY MPI are compatible with most major browsers. The Bank Administration and Merchant Administration web applications are compatible only with Internet Explorer 6 and above. 8.1 Test platform Tested on Windows 2008 R2, IIS 7.5,.NET framework 4 Tested for full 3DS transactions for CA Direct & CA Redirect All Browsers running on Windows XP, 32-bit (only IE9, IE10 running on Win 2008 R2 64-bit) 8.2 Legend Y = browser supported N = browser not supported X = browser partially supported Browser Checkout Application - DirectLink Checkout Application - RedirectLink 3DS Non-3DS 3DS Non-3DS Merchant Administration Bank Administration Safari 5.1.7 Y Y Y Y X N Chrome 28.0.1500.72 m Y Y Y Y X X Firefox 22.0 Y Y Y Y X X Opera 15.0.1147.130 Y Y Y Y X X IE7 Y Y Y Y Y Y IE8 Y Y Y Y Y Y IE9 Y Y Y Y Y Y IE10 (with compatibility view) Y Y Y Y Y Y Inc. and TSYS are federally registered service marks of Total System Services, Inc., in the United States. Total System Services, Inc., owns a number of service marks that are registered in the United States and in other countries. All other products and company names