Global E-Commerce Gateway Merchant€¦ · Global E-Commerce Gateway Merchant Integration Guide ... The Global E-Commerce Gateway provides a secure and standardised interface for

Global E-Commerce Gateway Merchant

Integration Guide

August 2012

Version 3.0

Copyright 2012 MasterCard. The information contained in this document is proprietary and confidential information of MasterCard.

The material cannot be disclosed, duplicated, or published, in whole or in part, without MasterCard's prior written consent. Page 2 V3/08/12

Elavon‘s Global

E-Commerce Gateway

Elavon‘s Global E-Commerce Gateway provides robust and secure online payment processing with secure end-to-end connectivity.

Our Global E-Commerce Gateway allows you to configure the solution to meet the unique needs of your business — and your customers — by extending a choice of payment types, user rights, currencies, fraud monitoring levels and integration options.

Elavon has partnered with DataCash, a leading ecommerce gateway provider, to create our Global E-Commerce Gateway. DataCash is a subsidiary of MasterCard International.

Copyright

Acknowledgement

Copyright © 1997 – 2011 DataCash Limited. All Rights Reserved.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software (the ―Software‖), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice, this permission notice and the acknowledgements below shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED ―AS IS‖, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL DATACASH LIMITED BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY WHATSOEVER OR HOWSOEVER OR ANY TYPE OF LOSS WHETHER DIRECT, INDIRECT, CONSEQUENTIAL OR LOSS OF GOODWILL, DATA OR PROFITS. WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE ANYWHERE IN THE WORLD.

Except as contained in this notice, the name of DataCash Limited shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorisation from DataCash Limited.

DataCash Limited acknowledges that part of the Software includes cryptographic software which was written by Eric Young (eaymincom.oz.au) and in relation to the SSL documentation by Tim Hudson.

License Agreement

The software described in this manual is supplied under a license agreement and may only be used in accordance with the terms of that agreement.



Table of Contents

1. Introduction to the Guide ................................................................................................... 5

1.1 Audience .................................................................................................................. 5 1.2 Scope ....................................................................................................................... 5 1.3 Support ..................................................................................................................... 5 1.4 Related Documentation ............................................................................................ 6

2. Business Integration Overview .......................................................................................... 7

2.1 Introduction .............................................................................................................. 7 2.2 Global E-Commerce Gateway Service Connectivity ................................................. 7 2.3 SSL Technology ....................................................................................................... 7

3. Merchant Integration Overview .......................................................................................... 9

3.1 Methods of Integration and Communication ............................................................. 9 3.2 The Server Hosted Method ....................................................................................... 9

3.2.1 Considerations for Using the Server Hosted Method .......................................... 10

3.3 The Merchant Hosted Method ................................................................................ 10 3.3.1 Considerations for Using the Merchant Hosted Method ..................................... 10

3.4 Considerations for Combining Merchant Hosted and Server Hosted Payments ...... 10 3.5 Comparison of Server Hosted and Merchant Hosted Payments ............................. 11 3.6 Setting up the Merchant Account Profile ................................................................. 14 3.7 Processing Methods ............................................................................................... 14

3.7.1 One Stage Processing .............................................................................................. 14

3.7.2 Two Stage/Delayed Processing .............................................................................. 15

3.8 Transaction Types .................................................................................................. 16 3.8.1 Merchant Transaction Source ................................................................................. 19

3.8.2 Merchant Transaction Frequency – Repeat and Recurring Card Payments ... 20

3.9 Global E-Commerce Gateway Integration Steps .................................................... 21 3.9.1 Global E-Commerce Gateway Integration Guidelines ......................................... 23

3.9.2 Transaction Query ..................................................................................................... 23

3.9.3 Best Practice Payments Guidelines ....................................................................... 24

3.9.4 Troubleshooting ......................................................................................................... 24

4. Integrating Merchant Hosted Payments ........................................................................... 25

4.1 Information Flow Steps ........................................................................................... 25 4.2 The Cardholder Interface ........................................................................................ 25 4.3 Testing ................................................................................................................... 26

5. Integrating Server Hosted Payments ............................................................................... 27

5.1 Integrating Hosted Card Capture (HCC) ................................................................. 27 5.2 Integrating Hosted Pages (HPS)............................................................................. 27 5.3 Using iFrames ........................................................................................................ 27 5.4 Information Flow Steps ........................................................................................... 28 5.5 Testing ................................................................................................................... 28



6. Integrating Authentication Only Transactions ................................................................... 29

6.1 Information Flow Steps ........................................................................................... 29 6.2 Testing ................................................................................................................... 29

7. Securing Payment Transactions ...................................................................................... 30

7.1 3-D Secure Payment Authentication ....................................................................... 30 7.2 Merchant Hosted 3-D Secure Summary ................................................................. 30 7.3 Server Hosted 3-D Secure Summary ..................................................................... 31 7.4 Address Verification Service (AVS) ........................................................................ 31 7.5 Card Security Code (CSC) ..................................................................................... 31 7.6 Transaction Integrity ............................................................................................... 32 7.7 Fraud Management ................................................................................................ 34

8. Tokenisation Service ....................................................................................................... 36

8.1 Introduction ............................................................................................................ 36 8.2 Generating Tokens ................................................................................................. 36

8.2.1 Requirements ................................................................................................ 36 8.2.2 Token Format ................................................................................................ 36 8.2.3 Token Generation .......................................................................................... 37

8.3 Using Tokens ......................................................................................................... 37 8.3.1 Payment Transactions Using a Token ........................................................... 37 8.3.2 Retokenize Transactions ............................................................................... 37

8.4 Other Uses ............................................................................................................. 38 8.4.1 Query Transaction ......................................................................................... 38

9. Technical Integration Overview ........................................................................................ 39

9.1 Introduction ............................................................................................................ 39 9.1.1 Secure Access .............................................................................................. 39

9.2 Integrating with the Global E-Commerce Gateway ................................................. 39 9.2.1 The XML Request ......................................................................................... 40 9.2.2 The XML Response ....................................................................................... 40

9.3 Failure Scenarios ................................................................................................... 41 9.4 Other Considerations .............................................................................................. 43

9.4.1 Transport Layer ............................................................................................. 43 9.4.2 Merchant Authentication ................................................................................ 43 9.4.3 Messaging ..................................................................................................... 43

10. Testing Overview ............................................................................................................. 44

11. Glossary .......................................................................................................................... 45



1. Introduction to the Guide

1.1 Audience

This document is intended to be used by merchants, developers, technical personnel and business analysts to facilitate a successful integration by an e-commerce merchant to the Elavon Global E-Commerce gateway solution.

1.2 Scope

This document describes the merchant processing options, merchant account profile set up, integration steps and guidelines, and the transaction types and security features available for integration of a merchant‘s e-commerce website with Global E-Commerce Gateway Services. This is mainly a business document and as such covers the business reasons and business processes for integration.

For detailed technical documentation on how to integrate to Global E-Commerce Gateway Services with a merchant‘s website, refer to the Global E-Commerce Gateway Developers‘ Reference Guide and associated appendices.

Both the Global E-Commerce Gateway Developers‘ Reference Guide and the various appendices are available at www.elavon.com/devportal.

1.3 Support

For any assistance or information pertaining to existing or new Global E-Commerce Gateway services, merchants should contact technical support.

http://www.elavon.com/devportal



1.4 Related Documentation

The following publications contain material directly related to this document. All documentation is available at www.elavon.com/devportal.

Reference Description

Global E-Commerce Gateway Developers‘ Reference

Developers‘ technical reference for integration of the Global E-Commerce Gateway API.

Appendix 1 – 3DS Technical reference for integration of 3-D Secure transactions.

Appendix 2 – Repeat and Recurring Card Payments

