AUTHORISATION AND

SETTLEMENT
TECHNICAL
SPECIFICATIONS
VERSION 1.4
OCTOBER 2017

The Authorisation And Settlement Technical Specifications contains information proprietary to

Global Payments. No part of this document may be reproduced, stored in a retrieval system or
transmitted, in any form or by any means, electronic, mechanical, photocopying, recording or
otherwise, without the permission of Global Payments. Information contained in this manual is
subject to change without notice.
Amendment History

Version Status Date Issued Comment Originator Reviewed By

Document retitled. Full

Senior
revision of text, format and Marketing
1.0 New March 2016 Technical
hyperlinks added to aid Operations
Consultant
navigation.
Addition of General Sub Senior
Marketing
1.1 Revised April 2016 Record 01 for POI Technical
Operations
Capabilities Consultant
Addition of MasterPass, In
App Payments, Senior
Marketing
1.2 Revised April 2017 tokenisation, and correction Technical
Operations
of errors from previous Consultant
version
Addition of additional
Senior
payment attributes values Marketing
1.3 Revised August 2017 Technical
for Visa Credential on File Operations
Consultant
Framework
Removal of incorrect ‘Note’
from tables on pages 16 to Senior
Marketing
1.4 Revised October 2017 19. Correction to length of Technical
Operations
payment network indicator Consultant
on table on page 35.
CONTENTS
SECTION PAGE
1. Introduction 1
2. Normative References 2
3. Abbreviations 2
3.1 Field Types 2
3.2 Table Headings 2
4. Glossary Of Terms 3
5. Settlement 4
5.1 File Structure 4
5.1.1 Record Types 4
5.1.2 Transaction Codes 5
5.1.3 File Integrity Checking 6
5.1.4 Testing 7
5.2 Header Label Formats 7
5.2.1 Volume Header Label Format (Vol 1) 7
5.2.2 First File Header Label Format (HDR 1) 8
5.2.3 Second File Header Label Format (HDR 2) 9
5.2.4 User Header Label Format (HDR 1) 9
5.3 Transactional Record Formats 10
5.3.1 Segment 1 10
5.3.2 Segment 2 Formats 12
5.3.2.1 Segment 2 – Type 20: Purchase With Cashback 12
5.3.2.2 Segment 2 – Type 50: Reference Number Or XML Layout 12
5.3.2.3 Segment 2 – Type 80: Dynamic Currency Conversion 13
5.3.3 Segment 4 – ICC Data Record 13
5.4 Sub-Record Formats 15
5.4.1 Sub-Record Format Type 01: General Sub Record 16
5.4.2 Sub-Record Format Type 02: Tokenisation Sub Record 17
5.4.3 Sub-Record Format Type 25: Reference Number/XML/VGIS 18
5.4.4 Sub-Record Format Type 26: Authorisation Network Reference Data 19
5.4.5 Sub-Record Format Type 27: Dynamic Currency Conversion (DCC) Data 20
5.4.6 Sub Record Format Type 30: MasterPass Online 21
5.4.7 Sub Record Format Type 31: Multiple Shipments 21
5.4.8 Sub-Record Format Type 39: Contactless Sub-Record 22
5.5 Net Summary Record 23
5.6 Net Claim Record 24
5.7 File Trailer Labels 25
5.7.1 First File Trailer Label: EOF 1 25
5.7.2 Second File Trailer Label: EOF 2 26
5.7.3 User Trailer Label: UTL1 27
SECTION PAGE
6. Authorisation 28
6.1 Authorisation Messages 28
6.1.1 Authorisation Request Message 28
6.1.2 Reversals 28
6.1.3 Partial Reversals 28
6.2 Condition Codes Used In Authorisation Messages (M/O/C) 29
6.3 Message Formats 29
6.3.1 Authorisation Request 29
6.3.2 Authorisation Response 31
6.4 Auxiliary Data Records 33
6.4.1 Auxiliary Data Records: Example Construction 33
6.5 Auxiliary Data Record Formats 34
6.5.1 Auxiliary Data Record Type 01: Ecommerce 34
6.5.2 Auxiliary Data Record Type 03: Dynamic Currency Conversion (DCC) 36
6.5.3 Auxiliary Data Record Type 06: Terminal Capabilities And Terminal Attributes 37
6.5.4 Auxiliary Data Record Type 09: Partial/Alternative Amount Approval 38
6.5.5 Auxiliary Data Record Type 10: Authorisation Network Reference Data 39
6.5.6 Auxiliary Data Record Type 12: Alternate Card Number 40
6.5.7 Auxillary Data Record Type 13: Scheme Digital Wallet 41
6.5.8 Auxiliary Data Record Type 15: Contactless Device Information Data 41
6.5.9 Auxiliary Data Record Type 18: Payment Attributes 42
6.5.10 Auxiliary Data Record Type 22: Tokenisation Response Data 43
6.5.11 Auxiliary Data Record Type 23: Payment Account Reference 44
6.6 Field Reference Tables 44
Table 1: Terminal Type/Capabilities 44
Table 2: Message Types 45
Table 3: Card Details 47
Table 4: Descriptive Data 48
Table 5: Reason Online Codes 48
Table 6: Authorisation Response Codes And Message Text 49
Table 7: Voice Referral Number 50
Table 8: Response Additional Data Codes 51
Table 9: Additional Transaction Security Data (ATSD) 52
Table 10: Terminal Attributes 53
Table 11: Point Of Interaction (POI) Capabilities 54
Table 12: Payment Attributes – For Use With General Sub Record Type 01 56
Table 13: Payment Attributes – For Use With Auxiliary Data Record Type 18 57
Table 14 – Supported Combinations Of Values For Ecommerce Transactions 58

Appendix 1: Currencies Supported 60

Appendix 2: Supplementary Guides 61
1. INTRODUCTION
This document details the settlement and authorisation message formats supported by Global Payments.

For settlement, all file formats are for a 640 byte variable file length. For backward compatibility, we also
support both 90 byte and 380 byte files but, these formats are outside the scope of this document and are not
permitted for new file submission certifications.

Both the authorisation and settlement formats contained within this document are derived from the UK Cards
Association Standard 70 and should be used to define the exact requirements for populating authorisation and
settlement messages into the Global Payments host systems. This document should be read in conjunction
with the UK Cards Association Standard 70, which can be obtained from them using the details below:

UK Payments Administration
2 Thomas Moore Square
London
E1W 1YN

Tel: 020 3217 8200

Fax: 020 7488 6959
Email: [email protected]

Message formats and fields contained within Standard 70 but not defined within this document should be
assumed as being unsupported by Global Payments.

Revised versions of this document will be issued when new functionality is released onto our host systems.

If you use a Payment Service Provider, bureau, or any other kind of third party to assist in the processing of
your card transactions, they will act, at all times, as your agent and you will be responsible for any acts or
omissions on their part. You must ensure that they comply, at all times, with the terms of our Card Processing
Agreement and ensure you promptly pass on to them all communications or information we provide to you that
will have an impact on the processing services they provide to you.

Furthermore, you agree to indemnify us against any losses, damages or liability that we may suffer as a result
of acting on your agent’s instructions or any other action or omission of theirs. Whilst we may provide details
of third party processors to you, you are responsible for making a selection appropriate to your requirements
and negotiating contractual terms directly with the third party in question. You remain fully responsible for
paying any fees charged by your agent and in no circumstances will we collect these for your agent or remit
them to your agent before making payment to you.

1
2. NORMATIVE REFRENCES
The following documents are referenced within this document and are indispensable for the application of this
document. For dated references, only the edition cited applies. For undated references, the latest version of
the referenced document (including any amendments) applies.

UK Cards Association Card acceptor to acquirer interface standards

Standard 70 www.ukpayments.org.
EMV Integrated circuit card specification for payment systems
www.emvco.com.
Global Payments For the purposes of this document, all references to Global
Payments, refers to GPUK LLP trading as Global Payments
ISO 3166 (all parts) Codes for representation of countries and their subdivisions.

ISO 4217 Codes for representation of currencies and funds.

PCI DSS Payment Card Industry Data Security Standards; maintained by PCI
SSC.
PCI SSC Payment Card Industry Security Standards Council
www.pcisecuritystandards.org.

3. ABBREVIATIONS

3.1 FIELD TYPES

Abbreviation Meaning

Alphanumeric: Alphanumeric fields are to be left justified and padded with spaces
A
unless specifically defined as otherwise in this specification.
Numeric: Numeric fields are to be right justified and padded with leading zeros
N
unless specifically defined as otherwise in this specification.
8 bit binary data converted into printable hexadecimal.
AB Note: All alpha characters must be upper case.

3.2 TABLE HEADINGS

Abbreviation Meaning

POS Position
Type The type of data to be submitted in the field (see 3.1 for full details)

Len Field Length

F/V Fixed or Variable

M/O/C Mandatory, Optional or Conditional

2
4. GLOSSARY OF TERMS
Acquirer The entity processing the card transaction (Global Payments)

Alternate Card Number A different card number to the one used for completion of the
transaction that relates to the same actual card account.

Card Acceptor The person accepting the card payments – for example the
merchant

Card Issuer The organisation issuing the card product

DCC Dynamic Currency Conversion

Form Factor A Contactless device can take on many forms, for example,
physical cards, NFC mobile phones, watches. The Form Factor is a
code that enables the Card Schemes to identify the type of
Contactless device that was used for a particular transaction.

Funding PAN The actual card number for applying debits/credits to, which may
have been replaced by a tokenised PAN during the transaction for
security.

IC Integrated Circuit

NUA Network User Address

ICC Integrated Chip Card

PAN Primary Account Number

POI Point Of Interaction

PWCB Purchase With Cashback

SRD Scheme Reference Data

Tokenised PAN A card number that has been replaced by a different number for the
undertaking of the transaction for security purposes. Tokens are
typically linked to merchants or payment channels and cannot be
used outside of these environments.

VGIS Visa Global Invoicing Service

3
5. SETTLEMENT

5.1 FILE STRUCTURE

Each file shall comprise of file header and trailer records encapsulating data records. The format of all these
records shall be as defined within this document.

Only record formats defined in this document may be included in a file.

Any additional records or variations to these records contained within the UK Cards Association Standard 70,
Book 3, are not supported by Global Payments and must not be included in a file.

The contents of the file shall show structural and, where appropriate, financial integrity to be deemed as a valid
file.

Variable Format File

Although Global Payments supports fixed length files for backwards compatibility, new functionality will not be
added to fixed length file formats and all new customers must submit variable length files.

A variable length file is described as:

• Variable length financial records to be delivered from the merchant (or their agent) to the acquirer.
• Variable length financial data records to be delivered within one single batch of transactions i.e. financial
records of different lengths can be presented in one file.
• Sub-records will be used to augment the financial data for example, Scheme Reference Data.
• Only segments and sub-records defined within this document are supported by Global Payments.
• 380 byte ‘K’ records are supported within a variable format file, 380 byte ‘J’ records are only supported
within the Fixed Format File.
• Net Summary and Net Claim records shall utilise the ‘E’ format (90 bytes in length).

5.1.1 RECORD TYPES

Non-Financial Data Records

Non-financial data records consist of a single segment of 30 or 90 bytes. As a file may not contain data records
of different lengths non-financial and financial data can only be sent together when financial data records are
only 90 bytes long. Where financial data records are longer than 90 bytes, non-financial data records shall be
sent in a separate file.

The purpose of non-financial data records is indicated in the Transaction Code data element.

Financial Data Records

Financial Data Records are built up of between one and four segments, as follows:
• Segment 1 shall always be present.
• Segment 2 will always be present. If there is no appropriate Segment 2 for the transaction type (i.e. the
transaction is not PWCB, DCC or VGIS), Segment 2 Type 50 shall be used to facilitate the transmission
of sub-records.
• Segment 3 is not supported by Global Payments.
• Segment 4 may or may not be present.
• Segment 4 must always be present for all chip transactions.
• Segments are presented in the order 1 – 2 – 4 on a single record.

The combination of segments required determines the length of the record and, on a Variable Length File, the
presence of sub-records. The following table shows the combinations of segments and sub-records allowed
for a Variable Length File and, for each file format, the transaction code and record length (note record lengths
do not include any associated sub-records).

4
5.1.2 TRANSACTION CODES

The following table shows the permitted values for Digit 1 of the Transaction Code and which segments
should be present:

Transaction Record Segments Sub-Records

Code Digit 1 Length Required Required
1 2 4
E 90 X
L 173 X X X
N 346 X X
R 429 X X X X

Note: A Transaction Code Digit 1 of E shall only be used in Summary Records and Claim Records. All
Transaction Records shall use a Transaction Code Digit 1 value of either L or R depending on the
card data capture method of the transaction (i.e. R for all IC read transactions and L for all swiped or
key entered transactions) – see individual record layouts for full details.

The following table shows the permitted values for Digit 2 of the Transaction Code:

Transaction
Description
Code Digit 2
1 Sale
2 Refund
3 Cash Advance
D Instalment Transaction

Within a single file, transactions should be batched in the following way:

VOL1 Volume Header Record

HDR1 Header 1
HDR2 Header 2
UHL1 User Header Label
n1 Sale
n2 Refund
E4/5/6 Summary Record
E7/8 Claim Record
n3* Cash Advance*
E6* Summary Record*
E8* Claim Record*
n2 Refund
n1 Sale
E4/5/6 Summary Record
E7/8 Claim Record
EOF1 End Of File 1
EOF2 End Of File 2
UTL1 User Trailer Label

*Cash Advances: A batch containing Cash Advance transactions must not contain any Sales or Refunds.

Note: The Cash Advance transaction type is only to be used by Financial Institutions and therefore, prior
written approval from Global Payments is required before submitting this transaction type.

5
File Submission Rules
• Although 90 byte file structures are supported for existing customers, new customers must submit files in
640 byte variable format.
• Empty files or zero value files must not be submitted (for example, files containing headers and trailers
but, no transactions).
• E4 records – All fields should be set to zero except for the Record Count, which should be set to ‘1’.
• E8 records – All fields should be set to zero except for the Debit Item Count, which should be set to ‘1’
and, the Record Count which should be set to ‘2’.
• UTL records – All fields should be set to zero except for the Debit Item Count, which should be set to ‘1’
and the Record Count which should be set to ‘2’.
• Files must be written in ASCII – The United Kingdom 7-bit data code.
• Settlement files must be batched by merchant outlet.
• Each transaction must have the 8 digit Global Payments Merchant Number.
• There is no batch limit (number of batches or number of transactions) for an incoming file to Global
Payments, except for merchants submitting VGIS Data.

For merchants submitting VGIS Data, the following limits apply:

• 99,999 transactions per batch.
• 9,999 batches per file.
• 999 VGIS Line Items per invoice (There is a limit of 2320 XML records per invoice).

5.1.3 FILE INTEGRITY CHECKING

There are two levels of integrity checking when you submit a file into us:
• A check for financial integrity.
• A check for logical integrity.

If either of these integrity checks fails, the entire file will be invalidated and rejected.

Financial Integrity Checking

Financial integrity is achieved by a hierarchical structure.

Transaction Records from a single source are netted by both number and value onto a single summary record
using either transaction code E4, E5 or E6:
• E4 is used when sales equal or exceed refunds.
• E5 is used when refunds exceed sales.
• E6 is used for cash advances, which shall not be intermixed with other transaction types that will always
appear in a different summary (E4 or E5).

Summary Records from one or more sources are then netted in both number and value into a single Claim
Record using either transaction code E7 or E8:
• E7 is used when refund summaries (E5) exceed sales summaries (E4) and cash advance summaries
(E6).
• E8 is used when sales summaries (E4) and cash advance summaries (E6) equal or exceed refund
summaries (E5).

Claim Records are netted together both in number and value into the audit fields of User Trailer Label.

All Transaction Records must be included in a Summary Record, all Summary Records must be included in a
Claim Record and all Claim Records must be included in the User Trailer Record.

If any of the levels of totalling do not reconcile, there is an integrity failure and the whole file will be invalidated.

6
Logical Integrity Checking
Logical Integrity is achieved by the numbering of the records within the file starting at 0000001 and
incrementing in single units with each subsequent record.

The audit fields on the User Trailer Label must contain the total record count, which must be equal to the
highest sequence number used.

Any break in the numbering sequence or, failure to record the correct number of records on the file shall cause
an integrity failure and the whole file will be invalidated.

5.1.4 TESTING

We strongly recommended that when making any changes to the format or content of your settlement file you
submit a test file to us to ensure errors have not been introduced into the file, which in turn could cause your
file to reject.

Testing can be arranged by contacting your Relationship Manager or, if you do not have a Relationship
Manager, by emailing Jane Sellwood at: [email protected].

5.2 HEADER LABEL FORMATS

5.2.1 VOLUME HEADER LABEL FORMAT (VOL1)

Num Name POS Type Len Value

1 Label Identifier 0 A 3 VOL

2 Label Number +3 A 1 1

3 Volume Serial Number +4 A 6 Zero Fill

4 Volume Accessibility +10 A 1 Space Fill

5 Reserved +11 A 26 Space Fill

Global Payments Merchant Number,
6.1 Merchant Number +37 A 10
right justified with leading zeros
6.2 File Currency Indicator +47 A 1 ‘0’

6.3 Reserved For future Use +48 A 3 Space Fill

7 Reserved For Future Use +51 A 28 Space Fill

8 Label Standards Version +79 A 1 ‘3’

7
5.2.2 FIRST FILE HEADER LABEL FORMAT (HDR1)

Num Name POS Type Len Value

1 Label Identifier 0 A 3 ‘HDR’

2 Label Number +3 A 1 ‘1’

3.1 Source ID or Originator +4 A 10 As advised by Global Payments

3.2 Record Type Identifier +14 A 1 ‘Z’

Version Number Of
3.3 +15 A 2 Space Fill
Standard
3.4 File Currency Indicator +17 A 1 ‘0’

3.5 Reserved For Future Use +18 A 3 Space Fill

4 File Set Identification +21 A 6 Zero Fill

5 File Section Number +27 A 4 ‘0001’

6 File Sequence Number +31 A 4 ‘0001’

7 Generation Number +35 A 4 ‘0001’

Generation Version
8 +39 A 2 ‘00’
Number
bYYDDD: Where b is blank, YY is the
last 2 digits of the year and DDD (001 –
9 Creation Date +41 A 6 366) is the day in the year. This field
must be equal to the processing date of
the User Header Label (UHL) Record
bYYDDD: Calculated as 14 calendar
days greater than the creation date.
10 Expiration Date +47 A 6 Where b is blank, YY is the last 2 digits
of the year and DDD (001 – 366) is the
day in the year
11 File Accessibility +53 A 1 Space Fill

12 Block Count +54 N 6 Zero Fill

13 System code +60 A 13 Space Fill If Not Used

14 Reserved +73 A 7 Space Fill

8
5.2.3 SECOND FILE HEADER LABEL FORMAT (HDR2)

Num Name POS Type Len Value

1 Label Identifier 0 A 3 ‘HDR’

2 Label Number +3 A 1 ‘2’

3 Record Format +4 A 1 ‘D’

4 Block Length +5 N 5 ‘00640’

5 Record Length +10 N 5 ‘00640’

6 Reserved +15 A 35 Space Fill

7 Offset Length +50 N 2 Zero Fill

8 Reserved +52 A 28 Space Fill

5.2.4 USER HEADER LABEL FORMAT (HDR1)

Num Name POS Type Len Value

1 Label Identifier 0 A 3 ‘UHL’

2 Label Number +3 A 1 ‘1’

bYYDDD: Where b is blank, YY is the
3 Processing Date +4 A 6 last 2 digits of the year and DDD (001 –
366) is the day in the year
Identifying Number Of
4.1 +10 A 4 Zero Fill
Receiving Party
4.2 Destination Code +14 A 4 ‘3457’

4.3 Reserved +18 A 2 Zero Fill

Spaces or ISO 4217 alpha currency
5 Currency Code +20 A 3 code (see Appendix 1 for a full list of
supported currencies)
6 File Currency Indicator +23 N 1 Zero Fill

7 Reserved +24 N 4 Zero Fill

8 Work Code +28 A 9 Space Fill

Starts at 001 and incremented by 1 for
9 File Generation Number +37 N 3 every file sent up to a total of 999 when
it restarts from 001
10 Reserved +40 A 14 Space Fill

11 Reserved +54 A 26 Space Fill

9
5.3 TRANSACTIONAL RECORD FORMATS

5.3.1 SEGMENT 1

Num Name POS Type Len Value

The Cardholder PAN, right justified and

1 Cardholder Number 0 N 19
padded with leading zeros
n0 = Unique Sale Transaction
n1 = Sale
n2 = Refund
2 Transaction Code +19 A 2 n3 = Cash Advance
nD = Instalment Transaction
Where n is the Record Type as defined
on page 5 Transaction Codes
As provided by Global Payments. Right
3 Source Number +21 N 11
justified and padded with leading zeros
4 Card Expiration Date +32 N 4 MMYY
Unsigned amount of the transaction in
5 Amount +36 N 11
the currency minor denomination
bYYDDD – Where b is blank, YY is the
last 2 digits of the year and DDD (001 –
366) is the day in the year. This must be
6.1 Transaction Date +47 A 6
the same date as appears on the
terminal receipt of other notification
given to the cardholder
The 24hr transaction time in the format
6.2 Transaction Time +53 N 6 HHMMSS. If not used, must be zero
filled
0 = Transaction authorised locally by
terminal, no authorisation code
generated
1 = Real time authorisation by acquirer
2 = Voice authorised by acquirer
3 = Voice authorisation on call failure
6.3.1 Authorisation Method +59 N 1 4 = Local authorisation on call failure
6 = Local authorisation on call failure,
real time authorisation was
attempted
7 = Transaction authorised locally by
terminal, authorisation code was
generated
6.3.2 Reserved For Future Use +60 A 1 Space Fill
Authorisation code, right justified and
6.3.3 Authorisation Code +61 A 6 padded with leading spaces. Space fill if
not used
Reference number allocated by the card
Originators Transaction acceptor to enable details of the
6.4 +67 A 12
Reference transaction to be recovered in the event
of a dispute
6.5 Reserved For Future Use +79 A 1 Space Fill
Terminal Type/Currency 0 = Unspecified Terminal Capabilities
6.6 +80 A 1
Indicator 1 = ICC Reader Only

10
Num Name POS Type Len Value

2 = Magnetic Stripe Reader Only

3 = ICC and Magnetic Stripe
4 = No Card Reader
If the Currency Code is indicated
elsewhere on the file (for example, the
E4 or E5 Summary Records) these
values will refer to the declared
currency, otherwise these values refer
to sterling
6.7 Reserved For Future Use +81 A 1 Space Fill
0 = Signed voucher
1 = Mail/Telephone Order
2 = Continuous Authority
3 = PIN verified online
4 = Signed voucher – ICC read
5 = Signed voucher – Mag stripe read
6 = Signed voucher – Keyed at POS
7 = Unattended device without PIN
verification
8 = PIN verified (card) transaction
recovered after sale
9 = Signed voucher recovered after sale
A = Unattended device with PIN verified
locally
D = Downgraded ICC (track 2 only)
transaction
F = ICC fallback to mag stripe read
Customer Instruction
6.8 +82 A 1 G = Ecommerce – Secure transaction
Value
with cardholder certificate
H = Ecommerce – Non authenticated
transaction with card acceptor
certificate
J = Ecommerce – Non authenticated
transaction without card acceptor
certificate using channel encryption
(for example, TLS)
L = Ecommerce – Non authenticated
transaction with card acceptor
certificate using channel encryption
(for example, TLS)
M = ICC Contactless – Proximity
transaction with full EMV data
N = MSR Contactless – Proximity
transaction with only track 2 mag
stripe (or equivalent data) available
Sequence Number of this record within
7 Sequence Number +83 N 7
the file

11
5.3.2 SEGMENT 2 FORMATS

5.3.2.1 SEGMENT 2 – TYPE 20: PURCHASE WITH CASHBACK

Num Name POS Type Len Value

0 = By Terminal
1 = Online To Acquirer
8 Method Of Authorisation +90 N 1
2 = Voice To Acquirer
5 = Method Of Authorisation Not Known
9 Type Of Transaction +91 N 1 1 = Purchase With Cashback
Cashback amount in the minor
10 Cash Amount +92 N 6 denomination of the transaction
currency.
11 Filler +98 A 69 Space Fill
Total number of sub-records within the
12 Sub-Record Count +167 N 4
transaction (minimum = 0001)
13 Format Type +171 N 2 ‘20’

5.3.2.2 SEGMENT 2 – TYPE 50: REFERENCE NUMBER OR XML LAYOUT

Num Name POS Type Len Value

The name of the establishment (see

8 Establishment Name +90 A 26
Note 2)
The address of the establishment (see
9 Establishment Address +116 A 26
Note 2)
A unique reference number assigned by
the merchant to this transaction. This
number must be unique throughout the
file. The reference number used in
Segment 2 must match the Card
10 Reference Number +142 A 25
Acceptor Reference Number in the
associated Format 25 Sub-Record, but
must be unique for each complete
transaction set (i.e. segment 2 and sub-
record format 25) (see Note 2)
Total number of sub-records within the
11 Sub-Record Count +167 N 4
transaction (minimum = 0001)
12 Format Type +171 N 2 ‘50’

Note 1: Segment 2 Type 50 must be used for transactions that do not naturally have a segment 2 (i.e.
transactions other than PWCB, Reference Number/XML/VGIS and DCC) as a segment 2 must
be present to allow the addition of sub-records.

