Globalone API V 2.6.3

XML API Integration Guide
Version 2.6.3
July 10th,2015
GlobalOne
XML Integration Guide v.2.6.3
For support contact

integration@merchant-support.com
1-866-874-0029
2
2015 Pivotal Payments Direct Corp. All rights reserved. This material is not to be reproduced, disclosed, or used except in accordance with
program license or other written authorisation of Pivotal Payments. All other trademarks, service marks, and trade names referenced in this
material are the property of their respective owners
GlobalOne
Table of Contents
1
Introduction .......................................................................................................................................... 7
Choosing an Integration Method .......................................................................................................... 7

2.1 Scope ................................................................................................................................................ 7
2.2 Integration Methods to Consider .................................................................................................... 7
2.2.1
Hosted Payment Page ............................................................................................................. 7
2.2.2
XML Gateway .......................................................................................................................... 8
2.3 Costs ................................................................................................................................................. 9

2.3.1
Items for Consideration........................................................................................................... 9
2.4 A Word on Functionality .................................................................................................................. 9

3
Secure Communication/Card Types Supported.................................................................................. 10

3.1 Secure Communication with HASH Parameters ............................................................................ 10
3.2 Card Types...................................................................................................................................... 10
3.3 Multi-Currency Terminal IDs .......................................................................................................... 10
3.4 Integration and Validation Procedure ........................................................................................... 11
3.4.1
GlobalOne Testing Guide ...................................................................................................... 11
3.4.2
Merchant Validation Document............................................................................................ 11
Hosted Pages....................................................................................................................................... 11
4.1 Hosted Page Styling ....................................................................................................................... 12
4.2 Basic Mode Styling ......................................................................................................................... 13
4.3 Advanced Mode Styling ................................................................................................................. 14
Hosted Pay Page.................................................................................................................................. 15

5.1 Test Credentials ............................................................................................................................. 15
5.1.1
Sandbox Test Details ............................................................................................................. 15
5.1.2
Test Cards .............................................................................................................................. 15
5.2 MaxMind MinFraud (Where Available) ......................................................................................... 15

5.3 Payment Page ................................................................................................................................ 16
5.4 Hosted Pre-Auth Page .................................................................................................................... 20
5.5 Background Validation ................................................................................................................... 20
3
GlobalOne
5.6 Hosted Pages in iFrame Format ..................................................................................................... 22

5.7 SecureCard Storage via Hosted Payment Page.............................................................................. 22
6
XML Payments Integration.................................................................................................................. 24

6.1 Test Credentials ............................................................................................................................. 24
6.1.1
Sandbox Test Details ............................................................................................................. 24
6.1.2
Test Cards .............................................................................................................................. 24
6.2 MaxMind MinFraud (Where Available) ......................................................................................... 25

6.3 Request Types ................................................................................................................................ 25
6.3.1
XML Payments ....................................................................................................................... 25
6.3.2
Pre-Authorization Request .................................................................................................... 31
6.3.3
Pre-Auth Completion Request .............................................................................................. 35
6.3.4
Refunds ................................................................................................................................. 37
6.4 XML Requests with eDCC (Where Available) ................................................................................. 42

6.4.1
eDCC Exchange Rate Request ............................................................................................... 42
6.4.2
eDCC Information in the XML Requests ................................................................................ 45
6.4.3
Transaction Status Updates .................................................................................................. 47
6.4.4
Retrieve Foreign Currency Exchange Rates........................................................................... 49
6.5 3D Secure for XML transactions (Where Available)....................................................................... 51

7
Secure Card Storage ............................................................................................................................ 54

7.1 Secure Card Registration and Updating from the Hosted Page .................................................... 54
7.2 XML Secure Card Integration ......................................................................................................... 56
7.2.1
Secure Card Details Registration and Updating .................................................................... 56
7.2.2
Card Detail Removal .............................................................................................................. 59
7.2.3
Card Details Search ............................................................................................................... 60
7.2.4
XML Payments Using a Stored Secure Card .......................................................................... 62
Subscriptions ....................................................................................................................................... 63
8.1 Subscription Registration From Hosted Pay Page.......................................................................... 63
8.2 XML Subscription Integration ........................................................................................................ 66
8.2.1
Stored Subscription Request ................................................................................................. 66
8.2.2
Stored Subscription Deletion Request .................................................................................. 69
8.2.3
Subscription Creation Request .............................................................................................. 71

4
GlobalOne
8.2.4
Update Subscription Request................................................................................................ 74
8.2.5
Subscription Deletion Request .............................................................................................. 76
8.2.6
Subscription Payments Request ............................................................................................ 77
8.2.7
Subscription Notifications ..................................................................................................... 79
Bulk Payments..................................................................................................................................... 81
9.1 Request File Submission ................................................................................................................ 81
9.2 Request CSV File Format ................................................................................................................ 82
9.3 Request File Submission Response ................................................................................................ 82
9.4 Response File Request ................................................................................................................... 83
9.5 Response File Format ..................................................................................................................... 84
Appendix A: CVV & AVS Responses ............................................................................................................ 85

CVV results: ............................................................................................................................................. 85
AVS results: ............................................................................................................................................. 85
Appendix B: Supported Currencies ............................................................................................................. 87
Appendix C: Bank Response Codes ............................................................................................................. 89
Glossary ....................................................................................................................................................... 91
Version Control
Author
Raj Sandhu
Version
2.6.3
Date
14/07/2015
Raj Sandhu
2.6.1
07/11/2014
Raj Sandhu
2.6
06/10/2014
Changes
Updated TOC; Added new section 4 Hosted Pages, 4.1
Hosted Page Styling, 4.2 Basic Mode Styling, 4.3,
Advanced Mode Styling; Update under XML Payments
section 6.3.1 added Recurring Payment Flagging and
under Pre-Authorization Request. Updated Test Card
details under section 6.1.2. Updated under Request File
Submission added /submit to test link
Under XML Payments section 5.6.1 added MSR/CHP to
TRACKDATA added new terminal type #3 Cardholder
Present & #0 Cardholder Present (CHP) transaction, also
added new note #4. Added +BANKRESPONSECODE+ to
hash return in section 5.6.1 under note #2b; Updated
glossary with MSR & CHP description
Removed Section 2.4.1, added new notes #2 Under
Section 5.3.2 added +BANKRESPONSECODE+, Added
new Section 5.7, Added Appendix C for response codes,
under Section 6.3.1 modified & added new Field
Names; XID,CAVV,MPIREF,DEVICEID,CUSTOMFIELD also
added BANKRESPONSECODE. Under Section 6.3.1 Notes
5
GlobalOne
Raj Sandhu
2.5
11/08/2014
Kevin Goddard
2.4
22/07/2014
Kevin Goddard
2.3
17/04/2014
Kevin Goddard
2.2
11/03/2014
Kevin Goddard
Kevin Goddard
2.1
2.0
24/02/2014
17/02/2014
#2a added BANKRESPONSECODE and added new note

#3. Under Section 6.3.2 under Field Name added
BANKRESPONSECODE, modified note #2 under section
6.3.4.2 also corrected the respond hash calculation; and
under Section 7.1 removed MERCHANT and replaced
with REFERENCE, removed AVSONLY Under Section
5.3.1 XML Payments table, & updated TOC
Changed ORDERID to UNIQUEREF in Section 4.3
Section4.5 and section 7.2.6.Added new section 5.4.3
Transaction Status Updated
Added note about pre-auths, added information to card
expiry and cardholdername in sect 5 XML Payment
Integration, added processing terminal sect 5, Deleted
reference and added payment request fields section
under Pre-Auth Requests, added section under
unreferenced refunds, carddetails tag in XML requests.
Changed references to UTF8 to UTF-8, Added section
5.4.3 FX Terminal Rates Lookup, Added 7.2.7
Subscription Notifications, added user setup section
added currency table
Added section on Testing Guide and merchant
Validation, added two successful trx per trx type
required. Removed reference to MCP in hash for
preauth. Update URL to globalone.me. Changed
GlobalONE to GlobalOne
Added Development team modifications
Revised Version
6
GlobalOne
1 Introduction
The GlobalOne system is a secure server-based transaction processing service that will enable your
business to authorize and process credit/debit card transactions online in real-time. The information
needed to process the transactions is sent over a secure, encrypted Internet connection.
Once the customer has completed the payment or pre-auth form, the GlobalOne server connects
with your acquiring bank for payment authorization and if the sale is authorized, returns a receipt to the
customer. GlobalOne settles the transactions automatically and the acquiring bank deposits the funds
into your bank account. GlobalOne automatically archives sales that are finalized so that you can refer to
them at a later date, if necessary.
This guide provides instructions on how to integrate a website or application into the system and
hence take automatic credit card payments.
2 Choosing an Integration Method

There are two integration methods available to GlobalOne; the Hosted Payment Page and full XML
integration. You can use one or a combination of them as required, but you should consider the
integration method carefully before starting any development planning.
2.1 Scope
This section may be used as a guide to help you decide to most appropriate method of
Integrating with the GlobalOne gateway. It is intended for review after you have decided upon your
Merchant Account but before you start integrating with us. All costs should be considered including
integration cost, ongoing maintenance costs, PCI DSS compliance costs and GlobalOnes own charges.
Different technologies, languages, consumer industries, server environments and other technical
challenges should also be considered.
2.2 Integration Methods to Consider

2.2.1
Hosted Payment Page

The Hosted Payment Page (HPP) has been created as a method for small-to medium sized
organizations to integrate their websites with our payment gateway.
7
GlobalOne
This is a hosted service with the highest levels of Internet security, whose appearance can be
customized to look just like your site. This is solely for use as a payment gateway for websites.
The benefits of the HPP:
SSL certificate Costs: PCI DSS requires that web pages accepting credit card information must
have SSLv3 128-bit minimum certificates. Our host has a 128-bit to 256-bit certificate with full
"green bar" functionality for extra customer confidence. The equivalent certificate from VeriSign
is the "Secure Site Pro with EV" which currently costs upwards of $1,500/year.
PCI considerations: PCI also states that any site accepting card information must NEVER store
the CVV, and if it does store the card number, it must be 256- bit AES encrypted. Most web
servers log traffic to and from them, which may include card numbers. These logs would have to
be audited on a continual basis to ensure that card numbers are not being stored. Also, if you
accept any sensitive card information on your site you jump up from a PCI SAQ A (SelfAssessment Questionnaire) to an SAQ D. The required documentation grows significantly at this
point
Ease of integration: As opposed to other integration methods, the HPP integration is VERY
simple. You just have to submit a simple web form to us and then display the response that our
host sends back.
Functionality Deployment: The robust functionality of GlobalOne may be added to the HPP
without additional development. As a result you may offer your customers with the many
features of GlobalOne quickly and easily.
Plug-in availability: Off the shelf Hosted Payment Page plug-ins have been developed for many
popular shopping carts. Please contact our integration team for a list of current carts
supported.
iFrame implementable: If you do not want the customer to leave your site you can implement
the HPP within a frame. This is preferable for some merchants, but also means that the
customer will not see the green bar that would be displayed otherwise.
2.2.2
XML Gateway
The XML gateway is intended for larger, more complex integrations. This method offers full access
to all of our products and functionality through a high speed, common platform gateway.
As a result the payment and related functionality is seamlessly integrated into your existing
corporate infrastructure.
8
GlobalOne
Companies using the XML gateway must maintain their own security and are subject to rigorous PCI
security criteria.
Benefits of the XML gateway:
Access: All of our products can be accessed through the XML gateway, whether you want to process
a payment, register card information for secure storage on our system, setup a recurring payment,
check the status of existing subscriptions or refund a customer. Other related functionality may be
available depending on your merchant agreement and specific needs.
Site integration: For a seamless experience, XML site integration may be more beneficial to an
organization. Cards may be securely billed via tokenization, allowing for easy, yet secure PCI
compliant reoccurring billing.
Integration to CRM/Internal Systems: Larger more complex companies may require an interface to
CRM or accounting systems. This is more easily achieved when data is passed via XML.
Control: XML integrations give your company more control over the flow of data, assuming it meets
PCI compliance.
2.3 Costs
2.3.1
Items for Consideration

For small businesses the Hosted Payment Page is generally a more cost effective solution. There
may be extra costs involved with using a HPP service; however this is greatly outweighed by the savings
on purchasing an SSL certificate, and the cost in time and money ensuring that the development and
processes are PCI compliant. For larger enterprises or where seamless integration or CRM connectivity
is critical, XML integration may outweigh the costs involved. Resource availability and programming
costs should be considered carefully.
However you choose to integrate our team of specialists is available to help you make your
decision and implement your solution.
2.4 A Word on Functionality

This document encompasses all of the features and functionalities of the GlobalOne gateway. It is
important to understand that not all features and functionalities may be utilized in your specific
development and implementation. Although there are basic functionalities required, many are not and
will be determined by your specific business needs. Please consider your business needs before you
begin development.
9
GlobalOne
3 Secure Communication/Card Types Supported

3.1 Secure Communication with HASH Parameters
Every request to and response from GlobalOne includes an MD5 HASH parameter. This is a security
feature to ensure that none of the sensitive data in the request has been modified by a man-in-themiddle attack. This is achieved by including all the sensitive fields in a string (these vary per request
type) along with the shared SECRET (configured per terminal). This string is then used as the basis of an
MD5 HASH.
In this document, MD5 input strings are listed as (Please note you should not include the +
symbols in the calculation):
TERMINALID+ORDERID+AMOUNT+DATETIME+SECRET
For the example in the first section below if the shared SECRET was x4n35c32RT then the MD5
HASH would be calculated as:
md5(6491002328110.0015-3-2006:10:43:01:673x4n35c32RT)
This would equal to: dd77fde79d1039d6b39e20d748211530. Note that the MD5 function should
always use a character set of UTF8 where appropriate.
3.2 Card Types

The card types that your account supports are determined by your acquiring bank and Merchant
Account. The options are: VISA, VISA DEBIT, ELECTRON, MASTERCARD, DEBIT MASTERCARD, MAESTRO,
LASER, AMEX, DINERS, JCB, DISCOVER. All live accounts will be set up with the correct card types enabled
as per the documentation that GlobalOne receives from your acquiring bank. ***Please send any
amendments to your merchant account to our support team so we may keep your account details up
to date. For testing purposes, use the test card numbers and sandbox test details are described in the
sections below.
3.3 Multi-Currency Terminal IDs

In some instances terminals that support multi-currency functionality are available depending on
the issuing bank. Such terminals will have their own terminal ID and may be identified with the letters
MC after the terminal ID. A Multi-currency terminal will allow processing of a transaction in one of a
number of the listed currencies in the drop down menu via the single terminal ID.
10
GlobalOne
When a terminal is set to process in multiple currencies the currency type ***MUST*** be
included in the request and response hash. Details on the hash and response are listed in section 4 and
in the sections relating to HPP and XML integration within this document. Please ask our integration
team if you have any questions relating to multi-currency terminals.
3.4 Integration and Validation Procedure