Technical reference for integration of repeat (recurring) payment transactions.

Appendix 3 – Hosted Card Capture and Hosted Pages Solution

Technical reference for integration of server hosted solutions.

Appendix 4 – Merchant Narrative

Technical reference for integration of Merchant Narrative service.

Appendix 5 – Batch Input Technical reference for integration to Batch Input service for offline processing

Appendix 6 – Risk Services Gateway

Technical reference for integration of the transaction screening and risk management services.

Appendix 7 - Tokenisation Service

Technical reference for merchants using tokens to store card data relating to a transaction rather than storing the actual card number.

http://www.elavon.com/devportal



2. Business Integration Overview

2.1 Introduction

The purpose of this section is to explain the features of the Global E-Commerce Gateway systems and how a merchant website will interact with them.

The Global E-Commerce Gateway provides a secure and standardised interface for online payment processing and ancillary services. This includes credit and debit card transactions, alternative payments, and services such as 3-D Secure and real time fraud screening.

It simplifies the complexity of integrating value added services and 3-D Secure, and greatly reduces the scope of payment integration effort required by the merchant.

When used with the Server Hosted method, the Global E-Commerce Gateway also greatly reduces the PCI DSS (Payment Card Industry Data Security Standard – see Glossary) compliance burden by eliminating the need for merchants to securely handle and store sensitive card data.

―Server Hosted‖ refers to a method of integration in which the Global E-Commerce Gateway manages the screen interaction with the cardholder for the purpose of collecting cardholder card details, offering value added services where applicable and 3-D Secure.

The other method of operation is the ―Merchant Hosted‖ method where the merchant website does not hand over the cardholder to be managed by the Global E-Commerce Gateway, but instead is responsible for collecting card data and passing it onto the Global E-Commerce Gateway. The merchant must comply with additional PCI DSS compliance requirements to use this method.

2.2 Global E-Commerce Gateway Service Connectivity

Cardholders connect from clients to the retailer website or application as part of their online shopping or e-commerce experience. When it comes to payment processing, the retailer‘s system connects over the Internet to the Global E-Commerce Gateway. For value added services, the Global E-Commerce Gateway in turn connects to the service and manages both the service and the payment transaction.

The integration of the retailer‘s system to the Global E-Commerce Gateway requires only the gateway network interface messages to be built.

2.3 SSL Technology

A merchant who collects and transmits cardholder and transaction data via a website application must securely protect that information as it moves between the cardholder‘s browser, the merchant‘s application, and the Global E-Commerce Gateway server.



A merchant application must use Secure Sockets Layer (SSL) technology to provide the necessary security and encryption for transmitting sensitive cardholder and transaction information.

It is also recommended that a merchant uses a secure method when collecting cardholder data.

The Global E-Commerce Gateway Server uses SSL to encrypt cardholder and other sensitive transaction details and provide a secure transmission with the cardholder where merchants use the Server Hosted integration method.

When the cardholder‘s browser connects to the merchant application using SSL the website address prefix changes to https:// and an indication appears in the browser address bar to indicate that the communication is encrypted and secure.



3. Merchant Integration Overview

3.1 Methods of Integration and Communication

The two methods to communicate with the Global E-Commerce Gateway server to process transactions are the redirect method and the direct method.

The method chosen depends on whether the Server Hosted or Merchant Hosted integration method is used.

A merchant may use both methods concurrently if appropriate to the merchant‘s business. For example, a web store may use the Server Hosted method, and at the same time a call centre taking phone orders may use the Merchant Hosted method. Both applications could be using the Global E-Commerce Gateway server at the same time.

3.2 The Server Hosted Method

This method involves the merchant, Elavon and cardholders, and allows the Global E-Commerce Gateway server to control the payment pages and securely collect and process the cardholders‘ card details on the merchant‘s behalf. The Global E-Commerce Gateway payment pages may be branded by the merchant or a default blank payment page is available.

The merchant redirects the cardholder to the Global E-Commerce Gateway server for the cardholder to enter the card details. The cardholder is redirected back to the merchant, and the merchant sends a Transaction Query transaction to the Global E-Commerce Gateway server to get the transaction result.

As an alternative to the redirect model, the secure page for the entry of the card data may be displayed as an iFrame (i.e. an inline frame—a HTML structure that places another HTML document into a HTML page.)

The Server Hosted method is only used for Internet based payment applications where a browser is involved.

There are two Server Hosted methods of implementation:

Hosted Card Capture (HCC) - The merchant manages the flow of XML requests to the Global E-Commerce Gatewayfor transaction authorisation, including 3-D Secure authentication.

Hosted Pages (HPS) - the Global E-Commerce Gateway manages the transaction authorisation and 3-D Secure authentication processes.

See Section 5 Integrating Server Hosted Payments.



3.2.1 Considerations for Using the Server Hosted Method

Merchants should use the Server Hosted method where:

They want the Payment Provider to collect cardholders‘ card details and simplify compliance with PCI DSS requirements.

They are integrating an Internet browser-based application only. This method cannot be used for call centres, IVRs and other applications.

The cardholder browser may be redirected away from the merchant‘s website to the Global E-Commerce Gateway server.

Note: This does not happen if the iFrame method is used.

3.3 The Merchant Hosted Method

This method involves the merchant and the Payment Provider and is used by merchants who want control over the transaction process by communicating directly, and who want to manage their own payment pages. They must also securely collect cardholders‘ card details.

The merchant‘s application communicates directly with the Global E-Commerce Gateway server, so the cardholder does not leave the merchant‘s website and the session is not split.

See Section 4 Integrating Merchant Hosted Payments.

3.3.1 Considerations for Using the Merchant Hosted Method

Merchants should use the Merchant Hosted method where:

They will collect cardholders‘ card details and comply with PCI DSS requirements.

They need to use functions such as captures, refunds, voids and queries that do not include card data in the transaction.

They do not want the cardholder browser to be redirected away from the merchant website to the Global E-Commerce Gateway server or do not want to use an iFrame for payment processing.

3.4 Considerations for Combining Merchant Hosted and Server Hosted

Payments

Merchants should use a combination of the Merchant Hosted and Server Hosted methods where:

They use the Server Hosted method for their Internet payments and the Merchant Hosted method for their call centre, IVR, or other payment applications.



They process recurring payments and use an Internet application to process a 3-D Secure authentication for the first payment and then process Merchant Hosted payments for subsequent recurring payments.

They wish to use the Server Hosted method for payment transactions and the Merchant Hosted method for other transactions like fulfils, refunds, cancels and queries.

3.5 Comparison of Server Hosted and Merchant Hosted Payments

A comparison of features of each of the Server Hosted methods and the Merchant Hosted method is as follows:

Server Hosted Merchant Hosted

Hosted Card Capture (HCC) Hosted Pages (HPS) Merchant Hosted Pages

Summary

The merchant manages the flow of XML requests for transaction authorisation and 3-D Secure authentication. The merchant requests a session ID and URL to redirect the cardholder to the HCC page to capture the card details, and then return to the merchant site to complete the transaction.

HCC allows use of dynamic fields to capture additional cardholder information.

The Global E-Commerce Gateway manages the transaction authorisation and 3-D Secure authentication processes. The merchant requests a HPS capture page containing all payment elements except card details, This returns a session ID, URL and gateway reference to display the HPS capture page to the cardholder for entry of the card details.

The Global E-Commerce Gateway sends the transaction for authentication and authorisation.

HPS does not allow dynamic capture fields.

The merchant displays the page for payment details to be captured and controls the transaction authorisation and 3-D Secure processes.

The cardholder does not leave the merchant website.





Data Capture

Up to nine dynamic capture fields are available for display on the capture page.

These fields are used to capture additional information from the cardholder which is returned as part of the query transaction.