Note 2: Where Segment 2 Type 50 is used purely to allow for the inclusion of sub-records (i.e. transactions
other than PWCB, Reference Number/XML/VGIS and DCC), fields 8, 9 and 10 should be space
filled.

12
5.3.2.3 SEGMENT 2 – Type 80: Dynamic Currency Conversion (DCC)

Num Name POS Type Len Value

8 Sub-Record Flag +90 A 1 ‘D’

9 Reserved For Future Use +91 A 51 Space fill

A unique reference number assigned by
Card Accepter Reference the processor to this transaction. This
10 +142 A 25
Number number must be unique throughout the
file
Total number of sub-records within the
12 Sub-Record Count +167 N 4
transaction (minimum = 0001)
13 Format Type +171 N 2 ‘80’

5.3.3 SEGMENT 4 – ICC DATA RECORD

Note: The column POS 1 gives the positions for data in Segment 4 when Segment 2 is not present.
POS 2 column gives the positions for the data in Segment 4 when Segment 2 is present.

EMV
Num Name POS 1 POS 2 Type Len Value
Tag
Application PAN Populate with the value of Tag
1 Sequence 0 +173 A 2 5F32 from the card. If Tag 9F34 5F34
Number is not present, zero fill
The response code sent back by
the acquirer in the authorisation
response or the code generated
locally by the terminal for
transactions completed locally,
when real time authorisation
could not be achieved. For
locally generated ARCs the
Authorisation following values shall be used:
2 Response Code +2 +175 A 2 Y1 = Offline Approved 8A
(ARC) Z1 = Offline Declined
Y2 = Approval after card
initiated referral
Z2 = Decline after card initiated
referral
Y3 = Unable to go online, offline
approved
Z3 = Unable to go online, offline
declined
Cryptogram The authorised amount of the
3 Transaction +4 +177 N 11 transaction excluding 9F02
Amount adjustments
Cryptogram
4 +15 +188 N 2 Cryptogram transaction type 9C
Transaction Type
The date supplied to the card
Terminal
5 +17 +190 N 6 during the creation of the 9A
Transaction Date
cryptogram in YYMMDD format

13
 EMV
Num Name POS 1 POS 2 Type Len Value
Tag
The ISO 4217 numeric currency
Transaction code of the transaction (see
6 +23 +196 N 3 5F2A
Currency Appendix 1 for a full list of
currencies supported)
826 (the ISO 3166 numeric
Terminal Country
7 +26 +199 N 3 country code for the United 9F1A
Code
Kingdom)
The transaction cryptogram
Transaction being submitted to settle the
8 +29 +202 AB 16 9F26
Cryptogram transaction. This may be a TC,
an ARQC or an AAC
Application The Application Interchange
9 Interchange +45 +218 AB 4 Profile taken from Tag 82 of the 82
Profile card
Application The Application Transaction
10 Transaction +49 +222 AB 4 Counter taken from Tag 9F36 of 9F36
Counter the card
The Unpredictable Number
Unpredictable generated by the terminal to
11 +53 +226 AB 8 9F37
Number ensure the generation of a
unique application cryptogram
Terminal The Terminal Verification
12 Verification +61 +234 AB 10 Results generated by the 95
Results terminal for the transaction
Undefined data sent by the card
issuer to enable authentication
of the card. The data returned
Issuer Application by the issuer may be shorter
13 +71 +244 AB 64 9F10
Data than the total 32 bytes that is
allowed, in which case, it should
be right justified and padded
with leading FF (Hex)
The Application Usage Control
Application Usage
14 +135 +308 AB 4 taken from Tag 9F07 on the 9F07
control
card.
00 = AAC
Cryptogram
15 +139 +312 AB 2 40 = TC 9F27
Information Data
80 = ARQC
Cardholder The results of cardholder
16 Verification +141 +314 AB 6 verification as sent from the 9F34
Method Results terminal in Tag 9F34
The Application Identifier from
card, the application provider
Application and the business function or the
17 +147 +320 AB 32 4F
Identifier DF name if it is longer. Right
justified and padded with leading
FF (Hex)
Application The version of the card
18 +179 +352 AB 4 9F08
Version Number application from Tag 9F08
The transaction status
Transaction
19 +183 +356 AB 4 information generated by the 9B
Status Information
terminal in Tag 9B
22 = Attended Terminal
20 Terminal Type +187 +360 AB 2 9F35
25 = Unattended Terminal

14
 EMV
Num Name POS 1 POS 2 Type Len Value
Tag
The Terminal Capabilities
Terminal
21 +189 +362 AB 6 defined in the terminal using 9F33
Capabilities
EMV tag 9F33
A two digit code identifying how
a transaction was completed
and, what cardholder verification
was used;
Digit 1: Card Transaction
Information;
1 = Swiped
2 = Keyed
3 = ICC
4 = Recovered data, keyed
5 = Recovered data, electronic
6 = Reserved for future use
7 = Downgraded ICC
transaction
22 POS Entry Mode +195 +368 A 2 8 = Swipe, ICC fallback
9 = Proximity
Digit 2: Cardholder
Verification, if any;
1 = Customer present, signature
2 = Customer present, PIN
3 = Reserved for future use
4 = Customer present, UPT, no
CVM
5 = Customer Present, UPT,
PIN
6 = reserved for future use
7 = Customer not present
8 = No cardholder verification
9 = Reserved for future use
23 Filler +197 +370 A 59 Space Filled

5.4 SUB-RECORD FORMATS

Sub-records provide a means of sending additional data for a transaction, some of which may be required for
settlement (for example, Scheme Reference Data), whilst some is required for other purposes such as MI
production (for example, DCC).

• In order to submit sub-records, the file must contain a segment 2 record regardless of whether, or not,
there is an appropriate sub-record for the transaction type (for example, PWCB and DCC).
• Where there is no matching segment 2 for a transaction type (i.e. for a straight forward sale transaction)
Segment 2 Type 50 (Reference Number or XML Layout) should be used.
• When using Segment 2 Type 50 for a non XML/Reference transaction, all fields should be space filled
except the sub-record counter and, the Format Type.
• Sub-Record Type 01 is mandatory for mPoS devices and optional for all other devices unless, data in the
POI Capabilities or Payment Attributes fields are being used.
• Sub-Record Type 26 is mandatory for all online transactions as this carries the Scheme Reference Data
that is used to link the settlement record to the corresponding authorisation record.
• Sub-records must be sent in ascending transaction code order and failure to do so will result in the file
being rejected.

15
• The Transaction Code in Segment 1 must reflect the requirement for Segment 2 and Sub-records to be
included. For example:
• An offline IC transaction would have a Transaction Code of ‘N’ and would contain only Segment 1
and Segment 4.
• An online IC transaction would have a Transaction Code of ‘R’ and would contain Segment 1,
Segment 2, Segment 4 and at least 1 sub-record (Sub-Record Type 26, Scheme Reference Data is
mandatory for an online transaction).

5.4.1 SUB-RECORD FORMAT TYPE 01: GENERAL SUB RECORD

Num Name POS Type Len Value

The sequence of the sub-record in

relation to all sub-records submitted for
1 Sub-Record Counter 0 N 4 this transaction starting at ‘0001’ and up
to the value sent in the ‘Sub-Record
Count’ field sent in Segment 2
2 Reserved For Future Use +4 A 15 Space Filled

3 Transaction Code +19 N 2 ‘01’

4 Reserved For Future Use +21 A 4 Space Filled

5 POI Capabilities +25 A 24 See Table 11

6 Payment Attributes +49 A 24 See Table 12

7 Reserved for future use +73 A 10 Space Filled

Record Sequence The sequence number of this record
8 +83 N 7
Number within the file.
90 Byte Record.

16
5.4.2 SUB-RECORD FORMAT TYPE 02: TOKENISATION SUB-RECORD

Num Name POS Type Len Value

The sequence of the sub-record in

relation to all sub-records submitted for
1 Sub-Record Counter 0 N 4 this transaction starting at ‘0001’ and up
to the value sent in the ‘Sub-Record
Count’ field sent in Segment 2
2 Reserved For Future Use +4 A 15 Space Filled

3 Transaction Code +19 N 2 ‘02’

4 Token Assurance Level +21 N 2

5 Token Requester ID +23 N 11

6 Reserved For Future Use +34 A 49 Space Filled

Record Sequence The sequence number of this record
7 +83 N 7
Number within the file.
90 Byte Record

17
5.4.3 SUB-RECORD FORMAT TYPE 25: REFERENCE NUMBER/XML/VGIS

Num Name POS Type Len Value

The sequence of the sub-record in

relation to all sub-records submitted for
1 Sub-Record Counter 0 N 4 this transaction starting at ‘0001’ and up
to the value sent in the ‘Sub-Record
Count’ sent in Segment 2
2 Reserved For Future Use +4 A 15 Space Filled

3 Transaction Code +19 N 2 ‘25’

4 Sub-Record Length +21 N 3 Minimum 90 bytes, maximum 636 bytes

Unique Reference Number assigned by
the merchant for this transaction.
Card Acceptor Reference Note: This reference number must
5 +24 A 25
Number match the one sent in field 10 of
the associated Segment 2
record.
6 Reserved for future use +49 A 34 Space Filled
Record Sequence The sequence number of this record
7 +83 N 7
Number within the file.
0–
8 XML Data +90 A Variable length XML data
546
This is a flexible length Sub-record with a valid length of 90 to 636 bytes depending on the amount of XML
data sent.

18
5.4.4 SUB-RECORD FORMAT TYPE 26: AUTHORISATION NETWORK REFERENCE DATA

Num Name POS Type Len Value

The sequence of the sub-record in

relation to all sub-records submitted for
1 Sub-Record Counter 0 N 4 this transaction starting at ‘0001’ and
up to the value sent in the ‘Sub-Record
Count’ sent in Segment 2
2 Reserved For Future Use +4 A 12 Space Filled
Authorisation Reference
3 +16 N 3 ‘002’ = Scheme Reference Data
Type
4 Transaction Code +19 N 2 ‘26’
Authorisation Network The date of the transaction
5 +21 N 6
Reference Date authorisation in YYMMDD format
Unique reference number returned by
the authorisation network in the
authorisation response message. Data
must be left justified and padded with
trailing spaces.
Mastercard/American Express Trace
ID Format
Authorisation Network
6 +27 A 56 15 Characters, data should be sent as;
Data
+27 Trace ID
Visa Transaction ID
15 Character Transaction ID plus a 4
character validation code, data should
be sent as;
+27 Transaction ID
+42 Validation Code
Record Sequence The sequence number of this record
7 +83 N 7
Number within the file.
90 Byte Record

Note: Submission of Scheme Reference Data is mandatory for all transactions that were authorised online.
Global Payments will not accept responsibility for any Card Scheme fees or charges resulting from
Scheme Reference Data not being submitted with the settlement data for any transactions that
received Scheme Reference Data back as part of the authorisation process.

19
5.4.5 SUB-RECORD FORMAT TYPE 27: DYNAMIC CURRENCY CONVERSION (DCC) DATA

Num Name POS Type Len Value

The sequence of the sub-record in

relation to all sub-records submitted for
1 Sub-Record Counter 0 N 4 this transaction starting at ‘0001’ and up
to the value sent in the ‘Sub-Record
Count’ field sent in Segment 2
2 Reserved For Future Use +4 A 15 Space Filled

3 Transaction Code +19 N 2 ‘27’

Transaction value prior to conversion in
DCC Card Acceptor
4 +21 N 11 the lowest denomination of the Card
Currency Amount
Acceptor currency
The ISO 4217 numeric currency code of
DCC Card Acceptor
5 +32 N 3 the transaction prior to conversion –
Currency Code
normally set to 826 for United Kingdom
Commission Fee on the DCC
6 DCC Commission Fee +35 N 11 transaction in the lowest denomination
of the currency after conversion
Conversion Rate used in the DCC
DCC Conversion Rate transaction, as printed on the DCC
7 +46 N 11
Applied receipt minus the decimal point (see
Note 1)
The mark up percentage applied to the
8 DCC Mark Up Fee +57 N 11
DCC transaction to 2 decimal places
9 Reserved +68 A 15 Space Filled
Record Sequence Sequence number of this record within
10 +83 N 7
Number the file
90 Byte Record

Note 1: The format of the DCC conversion rate applied shall be as follow: xnnnnnnnnnn, where x is the number
of decimal places to be used. For example, 60001234567 indicates an exchange rate of 1.234567.

20
5.4.6 SUB-RECORD FORMAT TYPE 30: MASTERPASS ONLINE

Num Name POS Type Len Value

The sequence of the sub-record in

relation to all sub-records submitted for
1 Sub-Record Counter 0 N 4 this transaction starting at ‘0001’ and up
to the value sent in the ‘Sub-Record
Count’ field sent in Segment 2
2 Reserved For Future Use +4 A 15 Space Filled

3 Transaction Code +19 N 2 ‘30’

4 Wallet Transaction Origin +21 N 3

5 Reserved +24 A 59 Space Filled