In order to integrate with the GlobalOne gateway you will be required to make the necessary
modifications to your website to connect with the GlobalOne gateway. This document describes
the cases and methods to achieve this.
3.4.1 GlobalOne Testing Guide
In addition you must read the GlobalOne Testing Guide for more information on the process.
3.4.2 Merchant Validation Document
Once you have completed your modifications, perform the relevant transaction types as listed in
our Merchant Validation Document. ***Please note that when testing you must supply at least
TWO successful transactions per transaction type that you intend to use. *** Please refer to the
functionality checklist in the Merchant Validation Document. Two transactions are necessary to
ensure consistency when our Integration team analyses your transactions. Record all pertinent
information relating to the testing and return the completed forms to our integration team via
email. The integration team will contact you to confirm that you have successfully validated against
the GlobalOne Gateway.
Hosted Pages
GlobalOne provide Hosted Pages for the entry of some sensitive data so that the merchants servers
do not have to be exposed to this data. This is advisable to reduce the security overhead of the
integrated solution as GlobalOne is responsible for maintaining the security and integrity of the data
sent to these pages. The payment is then processed by GlobalOne and the account holder is redirected
to the merchant's receipt page
These pages can also be highly styled so that they look very appealing to the customers. This helps
improve conversion rates and improves the customers overall payment experience.
11
GlobalOne
4.1 Hosted Page Styling
The GlobalOne hosted pages can be heavily styles and are device aware, responsive and reactive,
depending on the amount of effort the developer wants to put in to styling them.
As you can see from the image above it is simple to configure separate templates to be used for
various devices. This is intended as a shortcut; a simple way of cheating the customer to think it's a
responsive webpage, however a single template can be made totally responsive if desired.
As you can see different template can also be used for Mail Order (TEL) and eCommerce
transactions (WEB).
There are three permanent templates and they default to some sample styles. They do not all have
to be used.
Images can be included but the image files must be hosted on the merchants website. The URL of
the image will be required in the Payment Page styling.
Note: only users who have Pay Pages permissions will have access to this interface. It can be
found once logged in by clicking Settings and then Pay Pages in the menu
12
GlobalOne
4.2 Basic Mode Styling
Basic template styling requires no knowledge of HTML or CSS. It can allow a merchant to style the
page to an acceptable level. Previews of all hosted pages can be viewed on the right hand side.
All new templates created are basic. It's best to style as close as possible to what you are looking
for in this mode before clicking Advanced Mode for more options.
13
GlobalOne
4.3 Advanced Mode Styling
Advanced mode allows you to directly edit the CSS of the page and also the HTML of the Header
and Footer. It is recommended not to use Auto Update in this mode.
Because of the custom CSS that cannot be reverted to the same constraints as the Basic Mode,
once you have entered Advanced mode you cannot go back to Basic Mode styling.
14
GlobalOne
5 Hosted Pay Page

5.1 Test Credentials
5.1.1
Sandbox Test Details

The following values should be used when testing against the Pivotal test URLs. Please see the
Testing and Certification guide for further details. The terminal details are:
a.
b.
c.
d.
e.
f.
5.1.2
Currency Terminal ID Shared SECRET

USD
33001
SandboxSecret001
CAD
33002
SandboxSecret002
EUR
33003
SandboxSecret003
GBP
33004
SandboxSecret004
MCP* 36001
SandboxSecret001
*MCP is the Multi Currency Terminal Settings
Test Cards
Test cards that may be used on our host are:
Visa 4444 3333 2222 1111
MasterCard 5404 0000 0000 0001
Laser 6304 9900 0000 0000 044
Maestro 3000 0000 0000 0000 04
UK Domestic Maestro 5641 8200 0000 0005
Electron 4917 3000 0000 0008
Visa Debit 4462 0000 0000 0003
Debit MasterCard 5573 4700 8901 0012
American Express 3742 0000 0000 004
JCB 3569 9900 0000 0009
Diners 3600 0000 0000 08
Solo 6767 6222 2222 2222 222
All test cards can be used with any expiry date in the future, and any CVV (American Express
cards have a 4 digit CVV) and any Issue number where appropriate.
5.2 MaxMind MinFraud (Where Available)

Certain fields are required for performing fraud scoring on the transaction using the MaxMind
MinFraud service. There is no charge for this service, and it can be enabled in the Terminal Setup section
of our SelfCare System.
More
information about
this service is
available
on the MaxMind
website
here:
https://www.maxmind.com/en/ccv_overview
15
GlobalOne
This service will provide a score for the transaction between 0.01 and 100 (riskScore), effectively the
percentage chance that it could be fraudulent. Please read the MaxMind website linked above
thoroughly before implementing this feature.
5.3 Payment Page

The Hosted Payment Page (fig. 1) is built to allow merchants to easily integrate with the GlobalOne
system for processing payments without requiring significant development by the merchant.
The payment Page header and footer may be configured from the merchant Self Care system via
Payment Page Layout. You will need to include HTML before (Header) and after (Footer) the
payment form, all of which is within the BODY tag. As a result please do not include HTML header links
or scripts. JavaScript may not be used; however inline CSS style tags may be included in the header.
Please contact our integration team should you have further questions.
Cardholders are redirected to the GlobalOne payment page once they have made the decision to
buy. Upon the customer clicking the submit button, all payment details are collected, processed and
GlobalOne gives a result to the cardholder. The cardholder is redirected to the merchants receipt page.
GlobalOne may be configured at the terminal level to manage 3D Secure and eDCC functionality when
available.
The above is accomplished by means of a simple HTML form post with a number of defined form
fields (below). The following is the GlobalOne test payment page URL:
https://testpayments.globalone.me/merchant/paymentpage
The live URL will be provided once testing is complete.
16
GlobalOne
Fig 1. An example of a hosted Payment Page
The following table describes the form fields to be posted:

Field Name
TERMINALID
ORDERID
Requi
red
Y
Y
CURRENCY
AMOUNT
DATETIME
HASH
CARDHOLDERNAME
Y
Y
N
Description
A TerminalID provided by GlobalOne.
A unique identifier for the order created by the merchant. (Max 12
Characters).
A 3-character currency code of the transaction. ISO 4217 Currency
Code
The amount of the transaction as a 2 digit decimal or an Integer value
for JPY amounts.
Format: DD-MM-YYYY:HH:MM:SS:SSS.
An MD5 HASH. See Note 1 below.
This will pre-populate the Cardholder Name field on the payment
17
GlobalOne

page. This will be editable on the payment page.
Y or N. Automatically set the transaction to Ready in the batch. If not
present the terminal default will be used.
A description of the transaction.
An email address to send a confirmation email to. Normally this is
cardholder email address.
This is the URL of the page on your site that will display the result of
the transaction. If sent this will override the terminal setting in the
SelfCare System.
This will overwrite the default Background Validation URL and will
display an error if this feature is not enabled and sent. **Highly
recommended see section 5.5****
1 or 2 (default). Defines whether the transaction is to be processed as
Mail Order/Telephone Order (1) or eCommerce (2 or not sent). Mail
Order transactions can have a separate Payment Page Layout.
AUTOREADY
DESCRIPTION
EMAIL
N
N
RECEIPTPAGEURL
VALIDATIONURL
TERMINALTYPE
TRANSACTIONTYPE
Normal Mail Order/Telephone Order trans (Mail Order for First

Data Latvia)
5 = 3DS fully authenticated trans
6 = 3DS attempted trans
7 = Normal eCommerce trans
9 = Telephone Order (First Data Latvia only)
ADDRESS1
ADDRESS2
POSTCODE
N
N
CITY
REGION
N
N
COUNTRY
PHONE
CUSTOMFIELD1
Will pre-populate the ADDRESS1 field on the Hosted Payment Page if

there is also a valid POSTCODE sent and AVS is enabled for the
terminal. Handling of display is managed by the GlobalOne and can be
to display read only, display editable or to hide them on form.
The same handling as ADDRESS1.
If sent then AVS data will be populated. Also required for MaxMind
MinFraud fraud scoring. See section 5.2
Required for MaxMind MinFraud fraud scoring. See section 5.2
Required for MaxMind MinFraud fraud scoring. See MaxMind
definition of this field as it is forwarded to them without modification.
See section 5.2
ISO 3166-1-alpha-2 code. Required for MaxMind MinFraud fraud
scoring. See section 5.2
Customer phone number, to be stored against transaction.
International format and numeric.
The merchant can configure any number of custom fields, which will
be added to the transaction and returned to the receipt page. (See
Note 2 below).
CUSTOMFIELDN
Notes:
1.
The
MD5z
hash
is
generated
using
the
following
as
an
input
string:
TERMINALID+ORDERID+AMOUNT+DATETIME+RECEIPTPAGEURL+VALIDATIONURL+SECRET
If the RECEIPTPAGEURL or VALIDATIONURL parameters are not being sent, they should not be
18
GlobalOne
included in the hash. When a terminal is setup to process more than one currency (Multi-currency)
CURRENCY must be included in the hash. The three character currency code must be included after
ORDERID and before AMOUNT, please refer to hash below (Also section 3.3)
TERMINALID+ORDERID+CURRENCY+AMOUNT+DATETIME+RECEIPTPAGEURL+VALIDAT
IONURL+secret)
2. Any non-standard field will be considered as a Custom Field, the name does not have to starts
with CUSTOMFIELD. Custom Fields are those that are set up in Terminal Setup. They will be
included in posts to the Background Validation URL and may be prompted for on the payment
page if not sent.
3. Any other fields that are sent to the HPP are considered to be 'extra fields'. These will be
returned in the response to the Receipt Page, but will not be stored or sent to the Background
Validation URL.
The following HTML shows the minimum required to initiate a transaction.
<html>
<body>
<form action="https://testpayments.globalone.me/merchant/paymentpage"
method="post">
<input type="hidden" name="TERMINALID" value="6491002" />
<input type="hidden" name="ORDERID" value="3281" />
<input type="hidden" name="CURRENCY" value="EUR" />
<input type="hidden" name="AMOUNT" value="10.00" />
<input type="hidden" name="DATETIME" value="15-3-2006:10:43:01:673" />
<input type="hidden" name="HASH"
value="dd77fde79d1039d6b39e20d748211530" />
<input type="submit" value="Pay Now" />
</form>
</body>
<html>
Utilize the Terminal Setup screen to define the URL where GlobalOne will send transaction processing
results (Receipt Page URL field). The following fields are returned in the response,
Field Name
ORDERID
APPROVALCODE
RESPONSECODE
RESPONSETEXT
DATETIME
Description
The original order ID of the transaction.
Six digit AuthCode.
A or D or R(Approved or Declined or Referral).
The text of the authorization.
The time of the transaction created by the bank. Format: YYYY-MMDDTHH:MM:SS.
19
GlobalOne
AVSRESPONSE
CVVRESPONSE
UNIQUEREF
The result of the AVS check. See Appendix A for more information.
The result of the CVV check. See Appendix A for more information.
Generated reference that should be stored for tracking and remote XML
refunding.
If sent we will return this value.
The card number (obfuscated) that was used for the transaction.
An MD5 HASH. See Note1 below.
Any other fields sent in the request; will be treated as a custom field. It
EMAIL
PHONE
COUNTRY
CARDNUMBER
HASH
Any other field
will be returned to the Receipt and Validation URLs also. Note that
this is subject to the max length of a HTTP GET request which we
would conservatively recommend considering to be 2000 characters.
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALID+UNIQUEREF+AMOUNT+DATETIME+RESPONSECODE+RESPONSETEXT+SECRET
2. Many code examples on how to generate an MD5 HASH can be found in the Internet. For
assistance, please contact the GlobalOne integration team.
5.4 Hosted Pre-Auth Page

The hosted Pre-Auth page allows for pre-authorization where the merchant account allows such
requests. Approved pre-auth transactions must be flagged as completed using SelfCare system before
they will be settled. Final transaction amount may be adjusted on completion.
The hosted Pre-Auth Page looks the same as the Hosted Payment Page, and has the same set of
fields as Payment Page. However, in the event of a pre-authorization, the following URL should be used:
https://testpayments.globalone.me/merchant/preauthpage
Note: Pre-auths dont go to an Auto Ready state. A pre-auth will always go into a READY state when
completed via an XML.
5.5 Background Validation

Background validation is a method of double-checking the result of transactions using a server-side
post. It is useful for Hosted Payment Page transactions as the result of the transaction (i.e. the response
20
GlobalOne
redirect) can sometimes fail, leaving the site without a result for the transaction even though the
transaction may have been authorized. It is possible to enable background transaction validation at a
terminal level. If this feature is enabled then all transactions sent through the Hosted Payment Page will
be validated.
The Validation URL should be set for the terminal or sent in the payment request to the Payment
Page. GlobalOne will use this URL to send an HTTP POST request with transaction processing result and
will expect to receive OK in the HTTP response body (2 characters only, no HTML). Any other response
or connection issue will be considered as not validated. GlobalOne will make further attempts to reach
the validation URL; with this process repeating until the maximum allowed time for validation has
passed. If the maximum allowed time has passed and the transaction was not successfully validated, the
transaction will be marked as expired a notification email sent to the merchants email address on file.
Background Validation may be enabled through the SelfCare System in the Terminal Setup section.
The following parameters are sent in the validation request:
Field Name
TERMINALID
UNIQUEREF
ORDERID
RESPONSECODE
RESPONSETEXT
APPROVALCODE
EMAIL
DATETIME
AVSRESPONSE
CVVRESPONSE
HASH
Custom Parameters
Description
Terminal Id.
Generated reference that should be stored for tracking and
remote XML refunding.
Order ID supplied by merchant in request.
A, D or R (Approved, Declined or Referral).
Text describing transaction state. This will be populated with an
error message if there was an issue during processing.
Transaction approval code if transaction was authorized
otherwise empty.
Cardholder e-mail.
Format: YYYY-MM-DDTHH:MM:SS.
AVS response, available only when AVS is enabled for the
terminal. See Appendix A
CVV response, available only when CVV is enabled for the
terminal. See Appendix A
Configured Terminal Custom Parameters.
Notes:
1. The MD5 HASH is generated using the following as an input string:
21
GlobalOne
(For multi-currency Terminal IDs (see section 3.3 above) this should be:
TERMINALID+UNIQUEREF+CURRENCY+AMOUNT+DATETIME+RESPONSECODE+RESPONSETEXT+secret)
5.6 Hosted Pages in iFrame Format

It is also possible to process transactions using an iFrame rather than a full redirect. All the same
fields are required as the standard full redirect integration; however the implementation for the iFrame
is slightly different.
There are two methods of implementing iFrame:
1. Build and submit the form the same as the standard integration, but within the iFrame.
2. Build the POST query string within the main page, creating an iFrame with the string the SRC
value.
In either case the following parameter must be included:

Field Name
INIFRAME
Value
Y
Description
Ensures that all redirects performed by GlobalOne do not break
out of the iFrame.
5.7 SecureCard Storage via Hosted Payment Page

The Hosted Payment Page can be configured to store the processed card
as a SecureCard upon successful authorisation of the requested payment.
This must be enabled by GlobalOne; if required please email us to request
this feature be enabled.
If this feature is enabled and you wish to store the card after the
transaction you need to include the following in the payment request:
Field Name
SECURECARDMERCHANTREF
Value
Y
Description
Unique Reference assigned by the
merchants site/software to identify the
stored card details. Length is limited to
22
GlobalOne
48 chars.
The following additional parameters will be sent to the Receipt Page URL:
Field Name
ISSTORED
SCERROR
MERCHANTREF
CARDREFERENCE
CARDTYPE
CARDEXPIRY
Description
true or false
Description of storage error if
ISSTORED is false
Original SecureCard Merchant
Reference.
Generated Card Reference.
See section 3.2 above.
Expiry date of the card.
Notes:
1.
The MD5 response HASH for Hosted Payment Page transactions
where the card is stored is generated using the following as an input

string:
TERMINALID+UNIQUEREF+AMOUNT+DATETIME+RESPONSECODE+RE
SPONSETEXT+MERCHANTREF+CARDREFERENCE+CARDTYPE+CARDNU
MBER+CARDEXPIRY+secret
23
GlobalOne
6 XML Payments Integration

It is also possible to send XML directly to the GlobalOne payment server. This is useful in a scenario
where your application needs full control of the payment process or where you wish to collect card
details on your site. The XML XSD description for all of the packet types below is available there:
https://testpayments.globalone.me/merchant/gateway.xsd
6.1 Test Credentials

6.1.1
Sandbox Test Details

The following values should be used when testing against the Pivotal test URLs. Please see the
Testing and Certification guide for further details. The terminal details are:
a.
b.
c.
d.
e.
f.
6.1.2
Currency Terminal ID Shared SECRET

USD
33001
SandboxSecret001
CAD
33002
SandboxSecret002
EUR
33003
SandboxSecret003
GBP
33004
SandboxSecret004
MCP* 36001
SandboxSecret001
*MCP is the Multi Currency Terminal Settings
Test Cards
Test cards that may be used on our host are:
Card Scheme
American
Express
Debit
MasterCard
Debit
MasterCard
Debit
MasterCard
Diners
Diners
JCB
Maestro
Maestro
Maestro
MasterCard
MasterCard
MasterCard
MasterCard
MasterCard
Switch
DCC
Enabled
Currency
Supports
CVV
Card Number
EUR
3400000000000067
EUR
5103150000000024
GBP
5105091000000085
USD
EUR
USD
GBP
EUR
GBP
USD
EUR
GBP
GBP
JPY
USD
EUR
Y
N
N
N
Y
Y
Y
Y
N
Y
Y
Y
N
Y
N
N
Y
Y
Y
Y
Y
Y
Y
Y
Y
N
5100270000000007
3600000000000032
6011000000000053
3528000000000072
5016590000000019
6301144000000066
5021230000000007
5100010000000056
5534223000000085
5101080000000033
5120790000000018
5100040000000095
6706989000000008
24
GlobalOne
Switch
Switch
Visa Credit
Visa Credit
Visa Credit
Visa Credit
Visa Credit
Visa Credit
Visa Credit
Visa Credit
Visa Debit
Visa Debit
Visa Debit
Visa Debit
Visa Debit
Visa Debit
Visa Debit
Visa Debit
Visa Electron
Visa Electron
Visa Electron
Visa Electron
GBP
USD
EUR
EUR
GBP
GBP
JPY
JPY
USD
USD
EUR
EUR
GBP
GBP
JPY
JPY
USD
USD
EUR
GBP
JPY
USD
N
N
N
Y
N
Y
N
Y
N
Y
N
Y
N
Y
N
Y
N
Y
Y
Y
Y
Y
N
N
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
6301144000000017
6706988000000018
4005530000000086
4001310000000095
4300000000000082
4008800000000031
4051700000000021
4205030000000036
4005510000000013
4000020000000000
4033400000000005
4000340000000069
4300009900000050
4000330000000078
4051705010000085
4000360000000018
4005525010000084
4000060000000055
4003110000000071
4001150000000061
4980040000000044
4002730000000010
All test cards can be used with any expiry date in the future, and any CVV
(American Express cards have a 4 digit CVV) and any Issue number where appropriate.
6.2 MaxMind MinFraud (Where Available)

Certain fields are required for performing fraud scoring on the transaction using the MaxMind
MinFraud service. There is no charge for this service, and it can be enabled in the Terminal Setup section
of our SelfCare System.
More
information about
this service is
available
on the MaxMind
website
here:
https://www.maxmind.com/en/ccv_overview
This service will provide a score for the transaction between 0.01 and 100 (riskScore), effectively the
percentage chance that it could be fraudulent. Please read the MaxMind website linked above
thoroughly before implementing this feature.
6.3 Request Types

6.3.1
XML Payments
The following is a simple example of a payment via an XML POST:

25
GlobalOne
<?xml version="1.0" encoding="UTF-8"?>

<PAYMENT>
<ORDERID>115010922465</ORDERID>
<TERMINALID>6491002</TERMINALID>
<AMOUNT>10</AMOUNT>
<DATETIME>12-06-2006:11:47:04:656</DATETIME>
<CARDNUMBER>4111111111111111</CARDNUMBER>
<CARDTYPE>VISA</CARDTYPE>
<CARDEXPIRY>0807</CARDEXPIRY>
<CARDHOLDERNAME>John Doe</CARDHOLDERNAME>
<HASH>d04c3bab519095ecb046eff91722e8df</HASH>
<CURRENCY>EUR</CURRENCY>
<TERMINALTYPE>1</TERMINALTYPE>
<TRANSACTIONTYPE>7</TRANSACTIONTYPE>
<CVV>214</CVV>
</PAYMENT>
For testing, this XML is posted to:
https://testpayments.globalone.me/merchant/xmlpayment
A response for this transaction would be:
<PAYMENTRESPONSE>
<UNIQUEREF>JJCVGCTOV3</UNIQUEREF>
<RESPONSECODE>A</RESPONSECODE>
<RESPONSETEXT>APPROVAL</RESPONSETEXT>
<APPROVALCODE>475318</APPROVALCODE>
<DATETIME>2005-11-14T12:53:18</DATETIME>
<CVVRESPONSE>M</CVVRESPONSE>
<HASH>afe4c8b57f3ea0dfee7c8f75fae7e90d</HASH>
</PAYMENTRESPONSE>
Payment request field description:
Field Name
ORDERID
Required
Y
TERMINALID
AMOUNT
DATETIME
TRACKDATA(MSR/CHP)
Y
N
Description
A unique identifier for the order created by the merchant.
(Max 12 Characters).
A Terminal ID provided by GlobalOne. NB Please contact
GlobalOne to be issued with a test terminal ID.
The amount of the transaction as a 2 digit decimal or an
Integer value for JPY amounts.
Track 2 data should be present for a swiped cardholder
present (CHP) transaction. If this is present then
TERMINALTYPE should be set to 3 and TRANSACTIONTYPE
should be set to 0. See Note 4
26
GlobalOne
CARDNUMBER
CARDTYPE
CARDEXPIRY
Y
N
CARDHOLDERNAME
HASH
CURRENCY
Y
Y
FOREIGNCURRENCYINFOR
MATION
TERMINALTYPE
The payment card number required if TRACKDATA is not

being sent.
4-digit expiry field (MMYY), required if TRACKDATA is not
being sent.
The name of the card holder required if TRACKDATA is not
being sent and not using a SecureCard.
An MD5 HASH. See Note 1 & 2 below.
A 3-character currency code of the transaction. ISO 4217
CURRENCY CODE
Tag contains Dynamic Currency Conversion information. It
has to be present in the eDCC-enabled transactions. Only
available to eDCC enabled merchants.
The type of the terminal:
TRANSACTIONTYPE
1 - MOTO (Mail Order/Telephone Order)

2 eCommerce
3 Cardholder Present
Y
Normally:
0 Cardholder Present (CHP) transaction

4 MOTO (Mail Order/Telephone Order)
7 eCommerce
Recurring Payment Flagging:
2 Specify that this transaction is

recurring. This must be accompanied by the
RECURRINGTXNREF field or have special
permission granted by the Gateway. Not all
processors support this transaction type
and consultation with the integration team
should be carried out prior to configuring
recurring payment flagging.
For First Data Latvia terminal MOTO transactions:
4 Telephone Order
9 Mail Order
27
GlobalOne

If sending XID & CAVV from nonGlobalOne MPI on an
eCommerce transaction use:
0 not applicable
1 Single transaction
2 Recurring transaction
3 Installment payment
4 Unknown classification
5 - Fully authenticated transaction 3D Secure

transaction (3D Secure not currently supported)
6 - The merchant attempted to authenticate the

cardholder, but the cardholder cannot or does not participate
in 3DSecure (3D Secure not currently supported).
7 - Transaction when payment data was transmitted

using SSL encryption, or Channel Encrypted
8 Transaction in the clear, or Non Secure
AUTOREADY
EMAIL
CVV
ADDRESS1
ADDRESS2
POSTCODE
N
N
N
N
DESCRIPTION
XID
CAVV
MPIREF
N
N
N
N
MOBILENUMBER
DEVICEID
N
N
PHONE
CITY
REGION
N
N
COUNTRY
IPADDRESS
Y or N - If this is set to Y GlobalOne will automatically set

the transaction to Ready in the batch. If set to N then the
transaction will go to a PENDING status. If not present the
terminal default will be used.
Cardholders e-mail address. If populated the cardholder will
be sent an email receipt. The SelfCare Terminal Setup
setting Disable Cardholder Receipt can override this.
The security code entered by the cardholder.
The first address field for AVS.
The second address field for AVS.
The postal/ZIP code (required) for AVS. Also required for
MaxMind MinFraud fraud scoring.
The XID for a 3D Secure transaction.
The CAVV for a 3D Secure transaction.
3D-Secure GlobalOne Transaction Reference supplied in
GlobalOne MPI transactions.
Used for SMS receipts. International format, numeric only.
The unique identifier string for a connecting device.
Mandatory for non-server based devices such as handheld
devices/cash registers etc.
Card Holder Phone Number stored against transaction.
International format, numeric only.
Required for MaxMind MinFraud fraud scoring.
Required for MaxMind MinFraud fraud scoring. See
MaxMind definition of this field as it is forwarded to them
without modification.
ISO 3166-1-alpha-2 code. Required for MaxMind MinFraud
fraud scoring.
Recommended inclusion. Required for MaxMind MinFraud
28
GlobalOne
SIGNATURE
fraud scoring.
Optional field if processing Cardholder Present (CHP)
transaction using the TRACKDATA field.
CUSTOMFIELD
RECURRINGTXNREF
Should also use the NAME xml attribute to assign the

name of the custom field. See Note 3 below.
Should be set to the value of a UNIQUEREF returned in
a
PAYMENT
response
for
matching
card.
TRANSACTIONTYPE should be set to 2.

CAVV
MPIREF
DEVICE ID
The CAVV for a 3D Secure transaction when not using our

MPI. (3D secure not currently supported)
3D-Secure GlobalOne Transaction Reference supplied in
GlobalOne MPI authentication requests (3D Secure not
currently supported).
The unique identifier string for a connecting device.
Mandatory for non-server based devices such as handheld
devices/cash registers etc.
The following fields are returned in the response:

Field Name
UNIQUEREF
RESPONSECODE
RESPONSETEXT
APPROVALCODE
BANKRESPONSECODE
AUTHORIZEDAMOUNT
DATETIME
AVSRESPONSE
CVVRESPONSE
Description
Generated reference that should be stored for tracking and remote
XML refunding.
A or D or R (Approved or Declined or Referral).
Six digit AuthCode.
Only sent on TSYS terminals. The TSYS response code returned in the
authorisation response. See Appendix C for response codes
Only sent for specific acquirers. Partial amount authorized for some
transactions.
The time of the transaction created by the bank. Format: YYYY-MMDDTHH:MM:SS. Note that this is intentionally in a different format to
the request timestamp to highlight the fact that it is a different time.
The result of the AVS check. See Appendix A for more information.
The result of the CVV check. See Appendix A for more information.
29
GlobalOne
PROCESSINGTERMINAL
HASH
If the transaction was performed on a routing terminal then this is

populated with processing terminal ID that the system selected to
process the transaction
Notes:
a. TERMINALID+ORDERID+AMOUNT+DATETIME+secret
b. (For multi-currency Terminal IDs (see section 3.3 above) this should be:
TERMINALID+ORDERID+CURRENCY+AMOUNT+DATETIME+secret)
a. TERMINALID+UNIQUEREF+AMOUNT+DATETIME+RESPONSECODE+RESPONSETEXT+BAN
KRESPONSECODE+secret For multi-currency Terminal IDs (see section 3.3 above) this
should be:
b. TERMINALID+UNIQUEREF+CURRENCY+AMOUNT+DATETIME+RESPONSECODE+RESPONS
ETEXT+BANKRESPONSECODE+secret)
The DATETIME is the time returned by the bank for the transaction. Many code examples on how to
generate an MD5 HASH can be found in the Internet. For assistance, please contact the GlobalOne
integration team.
3. Custom Fields are configured in Terminal Settings to store details against a transaction. There
can be a max of 30 custom fields
4. For card present transactions please add TRACKDATA information, you dont have to include
credit card data it will be included in the TRACKDATA
Error handling
If there is an error processing the transaction, the error string is returned in an XML message with
the simple:
<ERROR><ERRORSTRING></ERRORSTRING></ERROR>
tags.
30
GlobalOne
6.3.2
Pre-Authorization Request
Only certain acquiring banks support pre-authorization transactions Please check with the
GlobalOne integration team if you wish to support Pre-authorizations.

Example of a XML Pre-Auth request:
<PREAUTH>
<AMOUNT>15.62</AMOUNT>
<HASH>9c58e8d7ff9eb98db4ece2af75dec6ae</HASH>
<CVV>214</CVV>
</PREAUTH>
<PREAUTHRESPONSE>
<UNIQUEREF>F523SJTZ0</UNIQUEREF>
<CVVRESPONSE>M</CVVRESPONSE>
<HASH>afe4c8b57f3ea0dfee7c8f75fae7e90d</HASH>
<PROCESSINGTERMINAL> 6491002</PROCESSINGTERMINAL>
</PREAUTHRESPONSE>
31
GlobalOne
Payment request fields description:

Field Name
Requi
Description
red
ORDERID
TERMINALID
AMOUNT
DATETIME
CARDNUMBER
Y
N
CARDTYPE
CARDEXPIRY
Y
N
CARDHOLDERNAME
HASH
CURRENCY
Y
Y
FOREIGNCURRENCYINFORMA
TION
TERMINALTYPE
A unique identifier for the order created by the

merchant. (Max 12 Characters).
A Terminal ID provided by GlobalOne. NB Please
contact GlobalOne to be issued with a test terminal ID.
The amount of the transaction as a 2 digit decimal
or an Integer value for JPY amounts.
The payment card number, required if TRACKDATA
is not being sent.
4 digit expiry field (MMYY), required if TRACKDATA
is not being sent and not using a SecureCard.
The name of the card holder, required if
TRACKDATA is not being sent and not using a
SecureCard.
A 3 character currency code of the transaction. ISO
4217 Currency Code.
Tag contains Dynamic Currency Conversion
information. It has to be present in the eDCC enabled
transactions. See XML Payments with eDCC.
The type of the terminal:
TRANSACTIONTYPE

2 - eCommerce
Normally:

7 eCommerce
Recurring Payment Flagging:
2 Specify that this transaction is
recurring. This must be accompanied by the

RECURRINGTXNREF
field
or
have
special
permission granted by the Gateway. Not all

processors support this transaction type and
consultation with the integration team should
32
GlobalOne

be carried out prior to configuring recurring
payment flagging.
For First Data Latvia terminal MOTO transactions:
4 - Telephone Order
9 - Mail Order
If sending XID & CAVV from non-GlobalOne MPI on an

eCommerce transaction use:
EMAIL
CVV
ISSUENO
ADDRESS1
ADDRESS2
POSTCODE
N
N
N
N
N
DESCRIPTION
CITY
REGION
N
N
N
0 - not applicable
1 - Single transaction
2 - Recurring transaction
3 - Installment payment
4 - Unknown classification
5 - Fully authenticated transaction 3D
Secure transaction
6 - The merchant attempted to
authenticate the cardholder, but the cardholder
cannot or does not participate in 3D-Secure.
7 - Transaction when payment data was
transmitted using SSL encryption, or Channel
Encrypted
8 - Transaction in the clear, or Non
Secure
Cardholders e-mail address. If populated the
cardholder will be sent an email receipt. This can be
overridden by the SelfCare Terminal Setup setting
Disable Cardholder Receipt.
The security code entered by the card holder.
The issue no. of the card (Solo).
The first address field for AVS.
The second address field for AVS.
The postcode (required) for AVS. Also required for
MaxMind MinFraud fraud scoring.
Required for MaxMind MinFraud fraud scoring. See
MaxMind definition of this field as it is forwarded to
them without modification.
33
GlobalOne
COUNTRY
IPADDRESS
CUSTOMFIELD
RECURRINGTXNREF
ISO 3166-1-alpha-2 code. Required for MaxMind

MinFraud fraud scoring.
Recommended inclusion. Useful for tracking
customers. Functionality will expand in the future.
Should also use the NAME xml attribute to assign
the name of the custom field. See Note 3 in PAYMEN T
section.
Should be set to the value of a UNIQUEREF returned
in a PAYMENT response for a non-recurring transaction
on a matching card. TRANSACTIONTYPE should be set
to 2.

Field Name
UNIQUEREF
RESPONSECODE
RESPONSETEXT
BANKRESPONSECODE
APPROVALCODE
DATETIME
AVSRESPONSE
CVVRESPONSE
PROCESSINGTERMINAL
HASH
Description
Generated reference that should be stored for tracking and
remote XML refunding.
A or D or R (Approved or Declined or Referral).
Only sent on TSYS terminals. The TSYS response code returned in
the authorisation response. See Appendix C for response codes
Six digit AuthCode.
The time of the transaction created by the bank. Format: YYYYMM-DDTHH:MM:SS. Note that this is intentionally in a different
format to the request timestamp to highlight the fact that it is a
different time.
The result of the AVS check. See Appendix A for more
information.
The result of the CVV check. See Appendix A for more
information.
If the transaction was performed on a routing terminal then
this is populated with processing terminal ID that the system selected
to process the transaction.
Notes:
1.
The MD5 HASH is generated using the following as an input string:

TERMINALID+ORDERID+AMOUNT+DATETIME+secret
(For multi-currency Terminal IDs this should be:

TERMINALID+ORDERID+CURRENCY+AMOUNT+DATETIME+secret)
2.

34
GlobalOne

TERMINALID+UNIQUEREF+AMOUNT+DATETIME+RESPONSECODE+RESPONSETEXT+BANKRE
SPONSECODE+secret
(For multi-currency Terminal IDs) this should be:
TERMINALID+UNIQUEREF+CURRENCY+AMOUNT+DATETIME+RESPONSECODE+RESPONSETEXT+s
ecret)
The DATETIME is the time returned by the bank for the transaction.
Many code examples on how to generate an MD5 HASH can be found in the Internet. For
assistance, please contact GlobalOne.
Errors handling
If there is an error processing the transaction, the error string is returned in an XML message with the
simple tags:
6.3.3
Pre-Auth Completion Request
Example of a Pre-Auth completion request:

<PREAUTHCOMPLETION>
<CVV>785</CVV>
<HASH>ff2e84856d7debbf07d3dfeffad5898c</HASH>
</PREAUTHCOMPLETION>
<PREAUTHCOMPLETIONRESPONSE>
35
GlobalOne
<HASH>93527dbb00534a4b33546161aefe5222</HASH>
</PREAUTHCOMPLETIONRESPONSE>
Pre-Auth Completion request fields description:
Field Name
UNIQUEREF
Required
Y
TERMINALID
AMOUNT
Y
Y
MATION
DESCRIPTION
DATETIME
CVV
Y
N
HASH
Description
A unique identifier for the order created by the merchant
(12 characters max). The UNIQUEREF for the original
authorization
integer value for JPY amounts.
Tag contains Dynamic Currency Conversion information. It is
required when completing out of the 15% margin eDCC
transaction.
An optional description, overrides original pre-auth
description if available.
Format DD-MM-YYYY:HH:MM:SS:SSS.
The security code entered by the cardholder. It should be
available when CVV is enabled for a terminal and
completing out of the 15% margin transaction.
An MD5 HASH (See Note 1 below).

Field Name
RESPONSECODE
RESPONSETEXT
APPROVALCODE
DATETIME
AVSRESPONSE
CVVRESPONSE
PROCESSINGTERMINAL
HASH
Description
Six digit AuthCode.
The time of the transaction created by the bank. Format: YYYYMM-DDTHH:MM:SS. Note that this is intentionally in a different
format to the request timestamp to highlight the fact that it is a
different time.
The result of the AVS check. See Appendix A for more
information.
The result of the CVV check. See Appendix A for more
information.
this is populated with processing terminal ID that the system
selected to process the transaction
Notes:
1) The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALID+UNIQUEREF+AMOUNT+DATETIME+SECRET
36
GlobalOne
2) The

MD5
HASH
is
generated
using
the
following
as
an
input
string:
Errors handling
If there is an error processing the transaction, the error string is returned in an XML message with the
simple tags:
6.3.4
Refunds
6.3.4.1 Standard Refunds

Standard refunds can be performed on any authorized transactions in the GlobalOne system, either
in the Open Batch or Closed Batch. By default you can refund any amount up to 100% of the original
transaction value. If multiple partial refunds are performed then the sum total cannot exceed 100% in an
effort to prevent fraud.
The percentage value is configurable at a Terminal level. Please contact our integration team to
make changes to this percentage value.
The following is a simple example of a refund via an XML POST:
<REFUND>
<UNIQUEREF>Q8F40S2V</UNIQUEREF>
<HASH>cfa094f53a508d2031c7895f9f766cbb</HASH>
<OPERATOR>Test Operator</OPERATOR>
<REASON>Faulty Goods</REASON>
</REFUND>
<REFUNDRESPONSE>
<RESPONSETEXT>SUCCESS</RESPONSETEXT>
37
GlobalOne
<HASH>6a06aa6f14fe539f4dedd305465811ab</HASH>
</REFUNDRESPONSE>
The GlobalOne payment system then handles subsequent transaction settlement and storage.
The following is a description of each field:
Field Name
UNIQUEREF
TERMINALID
Required
Y
Y
AMOUNT
DATETIME
HASH
OPERATOR
REASON
Y
Y
Y
Y
Description
The UNIQUEREF for the original authorization.
A TerminalID provided by GlobalOne. NB Please
The amount of the transaction as a 2 digits decimal or
an Integer value for JPY amounts.
An MD5 HASH. See note 1 below.
An identifier for who executed this transaction.
The reason for the refund.

Field Name
RESPONSECODE
RESPONSETEXT
UNIQUEREF
TERMINALID
Description
A or D (Approved or Declined).
The UNIQUEREF for this refund.
AMOUNT
DATETIME
HASH
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
as
an
input
string:
TERMINALID+UNIQUEREF+AMOUNT+DATETIME+SECRET
2. The
MD5
HASH
is
generated
using
the
following
(n.b. the response UNIQUEREF is to be used here)
38
GlobalOne
6.3.4.2 Unreferenced Refunds

Unreferenced refunds are refunds that do not require a sale transaction to be referenced to. They
are only available on certain accounts by request (please request from the GlobalOne integration team)
and must also be approved by your acquiring (merchant) bank.
The following is a simple example of an unreferenced refund via an XML POST:
<UNREFERENCEDREFUND>
<CARDDETAILS>
</CARDDETAILS>
<EMAIL>cardholder_email@globalonecommerece.com</EMAIL>
The following is a simple example of an unreferenced refund on a SecureCard via an XML POST:
<UNREFERENCEDREFUND>
<CARDREFERENCE>2967534771694736</CARDREFERENCE>
<EMAIL>cardholder_email@globalone.me</EMAIL>
</UNREFERENCEDREFUND>

<UNREFERENCEDREFUNDRESPONSE>
<UNIQUEREF>G53D0M1S4</UNIQUEREF>
39
GlobalOne
</UNREFERENCEDREFUNDRESPONSE>
Field Name
Description
ORDERID
Require
d
Y
TERMINALID
A TerminalID provided by GlobalOne. NB Please contact

If using a SecureCard then this tag must contain a valid
SecureCard Card Reference.
If not using a SecureCard then this tag must be
populated. See section 6.3.4 for more details
A 3-character currency code of the transaction. ISO 4217
currency code. Required only for multi-currency Terminal
IDs (See section 3.3)
The amount of the transaction as a 2 digits decimal or an
Y or N. Automatically set the transaction to Ready in the
batch. If not present the terminal default will be used.
An email address to send a confirmation email to. Normally
this is cardholder email address.
An identifier for who executed this transaction.
The description for the refund.
CARDREFERENCE
CARDDETAILS
CURRENCY
AMOUNT
AUTOREADY
EMAIL
DATETIME
HASH
OPERATOR
DESCRIPTION
Y
Y
Y
N
A unique identifier for the order created by the merchant.

(Max 12 Characters).

Field Name
RESPONSECODE
RESPONSETEXT
UNIQUEREF
TERMINALID
AMOUNT
DATETIME
PROCESSINGTERMINAL
HASH
Description
A or D (Approved or Declined).
The UNIQUEREF for this refund.
this is populated with the processing terminal ID that the
system selected to process the transaction
40
GlobalOne
Notes:
TERMINALID+ORDERID+CARDTYPE+CARDNUMBER+CARDEXPIRY+
CARDHOLDERNAME+AMOUNT+DATETIME+secret
For multi-currency Terminal IDs (see section 3.3 above) this should be:
TERMINALID+ORDERID+CARDTYPE+CARDNUMBER+CARDEXPIRY+
CARDHOLDERNAME+CURRENCY+AMOUNT+DATETIME+secret
If using a SecureCard (CARDREFERNCE tag) then the MD5 HASH is
generated
using
the
following
as
an
input
string:
TERMINALID+ORDERID+AMOUNT+DATETIME+secret
For multi-currency Terminal IDs (see section 3.3 above) this should
be:
TERMINALID+ORDERID+CURRENCY+AMOUNT+DATETIME+secret
2. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALID+UNIQUEREF+AMOUNT+DATETIME+RESPONSECODE+RESPONSETEXT+secret
6.3.4.3
CARDDETAILS tag in XML Requests
Some XML packets require the options CARDDETAILS tag and it nested tags.
There is an example of Foreign Currency information in the XML payment request:
<CARDDETAILS>
<CARDHOLDERNAME>0.667157</CARDHOLDERNAME>
</CARDDETAILS>
41
GlobalOne
Description of FOREIGNCURRENCYINFORMATION fields:

Field Name
CARDTYPE
CARDNUMBER
CARDEXPIRY
CARDHOLDERNAME
Required
Y
Y
Y
Y
Description
The payment card number (PAN).
4 digit expiry field (MMYY).
The name of the card holder.
6.4 XML Requests with eDCC (Where Available)

Direct XML transactions (Payment, Pre-Auth and Pre-Auth Completion) can be DCC
(Dynamic Currency Conversion) enabled. This is useful when card and terminal currencies are
different. eDCC enabled XML transaction request should include additional tag FOREIGNCURRENCYINFORMATION with all required nested tags.
DCC transactions are allowed for the eDCC-enabled terminals only. DCC support for the
terminal can be enabled or disabled by the GlobalOne support team only. DCC is not currently
available on multi-currency Terminals (See section 3.3)
6.4.1
eDCC Exchange Rate Request
The following is an example of a Conversion Rate request for the Terminal ID and BIN:
<GETCARDCURRENCYRATE>
<CARDBIN>411111</CARDBIN>
<HASH>15f6c0f0b51faff9cbb77220ab8ddfce</HASH>
</GETCARDCURRENCYRATE>
Fields description:
Field Name
Required
Description
TERMINALID

contact GlobalOne to be issued with a test terminal
ID.
CARDBIN
BIN. The first 6 digits from the Card Number.

42
GlobalOne
BASEAMOUNT
Transaction amount in the base currency. If sent

GlobalOne will return the correctly formatted and
calculated FOREIGNAMOUNT.
DATETIME
Request Date and Time. Format: DD-MMYYYY:HH:MM:SS:SSS.
HASH
Notes:
1.
TERMINALID+CARDBIN+DATETIME+secret
A response for this request would be:
<CARDCURRENCYRATERESPONSE>
<TERMINALCURRENCY>EUR</TERMINALCURRENCY>
<CARDCURRENCY>GBP</CARDCURRENCY>
<CONVERSIONRATE>0.667157</CONVERSIONRATE>
<EXCHANGERATESOURCENAME>Imaginary Bank</EXCHANGERATESOURCENAME>
<MARGINPERCENTAGE>1.50</MARGINPERCENTAGE>
<COMMISSIONPERCENTAGE>1.00</COMMISSIONPERCENTAGE>
<FOREIGNAMOUNT>15.98</FOREIGNAMOUNT>
<HASH>a12a10322f5af4a8a419f7dc1c6dd39f</HASH>
</CARDCURRENCYRATERESPONSE>
The following fields will be returned in the response:

Field Name
Description
TERMINALCURRENCY
Terminals currency code. ISO 4217 Currency Code
CARDCURRENCY
Cards currency code. ISO 4217 Currency Code
CONVERSIONRATE
Conversion rate. See Note 2 below.
DATETIME
EXCHANGERATESOURCENAME
Source of rates. Display on decision page.
MARGINPERCENTAGE
Margin percentage applied.
COMMISSIONPERCENTAGE
Commission percentage applied.
FOREIGNAMOUNT
Converted amount.
43
GlobalOne
HASH
Notes:
1.
TERMINALCURRENCY+CARDCURRENCY+CONVERSIONRATE+DATETIME+secret
2.
In this string CONVERSIONRATE must be a decimal value with 6 decimal places
separated by dot character (.), example: 0.123000. The secret should be set by
merchant in the SelfCare system.
Error handling
If there is an error processing the request, the error string is returned in an XML message:
There is list of error codes and their brief descriptions:

Error Code
Description
101
Terminal not found.
102
BIN not found.
103
Currencies are the same.
104
eDCC is not allowed for the terminal.
105
Invalid card currency/Unknown currency.
106
Conversion rate not found.
107
Invalid request format.
108
Invalid hash in the request.
109
Other error.
110
Internal error.
111
Unsupported card currency.
44
GlobalOne
Notes:
1. Some errors may have more informative message. For example error with code 107 may
have detailed information on wrong or expected tag(s) in the XML.
6.4.2
eDCC Information in the XML Requests
eDCC enabled XML requests must include FOREIGNCURRENCYINFORMATION tag and it

nested tags.
There is an example of Foreign Currency information in the XML payment request:
<FOREIGNCURRENCYINFORMATION>
<CARDAMOUNT>6.67</CARDAMOUNT>
</FOREIGNCURRENCYINFORMATION>
Description of FOREIGNCURRENCYINFORMATION fields:

Field Name
Requir
Description
ed
FOREIGNCURRENCYINFORMA
TION
CARDCURRENCY
CARDAMOUNT
CONVERSIONRATE
N
Y
Y
Y
Outer tag for Currency Conversion Rate

informative fields.
Cards currency code.
Amount that is being charged in the
home currency.
Value received in the Conversion Rate
request should be there. Processing bank
(EuroConex) will decline transaction if wrong
rate will be there.
Example of a Payment transaction with eDCC:

<PAYMENT>
<AMOUNT>10</AMOUNT>
45
GlobalOne
<CVV>214</CVV>
</PAYMENT>
Example of an eDCC Pre-Auth transaction:

<PREAUTH>
<HASH>9c58e8d7ff9eb98db4ece2af75dec6ae</HASH>
<CVV>214</CVV>
</PREAUTH>
Example of out of 15% margin eDCC Pre-Auth Completion transaction:

<PREAUTHCOMPLETION>
<CVV>785</CVV>
<HASH>ff2e84856d7debbf07d3dfeffad5898c</HASH>
</PREAUTHCOMPLETION>
Note, that foreign currency information in the completion request is useful when completing an
out of 15% tolerance transaction, because the original pre-auth transaction will be reversed and a new
46
GlobalOne
PAYMENT transaction will be authorized instead, and the foreign currency details provided will be used
for the new transaction.
The original pre-auth exchange rate is used when an eDCC transaction within the 15% tolerance is
completed
6.4.3
Transaction Status Updates
Transaction updates allow you to update the status of a transaction in the Open Batch. You need to
know the existing status of the transactions in order to update it.
The following is a simple example of an update via an XML POST:
<TRANSACTIONUPDATE>
<UNIQUEREF>Q8F40S2V</UNIQUEREF>
<FROMSTATUS>PENDING</FROMSTATUS>
<TOSTATUS>READY</TOSTATUS>
</TRANSACTIONUPDATE>
<TRANSACTIONUPDATERESPONSE>
47
GlobalOne
</TRANSACTIONUPDATERESPONSE>
Field Name
Requir
Description
ed
UNIQUEREF
TERMINALID
Y
Y
OPERATOR
FROMSTATUS
Y
Y
TOSTATUS
The UNIQUEREF for the transaction being updated.

An identifier for who executed this update.
The current status of the transaction. Can be READY,
PENDING or REFERRAL
New status for the transaction. Can go from:
AUTHCODE
DATETIME
HASH
Y
Y
REFERRAL to PENDING or READY,

PENDING to READY,
READY to PENDING.
The approval code of of the referral. Only required if
changing a REFERRAL to PENDING or READY.

Field Name
RESPONSECODE
RESPONSETEXT
UNIQUEREF
TERMINALID
DATETIME
HASH
Description
Updated transaction Response Code.
Updated transaction Response Text.
The UNIQUEREF for this transaction.
48
GlobalOne
Notes:
1.
The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALID+UNIQUEREF=OPERATOR+FROMSTATUS+TOSTATUS+APPROVALCODE+DATETIME+s
ecret

TERMINALID+RESPONSECODE+RESPONSETEXT+UNIQUEREF+DATETIME+secret
6.4.4
Retrieve Foreign Currency Exchange Rates
Some Multi-currency terminal IDs (dependant on Acquiring Bank support - not eDCC enabled
terminals) can perform foreign currency rate lookups to retrieve their daily rate for a specific currency.
Note that these rates are not linked to any transaction or card. This is simply a method of retrieving
your daily rate from the Acquiring Bank.
Example of a FX Currency Rate lookup request:

<GETFXCURRENCYRATE>
<FXCURRENCY>CAD</FXCURRENCY>
<BASEAMOUNT>1.05</BASEAMOUNT>
<HASH>f8d07c81b09c75c7c1901b8bb3bc0e26</HASH>
</GETFXCURRENCYRATE>
Fields description:
Field Name
Require
Description
d
TERMINALID
49
GlobalOne
FXCURRENCY
BASEAMOUNT
DATETIME
HASH

The foreign currency for which the rate is
requested. ISO 4217 Currency Code.
Transaction amount in the base currency. If sent
GlobalOne will return the correctly formatted and
calculated FOREIGNAMOUNT.
Request Date and Time. Format: DD-MMYYYY:HH:MM:SS:SSS.
Notes:
1.
The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALID+FXCURRENCY+DATETIME+secret
Example of a FX Currency Rate lookup response:
<FXCURRENCYRATERESPONSE>
<TERMINALCURRENCY>USD</TERMINALCURRENCY>
<FXCURRENCY>CAD</FXCURRENCY>
<BASEAMOUNT>1.05</BASEAMOUNT>
<FOREIGNAMOUNT>0.70</FOREIGNAMOUNT>
<DATETIME>string</DATETIME>
<HASH>e66530eb86c1cb25cf1047c0e7d90df8</HASH>
</FXCURRENCYRATERESPONSE>

Field Name
TERMINALCURRENCY
FXCURRENCY
CONVERSIONRATE
BASEAMOUNT
FOREIGNAMOUNT
DATETIME
HASH
Description
Terminals currency code. ISO 4217 Currency Code.
Requested currency code. ISO 4217 Currency Code.
Conversion rate. See Note 2 below.
Base amount supplied in request. Only sent in response if sent in
request.
Converted amount. Only sent in response if BASEAMOUNT sent
in request.
50
GlobalOne
Notes:
1.
The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALCURRENCY+FXCURRENCY+CONVERSIONRATE+DATETIME+secret
2.
In this string CONVERSIONRATE must be a decimal value with 6 decimal places
separated by dot character (.), example: 0.123000. The secret should be set by merchant in
the SelfCare System.
There is list of error codes and their brief descriptions:
Error Code
101
103
104
105
106
107
108
109
110
111
Description
Terminal not found.
Currencies are the same.
FX Conversion is not allowed for the terminal.
Invalid currency/Unknown currency.
Conversion rate not found.
Invalid request format.
Invalid hash in the request.
Other error.
Internal error.
Unsupported currency.
6.5 3D Secure for XML transactions (Where Available)

To simplify 3D Secure integration using XML payments, GlobalOne provides a simple MPI
redirect. To allow 3D Secure transactions for a terminal it should be configured and registered
with the card schemes, please contact the GlobalOne support team for details.
The merchants application should redirect the cardholders browser to the URL:
https://testpayments.globalone.me/merchant/mpi
The previous URL should be used in test mode only, please contact the GlobalOne support
team to receive the live URL.
51
GlobalOne
Cardholder will have to pass the 3D Secure check, check result will be sent back to the
merchant application as a GET request. Processing result response will include MPIREF
parameter, which should be included in the XML payment request.
The following parameters should be passed in the request:
Field Name
Require
Description
d
TERMINALID
CARDNUMBER
CARDEXPIRY
CARDTYPE
AMOUNT
Y
Y
Y
Y
CURRENCY
ORDERID
Y
Y
CVV
DATETIME
HASH
N
Y
Y
A Terminal ID provided by GlobalOne. NB Please

The payment card number.
4-digit expiry field (MMYY).
A 3-character currency code of the transaction.
The security code entered by the cardholder.
Notes:
1.
TERMINALID+ORDERID+CARDNUMBER+CARDEXPIRY+CARDTYPE+AMOUNT+DATETIME+
secret
The following parameters are returned to a merchant application:
Field Name
RESULT
Description
MPI processing result:
MPIREF
ORDERID
STATUS
A Approved
D Declined
MPI reference, this value should be sent in the XML payment request if
received from the GlobalOne MPI.
Original order identifier.
A - An attempt at authentication was performed (ECI: 06)
N - Authentication attempt not performed (ECI: 06)
U - Unable to authenticate (ECI: 07 or 06)
52
GlobalOne
ECI
DATETIME
HASH
Y - Authentication attempted and succeeded (ECI: 05)

05 - Full 3D Secure authentication
06 - Issuer and/or cardholder are not enrolled for 3D Secure
07 - 3D Secure authentication attempt failed (numerous possible
reasons) (Visa only)
Notes:
1.
RESULT+MPIREF+ORDERID+DATETIME+secret
After the merchant application will receives the 3D Secure check result, it should send an
XML payment request. If the 3D Secure check was successful (A Result) the payment request
should contain the fields MPIREF, Order ID and Terminal ID and they should be the same as in
the 3D Secure request. If the 3D Secure check was not successful (D Result) the application can
send a non-3D Secure transaction (MPIREF will not be available in such case) or dont send
payment transaction at all. We recommend that the transaction should be marked as declined
in your system if our MPI rejects the transaction.
53
GlobalOne
7 Secure Card Storage

Secure Card Storage is the storage of sensitive card information in the GlobalOne system for use at a
later date. It is a requirement for Subscription processing. It is useful for merchants that are required to
perform regular payments without the cardholder entering their information. Only PCI-DSS certified
merchants are allowed to store card details themselves.
7.1 Secure Card Registration and Updating from the Hosted Page
Secure Card details can be registered or updated using the GlobalOne hosted page by the
cardholder; card details will be stored using GlobalOne Secure Card Storage.
To initiate a Secure Card registration or update a POST must be made to the following URL:
https://testpayments.globalone.me/merchant/securecardpage
The following table describes the form fields to be posted:
Field Name
ACTION
Required
Y
TERMINALID
MERCHANTREF
DATETIME
HASH
Y
Y
Description
register
update
contact GlobalOne to be issued with a test terminal
ID.
Unique Reference assigned by the merchants
site/software to identify the stored card details.
Length is limited to 48 chars.
Format: DD-MM-YYYY:HH:MM:SS:SSS
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALID+MERCHANTREF+DATETIME+ACTION+SECRET
54
GlobalOne
Below is an example HTML form to open card details registration page.

<html>
<body>
<form action="https://testpayments.globalone.me/merchant/securecardpage"
method="post">
<input type="hidden" name="ACTION" value="register" />
<input type="hidden" name="TERMINALID" value="6491002" />
<input type="hidden" name="MERCHANTREF" value="1234321" />
<input type="hidden" name="DATETIME" value="15-03-2006:10:43:01:673" />
<input type="hidden" name="HASH"
value="d5d3441fb0e8318ce6d03976c2e93749" />
<input type="submit" value="Register" />
</form>
</body>
<html>
To initiate card details updating, the value of the ACTION parameter should be changed to update. A
Secure Card of MERCHANTREF 1234321 must already exist under your account. Please note that the
TERMINALID here is not valid and must be changed.
Assuming valid details were sent, the Hosted Registration or Update page will be displayed, clicking
on Register or Update will save the card details, result GET parameters will be forwarded to the
Secure Card URL that is configured on the Terminal Setup page.
Following parameters will be sent to the Secure Card Receipt URL:
Field Name
RESPONSECODE
Description
Response Code A - Approval, check the Response
Codes table below for a full list of all supported codes.
Response Text.
Original Merchant Reference.
Generated Card Reference.
The card number (obfuscated) that
registered/updated.
Expiry date of the card.
RESPONSETEXT
MERCHANTREF
CARDREFERENCE
MASKEDCARDNUMBER
CARDTYPE
CARDEXPIRY
DATETIME
HASH
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
55
GlobalOne
TERMINALID+RESPONSECODE+RESPONSETEXT+MERCHANTREF+CARDREFERENCE+DATETIME+SECRET
Response Codes:
Error Code
Description
E01
E03
E04
E05
E06
E07
E08
E09
E10
E11
E12
E13
SYSTEM ERROR TRY AGAIN

OPERATION NOT ALLOWED
INVALID REFERENCE DETAILS
INVALID CARD TYPE
INVALID TERMINALID
METHOD NOT SUPPORTED
INVALID MERCHANTREF
INVALID DATETIME
INVALID CARDNUMBER
INVALID CARDEXPIRY
INVALID CARDHOLDERNAME
INVALID HASH
If invalid parameter values are sent, an Error Page will appear and the web browser will not be
redirected to the Secure Card Receipt Page. This should not happen in a production environment after
integration is completed.
7.2 XML Secure Card Integration