Dynamic capture fields are not available.

Dynamic capture fields are not available.

Card type identification is available to determine the card scheme prior to the authorisation process.

Card type identification is available for limited use after the authorisation process.

Card type identification is available for limited use after the authorisation process.

The merchant controls the authorisation process by managing the flow of XML requests to the Global E-Commerce Gateway, including 3-D Secure authentication if required.

The Global E-Commerce Gateway manages the authorisation process, including 3-D Secure authentication if required.

The merchant controls the authorisation process, including 3-D Secure authentication if required.





Payment Flow

When a card transaction is processed, the following actions are made, each of which makes a call to the Global E-Commerce Gateway:

When a card transaction is processed, the actions are similar to that in the HCC processing, but there are fewer calls made to the Global E-Commerce Gateway.

There is no gateway session set up, and the cardholder does not leave the merchant website.

1. Setting up a HCC Session:

i) The merchant sends a simple XML request which returns a session ID and URL.

ii) The Session ID in conjunction with URL allows the merchant to direct the cardholder to the HCC capture page (using the method implemented by the merchant – iFrame or redirect) where the card details are entered, captured and stored by the gateway for 10 minutes.

The datacash_reference can be used to track the data that is supplied.

iii) Once submitted, the cardholder is directed back to the merchant‘s website to complete the transaction by submitting an XML authorisation request.

Throughout this process, there is no need for the cardholder to be aware of leaving the merchant‘s website.

1. Setting up a HPS Session and Processing the Transaction:

i) The merchant sends a comprehensive XML request for a HPS capture page. The request contains all elements of the payment except card details. At this stage the merchant must provide amount, currency, transaction type and optionally fraud/risk information, and whether 3-D Secure is required or not. This returns a session ID, URL and datacash_reference.

ii) The Session ID in conjunction with URL allows the merchant to display the HPS capture page to the cardholder (using the method implemented by the merchant - iFrame or re-direct). The card details are entered, captured and sent to the acquiring bank for authorisation and transaction completion.

The datacash_reference can be used to track the data supplied.

1. Processing the Transaction:

i) The merchant displays the merchant hosted capture page to the cardholder. The payment details are entered and sent to the acquiring bank for authorisation and transaction completion.

The datacash_reference can be used to track the data supplied.

2. Querying the Captured Data:

This is an optional request to check whether the card details were captured correctly. The


This is an optional request—available for the merchant to make at the point when the


There is no card capture for merchant hosted. The query



response to this request will also include card scheme, country of issue, expiry date, card issuer and the masked PAN (card number) where applicable.

cardholder is returned to the merchant‘s website—to check whether the card details were captured correctly and the outcome of the authorisation request.

The response to this request will also include card scheme, country of issue, expiry date, card issuer and the masked PAN (card number) where applicable.

transaction will only return the transaction result.

3. Processing a Transaction:

At this stage the merchant can send a standard card transaction to the Global E-Commerce Gateway (referencing the captured details supplied from step 1 in the authorisation request) in place of the PAN (card number).

After this stage the transaction is complete.

3.6 Setting up the Merchant Account Profile

Each merchant must have a test and production account profile created on the Global E-Commerce Gateway system. The merchant account profile records the merchant‘s details and permitted functionality.

Production Merchant Account Profile

A production merchant account is activated by Elavon following satisfactory testing. Merchants are then able to process transactions on the production system.

3.7 Processing Methods

3.7.1 One Stage Processing

This is a processing method where only one transaction is required to complete the payment. For credit and debit card processing, the most common examples of this are the 'auth' and 'refund' transaction types.

Situations where this method is suitable include:

Instant access services such as software downloads

Selling physical goods that will be shipped same day



The transaction types that can be used with the one stage method are:

Transaction Type Uses

auth Requests authorisation to debit the card and, if approved, initiates payment from the cardholder to the merchant.

refund Returns funds from the merchant back to the cardholder.

3.7.2 Two Stage/Delayed Processing

This is a processing method where by two separate transactions are required to complete the processing. For credit and debit card processing, the most common example of this is the 'pre' transaction to perform the authorisation, and must be followed by a 'fulfill' transaction to settle the transaction.

Situations where this model is suitable include:

Ordered items are not currently available to ship

Additional in-house processes need to be completed prior to settlement.

The transaction types that can be used with the two stage model are:

Transaction Type Uses

pre (pre-auth) Reserves funds on the card, but does not debit the card and settle the transaction until a valid fulfill request is received.

fulfil Initiates settlement of a valid pre transaction to Completes the two stage process.

The card details are only required for the pre transaction type. They are not required to fulfill the transaction.



3.8 Transaction Types

The full list of transaction types is shown here:

Transaction Type

Global E-Commerce Gateway Transaction Type

Description

Purchase auth Requests authorisation to debit the card and settles transaction the next working day.

Authorisation pre The first stage of a two stage credit or debit card auth transaction.

A successful pre checks the card details and reserves funds against the card. It also allows merchants to perform any of the fraud services which the merchant is set up for.

The funds for a pre are not settled immediately. To settle the transaction, a valid fulfil request needs to be sent to the Global E-Commerce Gateway

Capture fulfill Allows a merchant using two stage processing to

capture the funds from an earlier pre to fulfill the

transaction, and to fulfill the customer‘s order.

A merchant using this mode performs two transactions to transfer the funds into the merchant‘s bank account.

The first transaction (pre) reserves the funds on the

cardholder's credit card account.

The second transaction (fulfill) transfers the funds

from the cardholder's account to the merchant's account.

There are two ways to fulfill the funds from a pre

transaction:

1. Manually via the merchant system portal. This is most suitable for small numbers of transactions.

2. Using the fulfill command to directly perform the

fulfill transactions from the merchant application.

Merchants can perform as many fulfill transactions

on the original pre transaction as required, but the total

amount fulfilled cannot exceed the amount of the

original pre transaction, unless the excessive fulfill

privilege is enabled, in which case the total amount

fulfilled can be up to 110% of the original pre

transaction.

https://datacash.custhelp.com/cgi-bin/datacash.cfg/php/enduser/std_adp.php?p_faqid=221&p_sid=4Lps7Ixk&p_lva=42&p_accessibility=0&p_redirect=&p_search_text=authorisation+transaction&p_widx=1





Transaction Type

Global E-Commerce Gateway Transaction Type

Description

Standalone Refund

refund Allows funds to be refunded from the merchant‘s account to the cardholder's account where there is no

previous auth or fulfill transaction.

The card number is required.

Merchants use the refund command to directly

perform the refund transactions from the merchant application.

Refund txn_refund Allows funds for a previously completed auth or

fulfill transaction to be refunded from the

merchant‘s account back to the cardholder's account.

The merchant does not need the card number to

perform a refund.

Any number of refund transactions can be performed

on the original transaction, but the total amount

refunded cannot be more than the original auth or

fulfill transaction.

There are two ways to refund the funds:

Manually via the merchant system portal. This is most suitable for small numbers of transactions.

Using the refund command to directly perform the

refund transactions from the merchant application.



Void capture cancel Allows merchants to cancel a previous fulfill

transaction in two stage processing mode. A cancel

must be performed before the batch containing the

original fulfill transaction is submitted for

settlement. This command cannot be used by merchants operating in one stage processing mode.

Only one cancel transaction can be performed on the

original fulfill transaction, as the function removes

the original fulfill transaction. Only the most recent

transaction for an order can be cancelled.

Neither the original fulfill transaction nor the

cancel transaction is included in the settlement file.

This function must be enabled for the merchant on the merchant account profile, and user privileges must be enabled.

There are two ways to perform a cancel against a

fulfill transaction:

1. 1. Manually via the merchant system portal. This is most suitable for small numbers of transactions.

2. 2. Using the cancel command to directly perform the