Record Sequence Sequence number of this record within
6 +83 N 7
Number the file
90 Byte Record

5.4.7 SUB-RECORD FORMAT TYPE 31: MULTIPLE SHIPMENTS

Num Name POS Type Len Value

The sequence of the sub-record in

relation to all sub-records submitted for
1 Sub-Record Counter 0 N 4 this transaction starting at ‘0001’ and up
to the value sent in the ‘Sub-Record
Count’ field sent in Segment 2
2 Reserved For Future Use +4 A 15 Space Filled

3 Transaction Code +19 N 2 ‘31’

Settlement Instance
4 +21 N 2
Number
5 Total Settlement Count +23 N 2

6 Reserved +25 A 58 Space Filled

Record Sequence Sequence number of this record within
7 +83 N 7
Number the file
90 Byte Record

21
5.4.8 SUB-RECORD FORMAT TYPE 39: CONTACTLESS SUB-RECORD

Num Name POS Type Len Value

The sequence of the sub-record in

relation to all sub-records submitted for
1 Sub-Record Counter 0 N 4 this transaction starting at ‘0001’ and up
to the value sent in the ‘Sub-Record
Count’ sent in Segment 2
2 Reserved For Future Use +4 A 15 Space Filled

3 Transaction Code +19 N 2 ‘39’

4 Reserved For Future Use +21 A 62 Space Filled

Record Sequence Sequence number of this record within
5 +83 N 7
Number the file
6 Contactless Form Factor +90 AB 70
Contactless Discretionary
7 +160 AB 70
Data
8 Reserved For Future Use +230 A 70 Space Filled

300 Byte Record

Contactless Form Factor

The contents of this data element will vary by Card Scheme; for Mastercard and Visa it is Tag 9F6E, for
American Express it is Tag 9F67.The definition of these data elements can be found in the appropriate Card
Scheme’s Contactless specifications.

The card acceptor will provide the whole data element in BER-TLV format as described in EMV as the Tag will
vary from Card Scheme to Card Scheme. When the data is converted to hexadecimal, the value of the length
component shall still represent the length of the binary data.

For example TTTTLLdddddd would be interpreted as:

• TTTT is the EMV Tag
• LL is the length of the data
• dddddd is the Contactless Form Factor – with the length as defined by LL

Data should be left justified and space filled.

Contactless Discretionary Data

The contents of this data will vary by Card Scheme and will be as agreed by interchange parties. For Visa the
discretionary data will be the content of Tag 9F7C. The definitions for these data elements can be found in the
appropriate Card Scheme’s Contactless specifications.

The card acceptor will provide the whole data element in BER-TLV format as described in EMV as the Tag will
vary from Card Scheme to Card Scheme. When the data is converted to hexadecimal, the value of the length
component shall still represent the length of the binary data.

22
5.5 NET SUMMARY RECORD

Num Name POS Type Len Value

1 Reserved For Future Use 0 N 19 Zero Filled

2 Transaction Code +19 A 2 E4, E5 or E6 as required

As advised by Global Payments, right
3 Source Number +21 N 11
justified and padded with leading zeros
The ISO 4217 Numeric Currency Code if
applicable (please see Appendix 1 for
list of available currencies).

If a valid ISO 42717 Numeric Currency

Code is provided in this field, all
transactions in the batch will be
processed in the currency defined on
Net Summary Currency the summary record.
4.1 +32 A 3
Code
Zero fill if currency is as defined within
transactions.

Note: Currency processing is not

available to all customers,
please contact Global Payments
before submitting currency
transactions
4.2 Reserved For Future Use +35 A 1 Space Filled
Net amount of fields 6.1 and 6.2 in the
lowest denomination (unsigned) of the
5 Net Amount +36 N 11
currency being used (or, the currency
specified in field 4.1)
6 Totals
Value of all preceding debit items since
6.1 Value Of Debit Items +47 N 11 the last net summary record or net claim
record
Value of all preceding credit items since
6.2 Value of Credit Items +58 N 11 the last net summary record or net claim
record
Count of all preceding debit items since
6.3 Count Of Debit Items +69 N 7 last net summary record or net claim
record
Count of all preceding credit items since
6.4 Count Of Credit Items +76 N 7 last net summary record or net claim
record
Record Sequence Sequence number of this record within
7 +83 N 7
Number the file

23
5.6 NET CLAIM RECORD

Num Name POS Type Len Value

1 Reserved For Future Use 0 A 19 Zero Filled

E7 – Payment by merchant (refunds
exceeds sales – total of E5 records
greater than total of E4 records plus E6
records)
2 Transaction Code +19 A 2
E8 – Claim by merchant (sales exceeds
refunds- total of E4 records plus E6
records is greater than or equal to the
number of E5 records)
3 Reserved For Future Use +21 N 11 Zero Fill
Zero Fill for GBP

The ISO 4217 numeric Currency Code if

applicable (please see Appendix 1 for
list of available currencies).

If a valid ISO Currency Code is provided

in this field, all transactions in the batch
4.1 Net Claim Currency Code +32 A 3
will be processed in the currency
defined on the summary/claim record.

Note: Currency processing is not

available to all customers,
please contact Global Payments
before submitting currency
transactions
4.2 Reserved For Future Use +35 A 1 Space Filled
Net value of the claim in the lowest
denomination (unsigned) of the currency
5 Net Claim Amount +36 N 11
being used or, of the currency specified
in 4.1
6 Totals
Value of all debit summary items (E4
records and/or E6 records) since the last
Net Claim Record in the lowest
6.1 Value Of Debit Items +47 N 11
denomination (unsigned) of the currency
being used or, of the currency specified
in 4.1
Value of all credit summary items (E5
records) since the last Net Claim Record
6.2 Value Of Credit Items +58 N 11 in the lowest denomination (unsigned) of
the currency being used or, of the
currency specified in 4.1
Count of all debit summary items (E4
6.3 Count Of Debit Items +69 N 7
records) since last net claim record
Count of all credit items (E5 records)
6.4 Count Of Credit Items +79 N 7
since last net claim record

24
 Num Name POS Type Len Value

Record Sequence Sequence number of this record within

7 +83 N 7
Number the file.

5.7 FILE TRAILER LABELS

5.7.1 FIRST FILE TRAILER LABEL: EOF 1

Num Name POS Type Len Value

1 Label Identifier 0 A 3 ‘EOF’

2 Label Number +3 A 1 ‘1’

Global Payments Merchant Number,
right justified and padded with leading
Source Identifier Or zeros.
3.1 +4 A 10
Originator Note: The value of this field must
match the value of the Merchant
Number field in the VOL1 record
3.2 Record Type Identifier +14 A 1 ‘Z’

3.3 Reserved For Future Use +15 A 2 Space Filled

3.4 File Currency Indicator +17 A 1 ‘0’

3.5 Reserved For Future Use +18 A 3 Space Filled

4 File Set Identification +21 A 6 Zero Filled

5 File Section Number +27 A 4 ‘0001’

6 File Sequence Number +31 A 4 ‘0001’

7 Generation Number +35 A 4 ‘0001’

Generation Version
8 +39 A 2 ‘00’
Number
Date that the file was produced in the
format bYYDDD where b is blank, YY is
the last 2 digits of the year and DDD
(001 – 366) is the number of the day
9 Creation Date +41 N 6
within the year.
Note: This field must be equal to the
Processing Date in the UHL
Label record.
Earliest date at which the file may be
overwritten in the format bYYDDD
U10 Expiration Date +47 N 6
calculated as 14 days from the Creation
Date
11 Accessibility +53 A 1 Space Fill

12 Block Count +54 N 6 Zero Filled

25
 Num Name POS Type Len Value

13 System Code +60 A 13 Space Filled

14 Reserved For Future Use +73 N 7 Space Filled

5.7.2 SECOND FILE TRAILER LABEL: EOF 2

Num Name POS Type Len Value

1 Label Identifier 0 A 3 ‘EOF’

2 Label Number +3 A 1 ‘2’

3 Record Format +4 A 1 ‘D’

4 Block Length +5 N 5 ‘02048’

5 Record Length +10 N 5 ‘00640’

6 Reserved For Future Use +15 A 35 Space Filled

7 Offset Length 50 N 2 Zero Filled

8 Reserved For Future Use +52 A 28 Space Filled

26
5.7.3 USER TRAILER LABEL: UTL1

Num Name POS Type Len Value

1 Label Identifier 0 A 3 ‘UTL’

2 Label Number +3 A 1 ‘1’

Monetary total of all debit Net Claim

Records (E8 records) since the
3.1 Value Of Debit Items +4 N 13
preceding HDR Label Group. This is a
hash total

Monetary total of all credit Net Claim

Records (E7 records) since the
3.2 Value of Credit Items +17 N 13
preceding HDR Label Group. This is a
hash total

Count of all debit Net Claim Records

3.3 Count Of Debits +30 N 7 (E8 records) since the preceding HDR
Label Group

Count of all credit Net Claim Records