7.2.1
Secure Card Details Registration and Updating
The following is an example of a Secure Card Details Registration request for a terminal:
<SECURECARDREGISTRATION>
<MERCHANTREF>77001</MERCHANTREF>
<CARDHOLDERNAME>John Doe<CARDHOLDERNAME>
</SECURECARDREGISTRATION>
The following is an example of a Secure Card Details Updating request:
<SECURECARDUPDATE>
56
GlobalOne
</SECURECARDUPDATE>
Fields description:
Field Name
MERCHANTREF
Required
Y
TERMINALID
DATETIME
CARDNUMBER
CARDEXPIRY
CARDTYPE
CARDHOLDERNAME
HASH
DONTCHECKSECURITY
CVV
Y
Y
Y
Y
Y
Y
Y
N
N
Description
Unique Merchant Reference. Length is limited to 48
chars.
The payment card number.
Card type supported by terminal.
Cardholder name.
Send Y if not sending CVV online for this registration.
The security code entered by the cardholder. If sent (and
DONTCHECKSECURITY not Y) then GlobalOne will
perform an authorization for 1 major unit of the terminal
currency. If authorized GlobalOne will void the
transaction so that it is not charged to the cardholder
and add the SecureCard. If declined or referred
GlobalOne will return an error to the SecureCard
registration request.
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALID+MERCHANTREF+DATETIME+CARDNUMBER+CARDEXPIRY+CARDTYPE+CARDHOLDERNAME+
SECRET
If the card was successfully registered, response for registration request would be:
<SECURECARDREGISTRATIONRESPONSE>
</SECURECARDREGISTRATIONRESPONSE>
57
GlobalOne
Example of a successful card updating response:

<SECURECARDUPDATERESPONSE>
</SECURECARDUPDATERESPONSE>
Field Name
MERCHANTREF
CARDREFERENCE
DATETIME
HASH
Description
Original Merchant Reference sent in registration request.
System-Generated Card Reference (Secure Card).
Notes:
1) The MD5 HASH is generated using the following as an input string: TERMINALID +
MERCHANTREF + CARDREFERENCE + DATETIME + SECRET
Error handling: If card was not registered or updated, error code and error message will be
returned:
<ERROR>
<ERRORCODE>E08</ERRORCODE>
<ERRORSTRING>INVALID MERCHANTREF</ERRORSTRING>
</ERROR>
There is list of error codes and corresponding messages:

Error Code
E01
E03
E04
E05
E06
E07
E08
E09
E10
E11
Description
INVALID CARD TYPE
INVALID TERMINALID
INVALID MERCHANTREF
INVALID DATETIME
INVALID CARDNUMBER
INVALID CARDEXPIRY
58
GlobalOne
E12
E13
INVALID CARDHOLDERNAME
INVALID HASH
7.2.2 Card Detail Removal

Note that SecureCard MerchantRef's cannot be re-used after deletion. This is because they are tied
to existing transactions in our system and are retained internally for data integrity and future refund
functionality.
Card details removal request format:
<SECURECARDREMOVAL>
</SECURECARDREMOVAL>
Fields description:
Field Name
MERCHANTREF
Required
Y
CARDREFERENCE
Description
chars.
System-Generated Card Reference (Secure Card).
TERMINALID
DATETIME
HASH
Y
Y
Y

Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALID+MERCHANTREF+DATETIME+CARDREFERENCE+SECRET
2.
Card detail successful deletion response format:
<SECURECARDREMOVALRESPONSE>
</SECURECARDREMOVALRESPONSE>
Field Name
DATETIME
Description
59
GlobalOne

HASH
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALID+MERCHANTREF+DATETIME+SECRET
Errors handling
If request was not successful, error code and error message will be returned:
<ERROR>
</ERROR>
There is list of error codes and corresponding messages:
Error Code
E01
E03
E04
E06
E07
E08
E13
7.2.3
Description
INVALID TERMINALID
INVALID MERCHANTREF
INVALID HASH
Card Details Search
Secure Card search by Merchant Reference can be performed as needed:

<SECURECARDSEARCH>
</SECURECARDSEARCH>
Fields description:
Field Name
MERCHANTREF
Required
Y
TERMINALID
DATETIME
Y
Y
Description
chars.
60
GlobalOne
HASH
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
as
an
input
string:
Secure Card detail successful deletion response format:
<SECURECARDSEARCHRESPONSE>
</SECURECARDSEARCHRESPONSE>
Field Name
MERCHANTREF
CARDREFERENCE
CARDTYPE
CARDEXPIRY
CARDHOLDERNAME
DATETIME
HASH
Description
Unique Merchant Reference.
Card Reference.
Card type supported by terminal.
Cardholder name.
Notes:
1. The
MD5
HASH
is
generated
using
the
following
TERMINALID+MERCHANTREF+CARDREFERENCE+CARDTYPE+CARDEXPIRY+CARDHOLDERNAME+DATETIM
E+SECRET
Errors handling
If request was not successful, error code and error message will be returned:
<ERROR>
<ERRORSTRING>INVALID REFERENCE DETAILS</ERRORSTRING>
</ERROR>
61
GlobalOne
Here is list of error codes and corresponding messages:

Error Code
E01
E03
E04
E06
E07
E08
E13
7.2.4
Description
INVALID TERMINALID
INVALID MERCHANTREF
INVALID HASH
XML Payments Using a Stored Secure Card
To send a payment transaction using a registered card, a standard PAYMENT request should be sent.
The Card Type should be set to 'SECURECARD', the CARDNUMBER should contain the Secure Card
Reference, both CARDEXPIRY and CARDHOLDERNAME tags should be omitted from the request.
62
GlobalOne
8 Subscriptions
GlobalOne Subscriptions is a versatile and complete recurring payments solution. It can be used in
two main ways:
1. Automatic payments - This is a fully automated solution that will manage the lifetime of a
recurring payment once it is registered and notify the merchant of any issues that happen during it's
lifetime.
2. Manual payments With this solution, recurring payments are set up in our system just as they
are for automatic payments. The main difference is that our system does not actually process payments
automatically. Instead, when a payment is pending, the merchant should initiate the payment, either via
and XML Payment Request or through the SelfCare system. Another difference with this method is that
you can modify the amount of the payment.
Subscriptions can only be set up on card details already stored in our system using the Secure Card
feature above. Subscriptions are set up in two levels:
1. Stored Subscriptions Stored subscriptions are not subscriptions in their own right, but instead
are templates for multiple subscriptions that are registered under them. They define the period (daily /
weekly / monthly / quarterly / annually), the number of those periods (if it's a fixed number), setup
price, recurring price, etc. They are intended to represent a product, for example.
2. Subscriptions Every subscription set up has to be under a Stored Subscription. However some
of the settings of the stored subscription can be overruled by the Subscription itself, as you will see
below. Subscriptions are intended to represent a specific order of a product represented by the stored
subscription that it's under.
8.1 Subscription Registration From Hosted Pay Page

New Subscription can be registered from the GlobalOne hosted page. When new subscription is
created it name, description, set-up price, recurring price, length, period type and type are copied from
the corresponding stored subscription.
To get Subscription Registration Page opened in a client browser a POST must be made to the
following URL:
63
GlobalOne
https://testpayments.globalone.me/merchant/subscriptionpage/register
Subscription registration POST parameters description:
Field Name
TERMINALID
Required
Y
Description
A TerminalID provided by GlobalOne. NB Please contact
MERCHANTREF
Y
Unique Merchant Reference. Length is limited to 48 chars.
STOREDSUBSCRIPTIONREF
N
This field is required if new Subscription being created should be
based on already existing Stored Subscription.
SECURECARDMERCHANTREF Y
Merchant Reference of a Sucre Card, which will be used to do
set-up and recurring payments.
DATETIME
Y
STARTDATE
Y
Subscription Start Date.
ENDDATE
N
Subscription End Date, if it is not set subscription will continue
until manually canceled or length reached (if it is set).
HASH
Y
Following parameters should be posted if new Stored Subscription should be created
(STOREDSUBSCRIPTIONREF shouldn't be posted in such case).
NEWSTOREDSUBSCRIPTIONRE N
Merchant Ref to be assigned for new Stored Subscription
F
being created.
NAME
Y
Display name for subscription.
DESCRIPTION
Y
Description explaining subscription.
PERIODTYPE
Y
Integer code of Period Type, can be:
1 DAILY
2 WEEKLY
3 BIWEEKLY
4 MONTHLY
5 QUARTERLY
6 - YEARLY
LENGTH
Y
0 for non ending / multiplier of period. This does not take
effect if (Subscription length * Period Type) > (End Date
Current Date).
RECURRINGAMOUNT
Y
Cost of each payment (will be ignored if manual).
INITIALAMOUNT
Y
Initial (set-up) payment to be taken off card. Payment will
not be taken if it is 0. Setup fails if setup payment declines.
TYPE
Y
Integer code of subscription type:
1 AUTOMATIC
2 MANUAL
3 AUTOMATIC (WITHOUT AMOUNTS)

ONUPDATE
Y
Integer code of onupdate:
1 CONTINUE
2 UPDATE (Let all depending subscriptions finish

their subscription prior to update / Update name,
description, recurringprice, setupprice, subscriptionlength,
periodtype, type for all subscriptions)
64
GlobalOne
ONDELETE
Integer code of ondelete:
1 CONTINUE
2 - CANCEL (Continue subscriptions until cancelled

manually or reach end date or length / Cancel all
subscriptions)
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALID+MERCHANTREF+SECURECARDMERCHANTREF+DATETIME+STARTDATE+SECRET
Below is an example HTML form to open subscription registration page.
<html>
<body>
<form
action=https://testpayments.globalone.me/merchant/subscriptionpage/register method=post>
<input type=hidden name=TERMINALID value=6491002>
<input type=hidden name=MERCHANTREF value=26352>
<input type="hidden" name="STOREDSUBSCRIPTIONREF" value="6523423">
<input type="hidden" name="SECURECARDMERCHANTREF" value="237498">
<input type=hidden name=DATETIME value=03-08-2009:17:32:18:329>
<input type="hidden" name="STARTDATE" value="04-08-2009">
<input type="hidden" name="ENDDATE" value="03-08-2010">
<input type=hidden name=HASH
value=b9a034421808a80dc8f1a5657da80f95>
<input type=submit value=Register>
</form>
</body>
<html>
Assuming valid details were sent, the Subscription Registration Hosted page will be displayed,
clicking on Accept & Subscribe button will create the subscription only if the setup amount authorizes
successfully, and the resulting GET parameters will be forwarded to the Subscription Receipt URL that is
configured on the Terminal Setup page. If Subscription Secure Card currency is other then Stored
Subscription currency then eDCC Decision Page will be displayed, and the customer will have to decide if
eDCC should be used for the initial and all subsequent payments for the subscription.
65
GlobalOne
Following parameters will be sent to the Subscription Receipt URL:

Field Name
RESPONSECODE
Description
Response Code:
A - Approval
C - Cancelled
Check the
Subscription creation and updating error codes table for a full list of
supported codes.
Response Text.
Original Merchant Reference.
RESPONSETEXT
MERCHANTREF
DATETIME
HASH
Notes:
1.
The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALID+MERCHANTREF+DATETIME+RESPONSECODE+RESPONSETEXT+SECRET
If invalid parameter values will be sent, an Error Page will appear and the web browser will not be
redirected to the Subscription Receipt Page. This should not happen in a production environment after
integration is completed.
8.2 XML Subscription Integration

Stored Subscription and Subscriptions can be managed through XML Gateway.
8.2.1
Stored Subscription Request
The following is an example of a Stored Subscription Registration request for a terminal:

<ADDSTOREDSUBSCRIPTION>
<MERCHANTREF>MR001</MERCHANTREF>
<NAME>Animal Life</NAME>
<DESCRIPTION>Magazine membership</DESCRIPTION>
<PERIODTYPE>MONTHLY</PERIODTYPE>
<LENGTH>12</LENGTH>
<RECURRINGAMOUNT>15.87</RECURRINGAMOUNT>
<INITIALAMOUNT>10.99</INITIALAMOUNT>
<TYPE>AUTOMATIC</TYPE>
<ONUPDATE>CONTINUE</ONUPDATE>
66
GlobalOne
<ONDELETE>CANCEL</ONDELETE>
<HASH>750f7c545a3d63ecaf3b48c149b95555</HASH>
</ADDSTOREDSUBSCRIPTION>
Example of a Stored Subscription Updating request:
<UPDATESTOREDSUBSCRIPTION>
<LENGTH>12</LENGTH>
<HASH>5023bbb6726d1b5d2dcb7c77fb11b94f</HASH>
</UPDATESTOREDSUBSCRIPTION>
Fields description:
Field Name
MERCHANTREF
Required
Y
TERMINALID
DATETIME
NAME
DESCRIPTION
PERIODTYPE
Y
Y
Y
Y
Y
LENGTH
CURRENCY
RECURRINGAMOUNT
INITIALAMOUNT
Y
Y
TYPE
ONUPDATE
Description
Unique merchant identifier per terminal. Length is limited to
48 chars.
Period Type, can be: DAILY, WEEKLY, BIWEEKLY, MONTHLY,
QUARTERLY, YEARLY.
Current Date).
Currency of subscription, this must either the base currency
of the terminal or if supported, one of the configured
allowed currencies.
Cost of each payment (will be ignored if manual).
not be taken if it is 0.
MANUAL / AUTOMATIC / AUTOMATIC (WITHOUT
AMOUNTS).
UPDATE/CONTINUE (Update name, description,
recurringprice, setupprice, subscriptionlength, periodtype,
67
GlobalOne
ONDELETE
HASH
type for all subscriptions/Let them finish their subscription

prior to update).
CANCEL/CONTINUE (Cancel all subscriptions / Continue
subscriptions until cancelled manually or reach end date or
length).
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALID+MERCHANTREF+DATETIME+TYPE+NAME+PERIODTYPE+CURRENCY+RECURRINGAMOUNT+I
NITIALAMOUNT+LENGTH+SECRET
If new stored subscription was successfully registered, response would be:
<ADDSTOREDSUBSCRIPTIONRESPONSE>
</ADDSTOREDSUBSCRIPTIONRESPONSE>
Example of a successful stored subscription updating response:
<UPDATESTOREDSUBSCRIPTIONRESPONSE>
<HASH>0af49616cad0fd1e19bc709de7d7c934</HASH>
</UPDATESTOREDSUBSCRIPTIONRESPONSE>
Field Name
MERCHANTREF
DATETIME
HASH
Description
Original Merchant Reference sent in registration
request
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
68
GlobalOne
Errors handling
If stored subscription was not registered or updated, error code and error message will be returned:
<ERROR>
</ERROR>
Stored Subscription creation and updating error codes:
Error Code
E01
E03
E06
E07
E08
E09
E13
E20
E21
E22
E23
E24
E25
E26
E27
E28
E29
Description
INVALID TERMINALID
INVALID MERCHANTREF
INVALID DATETIME
INVALID HASH
INVALID LENGTH
INVALID PERIOD TYPE
INVALID NAME
INVALID DESCRIPTION
INVALID RECURRINGAMOUNT
INVALID INITIALAMOUNT
INVALID TYPE
INVALID ONUPDATE
INVALID ONDELETE
INVALID TERMINAL CURRENCY
8.2.2 Stored Subscription Deletion Request

Note that Stored Subscription MerchantRef's cannot be re-used after deletion. This is because they
are tied to existing transactions in our system and are retained internally for data integrity and issue
tracingte stored subscription following XML Gateway request should be send:
<DELETESTOREDSUBSCRIPTION>
<HASH>efc5a04b5a98be9bd59ec5383abb9161</HASH>
</DELETESTOREDSUBSCRIPTION>
Fields description:
69
GlobalOne
Field Name
MERCHANTREF
Required
Y
TERMINALID
DATETIME
HASH
Y
Y
Y
Description
Unique merchant identifier per terminal. Length is
limited to 48 chars.
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
input
string:
Example of a successful stored subscription deletion response:
<DELETESTOREDSUBSCRIPTIONRESPONSE>
<HASH>8a8f462278c730e9de5561d8f186d7dc</HASH>
</DELETESTOREDSUBSCRIPTIONRESPONSE>
Field Name
MERCHANTREF
Description
request.
DATETIME
HASH
Notes:
1)
The
MD5
HASH
is
generated
using
the
following
as
an
Errors handling
If stored subscription was not registered or updated, error code and error message will be returned:
<ERROR>
</ERROR>
Here is list of error codes and corresponding messages:

Error Code
E01
Description
70
GlobalOne

E03
E06
E07
E08
E09
E13
8.2.3

INVALID TERMINALID
INVALID MERCHANTREF
INVALID DATETIME
INVALID HASH
Subscription Creation Request
Each subscription should be created based on some stored subscription. When new subscription is
created it name, description, set-up price, recurring price, length, period type and type are copied from
the corresponding stored subscription, most subscription fields can be changed by Subscription Updating
request.
To create new subscription based on an existing Stored Subscription following XML Gateway request
should be sent:
<ADDSUBSCRIPTION>
<MERCHANTREF>MR01-02</MERCHANTREF>
<STOREDSUBSCRIPTIONREF>MR01</STOREDSUBSCRIPTIONREF>
<SECURECARDMERCHANTREF>7126</SECURECARDMERCHANTREF>
<STARTDATE>01-08-2009</STARTDATE>
<ENDDATE>31-07-2010</ENDDATE>
<EDCCDECISION>Y</EDCCDECISION>
<HASH>8515ccc5605651c12ab0645f79eb0271</HASH>
</ADDSUBSCRIPTION>
If Stored Subscription doesn't yet exist it can be created putting all it details into the nested
NEWSTOREDSUBSCRIPTIONINFO tag, STOREDSUBSCRIPTIONREF in such case should be omitted. There
is example of such request:
<ADDSUBSCRIPTION>
<NEWSTOREDSUBSCRIPTIONINFO>
71
GlobalOne
<LENGTH>12</LENGTH>
</NEWSTOREDSUBSCRIPTIONINFO>
<HASH>8515ccc5605651c12ab0645f79eb0271</HASH>
</ADDSUBSCRIPTION>
Fields description:
Field Name
MERCHANTREF
Required
Y
TERMINALID
STOREDSUBSCRIPTIONREF
Y
N
SECURECARDMERCHANTR
EF
DATETIME
STARTDATE
ENDDATE
EDCCDECISION
NEWSTOREDSUBSCRIPTIO
NINFO
HASH
Y
Y
N
Description
Unique merchant identifier per terminal. Length is limited to 48
chars.
Stored Subscription Merchant Reference, it is allowed only if
NEWSTOREDSUBSCRIPTIONINFO do not present.
Merchant Reference of a Sucre Card, which will be used to do setup and recurring payments.
Subscription Start Date. Format: DD-MM-YYYY.
Subscription End Date, if it is not set subscription will continue
until manually canceled or length reached (if it is set). Format:
DD-MM-YYYY.
This field is supported by a eDCC-enabled terminals only and will
be ignored if terminal doesn't supports eDCC. Can be Y or N.
It is allowed only if STOREDSUBSCRIPTIONREF is not set. This tag
and all it children should be set if Stored Subscription on which
new Subscription being added should be based doesn't exists yet
and should be created. Please check
NEWSTOREDSUBSCRIPTIONINFO fields description table for
details.
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALID+MERCHANTREF+STOREDSUBSCRIPTIONREF+SECURECARDMERCHANTREF+DATETI
ME+STARTDATE+SECRET
72
GlobalOne
2. STOREDSUBSCRIPTIONREF should be omitted if it is not set.

NEWSTOREDSUBSCRIPTIONINFO fields description:
Field Name
MERCHANTREF
Required
Y
NAME
DESCRIPTION
PERIODTYPE
Y
Y
Y
LENGTH
CURRENCY
RECURRINGAMOUNT
INITIALAMOUNT
TYPE
ONUPDATE
Y
Y
ONDELETE
Description
Unique merchant identifier per terminal. Length is limited to
48 chars.
Period Type, can be: DAILY, WEEKLY, BIWEEKLY, MONTHLY,
QUARTERLY, YEARLY.
Current Date).
Currency of subscription, this must either the base currency
of the terminal or if supported, one of the configured
allowed currencies.
Cost of each payment (should not be sent if TYPE is
MANUAL).
not be taken if it is 0.
MANUAL / AUTOMATIC.
UPDATE/CONTINUE (Update name, description,
recurringprice, setupprice, subscriptionlength, periodtype,
type for all subscriptions/Let them finish their subscription
prior to update).
CANCEL/CONTINUE (Cancel all subscriptions / Continue
subscriptions until cancelled manually or reach end date or
length).
Example of a successful subscription creation response:

<ADDSUBSCRIPTIONRESPONSE>
<HASH>8bb39be67a1f05bf73fe334e12037257</HASH>
</ADDSUBSCRIPTIONRESPONSE>
Field Name
MERCHANTREF
DATETIME
HASH
Description
request.
Notes:
73
GlobalOne
1. The

MD5
HASH
is
generated
using
the
following
as
an
input
string:
Errors handling
If new subscription was not registered, error code and error message will be returned:
<ERROR>
</ERROR>
Subscription creation and updating error codes:
Error Code
E01
E03
E06
E07
E08
E09
E13
E20
E21
E22
E23
E24
E25
E26
E27
E28
E29
E30
E31
E32
E33
E34
E35
E36
E37
E38
E39
8.2.4
Description
INVALID TERMINALID
INVALID MERCHANTREF
INVALID DATETIME
INVALID HASH
INVALID LENGTH
INVALID PERIOD TYPE
INVALID NAME
INVALID DESCRIPTION
INVALID RECURRINGAMOUNT
INVALID INITIALAMOUNT
INVALID TYPE
INVALID ONUPDATE
INVALID ONDELETE
INVALID TERMINAL CURRENCY
INVALID STORED SUBSCRIPTION REF
INVALID STORED SUBSCRIPTION MERCHANT REF
INVALID SECURE CARD MERCHANT REF
INVALID STARTDATE
INVALID ENDDATE
INVALID EDCCDECISION
SETUP PAYMENT PROCESSING ERROR
INVALID SUBSCRIPTIONRECURRINGAMOUNT
INVALID SUBSCRIPTIONINITIALAMOUNT
SECURE CARD NOT VALIDATED
Update Subscription Request
The following is an example of a Subscription Updating request:

74
GlobalOne

<UPDATESUBSCRIPTION>
<LENGTH>12</LENGTH>
<HASH>53b6917aac8eb179e8b80f754c4afd5c</HASH>
</UPDATESUBSCRIPTION>
Fields description:
Field Name
MERCHANTREF
Required
Y
TERMINALID
SECURECARDMERCHANTREF
Y
Y
DATETIME
NAME
DESCRIPTION
PERIODTYPE
LENGTH
RECURRINGAMOUNT
STARTDATE
ENDDATE
Y
N
N
N
N
N
N
N
EDCCDECISION
HASH
Description
Merchant Ref of subscription, which should be
updated.
Merchant Reference of a Sucre Card, which will be
used to do recurring payments.
Subscription Name.
Subscription Description.
New Period Type.
Subscription Length.
New Recurring Amount.
Subscription Start Date.
Subscription End Date, if it is not set subscription will
continue until manually canceled or length reached
This field is supported by a eDCC-enabled terminals
only and will be ignored if terminal doesn't supports
eDCC. Can be Y or N.
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALID+MERCHANTREF+SECURECARDMERCHANTREF+DATETIME+STARTDATE+SECRET
Example of a successful subscription updating response:
<UPDATESUBSCRIPTIONRESPONSE>
75
GlobalOne
</UPDATESUBSCRIPTIONRESPONSE>
Field Name
MERCHANTREF
Description
request
DATETIME
HASH
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
Errors handling
If subscription was not updated, error code and error message will be returned:
<ERROR>
</ERROR>
Possible error codes are covered in the Subscription creation and updating error codes.
8.2.5 Subscription Deletion Request
Note that Subscription MerchantRef's cannot be re-used after deletion. This is because they are tied
to existing transactions in our system and are retained internally for data integrity and issue tracing.
The following is an example of a Subscription Deletion request:
<DELETESUBSCRIPTION>
</DELETESUBSCRIPTION>
Fields description:
Field Name
MERCHANTREF
Required
Y
Description
Merchant Ref of subscription, which should be deleted.
76
GlobalOne
TERMINALID
DATETIME
HASH
Y
Y
Y

Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
Example of a successful subscription deletion response:
<DELETESUBSCRIPTIONRESPONSE>
</DELETESUBSCRIPTIONRESPONSE>
Field Name
MERCHANTREF
Description
request.
DATETIME
HASH
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
Errors handling
If subscription was not deleted, error code and error message will be returned:
<ERROR>
</ERROR>
Possible error codes are covered in the Subscription creation and updating error codes.
8.2.6
Subscription Payments Request
Manual subscription recurring payment can be done from the XML Gateway. If automatic
subscription was not paid automatically because of card details expiration or other issue it also can be
paid in the same way as manual after Secure Card issue was solved. The following is an example of a
77
GlobalOne
Subscription Payment request:

<SUBSCRIPTIONPAYMENT>
<SUBSCRIPTIONREF>311</SUBSCRIPTIONREF>
<CARDCURRENCY>JPY</CARDCURRENCY>
<CARDAMOUNT>10638</CARDAMOUNT>
<EMAIL>cardholder_email@globalone.me</EMAIL>
</SUBSCRIPTIONPAYMENT>
Fields description:
Field Name
ORDERID
Required
Y
TERMINALID
AMOUNT
SUBSCRIPTIONREF
DESCRIPTION
MATION
DATETIME
EMAIL
HASH
Y
N
N
Y
N
Y
Description
contact GlobalOne to be issued with a test
terminal ID.
The amount of the transaction as a 2 digit
decimal or an Integer value for JPY amounts.
Merchant reference of a subscription being paid.
Transaction Description.
It is accepted for eDCC-enabled subscriptions
only.
Cardholder e-mail address.
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
TERMINALID+ORDERID+SUBSCRIPTIONREF+AMOUNT+DATETIME+SECRET
Example of a successful subscription payment response:
<SUBSCRIPTIONPAYMENTRESPONSE>
78
GlobalOne
<HASH>6dd32c4b61f180dd791310f9c07d76a1</HASH>
</SUBSCRIPTIONPAYMENTRESPONSE>
Field Name
RESPONSECODE
RESPONSETEXT
APPROVALCODE
DATETIME
HASH
Description
Six digit AuthCode.
The time of the transaction created by the bank. Format: DDMM-YYYY:HH:MM:SS:SSS.
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
Errors handling
If subscription payment was not accepted, error message will be returned:
<ERROR>
<ERRORSTRING>Invalid HASH field</ERRORSTRING>
</ERROR>
8.2.7
Subscription Notifications
The Subscription Notification URL can be set in the Terminal Setup page of the SelfCare System. If
this is set a POST notification will be sent to this URL each time automated activity happens on any
active subscriptions. Note that manual changes applied to subscriptions via the SelfCare System will not
generate these notifications.
The data sent to the Subscription Notification URL contains the normal subscription response fields
as well as these extra fields:
The following fields are sent in the notification:
Field Name
NOTIFICATIONTYPE
Description
Possible values for subscriptions are:
SUBSCRIPTIONCREATION
SUBSCRIPTIONUPDATING
79
GlobalOne
SUBSCRIPTIONDELETION
SUBSCRIPTIONSETUPPAYMENT
SUBSCRIPTIONRECURRINGPAYMENT
Possible values for stored subscriptions are:
TERMINALID
ORDERID
AMOUNT
STOREDSUBSCRIPTIONCREATION
STOREDSUBSCRIPTIONUPDATING
STOREDSUBSCRIPTIONDELETION
The Terminal ID that the subscription is set up on.
The Order ID that the system assigned to the Subscription
payment. Only sent for SUBSCRIPTIONSETUPPAYMENT and
The amount of the subscription payment as a 2 digit decimal
or an Integer value for JPY amounts. Only sent for
SUBSCRIPTIONSETUPPAYMENT and
Notes:
1. Subscription
payments
(SUBSCRIPTIONSETUPPAYMENT
and
SUBSCRIPTIONRECURRINGPAYMENT) MD5 HASH is calculated using the following as an input

string:
TERMINALID+MERCHANTREF+NOTIFICATIONTYPE+DATETIME+ORDERID+
AMOUNT+RESPONSECODE+RESPONSETEXT+secret
2. Subscription change MD5 HASH is calculated using the following as an input string:
TERMINALID+MERCHANTREF+NOTIFICATIONTYPE+DATETIME+
RESPONSECODE+RESPONSETEXT+secret
Note that for Stored Subscriptions RESPONSECODE and RESPONSETEST will always be blank.
80
GlobalOne
9 Bulk Payments
Bulk payments are useful for merchants that need to process a large amount of transaction
periodically for the customers.
We allow submission of these transactions in a csv file. We will immediately return a response
based on file format and field validation.
An e-mail notification will be sent when the bulk file has been processed. This will only be sent if
the notification email is configured. Please see the SelfCare User Guide for details.
If the customer does not wish to automate their bulk payments, all of these features are available
inside our SelfCare system. Please see the SelfCare User Guide for details.
9.1 Request File Submission

A HTTP POST will be sent to:
https://testpayments.globalone.me/merchant/bulkpayments/submit
during testing. The live URL will be supplied when the merchant is ready to go live.
The parameters for the HTTP POST are:
Field Name
terminalid
transactioncount
batchtotal
datetime
Required
Y
Y
Y
Y
hash
Description
Terminal ID Provided by GlobalOne TPS.
The count of transactions in the bulk payment file.
The net total of all amount fields in the bulk payment file.
The date time of submission. Format: DD-MMYYYY:HH:MM:SS:SSS.
MD5(terminalid +
transactioncount+batchtotal+datetime+SECRET)
This is an MD5 HASH of the above described string
without +s. The SECRET should be set by merchant in the
SelfCare section.
81
GlobalOne
9.2
Request CSV File Format