cancel fulfills from the merchant application.

Void refund cancel Allows merchants to cancel a previous refund

transaction. A cancel must be performed before the

settlement batch containing the original refund

transaction is processed by the acquiring bank. Only

one cancel transaction can be performed on the

original refund transaction as the function removes

the original refund transaction. Only the most recent

transaction for an order can be cancelled.


There are two ways to perform a cancel refund:


2. Using the cancel command to directly perform

cancel refunds from the merchant application.



Void purchase

cancel Allows merchants to cancel a previous auth

transaction. A cancel must be performed before the

batch containing the original auth transaction is

processed by the acquiring bank. It is not available for two stage processing mode merchants, and cannot be performed for debit and EBT transactions. Only one

cancel transaction can be performed on the original

auth transaction, as the function removes the original

auth transaction. Only the most recent transaction for

an order can be cancelled.


There are two ways to perform a cancel against an

auth transaction:


2. Using the cancel command to directly perform cancel auths from the merchant application

Query query Allows retrieval of details of a previous transaction by sending a request to the gateway.

Authorize transaction marked for referral

authorize_refe

rral_request

Allows merchants to proceed with the transaction which was ―referred‖ and an authorisation code has been manually issued.

3.8.1 Merchant Transaction Source

Merchant transaction source functionality allows a merchant to indicate the source of a Merchant Hosted transaction as follows:

Ecommerce

MOTO

IVR

If this field is not present the default value set in the merchant account profile is used.



3.8.2 Merchant Transaction Frequency – Repeat and Recurring Card Payments