(E7 records) since the preceding HDR
3.4 Count Of Credits +37 N 7
Label Group Count of all debit (net
claim

Total number of records since

3.5 Record Count +44 N 10
preceding HDR Label Group

3.6 Filler +54 A 26 Space Filled

27
6. AUTHORISATION

6.1 AUTHORISATION MESSAGES

The information in this section is valid for all transactions sent to the Global Payments authorisation host
individually.

6.1.1 AUTHORISATION REQUEST MESSAGE

An authorisation request message is a standard message sent to Global Payments by a merchant when a
transaction amount is above the merchant’s floor limit or, the transaction has been forced online either by a
velocity check being exceeded in the merchant’s POI (Point of Interaction) terminal or, on a cardholder’s IC
(Integrated Chip) card.

Authorisation request messages must have a transaction value of greater than zero except for when using the
Account Verification message type, in which case the transaction amount must always be set to zero.

6.1.2 REVERSALS

In order to reverse a transaction, the reversal message must be sent on the same day as the original
transaction authorisation message. This is to prevent transactions, where the authorisation has been reversed,
being inadvertently settled.

When an authorisation has been reversed, it is essential to ensure that any settlement transactions relating to
the original authorisation are not included in any settlement files.

Whilst the reversal messages do not need to follow immediately after the original sales transaction, the Scheme
Reference Data and the Acquirer Reference Data from the original authorisation response must be provided
in the Reversal Request Message.

Failure to include the Scheme and Acquirer Reference Data may result in the reversal request being rejected
by the Global Payments Authorisation System.

Where there is a need to reverse a transaction after the original transaction has been included in a settlement
file, a refund should be performed.

Global Payments will not accept responsibility for any Card Scheme fees or charges resulting from
authorisation messages being reversed after they have been settled or, where the necessary Scheme or
Acquirer Reference Data was not provided on the Reversal Request Message.

6.1.3 PARTIAL REVERSALS

For a reversal, the transaction amount in the reversal should contain the amount to be reversed. For a partial
reversal, this must be less than the amount originally authorised.

The Global Payments authorisation host does not require the originally authorised amount to be sent in the
Auxiliary Data Record Type 09 Partial/Alternative Amount Approval when submitting a Partial Reversal
Request.

28
6.2 CONDITION CODES USED IN AUTHORISATION MESSAGES (M/O/C)

Code Meaning

M Mandatory
O Optional
Mandatory if subsequent fields are present. If subsequent fields are present, the delimiter
C1
(FS,GS,US etc.) for an omitted field must be present
Mandatory for Purchase With Cash Back Transactions (including reversals) prohibited for other
C2
transaction types
C3 Mandatory for ICC transaction, optional for non ICC transactions
C4 Mandatory if subsequent sub fields within the field are present
C5 Mandatory for ICC transaction, prohibited for non ICC transactions
C6 Mandatory if returned by issuer
C7 Mandatory for tokenization request messages otherwise optional

6.3 MESSAGE FORMATS

6.3.1 AUTHORISATION REQUEST

Num Name F/V Type Len M/O/C Value

This number is incremented for

each dial attempt
1 = 1st dial
2 = 2nd dial
1 Dial Indicator F N 1 M
3 = 3rd dial (using 2nd NUA if
available)
4 = not a dial connection (for
example, IP)
Terminal ID of the terminal making
2 Terminal Identity F N 8 M
the authorisation request
This number is allocated by the
terminal. Message numbers should
3 Message Number F N 4 M
not be reset at the start of end of
the day for a given Terminal ID
Code indicating the terminal’s
Terminal Type /
4 F AB 4 M capabilities. See Table 1 –
Capabilities
Terminal Type/Capabilities
Code indicating the transaction type
5 Message Type F A 2 M and category. See Table 2 –
Message Types
6 Merchant Number V N 15 M Global Payments Merchant Number

7 Filed Separator F FS 1 M 1C (HEX)

The content and format of this field
8 Card Details V A 40 M vary with the mode of transaction
entry. See Table 3 – Card Details
9 Field Separator F FS 1 M 1C (HEX)
The amount of the transaction in
10 Transaction Amount V N 11 M the currency minor denomination.
Minimum acceptable value is 01.

29
Num Name F/V Type Len M/O/C Value

11 Field Separator F FS 1 M 1C (HEX)

Additional data specific to the
transaction. For example, CSC
12 Descriptive Data V A 16 O
and/address data. See Table 4 –
Descriptive Data
13 Field Separator F FS 1 C1 1C (HEX)

14 Field Separator F FS 1 C1 1C (HEX)

Only required for Mastercard
transactions
15 Authorisation Status F A 1 C A = Actual Amount Authorisation
E = Estimated Amount
Authorisation
16 Field Separator F FS 1 C1 1C (HEX)
Cash amount in minor
17 Cash Back Amount V N 11 C2 denomination of currency. Minimum
value 100
18 Field Separator F FS 1 C1 1C (HEX)
The date and time that the
Transaction Date And
19 F N 10 C3 transaction was generated in the
Time
format YYMMDDhhmm.
20 Field Separator F FS 1 C1 1C (HEX)
Mandatory for chip transactions
(including fallback to mag stripe),
21 EMV Terminal Type F N 2 C3 optional for non-chip transactions.
22 = Attended Terminal
25 = Unattended Terminal
22 Field Separator F FS 1 C1 1C (HEX)
‘826’ (The ISO 3166 Numeric
23 Terminal Country Code F N 3 M Country Code for the United
Kingdom
24 Field Separator F FS 1 C1 1C (HEX)
Transaction Currency The ISO 4217 Numeric Currency
25 F N 3 M
Code Code for the transaction
26 Field Separator F FS 1 C1 1C (HEX)
Code indicating why transaction
was processed online or, why
27 Reason Online Code F N 2 C3 transaction was processed off-line.
See Table 5 – Reason Online
Codes
28 Field Separator F FS 1 C1 1C (HEX)
Mandatory for chip transactions,
29 ICC Request Data
prohibited for non-chip transactions
Authorisation Request The cryptogram generated by the
29.1 F AB 16 C3
Cryptogram (ARQC) card requesting online authorisation

30
 Num Name F/V Type Len M/O/C Value

Code specifying the functions that

Application Interchange
29.2 F AB 4 C3 are supported by the application on
Profile (AIP)
the card
Count of transaction performed
Application Transaction
29.3 F AB 4 C3 taken from the application on the
Counter (ATC)
card
Random number generated by the
Terminal Random
29.4 F AB 8 C3 terminal and used during
Number (TRN)
cryptogram calculation
Coded values recording the results
Terminal Verification
29.5 F AB 10 C3 of the EMV terminal Action Analysis
Results (TVR)
process
00 = Sale
Cryptogram Transaction 20 = Refund
29.6 F N 2 C3
Type 09 = Purchase With Cashback
01 = Cash Advance
Additional, undefined data sent by
Issuer Application Data
29.7 V AB 64 C3 the card in Tag 9F10 to enable the
(IAD)
issuer to authenticate the card
29.8 Unit Separator F US 1 C3 1F (HEX)
The Application ID of the
Application Identification
29.9 V AB 32 C3 application on the card used to
Data (AID)
complete the transaction
29.10 Unit Separator F US 1 C4 1F (HEX)
The version of the application on
Application Version
29.11 F AB 4 C3 the card used to complete the
Number (AVN)
transaction
29.12 Unit Separator F US 1 C4 1F (HEX)
80 = ARQC
Cryptogram Information
29.13 F AB 2 C3 00 = AAC
Data (CID)
40 = TC
29.14 Unit Separator F US 1 C4 1F (HEX)
Card Verification Method Results of the cardholder
29.15 F AB 6 C3
Results (CVMR) verification from the terminal
30 Field Separator F FS 1 C1 1C (HEX)
Auxiliary data records to provide
31 Auxiliary Data Records V 480 A C5 additional data required in the
authorisation request message.
32 Field Separator F AB 1 C1 1C (HEX)

6.3.2 AUTHORISATION RESPONSE

Num Name F/V Type Len M/O/C Value

1 Dial Indicator F N 1 M Taken from Authorisation Request

31
Num Name F/V Type Len M/O/C Value

2 Terminal Identity F N 8 M Taken from Authorisation Request

3 Message Number F N 4 M Taken from Authorisation Request

4 Message Type F N 2 M ‘12’

A code sent back by the acquirer to
indicate the specific action to be
5 Acquirer Response Code F N 2 M taken by the terminal. See Table 6
– Authorisation Response Codes
And Message Text
6 Confirmation Request F N 1 M ‘0’

7 Field Separator F FS 1 M 1C (HEX)

8 Field Separator F FS 1 M 1C (HEX)

The message to be displayed and
printed by the terminal. See Table 6
9 Message Text V A 80 M
– Authorisation Response Codes
And Message Text
10 Field Separator F FS 1 M 1C (HEX)
Telephone number to call in the
N,
11 Voice Referral Number V 16 O event of a voice referral. See Table
US
7 – Voice Referral Number
12 Field Separator F FS 1 O 1C (HEX)
Revised floor limit to be applied by
13 Floor Limit V N 11 O
terminal
14 Field Separator F FS 1 O 1C (HEX)

15 Date F N 4 O YYMM

16 Field Separator F FS 1 O 1C (HEX)

ICC response data returned form
17 ICC Response Data V A 289 O
host
1C (HEX). Mandatory where field
18 Field Separator F FS 1 O
19 is present
Returned when the terminal has
indicated that it is capable of
processing response additional
19 Response Additional Data F AB 6 O data and, when CV2 and AVS data
was supplied in the Authorisation
Request message. See Table 8 –
Response Additional Data Codes
1C (HEX) Mandatory if CVC and
20 Field Separator F FS 1 O AVS data were provided in the
Authorisation Request message.
Auxiliary data as required. See 6.4:
21 Auxiliary Data V A 480 O
Auxiliary Data Records
22 Field Separator F FS 1 O

32
6.4 AUXILIARY DATA RECORDS

6.4.1 AUXILIARY DATA RECORDS: EXAMPLE CONSTRUCTION

Format 1: To Be Used In Authorisation Request Messages

Num Name F/V Type Len M/O/C Value

31.1 Field Separator F FS 1 M 1C (HEX)

Auxiliary data message
31.2 F N 1 M ‘1’
terminal capabilities
Auxiliary data message
31.3 F N 4 M 480
size limit
Variable length based on
31.n.n Auxiliary data record 1st V O Auxiliary Data message size
limit
Variable length based on
Auxiliary data record 2nd
31.n.n V O Auxiliary Data message size
(if applicable)
limit
Variable length based on
Auxiliary data record 3rd
31.n.n V O Auxiliary Data message size
(if applicable)
limit
Variable length based on
Auxiliary data record 4th
31.n.n V O Auxiliary Data message size
(if applicable)
limit
31.n.n Field Separator F FS 1 M 1C (HEX)

Format 2: To Be Used In Authorisation Response Messages

Num Name F/V Type Len M/O/C Value

21.1 Field Separator F FS 1 M 1C (HEX)

Residual Auxiliary
21.2 F N 2 M ‘00’
Message Count
Variable length based on
21.n.n 1st Auxiliary Data Record V O Auxiliary Data message size
limit
Variable length based on
21.n.n 2nd Auxiliary Data Record V O Auxiliary Data message size
limit
Variable length based on
21.n.n 3rd Auxiliary Data Record V O Auxiliary Data message size
limit
Variable length based on
21.n.n 4th Auxiliary Data Record V O Auxiliary Data message size
limit
Variable length based on
21.n.n nth Auxiliary Data Record V O Auxiliary Data message size
limit
21.n.n Field Separator F FS 1 M

33
6.5 AUXILIARY DATA RECORD FORMATS

6.5.1 AUXILIARY DATA RECORD TYPE 01: ECOMMERCE

Sub-Type 01: Standard Ecommerce

For valid combinations of Cardholder Authentication Value (Field 31.3.7), Electronic Commerce Indicator (Field
31.3.17), Additional Transaction Security Data (Field 31.3.5) and Customer Instruction (see Field 6.8 on page
11), please see Table 14.

Failure to use the correct combinations of values in these fields may result in transactions being rejected.

Num Name F/V Type Len M/O/C Value

31.3 Auxiliary Data Record

31.3.1 Record Separator F RS 1 M 1E (HEX)

Auxiliary Data Record
31.3.2 F A 2 M ‘01’
Type
Auxiliary Data Record
31.3.3 F N 2 M ‘01’
Sub-Type
31.3.4 Group Separator F GS 1 M 1D (HEX)
See Table 9: Additional
Additional Transaction
31.3.5 F AB 6 M Transaction Security Data
Security Data
(ATSD)
31.3.6 Group Separator F GS 1 C1 1D (HEX)
Up to 32 characters supplied
by the merchant.
Cardholder
31.3.7 V AB 32 O Mastercard: UCAF is 32
Authentication Value
characters long, Visa: CAVV
is 28 characters long
31.3.8 Group Separator F GS 1 C1 1D (HEX)
Cardholder Certificate Serial
Cardholder Certificate
31.3.9 V AB 24 O Number (Secure Ecommerce
Serial Number
Transactions only)
31.3.10 Group Separator F GS 1 C1 1D (HEX)
Merchant Certificate Serial
Merchant Certificate
31.3.11 V AB 24 O Number (Secure Ecommerce
Serial Number
Transactions only)
31.3.12 Group Separator F GS 1 C1 1D (HEX)
28 character transaction ID
31.3.13 Transaction ID/CAVV F AB 28 O issued as part of the
authentication process
31.3.14 Group Separator F GS 1 C1 1D (HEX)
The TranStain (Secure
31.3.15 TranStain F AB 28 O Ecommerce Transactions
Only)
31.3.16 Group Separator F GS 1 C1 1D (HEX)

34
 Num Name F/V Type Len M/O/C Value

This field must be only

populated if the ECI is
provided by the merchant. It
is provided directly by the
authentication or verification
system or as per the
Electronic Commerce
31.3.17 F N 2 O respective scheme
Indicator (ECI)
guidelines. Otherwise, it is
omitted
The ECI value takes
precedent over any
ecommerce setting of the
EMV Terminal Type
31.3.18 Group Separator F GS 1 C1 1D (HEX)

Sub-Type 02: Application Initiated Ecommerce

Ecommerce auxiliary data record Sub-Type 02 should be used for any application initiated purchases (for
example, Apple Pay or Android Pay).

It should be noted that these transactions always use an Electronic Commerce Indicator of ‘07’, indicating that
these transactions have not been verified using the 3D Secure process.

Num Name F/V Type Len M/O/C Value

31.3 Auxiliary Data Record

31.3.1 Record Separator F RS 1 M 1E (HEX)

Auxiliary Data Record
31.3.2 F A 2 M ‘01’
Type
Auxiliary Data Record
31.3.3 F N 2 M ’02 ’
Sub-Type
31.3.4 Group Separator F GS 1 M 1D (HEX)
Payment Network
31.3.5 F N 2 M
Indicator
31.3.6 Group Separator F GS 1 C1 1D (HEX)
Up to 32 characters supplied
by the merchant.
Cardholder Mastercard: UCAF is 32
31.3.7 V AB 32 O
Authentication Value characters long and is the
only data supported for this
field
31.3.8 Group Separator F GS 1 C1 1D (HEX)
Reserved For UK Cards
31.3.9 V AB 24 O
Association
31.3.10 Group Separator F GS 1 C1 1D (HEX)

35
 Num Name F/V Type Len M/O/C Value

Reserved For UK Cards

31.3.11 V AB 24 O
Association
31.3.12 Group Separator F GS 1 C1 1D (HEX)
28 character transaction ID
31.3.13 Transaction ID F AB 28 O issued as part of the
authentication process
31.3.14 Group Separator F GS 1 C1 1D (HEX)
Reserved For UK Cards
31.3.15 F AB 28 O
Association
31.3.16 Group Separator F GS 1 C1 1D (HEX)
Electronic Commerce
31.3.17 F N 2 O ‘07’
Indicator (ECI)
31.3.18 Group Separator F GS 1 C1 1D (HEX)

6.5.2 AUXILIARY DATA RECORD TYPE 03: DYNAMIC CURRENCY CONVERSION (DCC)

Num Name F/V Type Len M/O/C Comment

31.3 Auxiliary Data Record

31.3.1 Record Separator F RS 1 M 1E (HEX)

Auxiliary Data Record
31.3.2 F A 2 M ‘03’
Type
Auxiliary Data Record
31.3.3 F N 2 M ‘03’
Sub-Type
31.3.4 Group Separator F GS 1 M 1D (HEX)
Transaction amount prior to
currency conversion in the
31.3.5 Currency Amount V N 12 M
card acceptor currency minor
denomination
31.3.6 Group Separator F GS 1 M 1D (HEX)
The Card Acceptors ISO
4217 Numeric Currency Code
31.3.7 Currency Code F N 3 M
– normally 826 for United
Kingdom Sterling
Conversion rate used in the
DCC transaction as printed
31.3.8 Conversion Rate F N 24 M
on the transaction receipt.
See Note 1
31.39 Group Separator F GS 1 M 1D (HEX)
Commission fee on the DCC
31.3.10 Commission Fee F N 11 O transaction in the cardholder
currency, minor denomination
31.3.11 Group Separator F GS 1 M 1D (HEX)

36
 Num Name F/V Type Len M/O/C Comment

The mark up percentage

31.3.12 Mark up Fee V N 11 M applied to the transaction to 4
decimal places
31.3.13 Group Separator F GS 1 C1 1D (HEX)
Marker to indicate whether, or
not, the cardholder was
offered DCC but, chose to
pay in the card acceptor’s
31.3.14 Opt Out Marker F N 1 O currency
1 = DCC offered but not
accepted
0 = DCC offered and
accepted

Note 1: The conversion rate should be formatted in the following way:- DCC Exponent<US>Conversion
Rate (shown without decimal places) The DCC Exponent should contain up to 2 numeric
characters and denote the number of positions the decimal point should be moved from the right
in the Conversion Rate, which may contain up to 21 numeric characters. For example, a value of
6<US> 9977522 specifies a Conversion Rate of 9.977522.

6.5.3 AUXILIARY DATA RECORD TYPE 06: TERMINAL CAPABILITIES AND TERMINAL
ATTRIBUTES

Num Name F/V Type Len M/O/C Value

31.3 Auxiliary Data Record

31.3.1 Record Separator F RS 1 M 1E (HEX)

Auxiliary Data Record
31.3.2 F A 2 M ‘06’
Type
Auxiliary Data Record
31.3.3 F N 2 M ‘01’
Sub-Type
31.3.4 Group Separator F GS 1 M 1D (HEX)
Code indicating the terminal
31.3.5 Terminal Attributes F AB 6 M attributes. See Table 10:
Terminal Attribute Codes
31.3.6 Group Separator F GS 1 M 1D (HEX)
Code indicating the terminal
31.3.7 Terminal Attributes Used F AB 6 M attributes used for this
transaction
31.3.8 Group Separator F GS 1 M 1D (HEX)
EMV Terminal Terminal capabilities as
31.3.9 F AB 6 M
Capabilities defined in EMV Tag 9F33
31.3.10 Group Separator F GS 1 C1 1D (HEX)
The terminal capabilities used
EMV Terminal
31.3.11 F AB 6 O values are mapped to the
Capabilities Used
EMV terminal capabilities and

37
 Num Name F/V Type Len M/O/C Value

indicate which capabilities

were used for this transaction

6.5.4 AUXILIARY DATA RECORD TYPE 09: PARTIAL/ALTERNATIVE AMOUNT APPROVAL

The Partial/Alternative Amount Approval auxiliary record is returned in the authorisation response message
and is used when an issuer approves an amount that is different to the amount requested in the authorisation
request message.

In order to indicate that a terminal can support the use of this Auxiliary Data Record, the terminal must also
submit the Terminal Capabilities and Terminal Attributes Auxiliary Data Record (see table above) and, must
set bit 1 of position 2 of the Terminal Attributes Code (see Table 10) to indicate that Partial/Alternative Amount
Approvals are supported.

When a card issuer returns a Partial/Alternative Amount Approval, the acquirer shall set the Authorisation
Response Code to a value of 10 to differentiate between a normal approval (i.e. the full transaction amount
was approved) and a Partial/Alternative Amount Approval.

Num Name F/V Type Len M/O/C Value

1 Record Separator F RS 1 M
Data Record Type –
Partial/Alternative
2 Amount Approval F N 2 M
Auxiliary Data Record –
Type 09
Data Record Sub-Type =
3 F N 2 M
01
4 Group Separator F GS 1 M

5 Approval Amount V N 11 M

6 Group Separator F GS 1 M
01 = Amount is the partial
amount
02 = Amount is the alternative
7 Approval Amount Type F N 2 M
amount
03 – 99 = Reserved for future
use

Considerations For The Usage Of Partial/Alternative Amount Approvals

Partial/Alternative Amount Approvals are typically used for pre-paid cards and are used to prevent transactions
being declined if there are insufficient funds on the pre-paid card to complete the transaction.

Upon receipt of a Partial/Alternative Amount Approval, the terminal will need to prompt the merchant to either,
complete the remaining amount of the transaction by an alternative method or, cancel the transaction and
reverse the amount that was authorised.

38
Although theoretically, the transaction could be completed using a second card transaction, this could then
prevent the merchant from being able to reverse the original transaction should the second transaction be
declined or only partially approved.

Only allowing completion of the transaction using cash will retain the ability to reverse the initial authorisation,
if the overall transaction cannot be completed.

6.5.5 AUXILIARY DATA RECORD TYPE 10: AUTHORISATION NETWORK REFERENCE DATA

Sub-Type 01: Scheme Reference Data

This data is sent and received in the Auxiliary Data Field in the Authorisation Request/Response messages.
This data is passed to the Global Payments authorising host by the Card Scheme and forwarded by the Global
Payments authorising host if the terminal has indicated that it is capable of processing transaction identifiers.
It should be captured and submitted as part of the Clearing Data (see Sub-Record Format 26) for the original
authorisation and any associated consequent authorisations, for example, on incremental authorisations or
recurring transaction.

Num Name F/V Type Len M/O/C Value

31.3 Auxiliary Data Record

31.3.1 Record Separator F RS 1 M 1E (HEX)

Auxiliary Data Record
31.3.2 F A 2 M ‘10’
Type
Auxiliary Data Record ‘01’ = Scheme Reference
31.3.3 F N 2 M
Sub-Type Data
31.3.4 Group Separator F GS 1 M 1D (HEX)
Comprising of a string of up to
56 characters, Mastercard:
Trace ID is 15 characters
31.3.5 Scheme Reference Data V A 56 M
long, Visa: Transaction ID is
15 characters long Validation
ID is 4 characters long

39
Sub-Type 02: Acquirer Reference Data

This data is sent and received in the Auxiliary Data Field in the Authorisation Request/Response messages.
This data is generated by the Global Payments authorising host if the terminal indicates that it can support
transaction identifiers (in Position 2 of the Terminal Attribute Codes in Auxiliary Data Record 6) and passed to
the Point of Sale in the Authorisation Response message. The data must be included on any consequent
reversal; otherwise the Global Payments authorising host will not send the reversal online to the card issuer.

Num Name F/V Type Len M/O/C Value

31.3 Auxiliary Data Record

31.3.1 Record Separator F RS 1 M 1E (HEX)

Auxiliary Data Record
31.3.2 F A 2 M ‘10’
Type
Auxiliary Data Record ‘02’ = Acquirer Reference
31.3.3 F N 2 M
Sub-Type Data
31.3.4 Group Separator F GS 1 M 1D (HEX)
Comprising of a string of up to
56 characters;
31.3.5 Acquirer Reference Data V A 56 M Note: Global Payments will
return 16 characters
in this field

6.5.6 AUXILIARY DATA RECORD TYPE 12: ALTERNATE CARD NUMBER

With the advent of NFC mobile phone payment technology (for example, Apple Pay) that use tokenised PANs
for security, it has become necessary to be able to return the last four digits of the Cardholder’s Funding PAN
to the POS to allow both the merchant and the cardholder to identify which card the tokenised PAN relates to.
This is particularly useful for identifying the card that was used for the original purchase when performing a
refund.

This is achieved through the use of Auxiliary Data Record Type 12: Alternate Card Number.

In order for a terminal to receive the Alternate Card Number in the Authorisation Response it must indicate
that Alternate Card Number is supported by (a) sending the Terminal Capabilities and Terminal Attributes
Auxiliary Data record in the Authorisation Request and (b) setting a value of 4 position 2 of the Terminal
Attributes Codes.

Note: It is likely that other values will also be set in position 2 of the Terminal Attributes Codes, which means
that the actual value sent must equal the total for all functions supported.

Num Name F/V Type Len M/O/C Value

31.3 Auxiliary Data Record

31.3.1 Record Separator F RS 1 M 1E (HEX)

Auxiliary Data Record
31.3.2 F A 2 M ‘12’
Type
Auxiliary Data Record
31.3.3 F N 2 M ‘01’
Sub-Type

40
 Num Name F/V Type Len M/O/C Value

31.3.4 Group Separator F GS 1 M 1D (HEX)

Alternate Card Number
31.3.5 F N 19 M
(ACN)
31.3.6 Group Separator F GS 1 C1 1D (HEX)

31.3.7 CAN Expiry Date F N 4 O

6.5.7 AUXILIARY DATA RECORD TYPE 13: SCHEME DIGITAL WALLET

Sub-Type 10 – MasterPass Online

Num Name F/V Type Len M/O/C Value

31.3 Auxiliary Data Record

31.3.1 Record Separator F RS 1 M 1E (HEX)

Auxiliary Data Record
31.3.2 F A 2 M ‘13’
Type
Auxiliary Data Record
31.3.3 F N 2 M ‘10’
Sub-Type
31.3.4 Group Separator F GS 1 M 1D (HEX)
Wallet Transaction
31.3.5 F A 3 M
Origin

6.5.8 AUXILIARY DATA RECORD TYPE 15: CONTACTLESS DEVICE INFORMATION DATA

Num Name F/V Type Len M/O/C Comment

31.3 Auxiliary Data Record

31.3.1 Record Separator F RS 1 M 1E (HEX)

Auxiliary Data Record
31.3.2 F A 2 M ‘15’
Type
Auxiliary Data Record
31.3.3 F N 2 M ‘01’
Sub-Type
31.3.4 Group Separator F GS 1 M 1D (HEX)

31.3.5 Contactless Form Factor V AB 70 M

31.3.6 Group Separator F GS 1 C1 1D (HEX)

Contactless
31.3.7 V AB 70 O
Discretionary Data

41
Contactless Form Factor

The contents of this data element will vary by Card Scheme; for Mastercard and Visa it is Tag 9F6E, for
American Express it is Tag 9F67. The definition of these data elements can be found in the appropriate Card
Scheme’s Contactless specifications.

The card acceptor will provide the whole data element in BER-TLV format as described in EMV as the Tag will
vary from Card Scheme to Card Scheme. When the data is converted to hexadecimal, the value of the length
component shall still represent the length of the binary data.

For example TTTTLLdddddd would be interpreted as:

• TTTT is the EMV Tag
• LL is the length of the data
• dddddd is the Contactless Form Factor – with the length as defined by LL

Data should be left justified and space filled.

Contactless Discretionary Data

The contents of this data will vary by Card Scheme and will be as agreed by interchange parties. For Visa the
discretionary data will be the content of Tag 9F7C. The definitions for these data elements can be found in the
appropriate Card Scheme’s Contactless specifications.

The card acceptor will provide the whole data element in BER-TLV format as described in EMV as the Tag will
vary from Card Scheme to Card Scheme. When the data is converted to hexadecimal, the value of the length
component shall still represent the length of the binary data.

6.5.9 AUXILIARY DATA RECORD TYPE 18: PAYMENT ATTRIBUTES

Num Name F/V Type Len M/O/C Comment

31.3 Auxiliary Data Record

31.3.1 Record Separator F RS 1 M 1E (HEX)

Auxiliary Data Record
31.3.2 F A 2 M ‘18’
Type
Auxiliary Data Record
31.3.3 F N 2 M ‘01’
Sub-Type
31.3.4 Group Separator F GS 1 M 1D (HEX)

31.3.5 Payment Attributes F AB 24 M

42
6.5.10 AUXILIARY DATA RECORD TYPE 22: TOKENISATION RESPONSE DATA

When a scheme issued token is used to perform a transaction, Auxiliary Data Record Type 22 can be used
to return details of the token (if/when returned by the card issuer) to the terminal.

Receipt of this record is controlled by the setting Position 5 of the Terminal Attribute Codes (see Table 10).

Num Name F/V Type Len M/O/C Comment

31.3 Auxiliary Data Record

31.3.1 Record Separator F RS 1 M 1E (HEX)

Auxiliary Data Record
31.3.2 F A 2 M ‘22’
Type
Auxiliary Data Record
31.3.3 F N 2 M ‘02’
Sub-Type
31.3.4 Group Separator F GS 1 M 1D (HEX)
Token Usage Result
31.3.5 F N 2 O
Code
31.3.6 Group Separator F GS 1 C1 1D (HEX)

31.3.7 Funding PAN V N 19 O

31.3.8 Group Separator F GS 1 C1 1D (HEX)

Funding PAN Expiry
31.3.9 F N 4 O
Date
31.3.10 Group Separator F GS 1 C1 1D (HEX)

31.3.11 Token Assurance Level F N 2 C7

31.3.12 Group Separator F GS 1 C1 1D (HEX)

31.3.13 Token PAN V N 19 C6

31.3.14 Group Separator F GS 1 C1 1D (HEX)

31.3.15 Token PAN Expiry Date F N 4 C6

31.3.16 Group Separator F GS 1 C1 1D (HEX)

31.3.17 Token Requester ID F A 11 O

31.3.18 Group Separator F GS 1 C1 1D (HEX)

31.3.19 Token Status F A 2 O

31.3.20 Group Separator F GS 1 C1 1D (HEX)

Reserved For Future
31.3.21 O
Use
31.3.22 Group Separator F GS 1 C1 1D (HEX)

43
 Num Name F/V Type Len M/O/C Comment

Reserved For Future

31.3.23 O
Use
31.3.24 Group Separator F GS 1 C1 1D (HEX)
Reserved For Future
31.3.25 O
Use
31.3.26 Group Separator F GS 1 C1 1D (HEX)
Reserved For Future
31.3.27 O
Use

6.5.11 AUXILIARY DATA RECORD TYPE 23: PAYMENT ACCOUT REFERENCE (PAR)

Num Name F/V Type Len M/O/C Value

31.3 Auxiliary Data Record

31.3.1 Record Separator F RS 1 M 1E (HEX)

Auxiliary Data Record
31.3.2 F A 2 M ‘23’
Type
Auxiliary Data Record
31.3.3 F N 2 M ‘01’
Sub-Type
31.3.4 Group Separator F GS 1 M 1D (HEX)
Payment Account
31.3.5 V A 56 M
Reference

6.6 FIELD REFERENCE TABLES

Table 1: Terminal Type/Capabilities

It is essential that the following data is as accurate as possible. If the terminal’s true capabilities are not
accurately described by this data, then the Global Payments authorising host or the card issuer may not
approve the transaction. For example, Mastercard have strict rules concerning the acceptance of cards at
Unattended/Cardholder Activated Terminals that are triggered if the fourth position indicates ‘Unattended
Device’ support.

Feature 8 4 2 1

ICC Reader X

Magnetic Stripe Reader (MSR) X

First Position:
Terminal Capabilities
Manual Card Reader X

Extended Terminal Capabilities (see Note 1) X

Second Position:
Number of 16 lines that can be
displayed or printed. (0) Lines of display available X X X X
indicates display or printer not
available

44
 Feature 8 4 2 1

Down line loading of referral telephone

X
number supported
Third Position: Hold capability X
Response Message
Down line loading of floor limits/data
Capabilities X
supported
Response additional data support X

Unattended device X
Fourth Position:
PINPAD available X
Additional Features and
Capabilities. (0) indicates no
Terminal or operator able to capture cards X
additional capabilities
supported Cardholders device (for example, may be a
PC, mobile phone, PDA, digital TV or similar X
device for E or M commerce

Note 1: If this bit is set then the data supplied is the extended terminal capabilities and attributes auxiliary
data messages takes priority. See Table 10.

Table 2: Message Types

Message
Type Description Direction Category Notes
Class
Purchase With
03 Authorisation Request Card 1st try Swipe
Cashback
Purchase With
04 Authorisation Request Keyed 1st try
Cashback
Purchase With
05 Authorisation Request Card Re-try Swipe
Cashback
Purchase With
06 Authorisation Request Keyed Re-try
Cashback
Purchase Cardholder No
09 Authorisation Request 1st try Keyed
Not Present cardholder
10 Purchase Authorisation Request Card 1st try Swipe

16 Purchase Authorisation Request Card Re-try Swipe

Customer
20 Purchase Authorisation Request Keyed 1st try
Present
Cancel at
25 Debit Reversal Authorisation Request 1st try
signature
Customer
26 Purchase Authorisation Request Keyed Re-try
Present
28 Debit Reversal Authorisation Request Re-try

30 Cash Authorisation Request Card 1st try Swipe

31 Cash Authorisation Request Keyed 1st try

36 Cash Authorisation Request Card Re-try Swipe

45
 Message
Type Description Direction Category Notes
Class

37 Cash Authorisation Request Keyed Re-try

Purchase Cardholder No
45 Authorisation Request Re-try Keyed
Not Present cardholder
Refund Cardholder No
47 Authorisation Request 1st try
Not Present cardholder
Refund Cardholder No
49 Authorisation Request Re-try
Not Present cardholder
58 Refund Authorisation Request Card 1st try Swipe

61 Refund Authorisation Request Keyed 1st try

63 Refund Authorisation Request Card Re-try

67 Refund Authorisation Request Keyed Re-try

Purchase – No
A0 Authorisation Request 1st try
Continuous Authority cardholder
Purchase – No
A1 Authorisation Request Re-try
Continuous Authority cardholder
Purchase - Electronic
A8 Authorisation Request Card 1st try
Commerce
Purchase - Electronic
A9 Authorisation Request Card Re-try
Commerce
Refund - Electronic
AA Authorisation Request Card 1st try
Commerce
Refund - Electronic
AB Authorisation Request Card Re-try
Commerce
Purchase Electronic –
B2 Authorisation Request Keyed 1st try
Commerce
Purchase Electronic -
B3 Authorisation Request Keyed Re-try
Commerce
Refund - Electronic
B4 Authorisation Request Keyed 1st try
Commerce
Refund - Electronic
B5 Authorisation Request Keyed Re-try
Commerce
E6 Account Verification Authorisation Request Card 1st Try See Note 1

E7 Account Verification Authorisation Request Card 2nd Try See Note 1

E8 Account Verification Authorisation Request Keyed 1st Try See Note 1

E9 Account Verification Authorisation Request Keyed 2nd Try See Note 1

EA Account Verification Authorisation Request CNP 1st Try See Note 1

EB Account Verification Authorisation Request CNP 2nd Try See Note 1

Ecommerce / Account
EC Authorisation Request Keyed 1st Try See Note 1
Verification
Ecommerce / Account
ED Authorisation Request Keyed 2nd Try See Note 1
Verification
Note 1: For Account Verification, the transaction amount must always be zero and is applicable to
Mastercard and Visa transactions.

46
Table 3: Card Details

Magnetic Stripe Read (MSR) - Track 2 Data

No Size F/V M/O/C Type Note

Unaltered contents of Magnetic Stripe Read track 2 including the
A 40 V M A Star Sentinel, End Sentinel and Longitudinal Redundancy Check
(LRC)

Manual Key Entered (PKE)

No Size F/V M/O/C Type Note

a 1 F M US Unit Separator

b 25 V M N PAN

c 1 F O US Unit Separator

d 4 F O N Expiry date (entered as MMYY but sent as YYMM)

ICC Supplied Equivalent Track 2 Data – See Note 2

No Size F/V M/O/C Type Note

a 37 V M A ICC track 2 data (TAG ‘57’)

b 1 F M US Unit Separator

c 2 F O N ICC Application PAN sequence number ICC (Tag ‘5F34’)

IC Constructed Track 2 Equivalent Data Field –See Note 3

No Size F/V M/O/C Type Note

a 19 V M N ICC PAN (tag ‘5A’)

b 1 F M US Unit Separator
Leftmost 4 characters (YYMM) of ICC expiry date (ICC (Tag
c 4 F M N
‘5F24’))
d 1 F O US Unit Separator

e 2 F O N ICC PAN sequence number (ICC (Tag ‘5F34’))

Note 1: When a Start Date has been entered as part of the key entered transaction, the Start Date must
not be transmitted with the Authorisation Request message.

Note 2: Each 4 bit nibble of data in sub-field ‘a’ will be prefixed with binary ‘011’ with even parity inserted
on bit 8.

If rightmost (least significant) 4 bit nibble of data element ‘a’ is hex value ‘F’ this should be
discarded.

47
 Sub field ‘c’ is missing if the ‘Application PAN sequence number’ data object Tag ‘5F34’ is not
present on the card. Sub field ‘b’ is mandatory if sub field ‘c’ is present.

Note 3: Sub field ‘d’ and ‘e’ are missing if ‘Application PAN sequence number’ data object Tag 5F34’ is
not present on the card. Sub field ‘e’ is mandatory is sub field ‘e’ is present.

The terminal shall always check for the presence of ‘Track 2 Equivalent Data object Tag ‘57’ and,
if it is present, use this in the authorisation message from the terminal.

Table 4: Descriptive Data

Field Data

1 The 3 (4 in the case of Amex) digit CSC data

2 US – Unit Separator

3 The first 5 numeric from the Postcode (In the UK this will be 2 or 3 digits only)

4 US – Unit Separator
Numerics from address, truncated if required (these are the leading numerics from
5
each line of the address up to maximum 5 digits)

Note 1: The validation of the CSC depends on the correct Expiry Date being submitted in addition to the
CSC value. All address data shall relate to the customer’s statement/billing address.

Note 2: If this format is used, the two US characters are mandatory even if one or more of the sub
elements are not populated.

Table 5: Reason Online Codes

More than one value from the table below may be applicable to any one given transaction.

The codes are listed in priority order so that in the event of more than one code applying to a transaction, the
first code encountered in the list will apply. For example, a transaction could have fallen back from chip to mag
stripe – Reason Online Code 04, and also be above the merchant’s floor limit – Reason Online Code 10. In
this example, the Reason Online Code sent in the Authorisation Request message would be 04.

Value Description Example Conditions

04 Terminal not able to process IC Fallback for IC

05 Real-time forced by IC IC forced real-time, no bits set in TVR

Card used twice
Max times per day
One in ‘n’ authorisation
06 Real-time forced by card acceptor PAN key entry authorisation
Transaction type authorisation
Exclusion band checks
Pre-valid card
Expired card
09 Real-time forced by card issuer New card
Service code

48
 Value Description Example Conditions

Hot card

Force authorisation (NO at signature check)

11 Card acceptor suspicious
Card returns an inappropriate cryptogram
‘Transaction selected randomly for real-time
03 Terminal random selection
processing’ bit set in TVR (i.e. byte 4, bit 5)
10 Over floor limit Above floor limit

08 Real-time forced by terminal TVR indicates real-time required

Only used by IC/MSR terminals where the
IC application common data file unable to terminal has possession of the card and
00
process when this condition can be accurately
identified
Only used by integrated IC/MSR terminals
IC application, application data file unable to where the terminal has possession of the
01
process card and when this condition can be
accurately identified
02 IC random selection Not Used

07 Real-time forced by terminal Not used

25 IC processed IC authorised
Amount less than the pre-communications
26 Under floor limit
floor limit in a non IC transaction
Advice of a sale that has already been
authorised by means of one or more
27 Stand-in processing at the acquirer’s option
previously -authorised transactions,
completed real-time to the acquirer.

Table 6: Authorisation Response Codes And Message Text

The following table details the response codes that may be returned to a terminal along with the message text
that will be returned for the terminal to display and/or print.

Response Code Message Text Reason

00 AUTH CODE: NNNNNN Approve

Approval For Account Verification
00 ACCOUNT VALID
Transactions
00 REVERSAL ACCPTD Reversal Accepted

02 CALL AUTH CENTRE Referral

Merchant Unknown / Merchant Number
03 INVALID MERCHANT has not been set up on authorisation
system
04 DECLINE & PICKUP Issuer Requires Card To Be Retained

05 DECLINE Decline (N/A reversals)

49
 Response Code Message Text Reason

05 CANNOT AUTHORISE Terminal ID is unrecognised

Cardholder Has Ended A Recurring
05 CONSENT REVOKED
Transaction / Instalment
05 INVALID TRAN Transaction Not Allowed At Terminal

05 CARD EXPIRED Expired Card

Allowable Number Of PIN Tries
05 NOT AUTHORISED
Exceeded
Decline For Account Verification
05 ACCOUNT INVALID
Transactions
10 AUTH CODE: NNNNNN Partial/Alternative Amount Approval

13 INVALID AMOUNT Invalid Amount

14 INVALID CARD NO Invalid Account Number

21 TERM DEACTIVATED Invalid Terminal ID

30 BAD FORMAT Format Error In Authorisation Request

30 BAD AMOUNT Format Error In Authorisation Request

30 BAD EXPIRY DATE Format Error In Authorisation Request

30 INVALID TRACK 2 Format Error In Authorisation Request

30 BAD ACCOUNT Format Error In Authorisation Request

30 BAD DESCR Format Error In Authorisation Request

55 PIN Error Incorrect PIN

Table 7: Voice Referral Number Format

The Referral telephone number data element is a variable length data element up to 16 characters. The
Referral telephone number is a structured number returned to a terminal to assist the terminal in dialling the
acquirer should voice contact be necessary. The number is in 3 parts;
A. is the code required to access an exchange line on a PABX (exchange line),
B. is the code which identifies the distant exchange national number group (dial code),
C. is the exchange number.

By sub-dividing the Referral telephone number it is possible for the acquirer to change all or part of the number
previously stored in the terminal.

If the acquirer wishes to change all elements stored in the terminal then the number in the Referral telephone
number data element shall contain no US character. If the acquirer wishes the terminal to dial the number as
defined in the terminal then it shall send a single US character.

Sending the appropriate combination of numbers and US character can change any other parts of the stored
referral number. The table below lists the structures that may be sent:

50
 Referral Telephone Number
Terminal Response
Contents
No voice referral. Disconnect and display Text message
None
immediately.
Numbers Dial contents of A (if any) followed by numbers.

US (numbers) Dial contents of A and B (if any) followed by numbers.

US Dial contents of A, B and C.

Do not dial anything but switch to voice on the line already
US US
established.

Note: Any other combination is invalid.

Table 8: Response Additional Data Codes

Feature 8 4 2 1

Not Checked X

Matched X
First Position:
CSC
Not Matched X

Reserved For APACS X

Not Checked X

Matched X
Second Position:
Post Code
Not Matched X

Partial Match X

Not Checked X

Matched X
Third Position:
Address Numeric
Not Matched X

Partial Match X

Issuer X

Acquirer X
Fourth Position:
Authorising Entity
Not Used by GP X

Not Used by GP X

Reserved X
Fifth Position:
Reserved For Future Use
Reserved X

51
 Feature 8 4 2 1

Reserved X

Reserved X

Reserved X

Reserved X
Sixth Position:
Reserved For Future Use
Reserved X

Reserved X

Table 9: Additional Transaction Security Data (ATSD)

Feature 8 4 2 1

Mastercard SecureCode X

Reserved X
First Position:
Security Capability
Verified by Visa X

Channel Encryption (TLS) X

Reserved X

Reserved X
Second Position:
Certificates
Reserved X

Reserved X

Mastercard SecureCode X

Reserved X
Third Position:
Security Attempted
Verified by Visa X

Channel Encryption (TLS) X

Authentication Successful X
Evidence Of Attempted
X
Fourth Position: Authentication
Security Results
System Unable To Verify X

Previous Authentication Successful X

V.Me By Visa X
Fifth Position:
Reserved For Future Use
Mastercard PayPass Online X

52
 Feature 8 4 2 1

Reserved X

Reserved X

Reserved X

Reserved X
Sixth Position:
Reserved For Future Use
Reserved X

Reserved X

The values of the first second and third positions are each cumulative in that they record all the features
available or that are used in a transaction. Value settings for position 4 are mutually exclusive.

Table 10: Terminal Attributes

The terminal codes in the table below list the values used for both the Terminal Attributes Data Element and
the Terminal Attributes Used Data Element. The Terminal Attributes Data Element identifies the features
supported by the terminal and the Terminal Attributes Used Data Element identifies which of those features
were used in the transaction being processed. For any terminal that supports these data elements, the
Terminal Attributes Data Element shall be included in all authorisation and financial presentment messages
regardless of the terminal attributes used for the transaction being processed.

Terminal Attribute Codes

Feature 8 4 2 1

Contactless Reader Mag Stripe

X
Format
Contactless Reader EMV Format X
Position 1:
Read Capabilities Reserved For The UK Cards
X
Association
Reserved For The UK Cards
X
Association
Partial/Alternative Amount Approval
X
Responses Supported
Position 2: Transaction Identifiers Supported X
Response Message
Capabilities Alternate Card Number Supported X
Reserved For The UK Cards
X
Association
Contactless Signature X

Contactless CDCVM X
Position 3:
Contactless CVM Reserved For The UK Cards
X
Association
Reserved For The UK Cards
X
Association

53
 Feature 8 4 2 1

MPoS With Integrated Card Reader X

Position 4: MPoS With Separate Card Reader X

Mobile Point of Sale
Reserved For The UK Cards
(MPoS) X
Association
Reserved For The UK Cards
X
Association
Token Data Supported X
Pay-By-Instalment Offer Data
X
Position 5: Supported
Response Message capabilities
Additional Receipt Data Supported X
Reserved For The UK Cards
X
Association
Reserved For The UK Cards
X
Association
Reserved For The UK Cards
X
Association
Position 6
Reserved For The UK Cards
X
Association
Reserved For The UK Cards
X
Association

Table 11: Point Of Interaction (POI) Capabilities

The POI Capabilities is a set of 24 single character indicators that indicate the capabilities of the POI device
accepting the transactions.

Note: Global Payments does not currently support the full range of values shown in UK Cards Association
Standard 70, only the values indicated below should be submitted in settlement files.

POS Capability Value Meaning

1 Value not supported

2 Value not supported

3 Value not supported

4 Value not supported

M Mag stripe read capable

5 Swipe
N No mag stripe read capability

C Contact IC device
6 Contact ICC
N No contact ICC

7 Contactless ICC F Full Contactless capabilities

54
POS Capability Value Meaning

M Mag stripe Contactless only

E EMV Contactless only

N No Contactless capability

8 Value not supported

9 Value not supported

10 Value not supported

K Keying Possible
11 Keyed
N Keying Not Possible

12 Value not supported

13 Value not supported

14 Value not supported

I MPOS device with integrated card reader

15 MPoS N Not an MPOS device

S MPOS device with separate card reader

16 Reserved For UK Cards Association

17 Reserved For UK Cards Association

18 Reserved For UK Cards Association

19 Reserved For UK Cards Association

20 Reserved For UK Cards Association

21 Reserved For UK Cards Association

22 Reserved For UK Cards Association

23 Reserved For UK Cards Association

24 Reserved For UK Cards Association

55
Table 12 – Payment Attributes – For Use With General Sub Record Type 01

Posn. Attribute Value Meaning

A Re Authorisation

C Unscheduled Payment

D Delayed Charges

I Instalment
Card Acceptor/Cardholder Agreement
1 L Incremental
(see Note 1)
N Not Applicable

R Recurring Payment

S Re Submission

X No show
C Cardholder Not Present (unspecified)
M Mail Order

Cardholder Not Present Condition N Not Applicable (i.e. cardholder present)

2
(see Note 2)
T Telephone Order
E Electronic Commerce
A Application initiated electronic commerce
3 Reserved For The UK Cards Association
F Payment Details Stored for First Time

4 Stored Payment Details Indicator N Not Applicable

S Using Previously Stored Payment Details

5 Reserved For The UK Cards Association

6 Reserved For The UK Cards Association
7 Reserved For The UK Cards Association
8 Reserved For The UK Cards Association
9 Reserved For The UK Cards Association
10 Reserved For The UK Cards Association
11 Reserved For The UK Cards Association
12 Reserved For The UK Cards Association
13 Reserved For The UK Cards Association
14 Reserved For The UK Cards Association
15 Reserved For The UK Cards Association
16 Reserved For The UK Cards Association

56
 Posn. Attribute Value Meaning
17 Reserved For The UK Cards Association
18 Reserved For The UK Cards Association
19 Reserved For The UK Cards Association
20 Reserved For The UK Cards Association
21 Reserved For The UK Cards Association
22 Reserved For The UK Cards Association
23 Reserved For The UK Cards Association
24 Reserved For The UK Cards Association

Note 1: Values other than N only to be used with cardholder present, cardholder not present, continuous
authority or electronic commerce sale message types.

Note 2: Values other than N only to be used with cardholder not present or electronic commerce message
types

Table 13 – Payment Attributes – For Use With Auxiliary Data Record Type 18

Posn. Attribute Value Meaning

A Re Authorisation

C Unscheduled Payment

D Delayed Charges

I Instalment
Card Acceptor/Cardholder Agreement
1 L Incremental
(see Note 1)
N Not Applicable

R Recurring Payment

S Re Submission

X No show
C Cardholder Not Present (unspecified)
M Mail Order

Cardholder Not Present Condition N Not Applicable (i.e. cardholder present)

2
(see Note 2)
T Telephone Order
E Electronic Commerce

3 Reserved For The UK Cards Association

F Payment Details Stored for First Time
4 Stored Payment Details Indicator
N Not Applicable

57
 Posn. Attribute Value Meaning
S Using Previously Stored Payment Details

5 Reserved For The UK Cards Association

6 Reserved For The UK Cards Association
7 Reserved For The UK Cards Association
8 Reserved For The UK Cards Association
9 Reserved For The UK Cards Association
10 Reserved For The UK Cards Association
11 Reserved For The UK Cards Association
12 Reserved For The UK Cards Association
13 Reserved For The UK Cards Association
14 Reserved For The UK Cards Association
15 Reserved For The UK Cards Association
16 Reserved For The UK Cards Association
17 Reserved For The UK Cards Association
18 Reserved For The UK Cards Association
19 Reserved For The UK Cards Association
20 Reserved For The UK Cards Association
21 Reserved For The UK Cards Association
22 Reserved For The UK Cards Association
23 Reserved For The UK Cards Association
24 Reserved For The UK Cards Association

Note 1: Values other than N only to be used with cardholder present, cardholder not present, continuous
authority or electronic commerce sale message types.

Note 2: Values other than N only to be used with cardholder not present or electronic commerce message
types

Table 14 – Supported Combinations Of Values For Ecommerce Transactions

Mastercard

Customer
Data To Be Sent In Ecommerce Auxiliary
Description Instruction Value
Data Record Type 0101
To Be Used
ECI = 02
Cardholder was successfully
ATSD = D091 G
authenticated.
CAV = UCAF value that starts with a ‘j’
Authentication could not be ECI = 01
completed but a proof of ATSD = D092 H
authentication attempt was provided. CAV = UCAF value that starts with an ‘h’

58
 Customer
Data To Be Sent In Ecommerce Auxiliary
Description Instruction Value
Data Record Type 0101
To Be Used
Authentication could not be
ECI = not present
completed because of technical or
ATSD = D080 J
other problems or SecureCode
CAV = not present
processing was not performed.

Visa

Customer
Data To Be Sent In Ecommerce Auxiliary
Description Instruction Value
Data Record Type 0101
To Be Used
ECI = 05
Secure electronic commerce
ATSD = D0C1 G
transaction.
CAV = CAVV
Non-authenticated security
transaction at a 3D Secure-capable ECI = 06
merchant, and merchant attempted ATSD = D0C2 H
to authenticate the cardholder using CAV = CAVV
3D Secure.
Authentication could not be ECI = 07
completed because of technical or ATSD = D0C4 J
other problems. CAV = not present
ECI = 07
Verified By Visa processing was not
ATSD = D080 J
performed.
CAV = not present

59
APPENDIX 1: CURRENCIES SUPPORTED

ISO Currency
ISO Currency
Currency Code
Code (Alpha)
(Numeric)
Australian Dollar AUD 036
Bahraini Dinar BHD 048
Brazilian Real BRL 986
Canadian Dollar CAD 124
Danish Krone DKK 208
Egyptian Pound EGP 818
Euro EUR 978
GB Pound Sterling GBP 826
Hong Kong Dollar HKD 344
Indian Rupee INR 356
Japanese Yen JPY 392
South Korean Won KRW 410
Kuwait Dinar KWD 414
Lebanese Pound LBP 422
Malaysian Ringgit MYR 458
New Israeli Shekel ILS 376
New Turkish Lira TRY 949
New Zealand Dollar NZD 554
Nigerian Naira NGN 566
Norwegian Krone NOK 578
Polish Zloty PLN 985
Qatari Rial QAR 634
Russian Rubble RUB 643
Saudi Riyal SAR 682
Singapore Dollar SGD 702
South African Rand ZAR 710
Swedish Krona SEK 752
Swiss Franc CHF 756
Thai Baht THB 764
Ukrainian Hryvnia UAH 980
United Arab Emirates Dirham AED 784
United States Dollar USD 840
Yuan Renminbi (Chinese) CNY 156

60
APPENDIX 2: SUPPLEMENTARY GUIDES
This section of the Authorisation And Settlement Technical Specifications provides details of the
supplementary guides that are available from us. These guides provide additional details to allow the support
of functionality for niche markets. They are not standalone documents and must be read in conjunction with
this guide.

You must seek our agreement prior to implementing the functionality detailed in these guides.

Current Supplementary Guides

• Automated Fuel Dispensers (AFD)
• Mastercard Point Of Interaction (POI) Instalment Payments
• Enhanced Authorisation Data Service – Merchant Implementation Guide
• Stored Credential – Technical Implementation Guide

61
Global Payments
51 De Montfort Street
Leicester
LE1 7BB
Tel 0345 702 3344
Textphone 0345 602 4818
www.globalpaymentsinc.co.uk
www.globalpaymentsinc.com

Global Payments is HSBC’s preferred supplier for card processing in the UK.

Global Payments is a trading name of GPUK LLP. GPUK LLP is authorised by the Financial Conduct Authority under
the Payment Services Regulations 2009 (504290) for the provision of payment services and under the Consumer Credit
Act (714439) for the undertaking of terminal rental agreements.

GPUK LLP is a limited liability partnership registered in England number OC337146. Registered Office: 51, De Montfort
Street, Leicester, LE1 7BB. The members are Global Payments U.K. Limited and Global Payments U.K. 2 Limited.
Service of any documents relating to the business will be effective if served at the Registered Office.

© GPUK LLP. All rights reserved.

ASTS 10/2017 | GP378