Field Name
Required
Order ID
Y
Currency
Amount
Y
Y
Card Number
Card Type
Y
N
Card Expiry
Cardholder Name
N
N
Address 1
Address 2
Post Code
Date Time
Hash
N
N
N
Y
Y
Auto Ready
Description
Email
N
N
Description
A unique reference generated by Merchant system to
identify the transaction. (Max 12 Characters).
ISO 4217 Currency Code.
Amount formatted to two decimal places. E.g.
1653.00.
Card PAN. Can be SecureCard reference
See section 3.2 above. Leave blank if using
SecureCard.
MMYY. Leave blank when using SecureCard
The cardholders name. Leave blank when using
SecureCard
AVS Address Line 1.
AVS Address Line 2.
AVS Post Code.
An MD5 HASH of TerminalID + OrderID + Amount +
DateTime + SECRET
Amount should be formatted to 2 decimal places.
Set to Y for setting auto ready or N to mark as
pending.
Optional transaction description.
Card holder email for notification.
9.3 Request File Submission Response

The response is returned in csv format as a string, e.g. 200,76528
The response contains the following fields:
Field Name
Response Code
Description
Code defining the result of the bulk payment submission. Code is a 3 digit
numeric code.
Possible responses codes :
200 VALIDATION OK
001 INVALID FILE ITEM COUNT
002 INVALID FILE FORMAT
003 FILE UPLOAD ERROR
004 INVALID TRANSACTION COUNT
005 INVALID BATCH TOTAL
006 INVALID TERMINAL ID
007 INVALID DATETIME
008 INVALID HASH
82
GlobalOne

009
010
011
012
013
014
015
016
NOTHING TO SETTLE
INVALID NUMBER OF BATCH FILES
UNKNOWN ERROR
INVALID BULK ID
INVALID BULK ID TERMINAL ID COMBINATION
BULK PAYMENTS ARE NOT ALLOWED
BULK PROCESSING IN PROGRESS
9.4 Response File Request

The Response file is a csv file containing the results of all of the transactions submitted in a bulk
payment. This file is available for download in the merchant SelfCare system. Please see SelfCare User
Guide for details.
The response file request is a HTTP GET request. The test URL to submit to is:
https://testpayments.globalone.me/merchant/bulkpayments/result
The required parameters are:
Field Name
bulkid
Required
Y
terminalid
hash
Y
Y
Description
The bulk id supplied to merchant after submitting bulk
payments file.
Terminal ID Provided by GlobalOne.
Notes:
1. The
MD5
HASH
is
generated
using
the
following
as
an
input
string:
terminalid+bulkid+SECRET
If the file is still being progressed the response to this request will be error code
016 Which signifies BULK PROCESSING IN PROGRESS
83
GlobalOne
9.5 Response File Format

The response data is returned in a csv file. It will contain the results of the transactions in a
specified bulkid.
Field Name
Order ID
Required
Y
Approval Code
Response Code
N
N
Description
Order ID supplied by merchant in request. (Max 12
Characters).
Will be present for a successful authorization.
A, D or R (Approved,Declined or Referral)
In the case of an error there is an 3-digit numeric error code
contained in this column.
100 Order Already Processed
101
System Error
Response Text
Date time
Text describing state of transaction. Error message will be

displayed here if an issue was encountered while processing
transactions.
Only sent in the case of no error, same format as in request.
YYYY-MM-DD:HH:MM:SS.
Hash
Notes:
1.
The
MD5
HASH
is
generated
using
the
following
as
an
input
string:|TERMINALID+ORDERID+AMOUNT+DATETIME+RESPONSECODE+RESPONSETEXT+SECRET
84
GlobalOne
Appendix A: CVV & AVS Responses

Note that transactions can still be authorized even if the CVV and AVS responses are No match or
failure responses. CVV and AVS responses are for indication to the merchant only and usually do not
influence the overall Authorization result. This can vary per cardholders bank though (issuing bank).
CVV results:
M - CVV Match
N - CVV No Match
P - Not Processed
S - CVV should be on the card but the merchant indicates it is not.
U - User is unregistered
AVS results:
A - Address matches, ZIP does not. The first five numerical characters contained in the address match
with those stored at the VIC or issuers center. However, the zip code does not match.
E - Ineligible transaction.
N - Neither address nor ZIP matches. Neither the first five numerical characters contained in the address
match with those stored at the VIC nor issuers center nor the zip code match.
R - Retry (system unavailable or timed out).
S - Card type not supported. The card type for this transaction is not supported by AVS. AVS can verify
addresses for Visa cards, MasterCard, proprietary cards, and private label transactions.
U - Address information unavailable.
G - Address information unavailable, International - Visa Only The address information was not available
at the VIC or issuers center.
W - Nine-digit zip match, address does not. The nine-digit Postal zip code matches that stored at the VIC
or card issuer's center. However, the first five numerical characters contained in the address do not
match.
X - Exact match (nine-digit zip and address). Both the nine-digit Postal zip code as well as the first five
numerical characters contained in the address match.
Y - Address and five-digit zip match. Both the five-digit Postal zip code as well as the first five numerical
characters contained in the address match.
Z - Five-digit zip matches, address does not. The five-digit Postal zip code matches that stored at the VIC
or card issuers centre.
85
GlobalOne
Auto Decline AVS failures setting will only approve transactions that have an AVS response of Y, U, G or
Z.
86
GlobalOne
Appendix B: Supported Currencies

The following is a list of currency types supported by GlobalOne. Other may be added upon
request.
CURRENCY
CURRENCY CODE
EURO
BRITISH POUNDS
UNITED STATES DOLLARS
AUSTRALIAN DOLLARS
CANADIAN DOLLARS
SWISS FRANC
DANISH KRONE
HONG KONG DOLLAR
JAPANESE YEN
NORWEGIAN KRONE
NEW ZEALAND DOLLAR
SWEDISH KRONA
SOUTH AFRICAN RAND
CZECH KORUNA
SINGAPORE DOLLAR
THAI BAHT
ICELANDIC KRONA
HUNGARIAN FORINT
ARGENTINE PESO
BAHAMIAN DOLLAR
BAHRAINI DINAR
BARBADOS DOLLAR
BERMUDIAN DOLLAR
CHINESE YUAN
COLOMBIAN PESO
INDIAN RUPEE
ISRAELI SHEQEL
KENYAN SHILLING
SOUTH KOREAN WON
KUWAITI DINAR
LATVIAN LATS
MALAYSIAN RINGGIT
MEXICAN PESO
EUR
GBP
USD
AUD
CDN
CHF
DKK
HDK
JPY
NOK
NZD
SEK
ZAR
CZK
SGD
THB
ISK
HUF
ARS
BSD
BHD
BBD
BMD
CNY
COP
INR
ILS
KES
KRW
KWD
LVL
MYR
MXN
CODE
978
826
840
36
124
756
208
344
392
578
554
752
710
203
702
764
352
348
32
44
48
52
60
156
170
365
376
404
410
414
428
458
484
87
GlobalOne
MOROCCAN DIRHAM
OMANI RIAL
PANAMANIAN BALBOA
QUATARI RIAL
RUSSIAN RUBLE
SAUDI RIYAL
TRINIDAD AND TOBAGO DOLLAR
UAE DIRHAM
NEW TAIWAN DOLLAR
VENEZUELAN BOLIVAR
ROMANIAN LEU
TURKISH LIRA
UKRAINIAN HRYVNIA
POLISH ZLOTY
BRAZILIAN REAL

MAD
OMR
PAB
QAR
RUB
SAR
TTD
AED
TWD
VEF
RON
TRY
UAH
PLN
BRL
504
512
590
634
643
682
780
784
901
937
946
949
980
985
986
88
GlobalOne
Appendix C: Bank Response Codes

Auth Response
Message
Response
Code
Definition
Exact Match
Exact Match
Address Match
Zip Match
Zip Match
No Match
Ver Unavailable
Ver Unavailable
Retry
Error Ineligible
Serv Unavailable
Approval
Card Ok
Call
Call
No Reply
No Reply
Hold-call or Pick Up
Card
Card
00
00
00
00
00
00
00
00
00
00
00
00
85
1
2
28
91
4
Exact match, nine-character numeric ZIP

Exact match, five-character numeric ZIP
Address match only
Nine-character numeric ZIP match only
Five-character numeric ZIP match only
No address or ZIP match
Address unavailable
Non-U.S. Issuer does not participate
Issuer system unavailable
Not a mail/phone order
Service not supported
Approved and completed
No reason to decline
Refer to issuer
Refer to issuer-Special condition
File is temporarily unavailable
Issuer or switch is unavailable
Pick up card (no fraud)
Pick up card, special condition (fraud

account)
Card
Card
Acct Length Error
Already Reversed
Amount Error
Can't Verify PIN
Can't Verify PIN
Card No. Error
Cashback Not App
Cashback Not Avail
Check Digit Error
CID Format Error
Date Error
Decline
Decline
Decline
41
Lost card, pick up (fraud account)
43
Stolen card, pick up (fraud account)
EA
79
13
83
86
14
82
N3
EB
EC
80
5
51
N4
Verification error
Already reversed at switch
Invalid amount
Cannot verify PIN
Cannot verify PIN
Invalid card number
Cash back limit exceeded
Cash back service is not available
Verification error
Verification error
Invalid date
Do not honor
Insufficient funds
Exceeds issuer withdrawal limit
or
or
or
or
or
or
or
or
or
or
or
85
85
85
85
85
85
85
85
85
85
85
89
GlobalOne
Decline
Decline
Decline
Decline
Encryption Error
Error XXXX
(Check Service Custom
Text)
61
62
65
93
81
6
6
Exceeds withdrawal limit

Invalid service code, restricted
Activity limit exceeded
Violation, cannot complete
Cryptographic error
General error
Error response text from check service
Note: When processing a check guarantee
transaction, the service provider could
return a customized text message when
the response code is "06". Please contact
the appropriate check guarantee service
provider for a listing of possible custom
text messages.
Expired Card
Failure HV
Failure CV
Invalid Routing
Invalid Trans
No Account
No Action Taken
Unsolic Reversal
No Action Taken
No Check Account
No Credit Acct
No Save Acct
No Such Issuer
PIN Exceeded
RE Enter
Sec Violation
Serv Not Allowed
Serv Not Allowed
Srchg Not Allowed
54
HV
CV
92
12
78
21
76
77
52
39
53
15
75
19
63
57
58
B1
Expired card
Hierarchy verification failure
Card type verification error
Destination not found
Invalid transaction
No account
Unable to back out transaction
Unable to locate, no match
Inconsistent data, rev., or repeat
No checking account
No credit account
No savings account
No such issuer
PIN tries exceeded
Re-enter transaction
Security violation
Transaction not permitted-Card
Transaction not permitted-Terminal
Surcharge amount not permitted on Visa
cards or EBT food stamps
Srchg Not Allowed
B2
Surcharge amount not supported by debit

network issuer
Stop Recurring
R0
Customer requested stop of specific

recurring payment
Approval
Cannot Convert
T0
T1
First check is OK and has been converted

Check is OK but cannot be converted declined transaction
Invalid ABA
T2
Amount Error
T3
Invalid ABA number, not an ACH

participant
Amount greater than the limit
90
GlobalOne
Unpaid Items
Duplicate Number
MICR Error
Too Many Checks

T4
T5
T6
T7
Unpaid items, failed negative file check

Duplicate check number
MICR error
Too many checks (over merchant or bank
limit)
Glossary
AVS
Address Verification System
BIN
Bank Identification Number
CVV
Card Verification Value
eDCC
Electronic Dynamic Currency Conversion
HTML
Hypertext Mark Up Language
HTTPS
Hypertext Transfer Protocol Secure
MIS
Management Information System
TPS
Transaction Processing Services
URL
Universal Resource Locator
MCP
Multi Currency Processing
MSR
Magnetic Stripe Reader
CHP
Card Holder Present
91

Globalone API V 2.6.3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Globalone API V 2.6.3

Uploaded by

Copyright:

Available Formats

XML API Integration Guide

XML Integration Guide v.2.6.3

For support contact

XML Integration Guide v.2.6.3

Choosing an Integration Method .......................................................................................................... 7

Hosted Payment Page ............................................................................................................. 7

XML Gateway .......................................................................................................................... 8

2.3 Costs ................................................................................................................................................. 9

Items for Consideration........................................................................................................... 9

2.4 A Word on Functionality .................................................................................................................. 9

Secure Communication/Card Types Supported.................................................................................. 10

GlobalOne Testing Guide ...................................................................................................... 11

Merchant Validation Document............................................................................................ 11

Hosted Pay Page.................................................................................................................................. 15

Sandbox Test Details ............................................................................................................. 15

Test Cards .............................................................................................................................. 15

5.2 MaxMind MinFraud (Where Available) ......................................................................................... 15

XML Integration Guide v.2.6.3

5.6 Hosted Pages in iFrame Format ..................................................................................................... 22

XML Payments Integration.................................................................................................................. 24

Sandbox Test Details ............................................................................................................. 24

Test Cards .............................................................................................................................. 24

6.2 MaxMind MinFraud (Where Available) ......................................................................................... 25

XML Payments ....................................................................................................................... 25

Pre-Authorization Request .................................................................................................... 31

Pre-Auth Completion Request .............................................................................................. 35

6.4 XML Requests with eDCC (Where Available) ................................................................................. 42

eDCC Exchange Rate Request ............................................................................................... 42

eDCC Information in the XML Requests ................................................................................ 45

Transaction Status Updates .................................................................................................. 47

Retrieve Foreign Currency Exchange Rates........................................................................... 49

6.5 3D Secure for XML transactions (Where Available)....................................................................... 51

Secure Card Storage ............................................................................................................................ 54

Secure Card Details Registration and Updating .................................................................... 56

Card Detail Removal .............................................................................................................. 59

Card Details Search ............................................................................................................... 60

XML Payments Using a Stored Secure Card .......................................................................... 62

Stored Subscription Request ................................................................................................. 66

Stored Subscription Deletion Request .................................................................................. 69

Subscription Creation Request .............................................................................................. 71

XML Integration Guide v.2.6.3

Update Subscription Request................................................................................................ 74

Subscription Deletion Request .............................................................................................. 76

Subscription Payments Request ............................................................................................ 77

Subscription Notifications ..................................................................................................... 79

Appendix A: CVV & AVS Responses ............................................................................................................ 85

XML Integration Guide v.2.6.3

#2a added BANKRESPONSECODE and added new note

XML Integration Guide v.2.6.3

2 Choosing an Integration Method

2.2 Integration Methods to Consider

Hosted Payment Page

organizations to integrate their websites with our payment gateway.

XML Integration Guide v.2.6.3

XML Integration Guide v.2.6.3

Items for Consideration

2.4 A Word on Functionality

XML Integration Guide v.2.6.3

3 Secure Communication/Card Types Supported

3.2 Card Types

3.3 Multi-Currency Terminal IDs

XML Integration Guide v.2.6.3

3.4 Integration and Validation Procedure