In addition to single transactions (i.e. a transaction where a single payment is used to complete the cardholder's order), the Global E-Commerce Gateway can also process various types of repeat (recurring) transactions.

Merchants need a merchant ID capable of processing repeat transactions and the appropriate privileges to be able to perform repeat card payment transactions.

Recurring Payments - Merchants set up a Recurring Payments schedule with one instruction and the Global E-Commerce Gateway will manage all subsequent transactions. Recurring Payments are suitable where instalments are of fixed amounts, although the first and last payment may vary. For example, a home entertainment merchant could invoice a cardholder for a TV with regular payments spread over 36 months on a fixed payment plan.

Recurring Captures – Merchants send a recurring transaction set up request with the initial transaction made on a card. Subsequent instalment transactions are then sent through allowing the merchant to initiate each payment on that card. The amount and frequency of each instalment can vary. For example, a music download merchant could invoice a cardholder as and when they purchase music, regardless of the amount.

Pre-registered Recurring Captures – Merchants send a recurring transaction set up request with the initial transaction made on a card. The Global E-Commerce Gateway allocates a unique reference number to that card which allows merchants to send through subsequent instalment transactions using only this reference number. All card details are stored on MasterCard secure servers relieving the merchant‘s security liability. The amount and frequency of each instalment can vary. For example, a mobile phone merchant could invoice a cardholder each month for call charges and use this method to collect payment.



3.9 Global E-Commerce Gateway Integration Steps

Merchants need to perform the following steps to complete the Global E-Commerce Gateway integration.

1. Gather Support Documentation and Information

Merchants need:

Global E-Commerce Gateway Merchant Integration Guide

Example code for their website (written in ASP, JSP, PHP, .Net and Perl)

Global E-Commerce Gateway Testing Guide

A Merchant account

2. Choose an Integration Method

Merchants choose from:

Server Hosted method

Merchant Hosted method

A combination of both methods

3. Determine Any Optional Payment Functionality Required

Optional functionality includes:

3-D Secure cardholder authentication (e.g. MasterCard® SecureCode™, Verified by Visa™)

Two stage processing – separate pre transaction and fulfill transaction, including ―split shipment‖ transactions (allows multiple fulfil requests to be sent referencing the original pre)

refund transaction

standalone fulfill transaction

cancel fulfill transaction

cancel refund transaction

cancel auth transaction

Repeat (recurring) transactions (see this section)

Tokenisation (see Section 8)

AVS (see Section 7)

CSC (see Section 7)

Batch Input

Fraud and Risk Services

4. Obtain Account Password

When the merchant account is set up, a password is also provided. The password has a maximum lifetime of 12 months, and the merchant is responsible for changing it each time a person leaves the merchant‘s organisation.

5. Determine the Input and Output Fields

Merchants need to determine how to get the XML Request input fields and where to store the XML Response output fields in their application. Considerations include:

Session Variables – When using the Server Hosted method (with or without card details) some applications may require session variables to be



collected and sent to the Global E-Commerce Gateway server in the XML Request. The session variables are returned in the XML Response allowing the application to continue with the order process using the same application session.

Merchant Transaction Reference (merchantreference) – Merchants

need to determine how to produce a unique value for a transaction using

the merchantreference field.

6. Enable the Application Integration

To enable their application integration, merchants typically require a web developer familiar with both their application and the programming language used. This guide, together with the example code and Global E-Commerce Gateway Developers‘ Reference, provide the information and best practice guidelines to assist with this task.

7. Test the Integration

Merchants test their integration by performing transactions on the Global E-Commerce Gateway server acquirer test facility. They need to test all the response codes they are likely to encounter in production.

8. Conduct Pre-production Testing

Merchants should conduct final pre-production testing to validate end-to-end functionality, and depending on setup may want to include successful settlement of funds with Elavon.

9. Set Up in Production

After completing pre-production testing to confirm that the merchant integration works correctly, merchants need to advise their Payment Provider. The Payment Provider can then validate the test results and provide the merchant with a production account profile and instructions on how to change from test mode to production mode. This will enable the merchant to process live transactions with the acquiring bank.

10. Process Online Payments in Production

Merchants can now launch their payment enabled application and process online payments from cardholders.



3.9.1 Global E-Commerce Gateway Integration Guidelines

Merchants need to understand the merchant transaction reference field

(merchantreference) when integrating their payment application.

The merchantreference field is a unique identifier that the merchant assigns to

each transaction. This unique value is used by the merchant to query the Global E-Commerce Gateway server database to retrieve a copy of a lost/missing transaction receipt using a Merchant Hosted Transaction Query function. This value is displayed with the transaction in the merchant system portal, and can also be used in transaction search criteria.

Merchants can use a value such as an order number or an invoice number as the

merchantreference. To allow cardholders to repeat a transaction that was

declined and keep the same order number or invoice number, the

merchantreference must be modified by appending extra characters for each

subsequent attempt (e.g. merchantreference = '00789/1' on the first attempt,

'00789/2' on the second attempt, '00789/3' on the third attempt, etc.).

Under a fault condition (e.g. if the XML Response does not arrive back at the merchant's website due to a communication error), the merchant may need to check if the transaction was carried out successfully. Using a unique

merchantreference makes cross-referencing the transaction data easier when

performing a Transaction Query command to search the Global E-Commerce Gateway server database for the transaction. If each transaction attempt is not

given a unique merchantreference number the Transaction Query command

may not return the correct transaction attempt being searched for, as it only returns the most recent transaction.

3.9.2 Transaction Query

The Transaction Query command allows merchants to search for a transaction. The

search is performed on the Transaction ID key (datacash_reference) or

merchantreference, so these fields should contain a unique value.

Transaction Query does not return data for 3-D Secure Authentication Only transactions.

If the Transaction Query finds a transaction, the results will contain the same fields as the original transaction.

If there are multiple transactions that match the search criteria (e.g. if the

merchantreference that has been assigned by the merchant is not unique), only

the most recent matching transaction is returned. If the most recent transaction returned by the query is not the required transaction, the merchant must perform a manual search in the merchant portal.



3.9.3 Best Practice Payments Guidelines

Website Security

Merchants should ensure their web environment maintains appropriate security and adheres to PCI DSS guidelines.

Ensuring Payment Prior to Shipping

Merchants need to ensure the response integrity and the identification and authentication of the Global E-Commerce Gateway server during the payment process.

Where possible, they should implement the 3-D Secure services of MasterCard® SecureCode™ and Verified by Visa™.

3.9.4 Troubleshooting

This section contains suggestions and solutions to problems that may occur with Global E-Commerce Gateway integration.

Session Timeouts

The current Server Hosted payment timeout value is set at 15 minutes.

A current session may be terminated (e.g. by a communication failure) while a cardholder is entering the card details at the Global E-Commerce Gateway server. If the cardholder returns to the merchant site, it will be via a new session - the old session will not be completed.

To determine the status of the lost transaction, the merchant will need to perform a

Transaction Query based on the original merchantreference.

Cardholder Browser Support for Cookies

The Global E-Commerce Gateway requires a cardholder's browser to support cookies for all Server Hosted transactions.



4. Integrating Merchant Hosted Payments

In the Merchant Hosted payment method, the cardholder completes an order and provides card details ( card number, CVC and expiry date) to the merchant, rather than to the Global E-Commerce Gateway server, by Internet, Mail Order or Telephone Order (MOTO transactions) including Interactive Voice Response (IVR) systems.

The merchant carries the higher risk and responsibility of protecting the cardholders‘ card details.

4.1 Information Flow Steps

The information flow steps for the Merchant Hosted method are:

1. The merchant application collects the details of the cardholder‘s order.

2. The cardholder makes a purchase and provides card details directly to the merchant‘s online store.

3. The merchant application prepares the XML Request and sends it using HTTPS POST to the Global E-Commerce Gateway server.

4. The Global E-Commerce Gateway server passes the transaction to the network for authorisation.

5. After processing, the Global E-Commerce Gateway server generates an XML Response and returns it to the merchant‘s application. The XML Response indicates whether the transaction was approved or declined. The results should be stored by the merchant for future reference.

6. A receipt is displayed by the merchant to the cardholder.

4.2 The Cardholder Interface

With Merchant Hosted payments, the merchant integration captures the cardholder details and presents a receipt after the transaction has been processed by the Payment Provider.

Although merchants can implement Merchant Hosted payments with non-Internet based applications, an Internet connection is still required to interact with the Global E-Commerce Gateway server.

The cardholder is presented with two pages on the merchant‘s website:

The merchant‘s application checkout page—this is created as part of the merchant‘s application and displays the items the cardholder has selected to buy, including the total amount payable, and any taxes and delivery charges. The cardholder accepts the checkout details and payment amount, and proceeds to enter the card details.



The merchant‘s application receipt page—this confirms approval for the payment and shows the details of the items purchased. It typically provides a print option.

See Section 9 for Failure Scenarios.

4.3 Testing

Merchants must satisfy Global E-Commerce Gateway testing requirements before going live.

Comprehensive testing, including testing of error conditions, is essential.

For further details, see Section 10 Testing Overview.



5. Integrating Server Hosted Payments

In the Server Hosted payment method the Global E-Commerce Gateway server manages the payment pages and collects the cardholder's card details on the merchant‘s behalf.

The cardholder's browser is redirected to take the XML Request to the Global E-Commerce Gateway server to process the transaction.

The cardholder's browser is then returned to a web page nominated by the merchant in the transaction together with an XML Response.

The merchant sends a Transaction Query transaction to the Global E-Commerce Gateway server to get the results of the transaction.

For further details see the Global E-Commerce Gateway Developers‘ Reference and Global E-Commerce Gateway Developers‘ Reference Appendix3: Hosted Card Capture and Hosted Payments Service.

5.1 Integrating Hosted Card Capture (HCC)

The merchant manages the flow of XML requests to the Global E-Commerce Gateway server for transaction authorisation, including 3-D Secure authentication.

The merchant firstly sends a simple XML request which returns a session ID and URL. Together, the session ID and URL allow the merchant to redirect the cardholder to the HCC page for capture of the card details, and then return to the merchant site to complete the transaction.

HCC allows use of dynamic fields to capture additional cardholder information.

5.2 Integrating Hosted Pages (HPS)

The Global E-Commerce Gateway server manages the transaction authorisation and 3-D Secure authentication processes.

The merchant sends a comprehensive XML request for a HPS capture page containing all payment elements except card details. This returns a session ID, URL and gateway reference, enabling the merchant to display the HPS capture page to the cardholder for entry of the card details, which the Global E-Commerce Gateway then sends for authentication and authorisation.

HPS does not allow dynamic capture fields.

5.3 Using iFrames

The secure page for the entry of the card data may be displayed as an iFrame. An iFrame, or inline frame, is a HTML structure that places another HTML document into a HTML page (frame).



A customisable default page template is available for merchants.


The information flow steps for the Server Hosted method are:

1. The cardholder makes a purchase and provides shipping details to the merchant‘s online store checkout page.

2. The cardholder clicks a ‗pay‘ button and the online store redirects the cardholder's browser to the Global E-Commerce Gateway server.

3. The Global E-Commerce Gateway server displays screens to prompt the cardholder for the payment and card details.

4. The Global E-Commerce Gateway server passes the payment details to the network to process the transaction, then displays the transaction result—either a receipt number if it was successful or an appropriate information message if it was declined.

5. The Global E-Commerce Gateway server redirects the cardholder back to merchant's site. The merchant sends a Transaction Query transaction to the Global E-Commerce Gateway server to get the results of the transaction.

6. The online store interprets the response, displays the receipt and confirms the order to the cardholder.

5.5 Testing


Comprehensive testing, including testing of error conditions, is essential.

For further details, see Section 10 Testing Overview.



6. Integrating Authentication Only Transactions

The Global E-Commerce Gateway allows the merchant to perform a standalone 3-D Secure authentication. The payment is then processed later as a separate transaction.

To perform Authentication Only transactions, several different transaction types are required. Initially an enrolment check transaction must be performed which contains the details required to initiate the 3-D Secure authentication process, as well as the transaction details relating to the Authentication Only transaction. The response to this message indicates whether the cardholder is enrolled.

If the cardholder is enrolled, a validation authentication transaction is sent containing the PARes message returned from the ACS and a historic reference. A successful response to this transaction provides the merchant with enough 3-D Secure information to allow the merchant to submit the transaction for authorisation.


The information flow steps for the Authentication Only method are:

1. The merchant application collects the cardholder‘s card details and sends them to the Global E-Commerce Gateway.

2. The Global E-Commerce Gateway forwards them to the Directory Server to determine whether the card is enrolled for 3-D Secure, and sends an appropriate message back to the merchant.

3. If the card is enrolled, the message includes the PAReq, which contains details required for the merchant to redirect the cardholder to the Access Control Server page of the issuing bank to perform the authentication process.

The message also includes the information required to redirect the cardholder back to the merchant‘s website once authentication is complete.

4. The redirection process passes back the PARes from the issuing bank which contains information about the result of the check.

5. If the cardholder is not enrolled, the merchant‘s website proceeds to the next step.

6.2 Testing


Testing for 3-D Secure requires specific set up with the Global E-Commerce Gateway and use of specific test cards.

For further details, see Section 10 Testing Overview and the Global E-Commerce Gateway Testing Guide.



7. Securing Payment Transactions

This section covers payment security features.

7.1 3-D Secure Payment Authentication

The 3-D Secure protocol is used for MasterCard® SecureCode™, Verified by Visa™, JCB J/Secure™ and American Express SafeKey® to reduce credit card transaction fraud by attempting to authenticate cardholders and ensure that the legitimate owner is using the card.

The 3-D Secure authentication is performed immediately before a merchant performs a pre (authorisation) or fulfill transaction.

Merchants wanting to use 3-D Secure need to request a 3-D Secure enabled merchant account profile from their Payment Provider.

7.2 Merchant Hosted 3-D Secure Summary

The merchant's application collects the cardholder's card details and sends them to the Global E-Commerce Gateway.

Once the payment and cardholder details have been received, the Global E-Commerce Gateway forwards them to the Directory Server which determines whether the card is enrolled for 3-D Secure.

A message containing the results of the enrollment check is passed back to the merchant.

If the card is enrolled, this message includes the payment authentication request (PAReq), which contains the details required for the merchant to redirect the cardholder to the Access Control Server (ACS) page of the issuing bank to perform the authentication process.

It also contains the information required to redirect the cardholder back to the merchant‘s website once authentication is complete.

This redirection process also passes back the payment authentication response (PARes) generated by the issuing bank which contains information about the result of the check.

For cards not registered for 3-D Secure, the merchant may continue with the authorisation process if required.

For further details, see Global E-Commerce Gateway Developers‘ Reference Appendix 1 – 3-D Secure.



7.3 Server Hosted 3-D Secure Summary

The Global E-Commerce Gateway server collects the cardholder's card details and forwards them to the Directory Server which determines whether the card is enrolled for 3-D Secure.

A message containing the results of the enrollment check is passed back to Global E-Commerce Gateway server.

If the card is enrolled, this message includes the payment authentication request (PAReq), which contains the details required for the server to redirect the cardholder to the Access Control Server (ACS) page of the issuing bank to perform the authentication process.

It also contains the information required to redirect the cardholder back to the merchant‘s website once authentication is complete.

This redirection process also passes back the payment authentication response (PARes) generated by the issuing bank which contains information about the result of the check.

For cards not registered for 3-D Secure, the merchant may continue with the authorisation process if required.

For further details, see Global E-Commerce Gateway Developers‘ Reference Appendix 1 – 3-D Secure.

7.4 Address Verification Service (AVS)

The Address Verification Service (AVS) is a security feature used for card-not-present transactions that compares the billing address entered by the cardholder with the address held in the card issuer's database.

An AVS result code is returned in the XML Response message indicating the extent to which the addresses match (or fail to match). The merchant‘s application is responsible for deciding how to handle the payment transaction on the basis of the AVS result code.

If an issuing bank does not support AVS, it will return an appropriate result code in the transaction response to indicate it is not supported.

For further details, see the Global E-Commerce Gateway Developer‘s Reference.

7.5 Card Security Code (CSC)

The Card Security Code (CSC) is a security feature used for card-not-present transactions that compares the Card Security Code on the card with that held by the card issuer.

CSC validation is mandatory in some countries and regions. Some issuing banks, however, do not support CSC validation, and even though CSC data may be included in a transaction message, those issuing banks will return a CSC response code to indicate it is not supported.



On MasterCard and Visa credit cards, the CSC is the three-digit number printed on the signature panel on the back as shown here.

On American Express cards, the CSC is the four-digit number printed on the front above the credit card account number.

The CSC data is never stored or retained.

In a standard Server Hosted transaction the Global E-Commerce Gateway server requests the CSC from the cardholder.

The level of the match between the cardholder‘s CSC held by the issuing institution and the CSC provided by the cardholder in the transaction determines if the transaction will be accepted or declined.

For some Payment Providers, a CSC result code is returned which indicates the level that the CSC provided matches the CSC held by the cardholder‘s issuing institution. This may not always be provided and the result code may indicate that the CSC is ―Unsupported‖.

Where the CSC is not accepted the transaction is declined with Status field = ―7‖ for a ―Bank Declined Transaction‖.

For further details, see the Global E-Commerce Gateway Developer‘s Reference.

7.6 Transaction Integrity

The following guidelines may be used by merchants to maximise transaction integrity.

Use a unique merchant transaction reference for each transaction attempt

Each transaction attempt should be assigned a unique merchant transaction reference

(merchantreference).



Most applications and web programming environments generate a unique session for each cardholder which can be used as the unique merchant transaction reference to be returned in the XML Response.

Alternatively, a unique merchant transaction reference can be created by combining an order number or invoice number with a payments attempt counter. A timestamp may also be appended to the transaction reference ID to ensure that each one is unique.

Before sending a transaction to the Global E-Commerce Gateway server, the unique merchant transaction reference should be stored with the order details in the merchant‘s database.

A unique merchant transaction reference is required to reliably use the Transaction Query function to search for and retrieve transaction details.

Check that the field values in the response match those in the request

Ensure that important fields in the XML Response—such as the amount and the merchant transaction reference—match the values input in the original XML Request.

Store card numbers securely

It is recommended that merchants do not store credit card information in their website database. Where card numbers must be stored they should be securely hardware encrypted, or stored as masked values.

Use suitable password security

Merchants should choose a password that is difficult to guess and should change it regularly. A good password should be at least 8 characters and should contain a mix of capitals, numbers and special characters.

Validate the SSL certificate of the Global E-Commerce Gateway server

The SSL certificate of the Global E-Commerce Gateway server should be validated upon connection. The Global E-Commerce Gateway server SSL certificate is issued by an industry standard Certificate Authority whose root certificate should already be available in the merchant‘s Internet environment.



7.7 Fraud Management

The Global E-Commerce Gateway offers an optional, value added fraud management service.

It enables merchants to apply standard or customised sets of risk rules to screen their transactions either in real time or offline.

Transactions may be screened and cross-referenced against matrices and data models, as well as against in-house and external data sources to generate a risk score based on rules for:

Transaction validation

Purchase amount

Velocity series for the card number, email address, IP address

Blacklists, greylists and whitelists for the card number, email address, IP address, merchant, etc.

Information inconsistency/mismatch such as issuer and IP country, issuer and delivery country

Product details vs. risk

Scheme verification rules such as CSC and AVS.

Based on the risk score, transactions may be accepted, rejected or marked for review based on a manual assessment.

The web-based fraud management service portal is used for:

Case management of transactions flagged for review (referrals)

Transaction searching

Reporting and administration.

The following shows an example of a transaction screening result by the fraud management service, including the overall risk score, and the negative and positive rules triggered by the screening.



Sample fraud management service screening result screen

For further details, see the Global E-Commerce Gateway Developer‘s Reference Guide, Appendix 6.



8. Tokenisation Service

8.1 Introduction

Tokenisation is a mechanism for storing card data relating to a transaction without storing the actual card number (PAN).

The tokenisation service enables merchants to submit card data to the Global E-Commerce Gateway and have unique tokens returned that offer the same functionality of a card number, but without the related data security implications.

Each token generated during the tokenisation process is unique to a particular card number and merchant.

While storing a token alleviates some of a merchant‘s responsibility with respect to PCI-DSS it does not remove it completely. A merchant who captures card data before passing it to the Global E-Commerce Gateway is still responsible for ensuring PCI-DSS compliance.

To use tokens with Global E-Commerce Gateway, a merchant must be signed up for the Tokenisation Service. To do this, the merchant should contact technical support.

8.2 Generating Tokens

8.2.1 Requirements

To use the Tokenisation Service, a merchant requires:

A Global E-Commerce Gateway account configured for tokenisation;

A shared secret set up (optional);

A tokenisation group set up that allows merchants with multiple vTIDs to use shared tokens between those vTIDs. This is still a requirement if a merchant has a single vTID;

vTID accounts set up to use the tokenisation service within the vTID

8.2.2 Token Format

Each token is 40 characters, irrespective of card number length. Tokens are generated according to the following rules:

Tokens may be made up of uppercase English letters A to Z, and digits 0 to 9

Where used, a shared secret must be 20 characters (which may be uppercase English letters A to Z, and digits 0 to 9) in length, and the tokens must be generated using the shared secret.



8.2.3 Token Generation

The two ways to generate a token using the Tokenisation Service are:

By using a specific transaction type and specialised token generation message, where the transaction response generates the token. It is not necessary to supply the expiry date and other card information to generate a token.

The tokenisation transaction request may optionally include the shared secret.

The tokenisation transaction may be submitted as a single transaction, or multiple tokenisation transactions may be submitted via the batch input service.

As a by-product of performing a transaction request where, if a merchant is using the Tokenisation Service, the transaction response received for a successful card transaction request will include a token.

The transaction request may optionally include the shared secret.

The algorithms used by the Tokenisation Service to generate tokens will not generate the same token for any two card numbers for a merchant.

8.3 Using Tokens

A merchant using the Tokenisation Service, and who has received a token in response to a transaction request, or has had a token generated as part of a tokenisation transaction request, may supply the token in place of a card number in any subsequent transaction for that card.

Merchants with multiple vTIDs using a tokenisation group which has a shared secret configured may send a shared secret per transaction which is used instead of the vTID group shared secret.

8.3.1 Payment Transactions Using a Token

Merchants continue to use the same transaction format as before but replace the card number with a token and qualify the transaction to flag that a token is being used by using pan type=‖token‖ in the XML.

Although the card number is replaced with the token, the expiry date and, optionally, the CVV still have to be provided.

8.3.2 Retokenize Transactions

If a shared secret is changed, a merchant can continue to use the old token or can generate request for a new token (retokenize) using a new shared secret.



8.4 Other Uses

8.4.1 Query Transaction

Where a merchant is using the Tokenisation Service, the token generated by a transaction is returned as part of a query transaction for transactions performed after the merchant has been set up for the service.



9. Technical Integration Overview

9.1 Introduction

About the XML Request

The XLM Request is used to create a transaction in both the Server Hosted and Merchant Hosted methods.

About the XML Response

The XML Response contains a unique Transaction ID generated by the Global E-Commerce Gateway.

This Transaction ID should be stored in the merchant‘s order database as part of the transaction record in case a refund or void is required to be performed manually using the merchant system portal.

The Transaction ID or a unique messagereference is required for the Transaction Query. If the messagereference cannot be guaranteed to be unique the merchant should use the Transaction ID in Transaction Query requests.

9.1.1 Secure Access

Merchants are provided with a secure password (or secure secret) as part of their registration with their bank. This data must be handled securely at all times and stored in a file or database field that is only visible to authorised users or applications.

9.2 Integrating with the Global E-Commerce Gateway

Each method of processing requires particular information to be submitted and this information tends to be grouped within similar areas (parent elements) of the XML schema. The names of the parent elements are first introduced.

Each parent is then placed into its context in the schema and its child elements discussed. This includes any restrictions on the format, length and transaction type of each element.

There are certain features of the XML Request and XML Response that are applicable to all services—these elements are covered in this section. Other features are only used for a particular service or group of services—these elements are covered in the documentation for that service.

For a detailed description, refer to the Global E-Commerce Gateway Developers‘ Reference and appropriate Appendices.

Overviews of the XML Request and XML Response are as follows:



9.2.1 The XML Request

XML Requests must contain the version designation as follows:

<Request version=’2’>

The following information needs to be collected from the cardholder for every transaction (i.e. for every transaction that uses the card number – this does not apply where tokenisation is used):

the card number

the expiry date of the card

NOTE: in the case of Server-Hosted Payments, the Global E-Commerce Gateway will collect this data on behalf of the merchant.

To ensure each item of information required for each card is collected, card information files are provided. Each time a payment is entered onto the merchant system these files can be used to ensure all required fields have been completed before the transaction is submitted.

The card information files may be used to perform basic validation of the card information before submission, however, because there is no guarantee of the accuracy of information, these files:

should not be used to automatically reject cards

should not be used as a fraud prevention technique

do not guarantee authorisation of a successfully validated card.

These files also contain other information which can be utilised if required.

In addition to the card information, the following details about the transaction are also required:

the value and currency of the transaction

a unique reference number generated by the merchant system to allow the transactions to be distinguished from each other

the transaction type to allow the correct processing model - one of pre, auth, or refund.

Additional information fields may be required when using other features.

The XML Request is prepared using these fields.

For the Server Hosted method, the return URL to which the Global E-Commerce Gateway server needs to redirect the cardholder must also be included. At this point in the process the cardholder session with the merchant application is interrupted while the cardholder is redirected to the Global E-Commerce Gateway server.

9.2.2 The XML Response

XML Responses will contain the version designation as follows:



<Response version=’2’>

For the Server Hosted method the browser returns the XML Response to the merchant‘s website.

There are various results that can be returned for transactions. These can be clustered into two groups:

Bank Responses – the transaction is submitted to the bank

Error codes – an error occurred which prevented the transaction from being sent to the bank.

If the transaction is submitted to the bank, the bank can either accept, decline or refer the transaction. Example response codes for status 1 and 7 are shown here.

Status Meaning

1 The bank has authorised the transaction

7 The bank has declined or referred the transaction

All others All other responses are error codes

For a complete list of response codes see the Global E-Commerce Gateway Developers‘ Reference.

9.3 Failure Scenarios

In normal Server Hosted method conditions, the cardholder is redirected back to the merchant website once the payment transaction has been processed. Merchants need to keep track of orders that have been started for which the cardholder does not return.

Merchants need to carefully manage inventory (or stock or ticket allocation) to determine whether the cardholder abandoned the order, or whether the payment was successful and the order can be receipted manually (or via email for instance). In this scenario, the merchant application will not be provided with a Global E-Commerce Gateway generated Transaction ID, and the merchant will need to query the Global E-Commerce Gateway with the unique Message Reference supplied in the corresponding XML Request message.

At any point between the merchant application sending a redirect to the cardholder (shopper) and the cardholder returning to the merchant website there can be a failure in communications. For example, the cardholder may choose to go to a different website or the Internet connection may fail. This will lead to a ―hanging‖ (or ambiguous) order state in the merchant‘s system. To address this scenario, the Global E-Commerce Gateway provides a method by which merchants can determine the status of all orders.

Using either the Global E-Commerce Gateway generated Transaction ID or a unique Message Reference provided by the merchant application, a Transaction Query is performed to determine the status of a transaction at any time.

The Transaction Query can also be used in the Merchant Hosted method if no response is received for an XML Request.



Depending on the volume of transactions expected to be processed, the following suggestions are provided for ―cleaning up‖ failed transactions.

Low volume, non time critical stock holding

For low volume e-commerce merchants where the goods dispatch is predominantly manual, the suggested approach is to review all ―hanging‖ orders manually just prior to shipment. The final status of these orders can be determined by performing a Transaction Query using the Transaction ID received at transaction initiation.

Medium volume and time critical stock holding

It is assumed that a seat or ticket allocation can be held open for a fixed, relatively short period of time. Just prior to the process of relinquishing a reserved booking, merchants should perform a Transaction Query using the captured Transaction ID received at transaction initiation to determine if a payment was successful. A report of failed transactions should be logged in case of a customer inquiry.

High volume, high-level integration

A fully integrated system will include a ―clean up‖ routine running in the background of the application. This routine will sweep through the current incomplete orders and attempt to update the status of the transaction by issuing a Transaction Query after the order has been ―hanging‖ for a certain amount of time. The routine will then finish up an order based on the final transaction state.

Suggested timings are to query a transaction at 30 minutes after the initial XML Request and then an hour later if required. If the transaction is still in an incomplete state at that time then revert to a manual process to finish the clean up.

Depending on the merchant business it may also be necessary for an operator to be able to query on an ad hoc basis.



9.4 Other Considerations

9.4.1 Transport Layer

The transport layer for Global E-Commerce Gateway messages is standard HTTPS over the Internet. The merchant host posts all messages to the Global E-Commerce Gateway. All messages between the merchant host and the Global E-Commerce Gateway will be encrypted by SSL (TLS/SSLv3 with minimum 128 bit symmetric cipher strength) and server authenticated.

9.4.2 Merchant Authentication

There is a password shared between the merchant software and the Global E-Commerce Gateway. This password will be provided to the merchant by the bank once the merchant‘s integration development is complete.

The password must be stored securely, either in a secured database, or in a file that is not directly accessible by the merchant‘s web server and has suitable system security permissions. It must not be stored within the source code of an ASP, JSP or other website page as it is common for web server vulnerabilities to be discovered where the source code of such pages can be viewed.

9.4.3 Messaging

All interactions between the merchant software and the Global E-Commerce Gateway will be ―request-response‖ utilising the standard HTTPS over the Internet, with the exception of the interaction via cardholder browser redirects. All interactions will be initiated by the merchant software and all communication will occur over the publicly available Internet.



10. Testing Overview

For details on testing, see the individual appendices to the Global E-Commerce Gateway Developers‘ Reference, the Global E-Commerce Gateway Testing Guide or contact technical support.

10.1 Overview

The Global E-Commerce Gateway operates a production system and a test system.

Merchants apply for an account for the test system and validate their integration and transaction processing on the test system before attempting to process in production.

No transactions on the test system are forwarded to the banks and no funds are transferred. Instead, a set of test numbers can be used to generate automated responses which look as if the banks have been contacted.

The test system can be set up (on request) to match a merchant‘s live situation. For example, the currencies and services can be configured to reflect the merchant‘s production account.

Once testing is completed satisfactorily, merchants can begin processing transactions on their production account.

https://datacash.custhelp.com/cgi-bin/datacash.cfg/php/enduser/std_adp.php?p_faqid=47&p_sid=gII*Mkvk&p_lva=310&p_accessibility=0&p_redirect=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9MTQzLDE0MyZwX3Byb2RzPTAmcF9jYXRzPTAmcF9wdj0mcF9jdj0mcF9wYWdlPTEmcF9zZWFyY2hfdGV4dD10ZXN0aW5n&p_li=



11. Glossary

Term Index Reference Description

3-D Secure Section 7;

Global E-Commerce Gateway Developers‘ Reference Appendix 1

A data encryption standard protocol used to reduce credit card transaction fraud by attempting to authenticate cardholders and ensure that the legitimate owner is using the card.

Access Code An identifier that is used to authenticate the merchant while using the Global E-Commerce Gateway.

The access code is generated and allocated to the merchant by the merchant system portal.

Acquiring Bank

(Acquirer)

The bank where the merchant‘s business account is maintained and settlement payments are deposited. This is normally the same bank with which the merchant has a merchant facility for acceptance of online credit card payments.

Address Verification Service

(AVS)

Section 7 A security feature used for card-not-present transactions that compares the billing address entered by the cardholder with the address held in the card issuer's database.

Authentication Only Transactions

Section 6;


Standalone 3-D Secure authentication transactions.

Card Token Section 8;


The identifier for the stored card details that may be used later to refer to the card details to for a payment transaction.

Card Security Code

(CSC)

Section 7 A security feature used for card-not-present transactions that compares the Card Security Code on the card with that held by the card issuer.



Hosted Card Capture

(HCC)

Global E-Commerce Gateway Developers‘ Reference Guide Appendix 3

The merchant manages the flow of XML requests to the Global E-Commerce Gateway for transaction authorisation, including 3-D Secure authentication.

Hosted Pages

(HPS)

Section 3;

Global E-Commerce Gateway Developers‘ Reference Guide;

Global E-Commerce Gateway Developers‘ Reference Guide Appendix 3

The Global E-Commerce Gateway manages the transaction authorisation and 3-D Secure authentication processes.

iFrame

(inline frame)

Section 4 A HTML structure that places another HTML document into a HTML page (frame). The secure page for the entry of card data may be displayed as an iFrame.

Issuing Bank

(Issuer)

The bank or financial institution that issues credit cards to cardholders.

Merchant Hosted Section 3;

Global E-Commerce Gateway Developers‘ Reference Guide

Method of implementing the Global E-Commerce Gateway where the merchant‘s application communicates directly with the Global E-Commerce Gateway server, so the cardholder does not leave the merchant‘s website and the session is not split

merchantreference Section 3 A unique identifier that the merchant assigns to each transaction, such as an order number or an invoice number.

Merchant system portal

The web portal that allows the merchant to monitor and manage electronic transactions.

Global E-Commerce Gateway

The interface that provides secure communication between the Global E-Commerce Gateway server and the merchant application, and which enables processing of payments with the merchant‘s bank. It permits a merchant application to directly connect using the HTTPS protocol in the merchant's chosen programming language.

One Stage Processing

Section 3 A processing method where only one transaction is required to complete the processing.



Payment Provider Provides the merchant with gateway services and support.

The merchant‘s Payment Provider may be the acquiring bank or a third party technology services provider.

Global E-Commerce Gateway server

Facilitates the processing of secure payments in real time over the Internet between the merchant application/website and the Payment Provider.

All communications between the cardholder, the merchant application, the Global E-Commerce Gateway server and the Payment Provider are encrypted.

PCI-DSS The Payment Card Industry (PCI) Security Standards Council offers robust and comprehensive standards and supporting materials to enhance payment card data security. The PCI Data Security Standard (PCI DSS) provides a framework for developing a robust payment card data security process.

Pre-registered recurring Payments

Section 3 Uses pre-registered card functionality so that manually initiated recurring transactions can be triggered without the merchant retaining the card data.

Recurring Captures

Section 3 Manually initiated recurring payments.

Recurring Payments

Section 3 Automated recurring payments.

Server hosted Section 3;

Global E-Commerce Gateway Developers‘ Reference

Method of implementing the Global E-Commerce Gateway where the merchant redirects the cardholder to the Global E-Commerce Gateway server for the cardholder to enter the card details. The two server hosted options are Hosted Card Capture and Hosted Pages.

Split shipment transaction

Section 3 Transaction that allows multiple fulfill requests to be sent referencing the original pre authorisation. This also ensures that an authorisation which is over seven days old at the point of fulfillment will be sent to the acquiring bank for re-authorisation, thereby ensuring the authorisation code is still active. An additional re-authorisation stage may be added to the payment flow.

Transaction A combination of an XML Request and an XML Response. For each cardholder purchase or order, merchants may issue several transactions.



Tokenisation Section 8;


A mechanism for storing card data relating to a transaction without storing the actual card number (PAN).

The tokenisation service enables merchants to submit card data to the Global E-Commerce Gateway and have unique tokens returned that offer the same functionality of a card number, but without the related data security implications.

Each token is unique to a particular card number and merchant.

Storing tokens alleviates some of a merchant‘s responsibility with respect to PCI-DSS.

Transaction Query Section 3 The Transaction Query command allows merchants to search for a transaction. The search is performed on the Transaction ID key (datacash_reference) or merchantreference,

Transaction Source

Section 3 Transaction source functionality allows a merchant to indicate the source of a Merchant Hosted transaction as follows:

- Ecommerce - MOTO - IVR

Transaction Type Section 3 Type of card transaction or other transaction that may be processed using the Global E-Commerce Gateway.

Two Stage Processing

Section 3 A processing method where two separate transactions are required to completed the processing.

XML Request Section 9;


A request to the Global E-Commerce Gateway server to provide transaction information.

XML Response Section 9;


A response from the Global E-Commerce Gateway server indicating the outcome of the transaction.

Documents

Global E-Commerce Gateway Merchant€¦ · Global E-Commerce Gateway Merchant Integration Guide ... The Global E-Commerce Gateway provides a secure and standardised interface for