You are on page 1of 148

STANDARD 70 - BOOK 1

CARD ACCEPTOR TO ACQUIRER


INTERFACE STANDARDS
Business Rules for Card Processing

1 June 2007

APACS
Mercury House, Triton Court
14 Finsbury Square
London EC2A 1LQ
Telephone: 020 7711 6200
Facsimile: 020 7256 5527

© APACS (Administration) Limited 2004


COPYRIGHT

Copyright in this document lies with APACS (Administration) Limited. Without the express written permission of
APACS (Administration) Limited, it must not be:

1) altered or amended in any way;


2) copied or reproduced in whole or in part in paper form, electronically or otherwise (other than as is
reasonably necessary for the application of this standard by the purchaser);
3) re-sold in whole or in part.

Copies of this standard are available exclusively from:

The Standards Administrator


APACS
Mercury House, Triton Court
14 Finsbury Square,
LONDON EC2A 1LQ
United Kingdom

Telephone: 020 7711 6319 (International: + 44 (0)20 7711 6319)


Facsimile: 020 7711 6299 (International: + 44 (0)20 7711 6299)
E-mail: standards@apacs.org.uk
STANDARD 70 Book 1 PAGE: 1

CONTENTS 1 June 2007

FOREWORD

INTRODUCTION

1 SCOPE 7

2 NORMATIVE REFERENCES 9

3 TERMS AND DEFINITIONS 11

4 SYMBOLS (AND ABBREVIATED TERMS) 13

5 POS ENVIRONMENTS 15
5.1 Data Security 16
5.2 EMV Certification 16
5.2.1 General 16
5.2.2 EMV level 1 (hardware) certification 16
5.2.3 EMV level 2 certification 16

6 BUSINESS RULES 19
6.1 General 19
6.2 IC card process 20
6.2.1 Scope 20
6.2.2 Displays used in transactions 20
6.2.3 Transaction selection 20
6.2.4 Capture card data 20
6.2.5 Process card data 21
6.2.6 Capture transaction amount 23
6.2.7 Cardholder verification 24
6.2.8 Issuer and terminal action codes 26
6.2.9 Premature card removal 26
6.2.10 Terminals with no real-time capability 27
6.2.11 Unable to do a real-time authorisation 27
6.3 Proximity card process 28
6.3.1 Scope 28
6.3.2 Displays used in transactions 30
6.3.3 Transaction selection 30
6.3.4 Capture card data 30
6.3.5 Process card data 31
6.3.6 Capture transaction amount 31
6.3.7 Cardholder verification 31
6.3.8 Other comments about the process 31
6.4 Magnetic stripe process 32
6.4.1 Scope 32
6.4.2 Displays used in transactions 32
6.4.3 Transaction selection 32
6.4.4 Capture card data 33
6.4.5 Process card data 33
6.4.6 Capture transaction amount 34
6.4.7 Cardholder verification 34
6.5 Key entry process 35
6.5.1 Scope 35
6.5.2 Displays used in transactions 36
6.5.3 Transaction selection 36
6.5.4 Capture card data 36
6.5.5 Process card data 36
6.5.6 Capture transaction amount 37

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 2

CONTENTS 1 June 2007


6.5.7 Cardholder verification 37
6.6 Authorise the transaction 38
6.6.1 General 38
6.6.2 Local processing by the terminal 39
6.6.3 Real-time processing remotely by the acquirer 42
6.6.4 Local processing by the terminal after a call failure 44
6.6.5 Manual procedures 46
6.7 Printing 46
6.8 Submit transaction for settlement 46
6.8.1 General 46
6.8.2 Card acceptor capture of transactions 47
6.8.3 Acquirer capture of transactions 47
6.8.4 Message number 48
6.8.5 Delayed cancel 48
6.9 Exception transactions 48
6.9.1 General 48
6.9.2 Declined transactions 48
6.9.3 Voice referrals 50
6.9.4 Refund processing 51
6.9.5 Stand-in processing 53
6.9.6 Reversals 53
6.10 Industry specific transactions 55
6.10.1 General 55
6.10.2 Unattended Terminals (excluding ATMs) 55
6.10.3 Authorisations with an unknown final amount 57
6.10.4 Hospitality, hotel & car hire 57
6.10.5 Fast food 64
6.11 Dynamic currency conversion (DCC) 64

7 CARD ACCEPTOR FACILITIES 67


7.1 General 67
7.2 X and Z balances 67
7.3 Reconciliation 67
7.3.1 Outline 67
7.3.2 Sessions 68
7.3.3 Balancing with the acquirers 68
7.3.4 Balancing card issuer datasets 71

APPENDICES
A. MINIMUM TERMINAL HARDWARE REQUIREMENTS 73
B. MINIMUM SOFTWARE REQUIREMENTS 79
C. TRANSACTION TIMES 97
D. DISPLAYABLE MESSAGES 103
E. TERMINAL FALLBACK PROCEDURES 109
F. CARD SCHEME IDENTIFICATION 111
G. LUHN FORMULA 123
H. PRINTED DATA 125
I. USE OF SERVICE CODES 139
J. AUTHORISATION CODE ALGORITHM 141
K. REFERRAL TELEPHONE NUMBER PROCESSING 143
L. DIAGNOSTIC CODES 145

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 3

FOREWORD 1 June 2007

FOREWORD

This standard is the responsibility of the APACS Standards Maintenance Group (SMG). The
SMG has been established by, and reports to, the Acquirers’ POS Group (APG). The APG
reports to the APACS Card Payments Group (CPG).

It is the intention of APACS and the APG that this standard shall be maintained in line with
relevant standards published by ISO, CEN and APACS.

Standard 70 consists of the following books, under the general title - Card acceptor to
acquirer interface standards:

Book 1 - Business rules for card processing

Book 2 - Messages, data elements and code values for real-time systems

Book 3 - Messages, data elements and code values for post-event systems

Book 4 - Communications

Book 5 - Security and key management.

Book 6 - Data port interface

Book 7 - Terminal Identities

Standard 70 is a redrafting of a number of previous APACS standards (Standard 29-4, 30,


40, 50 and the Common Attachment) into a consistent format, which matches that used in
Standard 60.

Standard 60 specifies an alternative message structure (utilising a bit map to indicate the
presence or absence of data elements) to those described in Standard 70 Books 2 and 3.

The requirements of Standard 70 Books 1, 4, 5, 6 and 7 shall still apply regardless of


whether Standard 60 or Standard 70 Books 2 and 3 message formats are used.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 4

FOREWORD 1 June 2007

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 5

INTRODUCTION 1 June 2007

INTRODUCTION

The automation of credit and debit card transactions at the point of sale has been growing in
scale since the early 1980's. APACS has been at the forefront in setting standards covering
terminals, messages communications etc, which has greatly facilitated this expansion.

The previous APACS point of sale standards (numbered 29-4, 30, 40, 50 and the Common
Attachment) had been developed individually, over different timescales, to meet specific
operational requirements. As such they varied considerably in scope and functionality, whilst
still supporting the same basic business transactions (e.g. sale, refund cash advance etc).

Users tended to talk about APACS XX or APACS YY as if they were interchangeable. This
was misleading as they varied considerably in scope, as well as supporting different
operation environments. Table 1 — APACS standards functional comparison summarises
the major functional differences and Table 2 — APACS standards message flows shows the
different message flows (Standard 60 is included to show the whole picture).

Table 1 — APACS standards functional comparison


Functions 30 40 50 29-4 60
Device specification Y N N N N
POS Application specification Y Y N N N
Communications protocol Y Y Y N N
Message protocol Y Y Y Y Y
Message formats Y Y Y Y Y
Security protocol N Y X N X
Note: X indicates that the standard does not define, but does not preclude a security
protocol being implemented within the messages defined.

Table 2 — APACS standards message flows


Standard Initiation request Purpose Transaction level
30 From POS to acquirer Authorisation One transaction per message, real time
40 From POS to acquirer Authorisation and One transaction per message, real time
capture
50 From acquirer to POS Capture Batch of transactions per connection
post-event
29 From card acceptor to Capture File of transactions post-event
acquirer
60 Bi directional Authorisation and All options concurrently
capture

Whilst the standards were originally developed to meet individual specific business needs,
some have been integrated together in devices to meet developing requirements. Thus,
elements of Standard 30 had been implemented in post-event POS terminals and EPOS
systems (where the data capture elements were supported by either Standard 50 or
Standard 29-4).

With the growing proliferation of new ways to use a card (e.g. electronic commerce, mobile
commerce, mobile phone top up etc) and new technologies such as chip and PIN the
maintenance of these multiplicity of standards became ever more onerous.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 6

INTRODUCTION 1 June 2007


Early in 2003 APACS decided that a fundamental review of the current standards was
required. This was undertaken and it was decided that a new linked set of documents should
be produced, each focussing on a specific area. The objective being that users could mix
and match from the individual documents to meet their specific requirements

The Standard 70 series of documents is the result. It was originally based on level 18 of the
existing APACS point of sale standards. Nothing in the first version of Standard 70 changed
any of the requirements detailed in those documents. Users of the previous standards
should still be compliant with the October 2004 version of Standard 70. In theory each
document is completely stand-alone. The messages defined in Book 2 make no assumption
as to what communications will be used, nor the means by which a terminal has been
configured. Likewise the communications defined in Book 4 make no assumptions as to the
specific purpose of the messages sent by any of the communications options.

In reality, of course, such ultimate flexibility cannot readily be achieved. Acquirers, card
acceptors and terminal providers all have limitations as to what they can support. New users
of Standard 70 will need to discuss with their acquirers the options that they can support
(and are willing to type approve) before committing to any specific developments.

To facilitate clarity of description and definition Standard 70 is drafted on the basis that the
card acceptor end point will be a single terminal and the acquirer end point will be a
computer system of some sort. It is recognised that this is a narrow definition and in practice
the card acceptor end point is often an integrated EPOS system (fronting many terminals) or
even a mainframe computer fronting several outlets each with many terminals. However to
try and reflect this through out the documents would be confusing so the style is to refer to a
single terminal, acknowledging that in practice the acquirer may not be in direct contact with
an individual terminal.

To aid clarity, the following conventions are followed within this document:

a) Data element names (as used in messages) have the first letter capitalised,

b) Data element names (as used in messages) are shown in italics except when used in
tables or figures.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 7

PART 1: SCOPE 1 June 2007


1 SCOPE

This book of Standard 70 specifies the processes and procedures that shall be applied when
a terminal or EPOS system has determined that a payment card is to be used to complete a
transaction at a point of sale (POS).

It specifies the mandatory, optional and conditional tasks that shall be carried out in order to:

a) select the appropriate transaction type,

b) capture the card data,

c) capture the transaction data,

d) validate the cardholder,

e) authorise the transaction,

f) print and display any relevant messages or vouchers,

g) submit the transaction for settlement.

Together these constitute the business rules that shall be applied to all transactions involving
a payment card. The sequence in which these tasks are executed is not fixed but varies
depending on the card technology being used in any particular transaction and the terminal
design employed by the manufacturer.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 8

PART 1: SCOPE 1 June 2007

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 9

PART 2: NORMATIVE REFERENCES 1 June 2007

2 NORMATIVE REFERENCES

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

Access Prohibited? Information for Designers of Public Access Terminals - Dr. John Gill
(ISBN 1 86048 014 4 May 1997 - published by the RNIB)

Access to ATMs UK Design Guidelines. (Available from Centre for Accessible


Environments Tel +44 20 7357 8182 email cae@globalnet.co.uk

DDA Disability Discrimination Act(1995) with subsequent amendments

ISO 7811-2 Identification cards – Recording techniques – Part 2 Magnetic stripe –


Low coercivity.

ISO 7812-1 Identification cards – Identification of issuers – Part 1: Numbering


system.

ISO 7813 Identification cards – Financial transaction cards.

ISO 7816 Identification cards – Integrated circuit(s) cards with contacts.

ITU-T V22bis 2400 bits per second duplex modem using the frequency division
technique standardized for use on the general switched telephone
network and on point-to-point 2-wire leased telephone-type circuits.

ITU-T X.25 Interface between Data Terminal Equipment (DTE) and Data Circuit-
terminating Equipment (DCE) for terminals operating in the packet
mode and connected to public data networks by dedicated circuit.

ANSI X9.19 Financial institution retail message authentication.

ANSI X9.8 Banking – Personal identification number management and security –


Part 1 PIN protection principles and techniques for on-line PIN
verification in ATM and POS systems.

ANSI X3.92 Data Encryption Algorithm – DES.

EMV Integrated Circuit Card Specification for Payment Systems (see


www.emvco.com).

PCI:DSS Payment Card Industry: Data Security Standards

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 10

PART 2: NORMATIVE REFERENCES 1 June 2007

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 11

PART: 4 SYMBOLS (AND ABBREVIATED TERMS) 1 June 2007


3 TERMS AND DEFINITIONS

acquirer financial institution (or its agent) which acquires from the card acceptor
the data relating to a transaction and initiates that data into an
interchange system
card acceptor party accepting the card and presenting transaction data to an acquirer
card issuer financial institution (or its agent) which issues the financial transaction
card to the cardholder
data capture act of collecting the details of a financial transaction
dataset set of data elements logically grouped together, stored in a terminal to
control its actions during transaction processing
interface device that part of a terminal in which the IC card is inserted including such
(IFD) mechanical and electrical devices that may be considered part of it
message set of data elements used to exchange information between a card
acceptor and an acquirer
Note: No communications (header/trailer, protocol or character code) or
security implications are assumed
off-line process of verifying a cardholders PIN within an IC card
on-line process of verifying a cardholders PIN with the card issuer
open to buy a figure calculated by the card issuer to calculate the remaining
balance/available credit on cardholder’s account, taking into account all
authorisations
post-event not connected to an acquirer’s computer or data communications network
capture for transaction submission at the time the cardholder transaction takes
place
proximity that part of a terminal that connects using radio frequencies to the IC card
coupling device including such mechanical and electrical devices that may be considered
(PCD) part of it
real-time connected to an acquirers computer or data communications network for
transaction submission at the time the cardholder transaction takes place
standards group set up by the APACS Acquirer's POS group to manage the
management development of APACS POS standards
group (SMG)
terminal combination of hardware and software that together processes a financial
card transaction
Note: The hardware and software need not all be resident in the same
physical housing (i.e. may be split between a counter device and a
back office system) but shall operate as a cohesive entity when
processing card based transactions.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 12

PART: 4 SYMBOLS (AND ABBREVIATED TERMS) 1 June 2007

transaction one or more related messages within the same message class designed
to complete (insofar as this is possible) the intention of the sender of the
original message

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 13

PART: 4 SYMBOLS (AND ABBREVIATED TERMS) 1 June 2007


4 SYMBOLS AND ABBREVIATED TERMS

Abbreviations when used within this document have the following meanings:

ATM Automated teller machine


Auth. Authorisation
AVS Address Verification Services
CAT Cardholder activated terminal
CSC Card security code
CVM Cardholder verification method
DTMF Dual tone multi frequency
EPOS Electronic point of sale
FD Field divider
FS Field separator
HCF Hot card file
IC Integrated circuit
IFD Interface device
IIN Issuer identification number
LRC Longitudinal redundancy check
MAC Message authentication code
MSR Magnetic stripe read
NUA Network user address
PABX Private automatic branch exchange
PAD Packet assembler/disassembler
PAN Primary account number
PCD Proximity coupling device
PIN Personal identification number
POS Point of sale (also known as point of service)
PSTN Public switched telephone network
PWCB Purchase with cashback
STD Subscriber trunk dialling
TVD Transaction variable data

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 14

PART: 4 SYMBOLS (AND ABBREVIATED TERMS) 1 June 2007

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 15

PART 5: POS ENVIRONMENTS 1 June 2007

5 POS ENVIRONMENTS

Today the POS environment is hugely complex and varied. Over the years, very many
different configurations of hardware and software have been developed to meet the
requirements of card acceptors operating in radically different business environments.
Clearly the needs of a petrol station (usually with a single terminal) or a small family run
business will not be the same as those of a department store or a supermarket with multiple
points of sale and many terminals.

Despite this diversity all such systems are required to meet basically the same requirements
when processing financial transaction cards. Whilst the initial phases of a transaction will of
necessity be very similar (as will the authorisation process) the actual methods or
transaction capture and submission can and do vary. The benefits of following the APACS
standards as closely as possible are:

a) easier staff training and recruitment,

b) more confidence (and less queries) by cardholders in the processes being followed.

Through the use of the APACS POS standards the range of POS automation options has
been streamlined and today can be summarised as:

a) integrated EPOS systems (card acceptor owned) where the capture and submission
of transaction details is post-event but any authorisation required is undertaken in
real-time. The authorisation shall be undertaken using the authorisation messages as
defined in Standard 70 Book 2 or Standard 60 and the capture and submission of
transactions shall be undertaken using messages as defined in Standard 70 Book 3
or Standard 60,

b) standalone terminals (usually bank owned) where the capture and submission of
transaction details is post-event but any authorisation required is undertaken in real-
time. The authorisation shall be undertaken using the authorisation messages as
defined in Standard 70 Book 2 or Standard 60 and the capture and submission of
transactions shall be undertaken using messages as defined in Standard 70 Book 3
or Standard 60,

c) standalone terminals (usually bank owned) where both the authorisation, capture and
submission of transactions are undertaken in real-time. The authorisation shall be
undertaken using the financial presentment and reconciliation messages as defined
in Standard 70 Book 2 or Standard 60 where the capture and submission of
transactions is undertaken by the acquirer as an integral part of the authorisation
process.

The requirements that APACS places on these environments are different and these
differences are highlighted in this document.

There are still terminals and EPOS systems in card acceptors that have no authorisation
capabilities or have the authorisation supplied by a separate terminal or by a manual
telephone call. This document does not specifically address these terminals, as they will be
progressively replaced, as part of the implementation of PIN and IC cards.

This document therefore assumes that all terminals will have an authorisation capability but
leaves the methods of transaction capture and submission open to card acceptor's choice
(within the range of options specified in Standard 70). Manufacturers or card acceptors

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 16

PART 5: POS ENVIRONMENTS 1 June 2007


wishing to develop or install a terminal without an authorisation capability shall still abide by
the non-communications aspects of this document but will need to seek approval from their
acquirer before installing such terminals.

For integrated EPOS systems a minimum hardware configuration is assumed (otherwise


transactions could not be processed) however the actual way these components are linked
together is a matter for the card acceptor, subject to type approval by the acquirer. For real-
time terminals the requirements are much more stringent due to the nature of the transaction
key security system and acquirer capture and reconciliation processes.

Individual acquirers may have requirements over and above the minimum requirements
defined in this document. Terminal suppliers and card acceptors shall ensure that any
terminal or EPOS system they intend to deploy meets the requirements of their acquirer.

5.1 Data Security

This standard does not address specific card scheme requirements regarding the security
and storage of data between authorisation and settlement nor any limitations on the data to
be stored.

Schemes and acquirers shall mandate such requirements separately in, for example PCI:
DSS, and consideration must be given to such specifications when designing and
implementing any solution.

Specifications may include restrictions on data to be retained and force encryption of data
“in-flight” or “at rest”.

5.2 EMV Certification

5.2.1 General

Any newly developed POS or EPOS terminal shall be certified to EMV 4.1. A newly
developed PED, which shall be certified to EMV 4.1, may be connected to an existing
terminal with EMV 3.1.1 (EMV 96) Type Approval.

Note: EMV certification is additional to the PED certification detailed in Standard 70 Book 5

5.2.2 EMV level 1 (hardware) certification

The IFD interface shall be certified at an EMV approved certification laboratory. See the
EMV website at (www.emvco.com) for a current list of approved laboratories.

5.2.3 EMV level 2 certification

Terminal and PED certification shall be completed at an approved certification laboratory.


Kiosk/UPT and EPOS systems with built in or attached PEDs shall also be certified to Level
2. Rules of certification for these are available from EMV. Details may be found on the EMV
website (www.emvco.com).

American Express assumes EMV Level 1 and Level 2 compliance as a platform for building
American Express EMV functionality. Further details on American Express EMV certification
can be found by registering at their website
(www.americanexpress.co.uk/merchant/chipandpin).

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 17

PART 5: POS ENVIRONMENTS 1 June 2007


The EMV application kernel is also to be tested for JCB chip acceptance. Such tests shall be
carried out directly between the terminal manufacturer and JCB. For details of testing,
please contact JCB International (Europe) Ltd.

The list of terminals that have already passed JCB certification can be downloaded from the
following JCB website: (www.jcb-global.com/english/solution/jsmart/menu.html).

The design of the PED, the POS terminal, its operating environment and the use of a PIN at
the POS shall be developed taking note of the requirements of the Disability Discrimination
Act 1995 and subsequent amendments. The Act places a legal requirement upon the
providers of goods and services not to discriminate against people with special needs.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 18

PART 5: POS ENVIRONMENTS 1 June 2007

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 19

PART 6: BUSINESS RULES 1 June 2007

6 BUSINESS RULES

6.1 General

Regardless of the technology of the card proffered by the cardholder, and the cardholder
verification method chosen, there are a number of broad phases to a transaction that have
to be executed before a transaction can be considered complete i.e.:

a) select the appropriate transaction type,

b) capture the card data,

c) process the card data,

d) capture the transaction amount,

e) validate the cardholder,

f) authorise the transaction,

g) print and display any relevant messages or vouchers,

h) submit the transaction for settlement.

The order that these phases are completed depends on the card reading technology used
in any particular transaction and the particular configuration of the terminal or EPOS
system.

In order to better understand the operation of a terminal, a typical transaction is described,


along with a number of alternative courses of action where:

a) an IC is the method of data input (see section 6.2 IC card process),

b) the proximity card is the method of input (see section 6.3 Proximity card process),

c) the magnetic stripe is the method of data input (see section 6.4 Magnetic stripe
process),

d) the terminal keyboard is the method of data input (see section 6.5 Key entry
process).

This is not definitive but is presented as a background against which to view the detailed
requirements. Terminal manufacturers and card acceptors need not be bound by this
sequence.

The options available for exception processing (e.g. reversals), for industry specific
operating environments (e.g. unattended terminals), and for dynamic currency conversion
are also presented.

No specific assumption is made as to the particular type of terminal being used, however a
basic set of hardware and software facilities shall exist or transactions cannot be processed
in a manner defined by these Standards. The minimum hardware facilities are defined in
Appendix A, and the software facilities in Appendix B.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 20

PART 6: BUSINESS RULES 1 June 2007


The specific choice of hardware components and software design has implications on
transaction timing. The impact of the use of an IC card and PIN on the time a transaction
takes to complete, as perceived by the cardholder, shall be no greater than that for a
magnetic stripe transaction. For further guidance on this requirement refer to Appendix C.

Despite the use of the word “shall”, specified message displays are intended to show
minimum requirements and may be expanded upon if space permits on the card acceptor
and cardholder displays, subject to not losing the meaning of the message or its clarity. For
more guidance on the use of messages refer to Appendix D.

6.2 IC card process

6.2.1 Scope

A card acceptor with its own EPOS system may adapt the prompt sequences in order to
meet its own policies and environments. However, in order to ensure a common cardholder
experience, it is strongly recommended that the cardholder view and cardholder prompts be
followed as closely as possible.

6.2.2 Displays used in transactions

The terminal shall have at least one display to provide prompts, guidance and feedback to
the card acceptor and / or cardholder. Where two displays are provided the card acceptor
display shall provide more detail of the transaction process to allow them to assist the
cardholder. The actual card acceptor prompts displayed may vary but shall prompt at key
points within the transaction for example to ‘SELECT PAYMENT TYPE’, ‘PIN ENTRY’ or
question if an option is required ‘CASHBACK?’.

In the same way the cardholder shall be prompted at key points where action is required for
example ‘INSERT CARD’, ‘ENTER PIN’ and ‘REMOVE CARD’. At the point where on-line
transaction processing occurs the cardholder display shall display ‘PLEASE WAIT’ and
preferably provide an indication of transaction process by showing some form of changing
subsidiary prompt. The cardholder display shall not change from the ‘PLEASE WAIT’ or
equivalent display until the final outcome of the transaction is known to avoid cardholder
confusion.

6.2.3 Transaction selection

The card acceptor shall identify which of the available transaction types is required.
Pressing the appropriate key or selecting from a menu of options can achieve this. A 'sale'
transaction shall be the default transaction. The terminal shall display ‘INSERT CARD’.

6.2.4 Capture card data

The acceptance of an IC card is enabled through the use of an interface device (IFD). A
maximum of three attempts to read an IC shall be permitted (a first attempt and 2 retries).
The terminal shall respond to the first and second unsuccessful attempts by displaying
’INSERT AGAIN’. After the third unsuccessful attempt the terminal shall prompt the card
acceptor to revert to reading the magnetic stripe as the fallback option (see Appendix E).
This is known as technical fallback and support for technical fallback is mandatory.

Any IC transaction that falls back to reading a magnetic stripe shall not be authorised locally
by the terminal.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 21

PART 6: BUSINESS RULES 1 June 2007


The card acceptor shall revert to reading the magnetic stripe as the fallback option if either
no known application is present or if the card becomes unreadable at some point in the
transaction.

Technical fallback cannot take place if the card is blocked, all applications present are
blocked or if the chip transaction has already been declined.

6.2.5 Process card data

6.2.5.1 Application selection

6.2.5.1.1 Coding of application data file (ADF)

The coding of the ADF within the payment system’s directory of the IC is detailed in EMV.
The EMV specification refers to an optional data element, the 'application priority indicator'
(Tag 87). As detailed in EMV the terminal may select the application with the highest
priority without the requirement for the cardholder confirmation. This is the recommended
action for terminals unless card schemes mandate otherwise.

6.2.5.1.2 Terminal selection of application

In selecting the application, terminals shall follow the sequence described in EMV. Step 3 of
the selection sequence allows two choices where there are two or more applications
supported by both the IC and the terminal.

The EMV preferred option (step 4) is to offer the cardholder a list of mutually supported
applications, in priority order (e.g. 1 UK Maestro, 2: Maestro International) and invite the
cardholder to make a selection.

The second option (step 5) is for the terminal to select the highest priority application, which
will be UK Maestro and not Maestro International in the example above. This option shall
only be used if the terminal does not support application selection.

In order to offer UK cardholders a user-friendly transaction process terminals may use


business rules when building their candidate lists. For example, the terminal can have a rule
'if a domestic debit application (e.g. UK Maestro) is in the list, then ignore any international
debit (e.g. Maestro International) application'. This approach can also be used to ensure
that a V-PAY application is selected in preference to an Electron application, when
processing a Visa card.

This can only be done if the building of the candidate list is outside the EMV kernel. It is
recommended that wherever possible, business rules are handled outside of the EMV
kernel, so that if rule changes are required there will be minimal need for re-certification.

6.2.5.2 Multi-application cards and application selection

6.2.5.2.1 General

Suppliers need to plan for how they will handle multi-application cards when they are
presented. For the examples below the card presented is assumed to have three
applications; a credit application, a debit application and an electronic purse that are
defined with this priority order, and the terminal supports all of these.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 22

PART 6: BUSINESS RULES 1 June 2007


6.2.5.2.2 Card acceptor selection

If the card acceptor has a PINPAD with a limited display they could opt to ask the
cardholder which method of payment the cardholder wants to use and select it for them. In
this case the card acceptor display could be as Figure 1 — Card acceptor selection, limited
display.

Method of Payment?

Credit

Debit

Purse

Figure 1 — Card acceptor selection, limited display

When the card acceptor selects the method of payment then the PINPAD shall display the
option that has been chosen for the cardholder to confirm when entering the PIN (if
required). The PINPAD display for a debit card purchase could therefore be as Figure 2 —
Card acceptor selection, PINPAD display.

Debit Card
£25.35

ENTER PIN

Figure 2 — Card acceptor selection, PINPAD display

6.2.5.2.3 Cardholder selection

The cardholder could select the application as shown to them on the PINPAD display. How
they are selected will depend on the capabilities of the PINPAD display. So for a multi-line
display the information displayed could list all the applications with a numbered selection,
see Figure 3 — Cardholder selection, multi-line display.

Select Payment Type

1. Credit

2. Debit

3. Purse

Figure 3 — Cardholder selection, multi-line display

Where the display is limited to two lines of sixteen characters a scrolling display method
could be used, see Figure 4 — Cardholder selection, scrolling display.

Pay by Credit

Yes = E No = C

Press Cancel

Pay by Debit

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 23

PART 6: BUSINESS RULES 1 June 2007

Yes = E No = C

Press Cancel

Pay by Purse

Yes = E No = C

Figure 4 — Cardholder selection, scrolling display

The display would scroll round credit, debit and purse and back to credit on each press of
the 'cancel key' until the 'enter key' is pressed.

With both displays the method of payment selected shall be confirmed to the cardholder
when the amount is shown for PIN entry or acceptance in the case of a purse transaction,
see Figure 5 — Cardholder transaction acceptance.

Debit Card
£25.35

ENTER PIN

Figure 5 — Cardholder transaction acceptance

6.2.5.3 Transaction type validation

The terminal shall check that the type of transaction selected is consistent with the
parameters in the IC of the card presented. The geographic usage and services allowed are
determined by the application usage control in the IC application, which is independent from
the IIN on the card. If the type of transaction selected is not permitted the terminal shall
display 'REQUEST INVALID'.

6.2.6 Capture transaction amount

When the card details have been entered successfully, the terminal shall prompt the card
acceptor to enter the transaction value (by displaying 'ENTER AMOUNT'). The amount shall
be entered in the smallest denomination of the currency being used (for example in pence
for sterling transactions) and its completion shall be signified by depression of the enter key.
The entered digits shall be displayed with a decimal point separating the currency unit and
lowest denomination of the transaction currency. The terminal shall prevent the entry of
more than 11 numerical digits for the amount.

An amount of zero is not necessarily incorrect e.g. in a balance enquiry. However, terminals
shall not allow a zero amount to be entered by default, i.e. it shall be a deliberate act by the
card acceptor.

If an amount is entered that is greater than the appropriate amount ceiling limit (based on
terminal configuration data) the terminal shall halt the transaction and display a meaningful
message.

Purchase with cashback (PWCB) is a card acceptor option whether to offer the service and
if so how it is offered. Maximum cashback limits are negotiated between the card acceptor
and the acquirer and are therefore a terminal parameter.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 24

PART 6: BUSINESS RULES 1 June 2007


Where cashback is taken it is preferable for the cash element to be displayed separately to
the cardholder before PIN entry. However, the total (purchase + cashback) shall be
displayed prior to PIN entry. Regardless of whether the cash element is displayed it shall be
shown on any cardholder voucher.

6.2.7 Cardholder verification

6.2.7.1 General

Cardholder verification is required for financial transactions (except refunds, reversals or


when the cardholder is not present) but not for authorisation only transactions, unless it is
part of a check-in process. The type of verification depends upon the configuration of the
terminal and the requirements of the card issuer as defined in the IC and shall be prompted
for once the card and transaction details have been successfully entered.

For refunds, cardholder verification is optional, permitted by bi-lateral agreement (see


section 6.9.4.5 Cardholder verification for refunds).

6.2.7.2 Cheque guarantee cards

The treatment of cheque guarantee cards is presently outside the scope of UK IC card and
PIN processing. However, the presentation of multifunction cards (i.e. debit/credit, ATM and
cheque guarantee), at a terminal could lead to a degree of confusion for both card acceptor
and cardholder.

The current process using cheque guarantee cards involves the cashier:

a) selecting 'cheque' as the method of payment;

b) swiping the magnetic stripe on the payment card to obtain its details which can then
be used to enable:

1. printing of the card details on the back of the cheque, thereby satisfying the
cheque guarantee scheme requirement;

2. checking against a hot card file (HCF);

3. seeking authorisation from a cheque guarantee service provider.

The information required to successfully complete the cheque transaction is held on 'track 2'
of the magnetic stripe. This information is also held in the 'track 2 equivalent data' data
element in the public area of the IC.

Many IC cards will not deliver the ‘track 2 equivalent data’ data element without an
application being selected, it is recommended that card acceptors continue to swipe cards
and use the magnetic stripe data for cheque guarantee purposes.

If the card acceptor selects a cheque verification function, the terminal shall prompt CHECK
SIGNATURE but there is no requirement for any signature validation confirmation on the
terminal.

6.2.7.3 Processing Terminal Capabilities

For UK attended (including semi-attended) points of sale, the terminal shall support the
following Cardholder Verification Methods (CVMs):

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 25

PART 6: BUSINESS RULES 1 June 2007


a) Off-line encrypted PIN,

b) Off-line plaintext PIN,

c) Signature (see section 6.4.7.4 Signature validation),

d) No CVM.

For unattended points of sale, signature is not a valid CVM and shall not be supported.

It is possible to send a PIN to the card issuer (via the acquirer) for authentication; where the
PIN is encrypted by a separate key (see Standard 70 Book 5). This facility can only be
supported in acquirer capture of transactions using the financial presentment message
class messages as defined in Standard 70 Book 2 or Standard 60.

Note: This facility is not supported in the UK where only PIN verification to an IC card is
permitted.

6.2.7.4 PIN input

If the IC requests PIN entry, the terminal allows cardholder verification by PIN.

If the PIN Entry Device is inoperative, the TVR shall record that 'PIN entry required and
PINPAD not present or not working'.

6.2.7.5 PIN retries

Where the cardholder has problems entering their PIN, prompts are required to guide the
card acceptor and cardholder to allow for correction of the PIN. When an incorrect PIN is
entered, the terminal shall display ‘INVALID PIN’, and the cardholder shall be prompted
either to abort or to retry PIN entry. Under these circumstances the card acceptor shall have
similar displays to allow them to both know how the transaction is progressing and provide
assistance to the cardholder if required.

6.2.7.6 PIN bypass

6.2.7.6.1 Provision of PIN bypass

Provision of the PIN bypass facility is optional within EMV and is the card acceptor decision
for integrated EPOS systems and an acquirer decision for bank-owned terminals. If
supported the function shall be configurable. It is provided to cater for a situation where the
cardholder cannot remember their PIN or may temporarily not be able to enter the PIN. In
this case the card acceptor would have the option to bypass PIN entry and enable the IC
and terminal to process the next CVM, which may be signature.

Using PIN bypass reduces both the fraud prevention and operational benefits of using PIN.

PIN bypass shall only be able to be performed if:

a) the terminal is configured to provide the facility;

b) the card acceptor agrees to support it;

c) the card’s CVM list allows another CVM to be performed;

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 26

PART 6: BUSINESS RULES 1 June 2007


d) the function is allowed in this environment.

6.2.7.6.2 Implementation of PIN bypass

CVM fallback from off-line PIN to signature may be provided where both the terminal and
card support off-line PIN and signature.

It is recommended that a special key be provided or a combination of key depressions used


to initiate bypass and that it may be configured either to require a supervisor card/password
to be used to enable the bypass or to allow the card acceptor to initiate the bypass without
other authority.

Where the card does not permit fallback to signature through the CVM list settings, or
signature is not supported, the terminal shall advise the card acceptor that PIN bypass is
not permitted and prompt the card acceptor to confirm before cancelling the transaction
(e.g. an 'off-line decline' message is sent to the card).

In respect to the use of PIN bypass the TVR shall record that ‘PIN entry required, PINPAD
present, but PIN was not entered’.

Some card acceptors may elect to maintain this functionality for exceptional situations or to
serve disabled cardholders. For example it is probable that a cardholder confined to a
wheelchair will be able to use the PINPAD in most face-to-face ‘in-store’ transactions. This
probably will not be the case at petrol stations, where the cardholder will still require a
member of staff to collect their payment card, produce a ‘fallback’ signature voucher and
return this to the cardholder to sign.

6.2.7.7 PIN Locked

During the course of the current or a previous transaction the PIN on the card may have
become locked. Depending on the configuration of the card it may be possible to continue
to use it as a chip and signature card. The card issuer, however, may at some stage decide
to decline transactions that are sent on-line where the PIN has become locked.

To assist the cardholder to take steps to unlock the PIN it is recommended that they are
advised at the end of the transaction that the PIN is locked by use of either or both a
displayed message and a comment on the cardholder receipt. At the end of the transaction
the PINPAD shall display ‘REMOVE CARD’/’PIN LOCKED’ or ‘REMOVE CARD’/’PIN
LOCKED’/’CALL CARD ISSUER' if display space is available. “PIN Locked Call Card
Issuer” may be printed on the cardholder receipt immediately after the retention reminder.

6.2.8 Issuer and terminal action codes

Issuer action codes (IACs) are set in the IC by the card issuer and the terminal action codes
(TACs) are set by the acquirer/card acceptor. These settings are used by the terminal as
part of terminal risk management to determine whether a transaction shall be declined
locally, sent real-time to the acquirer for authorisation or whether to allow the transaction to
proceed locally.

6.2.9 Premature card removal

If the cardholder or card acceptor removes the card before the transaction is complete with
the IC (i.e. the TC or AAC has not been received from the card), the transaction shall
always be cancelled.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 27

PART 6: BUSINESS RULES 1 June 2007


If an authorisation has taken place (i.e. an ARQC has been sent and an ARPC is received),
and if the acquirer and transaction type support reversals, a reversal message shall be
sent.

If it is not possible to send a reversal message, then the transaction shall be voided and no
settlement data shall be sent.

6.2.10 Terminals with no real-time capability

Terminals in most environments have the ability to seek a real-time authorisation and the
EMV process expects the terminal to seek an authorisation when the card requests it.
There are a few environments where it is impractical or not cost-effective to support real-
time authorisation. These environments include on board trains, ferries, ships, aircraft and
submarines.

These terminals will identify their ‘type’ to cards as 'off-line only' and shall have their EMV
terminal type set to ‘off-line only’. Operators should be aware that some IC Cards might
decline the transaction at the 1st Generate AC when a TC is requested and procedures shall
be established to deal with this.

Even though the terminal identifies itself to the card as off-line only a card may return an
ARQC in error at the 1st Generate AC. If this is the case the transaction shall be processed
as described in section 6.6.4 Local processing by the terminal after a call failure.

6.2.11 Unable to do a real-time authorisation

6.2.11.1 General

Whatever the technology at the POS there is, inevitably, a percentage of downtime with any
communication system; this may be attributed to the card acceptor, acquirer or network
provider. During these times, the card acceptor may apply a 'post-comms' floor limit and
accept transactions up to that floor limit.

With an EMV transaction, if the result of terminal risk management is to seek an


authorisation, the terminal will seek an ARQC from the card. If the card acceptor is unable
to contact the acquirer, then the terminal has to determine the response to send to the card
(see section 6.6.4 Local processing by the terminal after a call failure).

6.2.11.2 Cardholder messaging

Messages to cardholders and card acceptors shall not overtly indicate that the system is
unable to conduct real-time messages. In a small number of cases (usually for high value
transactions) a supervisor approval or voice authorisation may be required.

A terminal shall not display the message returned from the card acceptor or acquirer
system until the final outcome of the transaction is known to prevent contradicting
messages being displayed for example ‘unable to authorise’ being followed by the
transaction being accepted.

6.2.11.3 HCF Checking

If the only check that will be carried out, at a system remote from the point of sale, is a hot-
list check (and there is no intention to seek a real-time authorisation) then the terminal shall
request a TC (unless these are other reasons for seeking an ARQC) as in nearly every
case the result of the terminal risk management will remain unchanged.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 28

PART 6: BUSINESS RULES 1 June 2007


If it is ascertained that the card is on the hot-list, then the current transaction shall be
declined and a new transaction initiated with the hot-list flag set. This will normally result in
an authorisation request with the appropriate flag set, and will avoid the possibility of the
transaction being authorised in stand-in mode by the acquirer or card scheme.

6.2.11.4 EPOS systems

For card acceptors with EPOS systems where a single floor limit (i.e. 'pre-comms' only) is in
operation, then this processing is not required. However where the card acceptor seeks to
apply a 'post-comms' floor limit, the transaction shall be processed as described in section
6.9.5.1 IC card stand-in processing.

6.2.11.5 Completion at card acceptor risk

Where the card acceptor wishes to accept transactions at its own risk under the 'post
comms' floor limit, it may inspect the terminal verification results to ensure that there are no
conditions existing under which it would not wish to accept the transaction (for example,
'card acceptor forced on-line' or 'cardholder verification failure').

TVR values that should normally result in a decline are:

byte 1 – bit 3: Combined DDA / Gen AC failed,

byte 1 – bit 4: off-line DDA failed,

byte 1 – bit 5: card on hot list,

byte 1 – bit 6: ICC data missing,

byte 1 – bit 7: SDA failed,

byte 1 – bit 8: off-line data authentication not performed,

byte 2 – bit 5: requested service not allowed for card product,

byte 2 – bit 6: application not yet effective,

byte 2 – bit 7: expired application,

byte 3 – bit 6: PIN try limit exceeded,

byte 3 – bit 8: cardholder verification unsuccessful,

byte 4 – bit 4: card acceptor forced on-line (i.e. suspicious),

byte 4 – bit 6: upper consecutive off-line limit exceeded.

6.3 Proximity card process

6.3.1 Scope

6.3.1.1 General

Proximity cards (also known as Contactless cards) encompass a wide range of products
and standards.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 29

PART 6: BUSINESS RULES 1 June 2007


6.3.1.2 Electrical and protocol standards

For proximity cards these determine how the power is coupled into the card from the
antenna, how communications are established with the card, and what protocols are used
to avoid collisions (where there are multiple cards in the field). The most widely used
standards for contactless cards are variants of the ISO 14443 standard (proximity cards) –
these include the ISO 14443A standard used by MiFare™ memory cards as well as ISO
14443B, which is the basis of the MasterCard Paypass specification. JCB and Visa have
licensed the PayPass 14443 specification from MasterCard.

In addition ISO 10536 defines a shorter range communications standard and ISO 15693
defines a “vicinity card” usable up to 1 metre. ISO 18092, published in 2004, defines the
“Near Field Communications” (NFC) interface for communications between devices such as
mobile phones and terminals; it leans heavily on ISO 14443A and Sony’s FeliCa™, another
proprietary system for contactless cards, which is widely used in the transport industry in
Asia. The method of communication between the cardholder device of whatever type, see
section 6.3.1.3 Form factors and formats, and the terminal is outside the scope of this
standard.

6.3.1.3 Form factors and formats

Although most proximity payment cards conform to the ISO 7811 ID1 card shape and size,
there are fewer limitations on these parameters for proximity cards; smaller sized cards,
key-tags and “buttons” are also used, while mobile phones may be fitted with the antennae
for NFC. In this standard the generic term proximity card is used to describe the cardholder
device regardless of the form factor.

6.3.1.4 Data and message formats

The simplest devices are known as “RFID tags” – they only transmit one piece of
information (an identification number) to the terminal. This ID number may be used to
access pre-registered account details stored on a host system.

The international card schemes currently offer two options: one with sufficient intelligence
on the card to transmit the equivalent of the magnetic stripe tracks 1 and 2, together with a
transaction counter and basic certificate which enhance the security of the system. The
other uses forms of the EMV protocols; each card scheme defines its own structure and
definition for these messages, for example qVSDC for Visa, PayPass MChip for
MasterCard, but they can all be transported over a standard EMV messaging system.

Again the data and message formats used between the cardholder device and the terminal
are outside the scope of this standard.

6.3.1.5 Payment product type

Proximity cards may be used for credit and debit transactions, either with or without
Cardholder Verification. In most cases it is felt that the advantages of using contactless are
not obtained if cardholder verification must also be sought. Most products using contactless
payment are for low value amounts and without cardholder verification.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 30

PART 6: BUSINESS RULES 1 June 2007

What data and


What payment
What form factor? What protocol? message
type?
standard?

Card (ID1) ISO 14443A or B Debit/Credit


RFID tags
Mini-card NFC Prepaid
Key-fob PayPass Pre-authorised debit
Wired-logic cards:
Button … other
MiFare, FeliCa,
Mobile phone
magstripe image
… other
EMV variants
(Card Scheme Specific)

Figure 6 - Options below illustrate the range of options

6.3.1.6 Proximity cards in Standard 70

As described in sections 6.3.1.3 Form factors and formats and 6.3.1.4 Data and message
formats there are variations in the types of cardholder device and the data supplied to the
terminal. This standard only deals with proximity cards that are able to supply sufficient
data, either the track 2 equivalent data or an EMV based application, to allow a payment
transaction to be constructed at the point of sale in a similar manner to an IC card with
contacts or magnetic stripe card.

6.3.1.7 Proximity cards only

For some operating environments the point of sale may support only proximity cards as a
means of payment i.e. IC contact and magnetic stripe transactions are not supported.

6.3.2 Displays used in transactions

There shall be a cardholder facing display associated with the proximity coupling device
[PCD] that shall show the amount of the transaction prior to the cardholder presenting their
proximity card to initiate payment.

It shall be clear to the cardholder whether reading the card data has been successful by the
use of visual and audible prompts. Specific displays and sounds demanded by particular
card scheme products to obtain certification are outside the scope of this standard.

6.3.3 Transaction selection

Transaction selection shall be as defined in the relevant card scheme specifications. There
may be specific restrictions applied to improve the speed of the transaction.

6.3.4 Capture card data

The terminal shall not limit the number of times that the proximity card is offered to the PCD
to try and initiate the transaction. The terminal shall ‘time-out’ after an agreed period if the
card has not been successfully presented and shall include an ‘escape’ facility to allow the
selection of alternative method of payment before the time-out period has expired if
required.

The method of payment (contact or contactless) will normally be selected automatically


using the business rules associated with the respective payment methods. However,

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 31

PART 6: BUSINESS RULES 1 June 2007


particularly where the PCD and the IC contact reader are integrated in the same device, the
terminal design shall take into account the possibility that the cardholder or merchant
wishes to override the default decision and, for example, carry out a contact-based
transaction even for a low value.

6.3.5 Process card data

6.3.5.1 Application selection

Application selection shall be as defined in the relevant card scheme specifications. There
may be specific restrictions applied to improve the speed of the transaction.

6.3.5.2 Transaction type validation

The terminal shall check that the type of transaction selected is consistent with the
configuration settings for the card presented for example purchase with cashback. If not the
terminal shall display 'REQUEST INVALID'.

6.3.6 Capture transaction amount

The final transaction amount shall be entered before the card is presented. It shall not be
possible to alter the transaction amount i.e. the Amount displayed to the cardholder shall be
the amount authorised and settled.

Otherwise, transaction amount capture shall be as described in section 6.2.6 Capture


transaction amount.

6.3.7 Cardholder verification

Cardholder verification shall be handled as described in scheme specifications.

6.3.8 Other comments about the process

Design of the terminal shall ensure that the transaction time experienced by the cardholder
is as fast as possible.

Card scheme rules currently state that a receipt shall be produced if requested by the
cardholder.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 32

PART 6: BUSINESS RULES 1 June 2007


6.4 Magnetic stripe process

6.4.1 Scope

Where the card acceptor has its own EPOS system the card acceptor may adapt the
sequences in order to meet its own policies and environments. However, in order to ensure
a common cardholder experience, it is strongly recommended that the cardholder view and
cardholder prompts be followed as closely as possible.

6.4.2 Displays used in transactions

Transaction
Amount known

Transaction Type or
Card Payment Selected Transaction Processed
including Authorisation

Operator Prompted
Voucher
for Card Swipre
Produced

Cardholder
Hands over Card Cardholder Signs
Voucher

Operator Performs
Visual Checks Operator Prompted
‘Check Signature’

Operator Operator Checks


Swipes Card Signature

Operator ‘keys
Operator Acknowledges
last four digits’
Signature OK

Receipt Produced,
Operator Prompted
Card Returned to
‘PLEASE WAIT’
Cardholder with receipt

Transaction
Complete

Figure 7 - Magnetic Stripe transaction

6.4.3 Transaction selection

The card acceptor shall identify which of the available transaction types is required.
Pressing the appropriate key or selecting from a menu of options can achieve this. A 'sale'
transaction shall be the default transaction. The terminal shall display ‘SWIPE CARD’.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 33

PART 6: BUSINESS RULES 1 June 2007


6.4.4 Capture card data

The acceptance of a magnetic stripe card is supported through the use of a magnetic stripe
reader. A maximum of three attempts to read a magnetic stripe shall be permitted (a first
attempt and two retries). The terminal shall respond to the first and second unsuccessful
attempts by displaying a meaningful message (see Appendix D). After the third
unsuccessful attempt, the terminal shall (subject to the acquirer allowing key entry as an
option) prompt the card acceptor to attempt the manual key entry of card data.

An attempted card swipe shall be rejected for any one or combination of the following
conditions:

a) no data present on track 2,

b) LRC check fail,

c) parity failure on one or more characters,

d) no start sentinel,

e) no end sentinel.

Note: These checks are normally performed by the hardware of the terminal.

Details of the contents and location of data on the magnetic stripe of cards will be provided
by each acquirer. For some cards additional checks than those specified below are required
to be performed. Advice shall be sought from the acquirer on the specifics of different card
schemes (see Appendix F).

6.4.5 Process card data

The following checks may be performed, depending on card scheme product requirements:

a) LUHN check; the final digit of the PAN may be a check digit (see Appendix G),

b) PAN length (based on terminal configuration data),

c) service code; the method of validation is described in Appendix I,

d) expiry date (valid limits are 01-12 for MM and 00-99 for YY). Presentation of an
expired card may require a voice authorisation call to be made depending on
acquirer requirements,

e) start date; a variety of methods exist to identify the start date. Advice shall be sought
from the acquirer on the specifics of different card schemes,

f) track length: track 2 may contain up to 40 characters, of which 3 are control


characters (start sentinel (SS), end sentinel (ES) and longitudinal redundancy check
(LRC)).

If any of the validation checks fail, the terminal shall display a clear and unambiguous error
message.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 34

PART 6: BUSINESS RULES 1 June 2007


The terminal shall check that the type of transaction selected is consistent with the
configuration settings for the card presented, using the IIN and the service code (see
Appendix F). If not the terminal shall display 'REQUEST INVALID'.

6.4.6 Capture transaction amount

When the card details have been entered successfully, the terminal shall prompt the card
acceptor to enter the transaction value (by displaying 'ENTER AMOUNT'). The amount shall
be entered in the smallest denomination of the currency being used (for example in pence
for sterling transactions) and its completion shall be signified by depression of the enter key.
The entered digits shall be displayed with a decimal point separating the currency unit and
lowest denomination of the transaction currency. The terminal shall prevent the entry of
more than 11 numerical digits for the amount.

An amount of zero is not necessarily incorrect e.g. in a balance enquiry. However, terminals
shall not allow a zero amount to be entered by default, i.e. it shall be a deliberate act by the
card acceptor.

If an amount is entered that is greater than the appropriate amount-ceiling limit (based on
terminal configuration data) the terminal shall halt the transaction and display a meaningful
message.

Purchase with cashback (PWCB) is a card acceptor option whether to offer the service and
if so how it is offered. Maximum cashback limits are negotiated between the card acceptor
and the acquirer and are therefore a terminal parameter.

6.4.7 Cardholder verification

6.4.7.1 General

Cardholder verification is required for financial transactions (except refunds, reversals or


when the cardholder is not present) but not for authorisation only transactions. The type of
validation depends upon the configuration of the terminal and shall be prompted for once
the card and transaction details have been successfully entered.

For refunds, cardholder verification is optional, permitted by bi-lateral agreement (see


section 6.9.4.5 Cardholder verification for refunds).

6.4.7.2 Cheque guarantee cards

If the card acceptor selects a cheque verification function the terminal shall prompt 'CHECK
SIGNATURE' but there is no requirement for any signature validation confirmation on the
terminal.

6.4.7.3 PIN validation

When using magnetic stripe cards it is possible to send a PIN to the card issuer (via the
acquirer) for authentication; where the PIN is encrypted by a separate key (see Standard 70
Book 5).

This facility can only be supported in acquirer capture of transactions using the financial
presentment message class messages as defined in Standard 70 Book 2 or Standard 60.

Note: This facility is not supported in the UK where only PIN verification to an IC card is
permitted.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 35

PART 6: BUSINESS RULES 1 June 2007


6.4.7.4 Signature validation

6.4.7.4.1 General

The terminal shall prompt the card acceptor to check the signature. If the signature is
satisfactory an appropriate key shall be pressed and the transaction shall complete once a
response has been received from the acquirer. If the signature is unsatisfactory an
alternative key shall be pressed and the transaction shall be ended with the terminal
displaying 'TRANSACTION VOID'.

For terminals configured to undertake only an authorisation (i.e. data capture is by another
terminal or method) there is no requirement for any signature validation confirmation to be
input to the terminal.

6.4.7.4.2 Delaying signature validation option

The facility is useful in applications where access to the terminal for signature is not
possible. Instead the voucher plus a copy are fed out of the terminal and are torn off
together for presentation to the cardholder for signing. The audit roll (if used) would not
contain the signature but the copy (presented along with the voucher) would, and shall be
stored by the card acceptor in case of later query.

If this facility is allowed, printing of the voucher and cardholder validation shall be delayed
until the transaction has been authorised either locally by the terminal, real-time by the
acquirer or after a voice referral. If the transaction is not authorised the terminal shall
complete the voucher without prompting for signature. If the transaction has been
authorised the terminal shall prompt for signature validation after the voucher has been
completed.

If the signature is satisfactory the terminal shall display any message from the acquirer held
pending until the result of the signature check is known. If the signature is unsatisfactory the
terminal shall display 'TRANSACTION VOID' and print a void voucher with
'CANCELLATION' clearly shown. This provides a record that the transaction has been
cancelled after the original voucher was printed.

6.4.7.4.3 Additional verification

Some acquirers may require additional verification for certain transactions (typically cash
advances) when a passport or driving licence needs to be checked by the card acceptor.
The authorisation response is sent with a relevant message being displayed on the
terminal. The validity of the authorisation is subject to the checking of the alternate ID of the
cardholder by the card acceptor.

6.5 Key entry process

6.5.1 Scope

In some instances the card acceptor may be able to enter card details via the keyboard
subject to the terminal and any IC card configuration settings e.g.;

a) following a magnetic stripe card swipe failure,

b) to input transactions completed manually (forced transactions),

c) when the cardholder is not present e.g. mail order.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 36

PART 6: BUSINESS RULES 1 June 2007


6.5.2 Displays used in transactions

Essentially this is the same as that defined in 6.4.2 Displays used in transactions with the
card acceptor keying the card data instead of swiping the card.

6.5.3 Transaction selection

The card acceptor shall identify which of the available transaction types is required.
Pressing the appropriate key or selecting from a menu of options can achieve this. A 'sale'
transaction shall be the default transaction. If the card details are to be entered via the
keyboard, the terminal shall display ‘KEY CARD NUMBER’.

6.5.4 Capture card data

The PAN shall be entered first as a number sequence terminated by pressing the enter key.

The following data elements embossed or printed on the front of the card may also be
entered via the keyboard:

a) expiry date,

b) start date,

c) issue number.

In addition, the Card Security Code (CSC) on the card may be entered (see section 6.5.7.4
Address/CSC verification).

Details of the data to be captured from the card and the checks to be performed will be
provided by each acquirer. Advice shall be sought from the acquirer on the specifics of
different card schemes (see Appendix F).

6.5.5 Process card data

When the PAN is entered, the following checks may be performed, depending on card
scheme product requirements (see Appendix F):

a) a valid IIN,

b) a PAN of the correct length,

c) a valid LUHN check digit (see Appendix G).

If these checks fail, a second input attempt shall be requested. After three failures, the
terminal shall halt the transaction and display the message 'CALL AUTH CENTRE'.

If the PAN is entered successfully, the terminal shall prompt for the entry of the expiry date
by displaying the message 'EXPIRES MM/YY' (subject to the to the terminal configuration
settings). The card acceptor shall key in the four-digit expiry date as embossed or printed
on the card. The terminal shall ensure that:

a) the month part is in the range of 01-12,

b) the year part is not more than 20 years hence.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 37

PART 6: BUSINESS RULES 1 June 2007


If manual entry of data is permitted but the expiry date is not required, then no prompt for
the entry of the expiry date shall be given.

If the expiry date checks fail, a second input attempt shall be requested. After three failures,
the terminal shall halt the transaction and display the message 'CALL AUTH CENTRE'.

If the expiry date is entered successfully the terminal shall prompt for the entry of the start
date by displaying the message 'VALID FROM MM/YY' (subject to the terminal
configuration settings). The card acceptor shall key in the four-digit number as embossed or
printed on the card. The terminal shall ensure that:

a) the month part of the date is within the range 01-12,

b) the year part is not more than 20 years previous.

If manual entry of data is permitted but the start date is not required, then no prompt for the
entry of the start date shall be given.

If the start date checks fail, a second input attempt shall be requested. After three failures,
the terminal shall halt the transaction and display the message 'CALL AUTH CENTRE'.

If the start date is entered successfully, the terminal shall prompt for the entry of the card
issue number by displaying the message 'ISSUE NUMBER' (subject to the terminal
configuration settings). The card acceptor shall key in the number as embossed or printed
on the card. The terminal shall ensure that the issue number is the correct length (the
acquirer shall provide the relevant data).

If manual entry of data is permitted but the issue number is not required, then no prompt for
the entry of the issue number shall be given.

If the card issue number checks fail, a second input attempt shall be requested. After three
failures, the terminal shall halt the transaction and display the message 'CALL AUTH
CENTRE'.

It is recommended that invalid input be given an audio signal for card acceptor
convenience.

The terminal shall check that the type of transaction selected is consistent with the
configuration settings for the card presented, using the IIN (see Appendix F). If not the
terminal shall display 'REQUEST INVALID'.

6.5.6 Capture transaction amount

The process is identical to that for a magnetic stripe read transaction (see section 6.4.6
Capture transaction amount).

6.5.7 Cardholder verification

6.5.7.1 General

Cardholder verification is required for financial transactions (except refunds, reversals or


when the cardholder is not present) but not for authorisation only transactions. The type of
verification depends upon the configuration of the terminal and shall be prompted for once
the card and transaction details have been successfully entered.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 38

PART 6: BUSINESS RULES 1 June 2007


For refunds, cardholder verification is optional, permitted by bi-lateral agreement (see
section 6.9.4.5 Cardholder verification for refunds).

6.5.7.2 Cheque guarantee cards

If the card acceptor selects a cheque verification function the terminal shall prompt 'CHECK
SIGNATURE' but there is no requirement for any signature validation confirmation on the
terminal.

6.5.7.3 Signature validation

The process is identical to that for a magnetic stripe read transaction (see section 6.4.7.4
Signature validation).

6.5.7.4 Address/CSC verification

In situations where the cardholder is not present (mail order, telephone order, e-commerce)
no PIN or signature validation is possible. In order to provide a level of cardholder
verification some acquirers will accept an amalgamation of the numeric parts of the house
number and postcode, along with the CSC on the card as a suitable alternative (see
Standard 70 Book 2).

This will show that the person making the transaction knows the billing address of the card
account and can see the card itself.

This information may be passed to a participating scheme acquirer as part of the


authorisation request for onward submission to the card issuer. The card issuer, if
participating, will then check the data against that held against the account.

The responses that shall be returned are described in Standard 70 Book 2.

The responses may be independent of the granting of an authorisation code, so it is


possible to receive an authorisation code and have all three CSC/AVS responses set to
“Not Matched”; it remains the card acceptor’s decision to proceed with the transaction
based upon this information.

6.6 Authorise the transaction

6.6.1 General

Authorisation may be undertaken:

a) locally by the terminal (i.e. with no attempt to go real-time to the acquirer, see
section 6.6.2 Local processing by the terminal),

b) remotely by the acquirer. (i.e. real-time to the acquirer with no attempt to process
locally in the terminal, see section 6.6.3 Real-time processing remotely by the
acquirer),

c) locally by the terminal after a call failure (i.e. locally after an attempt to go real-time
to the acquirer, see section 6.6.4 Local processing by the terminal after a call
failure),

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 39

PART 6: BUSINESS RULES 1 June 2007


d) using manual procedures (i.e. when the transaction cannot be processed locally by
the terminal, and the terminal has no real-time capability, see section 6.6.5 Manual
procedures).

Where a terminal supports updating of floor limits by the acquirer, the floor limit shall be
reset to zero for a given acquirer automatically after the fourth consecutive local
authorisation or a number of transactions as determined by the random transaction
process. It shall remain zero until it is re-established by a subsequent message from the
acquirer. Otherwise the floor limits shall be updated by a supervisor controlled function that
shall be protected from accidental (or malicious) amendment or from a remote terminal
configuration system.

For card schemes that support EMV IC cards the following transaction types shall not be
processed locally by the terminal:

a) All PAN key entered transactions (both cardholder present and not present),

b) All technical fallback transactions,

c) All magnetic stripe transactions.

Note: Refunds may be processed locally by the terminal (see section 6.9.4 Refund
processing).

6.6.2 Local processing by the terminal

6.6.2.1 Terminal checks

One or more of the checks shown in Table 3 – Terminal checks may be made, depending
on the card scheme and card type being presented. These checks shall be configurable by
card scheme. For IC transactions, unless specified otherwise, these checks are over and
above the normal EMV process but are typically used only in certain environments, e.g.
petrol filling stations.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 40

PART 6: BUSINESS RULES 1 June 2007


Table 3 – Terminal checks

Terminal check Description

Floor Limit For magnetic stripe and key entered transactions, a transaction shall not be
Checking processed locally by the terminal if the transaction value exceeds the configured floor
limit.

For EMV transactions floor limit checking shall be carried out in accordance with the
EMV rules for terminal risk management.

Maximum Times The maximum number of transactions on one card that can be processed locally by
Used Off-Line Per the terminal during a trading day. When this limit has been reached subsequent
Day transactions on the card for that trading day shall not be processed locally by the
terminal.

Maximum Times The maximum number of transactions on one card that can be performed during a
Used Per Day trading day. (Note: Once this count has been exceeded for a card, no further
transactions shall be undertaken against that card for that trading day).

Hot Card File If this check is turned on, the terminal must check to see that a valid hot card file has
Required been loaded. If a hot card file is not present, the transaction shall not be processed
locally by the terminal.

Hot Card File For magnetic stripe and key entered transactions, the card number shall be checked
Checking against a hot card file. If the card number is present, the transaction shall not be
processed locally by the terminal.

For EMV transactions hot card file checking shall be carried out in accordance with
the EMV rules for terminal risk management.

Ceiling Limit If this check is turned on, the transaction shall not be accepted if the transaction value
exceeds the configured ceiling limit.

Cash Limit For cash advance or purchase with cashback transactions, the transaction shall not
be accepted if the cash element of the transaction exceeds the configured cash limit.

Note: These checks are not required for refunds (see section 6.9.4 Refund processing).

6.6.2.2 Local authorisation

Transactions shall not be authorised locally under any of the following conditions:

a) the Maximum Times Used Off-Line Per Day limit check is enabled and the limit has
been exceeded,

b) a hot card file is required for the card scheme, but a valid hot card file has not been
loaded.

Otherwise, IC transactions may be authorised locally if allowed to do so by the TACs and


IACs.

All PAN key entered and magnetic stripe (including technical fallback) transactions shall be
sent on-line for authorisation unless exempted by environment (for example aircraft or
submarines) or by the card scheme. For these exemptions, transactions may be authorised
locally if the following conditions are fulfilled:

a) floor limit checking is enabled in the terminal,

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 41

PART 6: BUSINESS RULES 1 June 2007


b) the amount is less than the pre-comms floor limit and does not fall within the amount
exclusion band,

c) the expiry date has not been exceeded or other expiry date checks fail,

d) the start date has been exceeded and is a valid date,

e) the service code is valid and does not require real-time authorisation (see Appendix
I),

f) the transaction is an authorisation transaction and the facility to allow local


authorisation by the terminal has been enabled,

g) the transaction is a key entered transaction and the facility to allow local
authorisation for key entry has been enabled,

h) the card acceptor has not overridden the pre-comms floor limit to force a real-time
authorisation,

i) the card PAN does not appear on the local HCF,

j) the local process count (the number of transactions the terminal is allowed to
process off-line) has not been reached,

k) the transaction has not been selected for real-time authorisation (i.e. either by the 1
in n count or using the EMV random selection process),

l) this is not a cheque guarantee, cash advance or purchase with cashback


transaction.

Additionally if the terminal supports acquirer capture of transactions the following conditions
shall also be met:

a) in balance with the acquirer,

b) no relevant configuration edit since the last real-time transaction,

c) last real-time transaction was successful, i.e. valid MAC's exchanged,

d) the number of transactions stored locally is not one less than or equal to the local
count,

e) this is not an on-line PIN transaction,

f) this is not a balance enquiry transaction.

If the transaction cannot be processed locally by the terminal, the transaction shall be
transmitted real-time to the acquirer for authorisation (see section 6.6.3 Real-time
processing remotely by the acquirer), or declined, based on card scheme product
requirements. For totally off-line terminals, the transaction shall be authorised using manual
procedures (see section 6.6.5 Manual procedures), or declined, based on card scheme
product requirements.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 42

PART 6: BUSINESS RULES 1 June 2007


When authorising a transaction locally, the terminal shall generate a dummy authorisation
response code (see Appendix J) of the type 'AUTH CODE: nnnnn', provided that the card
data is valid, e.g. the LUHN check (see Appendix G) is satisfied (where enabled).

If the transaction is a financial presentment transaction (except a refund or a reversal) the


terminal shall wait for cardholder validation to be completed before generating an
authorisation code.

Before displaying the generated authorisation code, the terminal shall interject timing
delays, audible cues and displayed messages to simulate precisely the terminal
appearance during a real-time transaction.

If the transaction is a financial presentment transaction the terminal shall store the
transaction details required for the subsequent post-event advice message when this
transaction is sent to the acquirer for capture and submission.

6.6.3 Real-time processing remotely by the acquirer

6.6.3.1 General

In order to minimise the total transaction time the terminal shall establish communications
with the acquirer as early as possible in the transaction process thus, in some instances,
there will be an overlap between data communications and data entry.

If floor limit checking is not enabled (and the configuration option to delay call set up until
after amount entry is not selected) the terminal shall start to establish communications as
soon as the data is captured otherwise it shall wait for the amount to be entered.

If floor limit checking is enabled the terminal shall start to establish communications:

a) as soon as the card's details have been successfully entered if the current floor limit
setting is zero,

b) as soon as the amount has been entered and the floor limit test indicates the need
for acquirer authorisation,

c) for IC capable terminals as soon as the amount has been entered and either the 1 in
n count or the EMV random selection process (see Appendix B) indicates the need
for acquirer authorisation.

If the terminal is configured for signature only, there is no need to wait for the PIN entry
before sending a real-time request so the terminal may receive a response message before
signature verification is complete. The response shall only be actioned once the signature
has been validated: if the signature is invalid the transaction shall be voided.

The communications phase contains two separate processes:

a) connection to the acquirer system,

b) message exchange.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 43

PART 6: BUSINESS RULES 1 June 2007


6.6.3.2 Connection to the acquirer system

The terminal shall start the communications process (see Standard 70 Book 4) and shall
display the appropriate card scheme name once the data entry phase has been completed.

If the communications link fails at any time up to the completion of the transmission of the
request message, the failure is classed as an unsuccessful call attempt and the procedure
described in section 6.6.4.1 Unsuccessful call attempts, applies. If the request message has
been transmitted but the transaction has not been completed, the procedure in section
6.6.4.1 Unsuccessful call attempts shall be applied but the re-transmitted request message
shall be identified as a retry message (see Standard 70 Book 2 or Standard 60).

The card acceptor shall be able to cancel a transaction at any time. When a transaction is
terminated in this way, the terminal shall void the transaction and return to its idle state.

6.6.3.3 Message exchange

Once the terminal has established contact with the acquirer system, the application
messages are exchanged as described in Standard 70 Book 2 or Standard 60 using the
communications options defined in Standard 70 Book 4.

When a connection has been established with the acquirer the terminal shall display
'CONNECTION MADE'. If the data entry phase has still not been completed at this stage,
the terminal shall wait until data entry has been completed before continuing with the
transmitted message sequence. The 'CONNECTION MADE' display shall not be displayed
until the data entry has been completed.

On receipt of a Hold message with an empty Message data element the terminal shall
display 'PLEASE WAIT' otherwise it shall display the Message data element contents.

6.6.3.4 Post-event advices

Where the terminal supports acquirer capture of transactions the terminal shall have the
capacity to store up to n transactions locally per acquirer (where ‘n’ is defined by the local
count). If an attempt is made to store an ‘n+1’th transaction the terminal shall void the
transaction and display 'STORE FULL’/’CALL HELP DESK'. This feature allows the card
acceptor to be protected from occasional network or acquirer system problems.

Every time the terminal sends a real-time request message it shall check to see if there are
any transactions stored for that acquirer and if there are it shall send all those stored
transactions starting with the first one stored as post-event advice messages before
sending the real-time request for the current transaction.

On receiving a valid response message, regardless of the response code value, the
terminal shall delete the appropriate post-event message from its store. If a
communications failure occurs the terminal shall clear the call and enter recovery
processing; the message previously transmitted for which no response was received shall
be re-transmitted.

If the cancel key is pressed during the transmission of post-event advice messages, the
terminal shall cease processing the current post-event advice message and clear the
communications link. The interrupted post-event advice message and any other stored
post-event advice messages shall be transmitted the next time communications are
available to that acquirer.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 44

PART 6: BUSINESS RULES 1 June 2007


Transactions are stored within the terminal for subsequent transmission to the acquirer in
the following cases:

a) authorised by terminal (see section 6.6.2 Local processing by the terminal),

b) on call failure authorised amount is less than or equal to the post-comms floor limit
(see section 6.6.4 Local processing by the terminal after a call failure),

c) on call failure after a voice referral authorisation (see section 6.6.4 Local processing
by the terminal after a call failure),

d) after a voice referral response from the acquirer where the acquirer requests to be
informed of the result of the authorisation,

e) reconciliation (if configured for local processing of reconciliations),

f) the transaction is a forced data capture (i.e. where the local store is full this
transaction is not rejected but the terminal shall go real-time to the acquirer and
send this as a post-event advice message as the last transaction in the sequence).

Note: Where the issuer is undertaking on-line PIN verification remotely all on-line PIN
transactions shall go real-time to the acquirer. If this is not possible, the transaction
shall be voided, i.e. no forced voice referrals are allowed if on-line PIN is selected.

6.6.4 Local processing by the terminal after a call failure

6.6.4.1 Unsuccessful call attempts

If the terminal establishes contact with the PAD but is unable to contact the acquirer system
on the first call attempt, then a second attempt may be made, but only if the terminal uses
the second DATA telephone number and the second NUA (which shall be different to the
first NUA). Otherwise the terminal shall not attempt any further calls but follow the
procedure described in section 6.6.4.2 Call failure processing. This reduces
communications congestion in case of acquirer problems.

If the first call attempt fails for any other reason (e.g. no response from PAD) display
'SORRY FOR DELAY' and retry the first DATA telephone number.

After second failed attempt:

a) if a second DATA number is present - final attempt to this number. After failure of
this third attempt, terminal shall reset and display 'CALL AUTH CENTRE',

b) if no second DATA number is provided, terminal shall reset and display 'CALL AUTH
CENTRE'.

The appropriate protocol to be used after receipt of carrier signal is indicated in the
configuration data.

6.6.4.2 Call failure processing

Once all attempts to contact the acquirer have failed the transaction shall be authorised as
determined by the EMV process.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 45

PART 6: BUSINESS RULES 1 June 2007


For non-IC card transactions, the terminal shall wait for any amount entry and cardholder
validation to be completed. It shall then decide whether to locally authorise the transaction
or generate a voice referral using the voice referral telephone number stored in the terminal
(see Appendix K). The conditions for authorising a non-IC card transaction locally after a
call failure are:

a) floor limit checking is enabled in the terminal,

b) the amount is less than or equal to the post-comms floor limit,

c) the expiry date of the card has not been exceeded or other expiry date checks fail,

d) the start date has been exceeded and is a valid date,

e) the service code is valid and does not require real-time authorisation (see Appendix
I),

f) the card acceptor has not overridden the pre-comms floor limit to force a real-time
authorisation,

g) the Maximum Times Used Off-Line Per Day limit has not been exceeded,

h) a hot card file is required for the card scheme, and a valid hot card file has been
loaded.

i) the card PAN does not appear on the local HCF,

j) this is not a cheque guarantee transaction.

Additionally if the terminal supports acquirer capture of transactions the following conditions
shall also be met:

a) in balance with the acquirer,

b) no relevant terminal configuration updates since the last real-time transaction,

c) last real-time transaction was successful, i.e. valid MAC's exchanged,

d) the number of transactions stored locally does not equal the local count,

e) this is not an on-line PIN transaction,

f) this is not a balance enquiry transaction.

If all these conditions are met the transaction shall be authorised locally in the same way as
a pre-comms authorisation (see section 6.6.2 Local processing by the terminal); otherwise a
voice referral shall be generated (see section 6.9.3 Voice referrals) or the transaction shall
be declined (depending on card scheme product requirements).

If the terminal detects that the line is busy it shall not allow the transaction to complete until
the line is restored (to avoid card acceptor staff becoming aware of the floor limit).

If the transaction is a financial presentment, the terminal shall store approved transaction
details required for the subsequent post-event advice transaction.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 46

PART 6: BUSINESS RULES 1 June 2007


6.6.5 Manual procedures

For totally off-line terminals, the transaction shall be authorised as determined by the EMV
process.

For non-IC card transactions, the terminal shall decline the transaction under any of the
following conditions:

a) a hot card file is required for the card scheme, but a valid hot card file has not been
loaded,

b) the card PAN appears on the local HCF.

If the other conditions for local processing by the terminal are not fulfilled (see section 6.6.2
Local processing by the terminal), the transaction shall be subject to voice authorisation.

If it is not possible to make a voice authorisation (e.g. when on board an aeroplane or a ship
at sea), further manual procedures may take the form of additional identity checks.

Use of a manual procedure by a merchant using a totally off-line terminal is subject to


agreement with their acquirer and must not require specific customisation of the transaction
flow at the terminal.

6.7 Printing

Printing of a voucher shall begin as soon as possible so as to overlap the transaction


process. This will mean that the elapsed time as viewed by the card acceptor/cardholder is
minimised. If a transaction fails, or is cancelled or is declined, then a void voucher shall be
printed so as to clearly define the result of the transaction.

For signature verification, if the terminal configuration is set so as to require signature at the
end of a voucher (e.g. for use in restaurants or all night garages with security windows) then
the voucher shall be printed in full. In this case if a transaction fails a full duplicate voucher,
but marked void (and using the same message number on the voucher) shall be produced.

If the terminal is being used purely to obtain an authorisation and data capture and
submission is being undertaken elsewhere there is no requirement to print any sort of
voucher.

If the 'expiry date not used' option is configured then no expiry date shall be printed.

6.8 Submit transaction for settlement

6.8.1 General

The capture and submission of transactions for settlement may be undertaken by:

a) the card acceptor as a periodic activity e.g. daily (see section 6.8.2 Card acceptor
capture of transactions),

b) the acquirer on a transaction by transaction basis as part of the authorisation


process (see section 6.8.3 Acquirer capture of transactions).

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 47

PART 6: BUSINESS RULES 1 June 2007


6.8.2 Card acceptor capture of transactions

Where the card acceptor takes the responsibility for collecting together authorised
transactions for onward transmission for settlement he shall use the message formats as
defined in Standard 70 Book 3 or Standard 60. This process is completely separate from
the authorisation activities. In this case the authorisation request to the acquirer shall be
undertaken by using the authorisation message class messages as defined in Standard 70
Book 2 or Standard 60.

The end of shift and end of day reconciliation of transactions is wholly within the bounds of
the card acceptor’s system and not a matter for APACS standards.

6.8.3 Acquirer capture of transactions

6.8.3.1 General

Where the acquirer takes responsibility for collecting together authorised transactions as
part of the authorisation process, the authorisation and capture activities are undertaken
together (e.g. an authorisation is only granted by an acquirer if they are prepared to capture
the transaction for later settlement). In this case the authorisation request to the acquirer
shall be undertaken by using the financial presentment message class messages as
defined in Standard 70 Book 2 or Standard 60.

The end of shift and end of day reconciliation of transactions is wholly linked with the
acquirer system. See section 7.2 X and Z balances and section 7.3 Reconciliation for how
these facilities work.

6.8.3.2 Use of the transaction key system

In order to provide a security mechanism for transactions captured by the acquirer (over
public telephone networks) a MAC is generated for each financial presentment (and
reconciliation) message so that errors and malicious activity can be detected. The system
used is known as the transaction key system where the keys used to create the MAC are
changed for each transaction, based in some part on details from the previous transaction.
The transaction key system shall be used for all financial presentment and reconciliation
transactions and is described in detail in Standard 70 Book 5. It offers the following
advantages over conventional master/session key systems:

a) the keys (and hence the MAC from the terminal) change for each transaction in a
manner known only to the terminal and acquirer,

b) there is no need for fixed keys that are unsuitable in a retail environment,

c) the response proves that the acquirer received the original message and generated
the reply,

d) multiple acquirers are allowed access to terminals and each is responsible for its
own security; less security on the part of one acquirer does not jeopardise the
security of others,

e) transactions are linked together providing automatic confirmation and auditing,

f) establishes that the acquirer approved the transaction for the requested value,

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 48

PART 6: BUSINESS RULES 1 June 2007


g) provides for end-to-end PIN protection where on-line PIN verification by the issuer is
used,

h) the MAC provides error protection.

6.8.4 Message number

The message number shall be incremented on satisfactory link-level acknowledgement


(see Standard 70 Book 4) of the final application level message of a transaction provided
that the response message is not invalid.

For transactions that are authorised locally, the message number shall be incremented only
on display of an internally generated authorisation code.

Where a voucher is printed and the transaction is then cancelled, the message number
used shall be incremented for the next transaction, i.e. the same message number shall
never appear twice.

The message number shall not be incremented when receiving auxiliary messages, i.e. the
message number shall be the same for all messages in the same transaction.

6.8.5 Delayed cancel

Financial presentment confirmation messages are used to indicate the completion status of
a transaction to the acquirer. However, if the transaction is cancelled during communication
with the acquirer the normal operation is to immediately shut down the call, which prevents
indication of the completion status. Hence, if the delayed cancel configuration option is
enabled, and a transaction is cancelled between transmission to the acquirer and
communications completion, the terminal shall wait for the response message to complete
and the (optional) confirmation message to be sent before completing the cancel request. A
suitable message shall be presented to the card acceptor during this wait condition.

6.9 Exception transactions

6.9.1 General

Some transactions are exceptions to the ‘normal’ sale transactions process because they
either require additional manual intervention for example voice referrals or different
interactions with the IC card for example where the acquirer or card acceptor stands-in
because of communications failure.

6.9.2 Declined transactions

6.9.2.1 IC card decline only

Within the EMV process a transaction can reach a declined result through four routes:

a) the IC can decline the transaction based on internal risk and usage parameter
checks,

b) the terminal can decide that the transaction should be declined as a result of risk
and usage parameter checks,

c) the card issuer can request that the transaction be declined as a result of real-time
authorisation,

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 49

PART 6: BUSINESS RULES 1 June 2007


d) The IC can decline the transaction after real-time authorisation as dictated by the IC
related data of the response message and internal risk management and usage
parameters.

In addition to declining the transaction the card issuer can (as with any response) send a
script to be acted on by the IC and/or may also request that the card acceptor retains the
card.

Where the transaction is declined the card acceptor will be aware on their display that the
transaction has been declined. For display to the cardholder the term ‘NOT AUTHORISED’
is preferred. Where the terminal only has a single display, for example a portable terminal, it
shall be considered to be the card acceptor’s display.

The terminal shall provide the card acceptor with as much additional information as possible
as to the reason for the decline to aid communication with the cardholder e.g.:

a) transaction declined by the IC – before real-time authorisation - DECLINED BY


CARD - CARDHOLDER SHOULD CONTACT ISSUER,

b) transaction declined by the terminal – before real-time authorisation- CARD NOT


AUTHORISED – CARDHOLDER SHOULD CONTACT ISSUER,

c) transaction declined after real-time authorisation – additional display ISSUER


DECLINE - CARDHOLDER SHOULD CONTACT ISSUER,

d) transaction declined by the IC after real-time authorisation – UNABLE TO


AUTHORISE – CARDHOLDER SHOULD CONTACT ISSUER.

If the PINPAD display is not limited to two lines then ‘REMOVE CARD’ shall be displayed in
addition to the messages shown above.

If the transaction is declined then the data collected shall be discarded and the card
returned to the cardholder along with any completed transaction voucher showing that it has
been declined. Where the transaction is declined no settlement data shall be presented but
the card acceptor’s system shall keep a full audit trail.

A transaction declined by the IC, terminal or card issuer shall not be reprocessed using
alternative data entry (magnetic stripe or PAN key entry).

6.9.2.2 IC card decline and retain

In exceptional circumstances the card acceptor may be requested (through the response
message – see Standard 70 Book 2 or Standard 60) to retain the card (also known as
'decline and pickup'). This code will normally be sent in conjunction with a script, which
prevents the IC from carrying out further IC transactions. The retain card message shall not
be displayed to the card acceptor until the IC has processed the script.

While the card acceptor’s display shall display ‘DECLINED’/’KEEP CARD’ the cardholder’s
display shall continue to display ‘DO NOT REMOVE CARD’/’PLEASE WAIT’ until the card
is removed by the card acceptor where possible.

6.9.2.3 Magnetic stripe and key entry decline

The terminal shall provide the card acceptor with as much additional information as possible
as to the reason for the decline to aid communication with the cardholder e.g.:

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 50

PART 6: BUSINESS RULES 1 June 2007


a) transaction declined by the terminal – before real-time authorisation- CARD NOT
AUTHORISED – CARDHOLDER SHOULD CONTACT ISSUER,

b) transaction declined after real-time authorisation – additional display ISSUER


DECLINE - CARDHOLDER SHOULD CONTACT ISSUER.

6.9.2.4 Magnetic stripe and key entry decline and retain

Where the transaction is processed using the magnetic stripe or by keying in the data then
the card will be the possession of the card acceptor until the transaction is completed. If the
issuer requires the card to be retained the card acceptor’s display shall display
‘DECLINED’/’KEEP CARD’.

6.9.3 Voice referrals

6.9.3.1 General

Voice referrals occur either as a result of the final response message from the acquirer (see
Standard 70 Book 2 or Standard 60) or as a result of a call failure (see section 6.6.4.2 Call
failure processing). The referral telephone number can either be stored in the terminal or (if
acquirer update of referral telephone numbers is supported) received as part of a
transaction response (Appendix K) and shall be displayed on the terminal whilst it is being
dialled. Once dialling is complete the terminal shall display 'LIFT RECEIVER' and once the
receiver is lifted it shall display either 'REFERRAL', if the call was due to a call failure, or the
contents of the Message data element from the response message.

Please refer to section 6.9.3.2 IC card referrals for details of how to process a voice referral
for an IC transaction.

If the card acceptor finds that the terminal has not successfully connected the call (i.e. the
line is engaged or the call has been misrouted) the number shall be able to be automatically
redialled by pressing an appropriate key. As the terminal is expecting the input of an
authorisation code in response to the voice referral call, the terminal shall not allow the re-
dialling sequence to be interpreted as an authorisation code.

When contact is made the card acceptor shall obtain an authorisation code (or a decline)
from the acquirer that shall be manually entered on the terminal keyboard.

Note: Financial presentment transactions (see Standard 70 Book 2 or Standard 60) that
are authorised after a voice referral requested by the acquirer, shall only be
stored locally if this has been indicated in the Confirmation request data element of
the response message.

Financial presentment transactions that are authorised after a voice referral generated due
to a call failure shall be stored locally for subsequent capture and submission by the
acquirer.

If a voice referral is required but the terminal has not been configured to indicate that there
is an attached telephone or it has an incomplete telephone number, the terminal shall
display 'CALL AUTH CENTRE' and either void the transaction and complete the voucher
accordingly or provide the option to enter the result of a voice referral carried out on a
separate telephone.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 51

PART 6: BUSINESS RULES 1 June 2007


6.9.3.2 IC card referrals

In response to a real-time authorisation request the card issuer may return a response that
requests the card acceptor to make contact before the transaction can be completed.

To ensure all of the information requested during the referral call can be provided, this may
include data that is not printed on the voucher (for example the card security code on the
signature strip), the card shall be removed from the card reader when prompted.

In order to leave the IC in a known good state the EMV part of the transaction is completed
with the IC, so that it can be removed from the card reader. The terminal shall issue a 2nd
Generate AC command requesting an AAC. The card acceptor’s normal procedures shall
then be followed.

If the transaction is authorised the authorisation code is added to the data collected up to
the point of referral; these are used to complete the transaction and for settlement. The
ARQC and its supporting data from the authorisation message shall be used in the
settlement message.

An AAC shall not be submitted in a settlement message.

The card shall be returned to the cardholder along with the completed transaction voucher.
If the transaction is declined:

a) the completed transaction shall be reversed or cancelled within the terminal,

b) no further processing shall be done with the card (i.e. the IC believes it has
completed the transaction),

c) no settlement data shall be sent in respect of the transaction.

6.9.3.3 Magnetic stripe and key entry referrals

Where the transaction is processed using the magnetic stripe or by keying in the data then
the card will be the possession of the card acceptor until the transaction is completed. The
card acceptor will, therefore, be able to supply any details required from the front or back of
the card during the voice referral process.

6.9.4 Refund processing

6.9.4.1 General

Where goods or services have been paid for using a payment card then a refund of part or
full value shall where possible be returned to the payment card account on which the
original transaction was performed. There is no requirement to authorise refund
transactions but financial presentment terminals may send the transactions on-line to allow
their capture.

6.9.4.2 IC card refund processing

The simplest approach to process a refund transaction is utilising track 2 equivalent data
read from the chip. Some card acceptors may choose to undertake a full EMV transaction
with PIN. Performing a full EMV transaction for a refund may lead to issues in processing.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 52

PART 6: BUSINESS RULES 1 June 2007


The following options are available for processing refunds:

a) The preferred method is to start a chip transaction and follow the normal EMV
transaction flow in order to obtain the track 2 equivalent data from the chip to
generate the settlement message. The terminal shall obtain the PAN and expiry
date if the track 2 equivalent data is not present. If track 2 equivalent data is read
then it shall be formatted as defined in Standard 70 Book 2 for PAN key entered
data. If the Processing Options Data Object List (PDOL) indicates that the
transaction amount is to be included in the Get Processing Options command, it is
recommended that the terminal sends a zero transaction amount to the card. Once
the required data has been obtained, the terminal shall then stop the transaction
flow by asking the chip for an AAC (decline cryptogram) at the 1st Generate AC
stage of the transaction.

Note: Use of the data from the chip is preferred, but the chip does not have to be used.
The data may be obtained from the magnetic stripe, by PAN key entry or from
stored data subject to any scheme limitations on stored data (e.g. PCI:DSS).

b) A full EMV transaction may be undertaken but it is essential that the transaction is
kept off-line and no on-line authorisation is sought. This will require the terminal risk
management being disabled. The PoS reads the track 2 equivalent data from the
chip and attempts to conclude the EMV process at the 1st Generate AC by asking
the card for a Transaction Certificate (TC). If the card returns a decline AAC the
terminal shall abandon the full EMV process and continue refund processing using
option 1 above.

If an ARQC is generated from the card’s 1st Generate AC the PoS may indicate
unable to go On-line / off-line approved (submitting the TC or ARQC cryptogram in
the settlement record). If a referral to the acquirer host occurs any the response
code sent to the card shall be as defined in section 6.9.5.1 IC card stand-in
processing.

If a refund fails then a PAN key entered transaction may be completed.

6.9.4.3 Magnetic stripe and key entry refund processing

For magnetic stripe and key entered refunds the capture card data process will be the same
as a purchase transaction. There is no requirement for the refund voucher to be signed or
the signature to be checked. Some terminals may produce a signature panel on the refund
receipt for the card acceptor to sign or initial for internal audit purposes.

6.9.4.4 Data validation for refunds

The data validation required for refunds is minimal and is limited to ensuring the transaction
can be settled. The IIN shall be checked to ensure it can be processed and whether a
LUHN check is required for PAN key entered transactions. No fraud or risk checks are
required unless they are at the card acceptor’s choice.

6.9.4.5 Cardholder verification for refunds

Cardholder verification for refund transactions varies in operation between acquirers. The
card acceptor runs the risks involved in such transactions (i.e. he is the one debited). Thus
there needs to be some mechanism to control the use of refund transactions within the
control of the card acceptor's supervisory staff. Typically this is through the use of a
supervisor card that is passed through the terminal to permit the refund to proceed;

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 53

PART 6: BUSINESS RULES 1 June 2007


alternatively this can be through the use of a password or by turning a physical key on the
terminal.

6.9.4.6 Transaction presentment for refunds

For real-time systems the card details shall be sent in the PAN key entered format unless a
full EMV transaction has been performed. For post-event systems batch transfer only
message class 6 shall be used and for file transfer only segment 1 shall be used.

6.9.5 Stand-in processing

6.9.5.1 IC card stand-in processing

The processing of IC cards assumes that all real-time authorisation requests are sent to the
card issuer for approval.

In some instances, however, an intermediate system (e.g. acquirer or card acceptor) will
‘stand-in’ for the issuer, and authorise the transaction. In this situation the response
message will not contain an ARPC and the IC card may subsequently decline the
transaction if the response purports to come from the issuer.

To avoid this situation, the intermediate system shall indicate in the response message (in
the Response Additional Data field) that a system other than the card issuer is the
authorising entity. In addition, the terminal shall support the Response Additional Data field
and if the terminal should subsequently receive a response message indicating the card
acceptor or acquirer was the authorising entity it shall respond to the IC indicating that the
transaction was authorised or declined locally (using EMV response codes ‘Y3’ or ‘Z3’
respectively) subject to the processing of the default Terminal and Issuer Action Codes.

6.9.5.2 Magnetic stripe and key entry stand-in processing

For magnetic stripe and key entered transactions the transaction shall be authorised or
declined as defined by the acquirer response code.

6.9.6 Reversals

6.9.6.1 General

Reversals are used to undo transactions that have been performed in error. This is usually
where the transaction has been sent for authorisation and then the card acceptor or the
cardholder notices that the amount of the transaction is incorrect.

Terminals may adopt implicit and/or explicit reversal transaction processing.

Implicit transaction reversals arise where (subject to the system time available for recall) the
same TID and transaction sequence number are re-used in the next authorisation request
message. This is the method to use when a response is not received from the authoriser
and the transaction sequence number has therefore not been incremented.

Explicit transaction reversals arise where the above is not possible – generally arising
where TID availability is generated on a ‘round-robin’ basis and a response has been
received from the authoriser but the transaction is then cancelled e.g. if the signature on the
receipt does not match that on the card, or the IC card declines the transaction at the 2nd
Generate AC stage.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 54

PART 6: BUSINESS RULES 1 June 2007


If the acquirer supports reversals then the terminal shall create a reversal request message
from the data used for the original authorisation request, but with an incremented message
number, and send it real-time to the acquirer. On receipt of the response the terminal shall
void the transaction.

In all cases the terminal shall produce a voucher for the cardholder (which may be on the till
receipt) showing that the original transaction has been voided. For standalone terminals the
payment transaction may have to be restarted. For EPOS systems the transaction may still
be ‘alive’ and if so, a new tender process can be started within the transaction.

6.9.6.2 IC card reversals

In an IC card and PIN environment the amount is displayed to the cardholder before PIN
entry and before the IC and terminal have determined if this transaction needs to be sent to
the acquirer.

There will, however, be transactions where an error is noticed or the cardholder decides at
the last minute that they do not want all of the items for this transaction and authorisation is
already taking place. In a standalone terminal the whole transaction will have to be undone
but in an EPOS system it is just the tender element that needs correction and it may be
possible to keep the purchase transaction ‘alive’.

It is important that the IC is left in a known stable state and the action taken will depend on
the point reached in the EMV process:

a) if the transaction with the card has not reached the point where a cryptogram has
been requested, it can be simply powered off (see section 6.2.9 Premature card
removal). If required by the system design and for completeness the terminal can
ask for an application authentication cryptogram (AAC),

b) the terminal has requested an ARQC but has not yet sent a real-time message, then
the terminal can decline the transaction as 'unable to go on-line, off-line declined’
(using EMV response code ‘Z3’),

c) the terminal has requested a transaction certificate (TC) to complete the transaction
locally as no real-time authorisation has occurred.

In all of the above cases, as no communication has been made with the acquirer, it is only
necessary to complete the transaction with the IC card, power the card off and void the
payment within the terminal.

If an authorisation request has been sent to the acquirer the response shall be processed
as it may contain a script from the card issuer. Having processed the response message,
the terminal shall complete the EMV transaction by requesting an AAC and then powering
off the card.

If processing an explicit reversal the terminal shall create and send a reversal message with
the original transaction data, but may include the latest available chip data.

6.9.6.3 Magnetic stripe and key entry reversals

In a magnetic stripe environment reversals will often happen when the cardholder signs the
voucher. By this time the terminal has already begun, if not completed, the real-time
authorisation.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 55

PART 6: BUSINESS RULES 1 June 2007


It shall be possible to reverse this transaction by:

a) cancelling the transaction before confirming the signature,

b) selecting the reversal function on the terminal.

Option a) will result in an implicit reversal provided that a response has not been received
from the host. For option b) or if a response has been received to option a) then an explicit
reversal shall be sent.

6.10 Industry specific transactions

6.10.1 General

The operating environment, in some industries, may create specific changes in the
transaction process and functionality required that is outside the ‘norm’ of a face to face
transaction. This section deals with transaction types for those specific industry sectors.

6.10.2 Unattended Terminals (excluding ATMs)

6.10.2.1 Rules for cardholder activated terminals


Table 3 - Cardholder activated terminal

Magstripe only Terminals Chip only Terminals Hybrid


(chip and magstripe)
Floor Limits Zero floor limit May support non-zero Zero limit for magstripe
floor limit for IC card and May support non-zero
PIN floor limit for IC card and
PIN
Motorised IFD Required Optional Optional
Card Retention capability Required (except Optional Optional
payphones)
Technical Fallback No No No -– but waiver may be
(Chip read failure) granted on application to
acquirer unless agreed
by bi-lateral agreement
CVM support Cardholder Verification Off-line PIN Off-line PIN
No CVM No CVM
Authorisation capability Real-time required Real-time required Real-time required

Note 1: A real-time authorisation may not be appropriate in all environments, even if the IC
is set to request one e.g. at a road toll unattended terminal, where throughput speed
and low transaction value need to be kept in perspective. This would be an
exception to the principle proposed. The merchant shall agree with the acquirer the
Terminal Action Code – Default settings appropriate for the terminal environment.
Note 2: IC only terminal option: Where it is possible to redirect all magnetic stripe cards (and
fallback transactions) to an attended kiosk then the unattended terminal owner can
satisfy the card schemes 'honour all cards' rule.

6.10.2.2 PIN pad (PED) requirements

Unless the PED is handheld / portable in an unattended terminal, a privacy shield is


required. Refer to Standard 70 Book 5 for further guidance on PIN pad certification.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 56

PART 6: BUSINESS RULES 1 June 2007


6.10.2.3 Support for ‘No CVM’

IC capable terminals shall support offline PIN. However, in order to comply with the
requirements of the Disability Discrimination Act (DDA) unattended terminals may need to
support ‘No CVM’ so that cardholders who, through a disability, are unable to use PIN, and
whose cards are coded accordingly, may still make use of the unattended terminal.

Retailers may need to make a case with acquirers and schemes for terminals to support
only ‘No CVM’.

6.10.2.4 Unattended terminals in specific environments

The following specific environments are considered:

a) Petrol pumps

1. the cardholder is prompted to enter card into dispenser, IC is read, display


reads MAXIMUM <value> £XX – PLEASE ENTER PIN', PIN is entered and an
authorisation for one unit of the major denomination of the default currency,
e.g. £1 is generated,

2. petrol is dispensed, up to the advertised maximum of £XXvalue – the PIN


entry signifying that a sum up to that £XXvalue is agreed as the maximum sum
to be debited,

3. a second PIN entry is NOT required at the end of the transaction and the
integrity offered by the IC and PIN is established at the outset of the
transaction,

4. this transaction type involves an IC and PIN auth for one unit of the major
denomination of the default currency, e.g. £1, as a pre-authorisation, and a
final dispensed amount as the transaction figure. The TC would link back to
the £1 pre authorisation.

b) Motorway tolls. Terminals in this type of environment should be limited amount


terminals (LATs) and have their own existing rules and procedures.

c) Payphones. Operators may wish to introduce combined readers into payphones, to


enable the magnetic stripe to be read if the IC is unreadable.

6.10.2.5 Transaction vouchers

A receipt shall always be produced if a cardholder requests it, except for some low-value
transactions with the agreement of the acquirer. If a receipt is produced, it shall follow the
rules in Appendix H.

6.10.2.6 Card retention

Under current scheme rules, unattended terminals may still have to retain cards, if so
instructed in the authorisation response and the terminal has the capability. Specifically
card capture:

a) remains mandatory for Magnetic Stripe only unattended devices,

b) is optional for hybrid (EMV Chip and Magnetic Stripe) devices.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 57

PART 6: BUSINESS RULES 1 June 2007


6.10.3 Authorisations with an unknown final amount

In some environments (for example travel and entertainment) the amount authorised may
be an estimated amount and less that the final amount of the purchase (colloquially known
as a pre-auth). In these environments several authorisations (pre-auths) may be performed
that together may equal the final amount. It should be noted that any authorisations that are
older then five days may be considered as expired and be processed again to check that
funds are still available.

These transactions and are normally required to validate a payment card before goods or
services are used. The exact use of the authorisation depends on the environment of use
and in what specific scenario the card acceptor and cardholder are interacting.

This section presents the basic concepts and the combined UK Acquirer recommended
processing.

The reason for the authorisation is to authenticate the card and the cardholder and also
check funds availability. To perform an authorisation an amount must be entered and the
most suitable amount can vary depending on the card acceptor circumstances and
environment and must be agreed with the acquirer.

Anything less than 10 currency units (e.g. 10 pence) is NOT acceptable for any pre-
authorisation or authorisation transaction.

6.10.3.1 Amount selection

There are three options for population of the amount:

a) Nominal Amount - Authorise a nominal amount (e.g. £1),

b) Unit Amount - Authorise the lowest significant unit amount (e.g. minimum dispense
of petrol, first night in a hotel, first days car hire),

c) Estimated Amount - Authorise the estimated final amount at first customer


interaction (e.g. 3 nights in a hotel +20%, £30.00 of petrol, one week’s car hire).

6.10.3.2 Final amount greater / incremental authorisation

If the final transaction value is greater than the amount previously authorised plus any
scheme allowed percentage variation either:

a) perform an incremental authorisation for the difference between the amount already
authorised and the final amount of the transaction. The authorisation code from this
incremental authorisation transaction shall be used in the financial presentment,

b) The acquirer should be contacted, the original transaction reversed and a new
authorisation or financial presentment performed for the final amount performed.

6.10.4 Hospitality, hotel & car hire

A card acceptor should endeavour to deliver the best quality of data into settlement and
transactions accompanied by cryptographic data are always preferable. If this data cannot
be retained at the point of sale then consideration should be given to keeping it on a central
server or at a processing bureau subject to any data storage constraints (e.g. PCI:DSS).

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 58

PART 6: BUSINESS RULES 1 June 2007


6.10.4.1 Hotel advance bookings and deposits

Where the room booking is made with the cardholder not present, e.g. over the telephone
or via the Internet a card number may be taken at that time. This card number may be used
to debit a ‘no show’ fee from the cardholder if they fail to use the booking they have made.
Any such transaction shall be processed as it is today: as a cardholder not present, PAN
key entered transaction.

Advanced deposits may be taken with or without the cardholder being present. It is a
standard sale transaction and as such is completed at that moment – authorisation is
requested and the transaction completed at one time.

6.10.4.2 Hotel transaction process

When a card is presented at check-in at a hotel it is used to perform one or both of two
functions:

a) Authentication of the card and cardholder,

b) Authorisation of an estimated amount.

The transaction process must be able to fulfil both of the above functions and allow for the
authorisation of additional amounts over the whole of the cardholder’s stay. Additionally the
process must be able support express check-out, where the cardholder is not present, and
check-out where the cardholder is present.

Where the cardholder has paid in advance the hotelier may choose to carry out a full EMV
transaction for a nominal amount at check-in to authenticate the card and cardholder.

The receipt produced may be use to respond to any chargeback queries or to create
transactions to bill for any unpaid items.

6.10.4.2.1 Cardholder not present at check-out

Where the hotel offers an ‘express check-out’ facility the card holder will not be present to
complete the transaction. The method of operation will then depend on the functionality of
the point of sale terminal and particularly on its ability to store the cryptographic details
created at check-in. These methods are described in Figure 8 - Systems able to store
cryptographic data and Figure 9 - Systems NOT able to store cryptograhic data.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 59

PART 6: BUSINESS RULES 1 June 2007

Check-in

Full EMV transaction for Estimate Amount


* Card details, TC and supporting data stored for later
use. Auth Code 1 Saved.

Incremental Authorisation Using stored card details. Auth Code 2 Saved

Incremental Authorisation Using stored card details. Auth Code n Saved

Express Check-out Submit transaction using Final Amount using stored card
details, Auth Code n and TC and supporting data stored
from *

Figure 8 - Systems able to store cryptographic data

Check-in

Full EMV transaction for Estimate Amount


Card details and Auth Code 1. Printed on Card Acceptor
receipt

Incremental Authorisation Using printed card details. Auth Code 2 Printed on Card
Acceptor receipt

Incremental Authorisation Using stored card details. Auth Code n Printed on Card
Acceptor receipt

Express Check-out Submit transaction using Final Amount using card details
from printed receipt, Auth Code n Printed on Card
Acceptor receipt

Figure 9 - Systems NOT able to store cryptograhic data

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 60

PART 6: BUSINESS RULES 1 June 2007


6.10.4.2.2 Cardholder present at check-out

Where the cardholder chooses not to use the ‘expess check-out’ facility or none is available
then the card acceptor can perform a full Chip & PIN transaction. Care must be taken not to
debit the cardholder’s account for a second time and the transaction must be prevented
from authorising on-line to the card issuer but must also leave the card in the correct state.
The recommended method to achieve this is shown in Figure 10 - Cardholder present at
check-out.

Check-out

Full EMV transaction for Final Amount


st
PoS request ARQC for final amount on 1 Generate AC

nd
PoS request AAC on 2 Generate AC

Cardholder Checked-out Submit transaction Post Event using Final Amount, Auth
Code n and ARQC and supporting data

Figure 10 - Cardholder present at check-out

6.10.4.2.3 Restaurants – General

The usage of IC Cards and PIN has a significant impact on the operational procedures in
the restaurant business. The cardholder may be required to settle accounts:

a) At the table using a portable terminal,

b) At the cash register (where no portable terminals are available).

6.10.4.2.4 Gratuity

There are three potential solutions for adding gratuities to a bill where the customer is
paying using a card:

a) the restaurant may choose to present a bill to the customer that includes a service
charge within the transaction total,

b) the restaurant may choose NOT to include a service charge but also NOT to allow
tips to be added to the card payment,

c) the restaurant may choose to allow the cardholder to add any gratuity when
presented with the amount for the card transaction.

Note: this standard only considers option c).

6.10.4.2.5 Gratuity transaction processing

Where a gratuity value is entered on the terminal, the operator will initiate the transaction
and enter the bill amount. There are then two options identified for supporting gratuity value
processing:

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 61

PART 6: BUSINESS RULES 1 June 2007


a) the cardholder enters a new ‘full’ transaction amount to include any gratuity,

b) the cardholder has to mentally calculate a gratuity amount and enter this value to
arrive at a ‘full’ amount.

Option a) is the preferred acquirer approach, but both options are included within this
standard for completeness see Figure 11 - Gratuity transaction flow.

Card Inserted and


amount Entered

Terminal Displays
Amount £XXX.XX
Add Gratuity?
Yes = Enter Optionally the terminal may
prompt for the gratuity amount
No = Clear to be entered

Terminal Displays Enter


Cardholder Yes New Total
pressed Amount £XXX.XX
Enter then press Enter

No

Terminal Displays
Terminal Displays Original Amount £XXX.XX
Amount £XXX.XX Gratuity Amount £XXX.XX
Add Gratuity? Total Amount £XXX.XX
OK = Enter
Enter PIN
Not OK = Clear

Cardholder
Complete transaction pressed
for original amount Enter No

Yes

Terminal Displays
Amount £XXX.XX

Complete transaction
for new amount

Figure 11 - Gratuity transaction flow

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 62

PART 6: BUSINESS RULES 1 June 2007


6.10.4.2.6 Magnetic stripe and key entry gratuity transaction processing

If the authorisation is obtained before the addition of any gratuity then specific card scheme
rules apply to any subsequent processing. In this case acquirer capture and submission of
transactions is not possible (as the transaction protocol does not allow for transactions to be
amended after they have been authorised and captured by the acquirer) so the capture and
submission of transactions shall be as defined in Standard 70 Book 3 or Standard 60.

Authorisation rules governing the addition of the gratuity are set by each card scheme. The
general authorisation requirement involves a percentage (X) set by the scheme. If the
amount of the transaction, before the gratuity is added:

a) is below the card acceptors floor limit and the gratuity is within X% of the transaction
amount, the card acceptor is not required to call for authorisation even if the gratuity
brings the total transaction over the floor limit,

b) exceeds the card acceptors floor limit and the card acceptor has obtained
authorisation for the transaction amount, if the gratuity does not exceed X% of the
transaction amount an additional authorisation is not required,

c) exceeds the card acceptors floor limit and the card acceptor has obtained
authorisation for the transaction amount, if the gratuity exceeds X% of the
transaction amount, the card acceptor is required to obtain an authorisation on the
additional amount,

Note: The card acceptor shall, where possible, indicate both authorisation numbers and
amounts on the sales voucher.

The terminal shall allow a configurable voucher message to be printed, such as 'service' or
'gratuity', to allow the cardholder to add a gratuity when the voucher is signed.

The addition of a gratuity breaks the transaction into two parts. The terminal shall therefore
allow transactions to be recalled in order that the gratuity may be added.

Restaurants operate in different environments, such as single or multi-waiter, and payment


at the table or at a central checkout. In order to meet these requirements the terminal shall
assign a unique reference to each transaction to allow any transaction to be recalled at any
time.

The terminal shall allow for the gratuity to be deleted and re-entered if a mistake is made.

End of day reconciliation shall not be allowed if any transactions are left in an incomplete
state. All transactions shall be recalled and completed even if no gratuity has been added.

End of day reporting shall show a breakdown of the day's business of base meal amount
and gratuities by card scheme.

Optionally, the terminal may provide a full audit trail of each gratuity, identifying individual
waiters, dependent on the waiter I.D.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 63

PART 6: BUSINESS RULES 1 June 2007


6.10.4.2.7 Bar tab process

To combat the practice of retaining cardholder’s cards ‘behind the bar’ (where they are
vulnerable to skimming or theft) the following process is described as a means of
performing transactions where the final amount may not be known.

The authorisation performed at the beginning of the transaction must be for an amount
agreed between the card acceptor and the cardholder. If the cardholder’s spending reaches
the agreed amount then the transaction must be completed and a new transaction started if
the cardholder wishes to continue spending.

Care must be taken to ensure the date used in the settlement transaction is the same as
the date used in creating the cryptographic data. Particularly in the hospitality environment
the closing of the bar tab may occur after midnight and therefore be on a different day to
when it was opened.

Open Tab

Full EMV Authorisation transaction for


Agreed Amount

* Card details, TC and supporting data stored for later


use. Auth Code 1 saved.

Closing Tab

Full EMV transaction for Final Amount


st
PoS request ARQC for final amount on 1 Generate AC
(the transaction is not sent on-line)

nd
PoS request AAC for final amount on 2 Generate AC (to
complete the transaction off-line)

Tab Closed Submit transaction off-line using Final Amount, Auth


Code 1 and TC and supporting data from *

Figure 12 - Closing bar tab cardholder

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 64

PART 6: BUSINESS RULES 1 June 2007


6.10.4.2.8 Bar tab completion no cardholder

There is the possibility in the hospitality environment that the cardholder may mistakenly
leave without completing the transaction. In this case the data collected on opening the tab
may be used to complete the transaction.
Open Tab

Full EMV transaction for Agreed Amount


* Card details, TC and supporting data stored for later
use. Auth Code 1saved.

Closing Tab Submit transaction using Final Amount, stored card


details, Auth Code 1 and TC and supporting data stored
from * including ‘agreed amount’ as cryptogram amount.

Figure 13 - Closing bar tab cardholder not present

6.10.4.3 Car Hire

The process will be the same as that used for Hotels and the cases of different points of
sale for collection and return of a vehicle may be different towns for example one way hire
and cardholder not present to complete the transaction are true. Note the terminology used
in car hire is the reverse of hotels vehicles are ‘checked-out’ when they are collected and
‘checked-in’ when returned.

6.10.5 Fast food

In fast food and similar environments the normal transaction process may not involve the
production of any vouchers at all and the card acceptors audit trail will be from electronically
stored data. The cardholder shall have the option to ask for a voucher and this shall be
produced on request.

6.11 Dynamic currency conversion (DCC)

Dynamic Currency Conversion at PoS is an optional service to International cardholders


providing a choice of paying for goods and services in either the card acceptor’s currency or
the cardholder’s Issuer billing currency. DCC is discretionary and may only be implemented
with bi-lateral agreement. It is not available on all card schemes and each scheme has its
own rules that must be adhered to in the provision of this service.

If DCC processing is supported the PoS shall identify after card swipe or insertion that an
offer of DCC is applicable and which currency should be applied.

The PoS process shall be:

a) Card read by swipe or insertion,

b) POS to read PAN and use IIN number table and / or AID and other card data to
identify offer of DCC transaction,

c) Amount in the Card Acceptor Currency, in the Cardholder Currency, description of


the Cardholder Currency (e.g.€ or EUR) and the Exchange Rate used to be shown
on the display,

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 65

PART 6: BUSINESS RULES 1 June 2007


d) Customer Decision Point Yes / No

i. No = Abort DCC and process in Card Acceptor Currency

ii. Yes = Start EMV or magnetic stripe processing in Cardholder Currency,

e) DCC ‘receipt’ to be printed to include:

i. Card Acceptor Currency Amount

ii. Cardholder Currency Amount (including description)

iii. Conversion rate applied

iv. Relevant card scheme ‘disclaimer’ statement (see below)

v. Commission Fee

vi. Any mark-up fee applied

The use of a ‘receipt’ is suggested to communicate the offer terms to the cardholder.

Any authorisation amounts, incremental authorisation amounts and final amounts shall be in
the same currency.

If a transaction includes a gratuity option, the gratuity shall be added before applying the
offer of DCC.

Dynamic currency conversion has a requirement to print card scheme disclaimers on the
receipts for MasterCard and Visa. MasterCard have both a long and short version
disclaimer statement. The wording of these disclaimers can be found in Appendix H.1.10.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 66

PART 6: BUSINESS RULES 1 June 2007

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 67

PART 7: CARD ACCEPTOR FACILITIES 1 June 2007


7 CARD ACCEPTOR FACILITIES

7.1 General

A number of features shall be provided in terminals in order to assist the card acceptor in his
use of the terminal and his management of the communications with his acquirers. These
features have been described in this document as mandatory, however they may be omitted
by mutual agreement between the card acceptor and his acquirer(s).

7.2 X and Z balances

In order to assist card acceptors in periodic and end of day reconciliation with their EPOS
systems, terminals may support the X and Z balance functions. Where a terminal is
performing transactions in a single currency the values shall be real values; where the
terminal is performing transactions in more than one currency the values shall be hash
values (i.e. totals of all currencies).

For this set of totals two functions shall be available:

a) X function: to print the running totals without resetting these totals,

b) Z function: to print the totals as in the X function but reset these totals to zero.

This may be achieved either by swiping a supervisor card, entering a password or by the use
of a physical key on the terminal.

The terminal shall then print the card acceptor totals for each acquirer and any card issuer
associated with the acquirer. No totals shall be printed if the acquirer is configured for
authorisation only or if there has been no business transacted with that acquirer since the
last Z balance. The terminal shall define 'business transacted' as a change in message
sequence number so it shall print a Z or X balance even if all the transactions have been
declined and the total business value is zero.

After all the totals for each acquirer have been printed the terminal shall print a grand total of
all the individual acquirer totals (see Appendix H for sample printouts).

7.1 Reconciliation

7.1.1 Outline

Reconciliation, for card acceptors who do not use the acquirer capture of transactions
service, but capture and submit their own transactions (see Standard 70 Book 3 or Standard
60), is a matter for the card acceptor and their terminal suppliers. No requirements are
defined in this document.

Reconciliation for card acceptors who do use the acquirer capture of transactions service, is
an integral aspect of the service. It is used to assist card acceptors in periodic and end of
day reconciliation with their acquirer(s) for checking that they have received all the
transactions the card acceptor has performed.

Terminals shall support the reconciliation message class defined in Standard 70 Book 2 or
Standard 60. Where a terminal is performing transactions in a single currency the values
shall be real values; where the terminal is performing transactions in more than one currency
the values shall be hash values (i.e. totals of all currencies).

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 68

PART 7: CARD ACCEPTOR FACILITIES 1 June 2007


Timing of these processes is important if the amounts appearing on the card acceptor's bank
statement are to be reconciled with those appearing on the terminal, but they can be done
as often as the card acceptor requires.

Totals are printed in the order determined by the terminals configuration data.

7.2.1 Sessions

When an acquirer captures transactions for a card acceptor it is necessary, at some point in
a business day, to collect the captured transactions together and forward them for
settlement. This activity is usually undertaken once a day, often late in the evening.

In order for terminals to understand which transactions have been collected and which are
still awaiting collection, a control mechanism is required. This mechanism is the session
number. This relates to the business done within the acquirers' business day (or session)
and is used to show the card acceptor on the reconciliation printout which transactions have
been credited and which will not be credited to his account until the acquirer's next business
day.

A change in session is signified by a change in the session number (sent in the Session
number data element) in the first response message received in a new acquirer session.

When printing a reconciliation report (see Appendix H for example report layouts) the
session totals are defined as follows:

a) PREVIOUS The total business done within all sessions completed since the last
reconciliation (i.e. excluding the current session but including the
session within which the last reconciliation was performed),

b) CURRENT The total business in the current session so far,

c) STORED (Only printed if stored transactions are present). The total business
stored in the terminal not yet advised to the acquirer.

Each total is held under five headings:

a) Total value of debits - 11 digits max,

b) Total value of credits - 11 digits max,

c) Total quantity of debits - 4 digits max,

d) Total quantity of credits - 4 digits max,

e) The message numbers enclosing each total.

Note: Overflow of totals causes a roll over i.e. 999,999,999 99 + 1 = 0.

7.2.2 Balancing with the acquirers

7.2.2.1 Selective reconciliation

When a card acceptor wishes to balance with the acquirer(s), the reconciliation transaction is
selected (this shall be under the control of a supervisor and not instigated by accident or
maliciously). The card acceptor can then choose whether he wishes to reconcile with all the

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 69

PART 7: CARD ACCEPTOR FACILITIES 1 June 2007


acquirers or with only one particular acquirer. Individual reconciliation is useful if one or more
acquirers were not successfully reconciled at the first attempt or where further transactions
occurred after reconciling and a repeat of the reconciliation process to all acquirers may lead
to some unwanted reconciliation’s. No totals are printed for acquirers that are configured for
authorisation only.

7.2.2.2 Post-event versus real-time reconciliation

Once the decision (for selective or complete reconciliation) has been made by the card
acceptor, the terminal decides whether it needs to contact the acquirer and perform a real-
time reconciliation or whether the totals can be reconciled locally and then repeated as a
post-event repeat the next time the terminal contacts the acquirer. The conditions that have
to be met for the terminal to reconcile locally are:

a) the terminal agrees with the balance sent by the acquirer in the last real-time
response (balances not agreed imply some dispute),

b) the terminal successfully completed the last real-time transaction (an incomplete
transaction could lead to a reversal at the acquirer),

c) the terminal contains no stored post-event transactions. If the terminal contains any
stored post-event transactions, they shall be forwarded to the acquirer before they
can be reconciled,

d) the facility for post-event reconciliation has not been disabled.

These conditions apply whether or not any business has been done since the last
reconciliation. This means that a real-time reconciliation can be forced by reconciling twice in
succession. If the first reconciliation was post-event the second shall be real-time.

The reconciliation printout shall indicate a successful real-time reconciliation. The


reconciliation totals are reset on successful completion of a real-time or post-event repeat
reconciliation whether or not the totals agree.

7.2.2.3 Totals out of balance

If the quantity or amount of either the credit or debit acquirer totals stored in the terminal
differ from those sent in the reconciliation response from the acquirer, the terminal shall print
both the acquirer's totals sent in the response under the acquirer's name and the acquirer's
total stored in the terminal under the card acceptor name beneath the current and previous
totals and mark the print out 'SESSION TOTALS NOT AGREED'.

7.2.2.4 Communications failure

Prior to performing a real-time reconciliation the terminal will normally transmit any
transactions stored locally (see section 6.6.3.5 Post-event advices). However, if the terminal
fails to get through to a particular acquirer (after retries) the terminal shall still print the
session totals stored in the terminal but shall mark the print out 'SESSION TOTALS
UNCONFIRMED' and shall perform a local reconciliation. No further reconciliation shall be
stored locally until the stored reconciliation has been transmitted successfully. In the event of
a second transmission failure the terminal shall print 'CANNOT CONFIRM' under that
acquirer's name.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 70

PART 7: CARD ACCEPTOR FACILITIES 1 June 2007


If the reason for non-transmission requires the re-initialisation of the acquirer, first perform a
Z balance then delete or reset the acquirer. The session totals shall then be printed.

7.2.2.5 Examples of session and reconciliation totals

Figure 14 - Acquirer Sessions gives a pictorial example of what information is printed when
reconciliation is undertaken and what information is transmitted in relation to the acquirer's
business day (or session) and when the card acceptor decides to reconcile.

It details the printing of current and previous session totals and the reconciliation totals that
are transmitted to the acquirer.

ACQUIRER
ACQUIRER SESSION
1 2 3 4 5

CARD
A B C D E F G H I
ACCEPTOR
Rec Rec Rec Rec Rec
1 2 3 4 5

REC PREVIOUS TOTALS CURRENT TOTALS RECONCILIATION TOTALS


1 Unknown A Unknown
2 A+B C B+C
3 C+D E D+E
4 C+D E+F F
5 E+F+G+H I G+H+I

Figure 14 - Acquirer Sessions

7.2.2.6 Effect of deletion on reconciliation

Acquirer and card issuer datasets are deleted and configured separately. Thus deleting a
dataset in an active terminal has some bearing upon reconciliation and session totals. The
reconciliation totals are only held at the acquirer level. However, session totals are affected
by any dataset deletion.

The effects of deletion can be described by considering three instances:

a) delete card issuer and acquirer datasets,

b) delete a card issuer dataset,

c) reset acquirer dataset.

In a) all details concerning 'PREVIOUS', 'CURRENT' and 'STORED' totals shall be printed
on the delete slips, therefore reconciliation would consist of a manual comparison of these
totals with those held at the acquirer and which appear on the card acceptor's statement.
Message numbers do not appear with totals that refer to card issuer datasets but appear

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 71

PART 7: CARD ACCEPTOR FACILITIES 1 June 2007


when a reconciliation transaction or acquirer delete occurs. (Message numbers are an
acquirer function unaffected by deleting and initialising card issuer datasets).

In b) and c) two arrangements of the prints are considered:

a) card issuer and acquirer totals printed together,

b) totals printed separately.

Table 4 — Example reconciliation gives details where the totals represent simplified
sections of the printed slips. The stored transactions are repeated real-time.

The totals 'PREVIOUS', 'CURRENT' and 'STORED' are represented by the symbols P, C
and S respectively with the suffixes 'a' and 'c' referring to acquirer and card issuer
respectively. The following applies:

a) In all delete slips the total business done and due to the named card acquirer/issuer
within all sessions completed since the last reconciliation is in 'PREVIOUS',

b) In all delete slips the total business done and due to the named card acquirer/issuer
within the present session and advised to the acquirer is in 'CURRENT',

c) Any post-event details that are printed when deleting an acquirer are totalled in
'STORED'. The details are removed from the terminal,

d) A value in 'STORED' without any post-event transaction details represents the total
business done for the named card issuer not yet advised to the acquirer,

e) When deleting and re-initialising a card acquirer, the message numbers appearing on
the delete slip shall be held over to the next reconciliation when interpreting the
values in the printed totals,

f) Card acquirer/issuer delete slips can be identified by the presence/absence of


message numbers printed within the totals respectively,

g) Card acquirers/issuers are identified on a delete slip by their name.

7.2.3 Balancing card issuer datasets

The reconciliation and stored session totals are accumulated for all card issuer datasets in
the associated acquirer totals but the card acceptor totals and current and previous session
totals may be printed separately as configured in the terminal. See Appendix B.1.5 for how
totals can be linked.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 72

PART 7: CARD ACCEPTOR FACILITIES 1 June 2007


Table 4 — Example reconciliation slips
1. Totals Together 2. Totals Separate
Normal Reconciliation slips

ACQUIRER ACQUIRER
PREVIOUS Pa+Pc PREVIOUS Pa
TOTAL XXXX-YYYY-1 TOTAL XXXX-YYYY-1
CURRENT 0 Ca+Cc+Sa+Sc CURRENT 0 Ca+Sa
TOTAL YYYY-ZZZZ TOTAL YYYY-ZZZZ
CARD ISSUER
PREVIOUS Pc
CURRENT 0 Cc+Sc
Delete C.I. dataset

DELETE
CARD ISSUER As 'Together'
PREVIOUS Pc
CURRENT Cc
STORED Sc

RECONCILIATION As 'Together'
ACQUIRER
PREVIOUS Pa
TOTAL XXXX-YYYY-1
CURRENT 0 Ca+Sa
TOTAL YYYY-ZZZZ
Reset Acquirer

RESET
ACQUIRER
PREVIOUS Pa As 'Together'
TOTAL XXXX-YYYY-1
CURRENT Ca
TOTAL YYYY-ZZZZ
STORED Sa+Sc

RECONCILIATION RECONCILIATION
ACQUIRER ACQUIRER
PREVIOUS Pc PREVIOUS 0
TOTAL 0000-0000 TOTAL 0000-0000
CURRENT 0 Cc CURRENT 0
TOTAL 0001-0001 TOTAL 0001-0001
CARD ISSUER
(No extra business for sake of PREVIOUS Pc
example)
CURRENT 0 Cc

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 73

APPENDIX A: MINIMUM TERMINAL HARDWARE REQUIREMENTS 1 June 2007

A. MINIMUM TERMINAL HARDWARE REQUIREMENTS

A.1 EPOS SYSTEMS AND POST-EVENT TERMINALS

The principal components that shall be present are:

a) integrated circuit reader/writer capable of handling ISO 7816 / EMV compliant cards,

b) magnetic stripe reader capable of reading an ISO 7811-2 format track 2,

1. there shall be no damage inflicted on the card by the reader,

2. the reader shall be able to read data from cards at a range of swipe speeds
from a minimum of 10cms/second to 100cms/second or greater,

3. the reading shall not be affected by the presence of any secure card features,

c) keyboard with at a minimum the capability to enter numeric characters 0-9 (and
preferably alphabetic characters a-z and space) plus function keys for at least 'enter'
and 'cancel',

Note: Keys for specific functions e.g. sale or refund etc may be provided or these functions
may be selected from the display prompts by use of the function keys,

d) display with a minimum of 16 characters and preferably 32 (either as one line of 32


characters or 2 lines of 16 characters each),

Note: The acquirer can send up to 80 character messages to the terminal in response
messages, so the terminal needs to be able to display additional data by scrolling
longer messages in 16 or 32 character tranches.

e) printer for printing cardholder vouchers and card acceptor copies (with the cardholder
signature) See Appendix H for recommended voucher layouts,

f) PINPAD to allow for the user of a card to enter a PIN for the purposes of verifying the
user of the card,

1. the PINPAD can be hand-held or be in a fixed location separate to the


terminal keyboards,

2. it shall be designed to enable secure entry of the PIN in whatever position it is


located in normal operational use,

3. the interface between the PINPAD and the terminal shall be via a secure
connection,

4. see Standard 70 Book 5 for detailed specifications of a PINPAD,

g) modem or other communications interface for communications with an acquirer to


authorise and subsequently submit transactions,

Note: Where the communications is via the PSTN automatic dialling shall be provided
which is compatible with the specification for autodial mechanisms of the chosen
network provider.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 74

APPENDIX A: MINIMUM TERMINAL HARDWARE REQUIREMENTS 1 June 2007


h) optional socket for telephone attachment for voice referrals (or a means to prompt
the card acceptor to make a separate voice referral call).

A.2 REAL-TIME TERMINALS

A.2.1 General

Real-time terminals need to meet the requirements for post-event terminals defined above in
addition to the requirements defined below.

A.2.2 Connection to acquirer system

In order to effect a transaction, a terminal will need to establish a data communication link to
the appropriate acquirer. Terminals shall offer at least three modes of access (see Standard
70 Book 4):

a) via an application specific PAD - The terminal shall be able to perform an automatic
sequence which establishes a connection over the PSTN to an application specific
PAD dial up port and then establishes an X.25 connection to an acquirer system,

b) via a standard ITU-T X.25 PAD - As an alternative to a) above the same sequences
shall be possible to a standard ITU-T X.25 PAD,

c) direct PSTN connection to acquirer - In some instances acquirers will provide direct
access ports on the computer systems. Terminals shall provide an access routine in
which the protocols for communication via a) or b) above are bypassed,

d) alternatively communications with acquirers may be via a card acceptor local area, or
wide area network or public wide area network (for example broadband ADSL
networks).

A.2.3 Telephone network compatibility

Where a terminal uses the PSTN it shall be able to:

a) connect to the acquirer via an ITU-T X.25 network (see above),

b) undertake a voice referral call through a connected telephone, where this is an


option.

The terminal shall be able to detect (either directly or via configuration options) if a telephone
is connected or not and amend the voice referral facility accordingly.

The terminal shall be able to sense a busy line condition without impairing line conditions or
degrading signals transmitted on the line. When the terminal senses a busy line condition it
shall display the message 'LINE BUSY'.

An automatic dialling facility shall be supplied. Pauses before dialling and (on a PABX) after
dialling for an outside line shall be configurable. Dialling shall start before the expiry of pause
parameters if dial tone is detected first.

The terminal shall detect where possible all dial tones currently used in the UK.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 75

APPENDIX A: MINIMUM TERMINAL HARDWARE REQUIREMENTS 1 June 2007


Where a telephone is connected (and the terminal is used dial) to prevent unauthorised use
of the telephone for outgoing calls it shall be possible to bar calls (by configuration option),
whilst still allowing the use of dialling facilities for transactions, voice referrals and specific
numbers as specified by the telecommunications provider e.g. 999.

In addition any stored number entered prior to setting of the call barring facility shall be able
to be dialled.

A.2.4 Data communications capability

The terminal shall have a data communications capability as an integral part of the terminal
for transmitting data messages, appropriate for the network to which it is conntected. If
connection is via PSTN to connect with an ITU-T X.25 network then an ITU-T V22bis modem
unit shall be included as an integral part of the terminal. See Standard 70 Book 4 for
communications options.

A.2.5 Additional keys

The keys required for the handling of real-time transactions are given in Table 5 — Keys
required. The term 'keys' is used for simplicity but the functions may actually be provided by
menu lists or by other means as determined by the terminal manufacturer.

Table 5 — Keys required

Transaction keys Function keys


Sale Reconciliation
Numeric keys 0 to 9 X balances
Refund Z balances
Reversal Duplicate
Cash Advance Paper-feed
Cheque Guarantee Enter
Authorisation only Clear
Force Delete
Cancel
Programme
Alpha
Alternative Identification

Note: The above keys may be replaced by display prompts selected by such as a 'enter'
key.

At the discretion of the manufacturer terminals may provide other functions that are not
required in the handling of a transaction.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 76

APPENDIX A: MINIMUM TERMINAL HARDWARE REQUIREMENTS 1 June 2007


A.2.6 Memory

The terminal memory requirements fall into three distinct categories:

a) permanent (terminal specific) - the terminal identity is an eight digit numeric


sequence. Each terminal shall have a unique identity (see Standard 70 Book 7),

b) permanent (general data) - this category includes the basic microprocessor code and
a set of pre-defined data,

c) semi-permanent - two classes of semi-permanent data are required:

1. common data - a single set of data locations that are accessed during a
transaction for any card or for simple telephone operations,

2. datasets - each dataset shall consist of a number of locations for temporary


data that are updated during each transaction, and a number of 'semi-
permanent' values that provide the necessary parameters for processing a
transaction.

The operation of datasets is defined in Appendix B.

A.2.7 Audible alarm

An audible alarm shall be provided to enable card acceptor attention to be drawn to the
terminal, invalid data or message received as appropriate.

A.2.8 Data port

Optionally provision may be made to allow the terminal to connect to an associated EPOS
system via an RS232 connection (see Standard 70 Book 6).

A.2.9 Real-time clock

A 24-hour clock shall be incorporated into the terminal providing:

a) hours, minutes, seconds,

b) calendar - days, months, years,

c) automatic correction for the number of days in a month and leap years,

d) battery back up minimum of 30 days in the absence of mains power,

e) accuracy + 3 seconds per day.

A.2.10 Power supply

The terminal shall comply with all relevant national requirements for safety, interference and
connectivity to the power supply.

It is essential that, in the event of mains failure and total loss of power, any basic telephone
functions supported remain operational.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 77

APPENDIX A: MINIMUM TERMINAL HARDWARE REQUIREMENTS 1 June 2007


A.2.11 Terminal identity

A plate shall be permanently fixed to the base of the terminal giving the relevant statutory
details and a unique hardware terminal number. This number shall not be linked in any way
to the software terminal identity as defined in Standard 70 Book 7.

A.2.12 Diagnostic codes

The terminal shall maintain a record of problems that it shall print on a transaction voucher
(see Appendix H) in the form of a diagnostic code (see Appendix L). These help the acquirer
to diagnose problems when in discussion with card acceptors regarding the operation of the
terminal. The code shall be reset at the start of each new transaction.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 78

APPENDIX A: MINIMUM TERMINAL HARDWARE REQUIREMENTS 1 June 2007

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 79

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007

B. MINIMUM SOFTWARE REQUIREMENTS

B.1 GENERAL

With the introduction of IC card acceptance the configuration of terminals has become too
complex to be managed from a number of unrelated acquirer systems. Terminals are now
controlled and configured from bespoke terminal management systems, many including
software download facilities.

The means by which configuration data is input into a terminal is therefore a matter for card
acceptors and their terminal suppliers.

The concepts of datasets (developed to facilitate the configuration of first generation


terminals) are still, however, valuable and although a terminal may now be configured in a
proprietary way the terminal will still need to maintain the logical relationships between card
issuer, acquirer and card acceptor requirements. This document will therefore continue to
define the relationships between features and functions using these terms.

B.1.2 Dataset types

Throughout this document reference will be made to various types of datasets, in all cases
where the term dataset is used it means an actual dataset or its equivalent within a terminal
or system.

A terminal is required to have three types of dataset:

a) card acceptor dataset - for data common to all other datasets for example card
acceptor name and address,

b) acquirer dataset - for data specific to one acquirer / processor that is generic
configuration for example telephone numbers and network addresses,

c) card issuer dataset - for data specific to a card scheme or card product for example
IIN or PAN length.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 80

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


B.1.3 Dataset relationships

Figure 15 - Dataset relationships shows the relationships between datasets of different


types. The single card acceptor dataset is related to all acquirer datasets and the data
contained within it is available to all. The acquirer datasets may be a simple acquirer/issuer,
may support multiple card schemes, may support one complex card scheme or may support
multiple card schemes and card products.

Simple Acquirer/ Issuer Multiple Card Schemes Multiple Card Schemes


Complex Card Schemes
& Products

Merchant Acquirer Acquirer Acquirer Acquirer

Issuer
Issuer Issuer

Issuer Issuer Issuer Issuer

Issuer Issuer Issuer

Issuer Issuer

Issuer Issuer

Figure 15 - Dataset relationships

B.1.3.1 Simple acquirer/issuer

The simplest dataset is a single dataset definition (see Figure 16 - Simple acquirer/issuer)
that covers both acquirer data and card scheme data. A typical example of this is American
Express where all the transaction routing information and card product definition can be
contained within one dataset. In this case the card scheme IINs are a simple range, all
products within the scheme are processed in the same way at the POS and the acquirer only
processes this card type.

Acquirer / Issuer
Merchant
American Express

Figure 16 - Simple acquirer/issuer

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 81

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


B.1.3.2 Multiple simple card schemes

The next level of complexity is where one acquirer processes a number of ‘simple’ card
schemes (where the card scheme IINs and parameters are easily defined). Each Issuer
dataset shall contain the definition for one card scheme and shall be linked to the acquirer
for transaction routing information The transaction reconciliation and or reporting may be
linked or separate see section B.1.5.

M e rc h a n t A c q u ir e r

Is s u e r
M a s te rC a rd

Is s u e r
JC B

Figure 17 - Multiple simple card schemes

B.1.3.3 Complex card scheme

Some card schemes are complex in the range of IIN's that form the scheme and/or the
format of the card information e.g. UK Maestro (see Figure 18 - Complex card scheme). It
is not possible to adequately define all of these requirements within one card issuer
dataset and it is necessary to ‘chain’ a number of datasets together all linked to the
acquirer. For reconciliation and reporting these multiple Issuer datasets shall appear as a
single issuer dataset.

M e rc h a n t A c q u ir e r

Is s u e r
S w itc h R a n g e 1

Is s u e r Is s u e r
S w itc h R a n g e 2 S w itc h R a n g e 3

Is s u e r Is s u e r
S w itc h R a n g e 4 S w itc h R a n g e 5

Figure 18 - Complex card scheme

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 82

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


B.1.3.4 Multiple card schemes and products

The most complex relationship is where one acquirer processes multiple card schemes that
are in turn both simple and complex (seeFigure 19 - Multiple card schemes and products).
The complexity of this configuration is added to by the associated reconciliation and
reporting requirements.

Merchant Acquirer

Issuer Issuer Issuer


Issuer Issuer Issuer
Visa Delta Switch Switch Solo
JCB MasterCard Visa
Range 1 Range 1 Range 1

Issuer Issuer Issuer Issuer Issuer Issuer


Range 2 Range 3 Range 2 Range 3 Range 2 Range 3

Issuer Issuer Issuer Issuer Issuer Issuer


Range 4 Range 5 Range 4 Range 5 Range 4 Range 5

Figure 19 - Multiple card schemes and products

B.1.4 Dataset interaction

As facilities and functions can be configured at both acquirer and issuer level, rules have to
be established for the interaction between these datasets. In a complex configuration like
that shown in Figure 19 - Multiple card schemes and products acquirer may wish to support
certain functionality that is only allowed on one card issuer or product. On the other hand a
particular card product may require particular processing that shall override a more general
Acquirer configuration. The dataset interaction rules are defined in Table 6 — Dataset
interaction rules:

Table 6 — Dataset interaction rules


Interaction Acquirer Issuer Result

LOGAND (Logical And) N N N


N Y N
Y N N
Y Y Y
LOGOR (Logical Or) N N N
N Y N
Y N N
Y Y Y
ACQ (Acquirer Override) Use acquirer dataset
value and ignore
issuer.
ISSUER (Issuer Override) Use issuer dataset
value and ignore
acquirer

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 83

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


B.1.5 Totals linking

It shall be possible to link transaction total together in different ways to meet the card
acceptors reporting needs. The default for any acquirer shall be that all transactions are
added to a single total. Optionally the card acceptor shall be able to have different card
schemes and/or products added into sub-totals and the sub-totals into a grand total.

The configuration shall indicate which card issuers shall be linked together when printing X/Z
or session totals.

Reconciliation totals are accumulated for all linked datasets in the acquirer totals but totals
shall be printed separately if indicated by the configuration of the issuer dataset.

The default shall be that the card issuer session totals be added to the acquirer totals and
the acquirer name used. If issuer totals are linked in the configuration then all linked datasets
for that acquirer with the same value shall have their session totals added together and
printed under one sub-total using the name of the scheme or product defined. Issuers with a
unique linker configuration shall have their session totals printed separately. No totals shall
be printed if the acquirer is not configured for data capture. Table 7 — Totals linking gives a
typical example

Table 7 — Totals linking

Dataset Link value


Acquirer Not set (implicit link value 00)
Card Issuer 1 Not set (implicit link value 00)
Card Issuer 2 01
Card Issuer 3 00
Card Issuer 4 01
Card Issuer 5 02

Totals printed 1. Acquirer + C.I. 1 + C.I. 3under acquirer name


Totals printed 2. C.I. 2 + C.I. 4 under C.I. 2 name
Totals printed 3. C.I. 5 under C.I. 5 name

B.1.6 Security of terminal and data

The terminal shall be protected against unauthorised access. Card acceptor management
shall have access to the audit roll/advice printer by key lock but only authorised maintenance
personnel and the manufacturer shall have access to the remainder of the terminal.

Sensitive transaction types (e.g. refund and reconciliation) shall be allowed only after an
appropriate supervisor function e.g. swipe of a supervisor card, entering a password or the
use of a physical key.

B.1.7 Corrections

Keystroke errors shall be correctable by means of a cancel key. A single keystroke shall
cancel the last character entered. Two consecutive keystrokes shall cancel the entire input.
A third keystroke cancels the entire transaction. However, if there is only a single character

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 84

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


to be entered only one keystroke is required to cancel the entire input. Similarly, if there is no
data entered only one keystroke is required to cancel the transaction.

Alternatively a clear key may also be provided that shall clear the transaction at a single
stroke.

B.1.8 Communications via multiple systems

The assumption is that a terminal is communicating directly with an acquirer over a


communications network. However it is possible that messages are routed via intermediate
systems or third party processor.

In this situation the message shall be passed through untouched except for the Message
type data element that shall indicate that the transmission is a retry only if the intermediate
system itself has had to retransmit. It is, therefore, the responsibility of the intermediate
system to reset the message type received from the terminal and generate the correct one
for onward transmission.

Individual acquirers shall give approval to the use of intermediate systems and some may
not wish to accept authorisation requests resulting from such a configuration.

B.1.9 Use with multiple acquirers

Card acceptors are free to agree commercial terms with any number of acquirers. As such
cards processed under these agreements need to be routed to the correct acquirer.

The terminal shall automatically route transactions to different acquirers according to the
issuer of the card presented. The terminal will need to hold data in terminal memory for each
acquirer for such information as:

a) how to recognise the issuer and which is the relevant acquirer,

b) the scheme or scheme product name (for printing),

c) how to route calls to the acquirer.

B.2 CARD ACCEPTOR DATASET

B.2.1 General

The Card acceptor dataset contains global information that may be used by any of the other
datasets configured on the terminal. The data shall include some or all of the data elements
described in the following sections.

B.2.1.1 Card acceptor name

The trading name of the card acceptor, that is generally up to 16 alphanumeric characters.
This data shall be printed in bold letters on vouchers.

B.2.1.2 Card acceptor address

The address of the card acceptor outlet, that is generally up to 32 alphanumeric characters,
which shall be printed on vouchers.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 85

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


B.2.1.3 Courtesy message

The message printed on the voucher e.g. 'Thank you'.

B.2.1.4 Card acceptor message

Used by card acceptor for his or her own optional message e.g. 'Sale Starts Next Week'.

B.2.1.5 Transaction variable data

Alphanumeric characters used to input transaction data such as cashier/ticket number etc.

B.2.1.6 Stored telephone numbers

If the terminal supports integrated voice facilities then it shall support the storing of
commonly used telephone numbers.

B.1.2.7 PABX access digits

If the terminal is connected to the communications network by a PABX then the digits used
to access an outside line shall be stored here for use by all acquirer datasets.

B.2.1.8 Telephone signalling type

Identifies type of signalling used (i.e. pulse or tone dialling) and if a telephone is used.

B.2.1.9 Dial pause parameters

A parameter used to indicate a time delay between seizing the line and dialling, and/or
between dialling access digit/s and the main number.

B.2.1.10 Data port parameters

A parameter used to control a communications port to either an attached EPOS system or


an external modem (may include modem set-up strings).

B.2.1.11 Call barring indicator

If the terminal supports integrated voice facilities, it shall support the ability to bar certain call
types. Calls barred that shall be supported are:

a) None,

b) Numbers up to 5 digits but not beginning with 0 or 9,

c) Numbers up to 8 digits but not beginning with 0, 90, 100, 155, 9100, or 9155,

d) Numbers up to 11 digits but not beginning with 00, 155, 900 or 9155,

e) Numbers up to 4 digits but not beginning with 9,

f) All. Up to 16 digits if a stored number facility is used. Up to 24 digits if stored number


facility is not used. (Numbers 0, 151, 999, 9:999, 9999, 112, 9112 and 9:112 shall
always be allowed).

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 86

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


B.3 ACQUIRER DATASET

B.3.1 General

The acquirer dataset is used to store data specific to an acquirer.

B.3.2 Random transaction selection

The acquirer may, in addition to the floor limit, specify values that are to be used in
calculating whether the transaction shall be randomly sent real-time for authorisation:

a) target percentage to be used for random selection (in the range of 0 to 99),

b) threshold value for biased random selection (which shall be zero or a positive
number less than the floor limit),

c) maximum target percentage to be used for biased random selection (also in the
range of 0 to 99).

These values shall take into account, for each application, the relevant payment system
specified values. (See EMV Application Specification for detailed explanation of use.)

B.3.3 Application identities

If a terminal supports IC cards then the application identity (AIDs) of each of the card
applications supported shall be stored.

B.3.4 Card scheme public keys

If the terminal supports IC cards then it shall contain card scheme public key data. Refer to
EMV for maximum key sizes. Terminals shall be able to store a minimum of 40 scheme
public keys. For each key the terminal shall store:

a) RID (registered application provider identifier). Each scheme shall have its own RID,
and is the method of identifying which card scheme is used at the terminal. Scheme
products are further identified by the concatenation of a PIX to the RID that further
identifies scheme products,

b) exponent. A value assigned by the card issuer on card creation. Values are 3, 216+1,

c) hash check sum. An algorithm check installed in the terminal to verify the correct
value and installation of a scheme public key.

B.3.5 Data telephone numbers

Where the terminal supports dial-up operation the terminal shall store up to two telephone
numbers for each acquirer. The numbers may be the whole number required (including
PABX access digits) or just the PSTN portion of the number with the PABX access digits
being obtained from the card acceptor dataset.

When performing transactions the terminal shall try to establish communication with the
acquirer using the first data telephone number. If this first attempt fails the same number
shall be used for the second attempt. If a third attempt were required then the second data
telephone number shall be used.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 87

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


If all three attempts fail then communications shall be deemed to have failed.

For each of the data telephone numbers configured the terminal shall allow for dial-up
communications with:

a) PSTN access port to acquirer,

b) PSS PAD port access,

c) proprietary PAD access,

d) BT Special PAD.

If the terminal is only configured with one data telephone number then only two call attempts
shall be made.

B.3.6 Data network user addresses

When an X.25 packet switched network is used as the communications method, either in
conjunction with the data telephone numbers or via a communications port, a network user
address (NUA) is required. The terminal shall contain up to two NUAs with the first NUA
being used in conjunction with the first data telephone number or communications port call
attempts, and the second NUA with the second data telephone number or communications
port final call attempt. If only one NUA is present, this shall be used for both data telephone
numbers and all communications port call attempts.

B.3.7 Voice referral telephone number

It is possible the acquirer may require human intervention during the authorisation process.
This is indicated by a value in the Referral telephone number data element. It is possible that
a 'hold' message may be sent to lengthen the transaction timeout timer while an acquirer
decision is made. The final response message from the acquirer may then indicate if a voice
referral is required.

A 'hold' message (see Standard 70 Book 2) is an additional message sent prior to the final
response message to extend any terminal timeout timer and warn the card acceptor that the
response will take a little longer.

A voice referral shall cause the terminal to disconnect its data path and dial a separate
speech telephone number or indicate a telephone number to be dialled on a separate
telephone.

The card acceptor can then enter the transaction result via the keyboard for subsequent
submission.

For each acquirer it shall be possible to configure the terminal with a default telephone
number that is either dialled automatically or displayed if either a referral request be sent in
Referral telephone number data element as a response message as indicated in Appendix K
or the terminal is unable to complete the transaction without additional manual intervention.

The telephone number shall be stored as a three-part sequence that shall be indicated using
the field divider character (FD) to enable the number to be dynamically updated as part of
any referral response (the FD character is a Hexadecimal 12). The telephone number format
shall be as shown in Table 8 — Voice referral telephone number where:

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 88

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


a) A = PABX to exchange line access digit,

b) B = STD (Area) code for a trunk call,

c) C = Destination telephone number.

Table 8 — Voice referral telephone number

Contents Input sequence


ABC (Num sequence) (FD) (Num sequence) (FD) (Num sequence)
AB (Num sequence) (FD) (Num sequence) (FD)
AC (Num sequence) (FD) (FD) (Num sequence)
A (Num sequence) (FD) (FD)
B (FD) (Num sequence) (FD)
BC (FD) (Num sequence) (FD) (Num sequence)
C (FD) (FD) (Num sequence)
Empty NOT SET (Not set means no numeric value entered)

If the terminal does not support the use of updating referral numbers by the acquirer it shall
ignore any referral numbers sent in response messages and shall ensure that card
acceptors are prompted to dial the appropriate referral number if requested to do so by the
acquirer.

Note: Card acceptors with sophisticated EPOS systems may, subject to agreement by their
acquirers ignore the down-line loaded value in preference to using their own system
values.

B.3.8 Local count

The local count is the maximum number of transactions that can be stored locally in a
terminal for a particular acquirer and its associated issuers. Real-time authorisation is
required when the number of transactions stored is one less than or equal to the local count.

In the event of communications failure the terminal shall void the transaction if the number of
transactions stored is equal to the local count. Default value = 05.

B.3.9 Transaction limits and counts

For each acquirer the terminal shall be configured with a number of value limits.

B.3.9.1 Floor limits

The terminal shall support a minimum of one floor limit per acquirer ('pre-comms' limit) but
preferably two ('pre-comms' and 'post-comms' limits).

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 89

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


B.3.9.2 Down-line loaded terminal floor limit

Some acquirers provide an updated floor limit in the response message. Where a terminal
supports the use of down line loaded floor limits it shall hold a floor limit for each acquirer. All
floor limits shall initially be set to zero and may be updated by each subsequent response
from the acquirer in the Floor limit (pre comms) data element if it is an authorisation
transaction or Floor limit (pre comms and post comms) if it is a financial presentment
transaction.

The floor limit is one of the elements used to determine if a transaction is suitable for
authorisation by the terminal. The 'pre-comms' floor limit is used to manage communications
costs and the peak load on the acquirer. The 'post-comms' floor limit is normally higher and
is used to minimise the number of times the card acceptor has to revert to manual
procedures as a result of temporary acquirer or network unavailability.

In both cases, the terminal stores any financial presentment transactions for transmission
next time it contacts the appropriate acquirer. Such messages are identified as 'post-event
repeat' messages

Note: Card acceptors with sophisticated EPOS systems (who capture and submit their own
transactions) may, subject to agreement by their acquirers, ignore the down-line
loaded value in preference to using their own system values

B.3.9.3 Ceiling limit

The terminal shall support a maximum transaction value or ceiling limit of up to five digits
that defines the maximum value permitted for this acquirer and its associated issuers. The
default configuration shall be ceiling limit checking is disabled.

B.3.9.4 Exclusion band

The terminal shall support a band of values (in whole currency units, e.g. pounds) that shall
always require authorisation. The band shall contain a three digits lower transaction amount
limit and a three digit the upper transaction amount limit. Amounts greater than or equal to
the lower limit and less than the upper limit require real-time authorisation. The default shall
be that no checking takes place.

B.3.9.5 Cash pre-communications floor limit

The terminal shall support a pre-communications limit (in whole currency units, e.g. pounds)
for cash advances or the cash element of sale plus cash transactions. The limit shall be a
maximum of three digits and cash amounts greater than or equal to this value require real-
time authorisation. The default shall be no cash floor limit.

B.3.9.6 Cash-ceiling limit

The terminal shall support a cash ceiling limit (in whole currency units, e.g. pounds) for cash
advances or the cash element of sale plus cash transactions. Cash amounts greater than
this value shall cause the terminal to terminate the transaction. The default shall be no cash-
ceiling limit.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 90

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


B.3.10 Delay signature verification until end of transaction

This parameter enables or disables delaying the collection of the cardholder’s signature until
the transaction has been authorised/captured in environment where it is not possible for the
cardholder to sign on the terminal while the transaction is in progress.

B.3.11 Delay call set up until after amount entry

This parameter enables or disables the requirement to delay the setting up of the
communications link until the amount of the transaction has been entered.

B.3.12 Post-event reconciliation allowed

This parameter enables or disables the ability to perform post-event reconciliation.

B.3.13 Delayed cancel

This parameter enables or disables the ability to delay the termination of the communication
to the acquirer until after the response has been received and/or the confirmation message
has been sent.

B.3.14 Down-line loaded date

Some acquirers provide a date in the response message to enable a terminal to keep an
accurate local date in its memory. The date shall initially be set to zero and may be updated
by each subsequent response from the acquirer in the Date data element. The date shall be
used to check the validity of the expiry and start dates.

When the floor limit facility is in operation, the check is applied to all transactions subject to
local authorisation. Where the date entered is less than the stored date, the terminal shall
display an appropriate message (e.g. CALL CARD ISSUER). The date check operation is
linked to the floor limit indicator and is therefore disabled if the floor limit facility has been
disabled.

Note: Card acceptors with sophisticated EPOS systems may, subject to agreement by their
acquirers ignore the down-line loaded value in preference to using their own system
date.

B.4 ISSUER DATASET

There are no specific data requirements for issuer datasets that are not shared by equivalent
requirements for acquirer datasets.

B.5 ACQUIRER AND ISSUER DATASETS

B.5.1 General

It is possible for both an acquirer and an issuer dataset to be configured differently for the
same requirement. Appendix B.1.4 for how to decide which dataset takes precedence.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 91

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


B.5.2 Card ranges (ISSUER)

The terminal shall contain some form of card range identification that shall allow it to
correctly process and route transactions. This information shall be used to ensure that the
correct data in the correct format is collected.

B.5.2.1 IIN Ranges

The terminal shall be configured with the IIN ranges of the cards that it is able to accept and
process, this may also be known as a card ranging table.

When seeking a match between card PAN and dataset the terminal shall first scan the
longest numeric sequence and then others in descending length order until a match is found.
When configuring a terminal it is important to check for and ensure that there no overlapping
IIN numeric sequences.

B.5.2.2 PAN lengths

The configuration shall be able to define for each IIN range the PAN lengths for the cards
associated with that IIN. It shall be noted that some card schemes and therefore IINs support
more than one PAN length. A default of no PAN length checking may be used.

B.5.2.3 Issue numbers

Some card schemes use card issue numbers and it is necessary to be able to identify the
position and length of this number on track 2 of the magnetic stripe. Configuration of this
parameter shall also allow the determination of whether to prompt for the input of an issue
number on manual key entry of the data.

It is recommended that the configuration indicate the number of characters between the start
sentinel and the issue number and also the length of the number.

B.5.2.4 Start date checking

Some card schemes use either a start date or a validity period encoded on the magnetic
stripe and it shall be possible to define the position and format of the start date within the
card details.

It is recommended that the configuration indicate the number of characters between the start
sentinel and the start date data. Additionally the configuration shall define the format of the
data that may be in the format of:

a) MMYY,

b) YYMM,

c) A two-digit number at the assigned position on the account card representing the
number of months for which the card is valid. The validity check is to subtract the
number of months encoded from the expiry date and add 1, giving a calculated start
date.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 92

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


B.5.2.5 Service code checking

The terminal shall be configured to show if service code checking (see Appendix I) is
enabled. It is assumed that the service code is the first three digits immediately following the
expiry date on track 2.

B.5.2.6 Excluded card ranges

The excluded card ranges for an acquirer shall only be scanned once a match has been
found in the card issuer range. When seeking a match between card PAN and the dataset
the terminal shall first scan the longest numeric sequence and then others in descending
order until a match is found. If an equal or better match is found within the excluded ranges
than that found within the card issuer range the card shall be rejected.

B.5.3 Debit message printed (ISSUER)

Some card schemes require that formal messages 'Please Debit my account with the
amount shown' and 'Please keep a copy for your records' be printed on the cardholder’s
voucher. It shall be possible to configure these messages on or off by card issuer.

B.5.4 LUHN check operative (ISSUER)

Indicates if a LUHN check is to be performed.

B.5.5 OCD length (ISSUER)

This parameter defines the number of digits on track 2 that are not to be transmitted. (See
Standard 70 Book 6 for full description of end-to-end/break forward protection).

B.5.6 Position of expiry date (ISSUER)

Not all cards will be encoded with an expiry date on the magnetic stripe and if a date is
encoded its position, on the magnetic stripe, may vary. It shall support three conditions:

a) expiry date follows CFS (recommended default value),

b) no expiry date,

c) the number of characters on card between CFS and expiry date.

B.5.7 Terminal action codes (ISSUER)

If the POS supports IC cards then it shall be necessary to configure the terminal with
terminal action codes (TAC) that are used, in conjunction with IC data, to determine the
preferred actions and processing for the transaction. As acquirers may process a number of
different card types and products the acquirer dataset may contain TAC settings that define
the general processing requirements. Some card issuers or products may demand different
processing and this can be achieved by defining TACs at card issuer level (see EMV for
details of TAC definitions).

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 93

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


B.5.8 Track 2 printing (ISSUER)

This parameter defines the number of digits from track 2 that shall be printed on the voucher.
The count starts with the digit after the expiry date and does not include separators. Default
value shall be zero.

B.5.9 Address verification data collection (LOGAND)

This parameter enables or disables the requirement to collect CSC and address data on
PAN key entered cardholder not present transactions. If the data is collected then it shall be
sent in the Descriptive data data element of the request message.

B.5.10 Authorisation transaction types (LOGAND)

The terminal shall support at least the authorisation transaction type individually and in any
combination. For a full list of all permitted transaction types see Standard 70 Book 2,
message type codes.

B.5.11 Balance enquiry (LOGAND)

This parameter enables or disables the ability of the terminal to process and transmit
balance enquiry message types.

B.5.12 Cardholder verification (LOGAND)

For magnetic stripe initiated transactions if the terminal supports a PINPAD for (on-line
enciphered PIN with magnetic stripe use) then the method of cardholder verification (PIN or
signature) shall be configurable. The terminal shall be able to accept on-line enciphered PIN,
signature or both. If the terminal is able to accept both on-line enciphered PIN and signature
it shall also be possible to configure which is the default verification method. It shall be
possible to configure the following conditions:

a) signature only,

b) on-line enciphered PIN and signature - default signature,

c) on-line enciphered PIN only,

d) on-line enciphered PIN and signature – default on-line enciphered PIN.

If the acquirer dataset is configured for on-line enciphered PIN only or signature only then
the issuer dataset shall be configured in the same way to avoid conflict.

If cash advance is allowed as an authorisation only (i.e. non financial presentment) function
it shall not be allowed as a data capture function and vice versa.

B.5.13 Financial presentment transaction types (LOGAND)

The terminal shall support the following transaction types individually and in any
combination:

a) sale,

b) refund.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 94

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


For a full list of all permitted transaction types see Standard 70 Book 2, message type
codes.

B.5.14 Floor limit operative (LOGAND)

Indicates if the use of floor limits is allowed.

B.5.15 Force enabled (LOGAND)

This parameter enables or disables the ability of the terminal to accept transaction data for
transactions that have been previously authorised by an alternative method. All floor limit
and other value checks are not used and the transaction is stored for later transmission.

B.5.16 Gratuities (LOGAND)

This parameter enables or disables the ability to support a gratuity function. How this is
achieved will depend on the operating environment but in all cases space shall be allowed
on the voucher for the cardholder to enter a gratuity amount. This may be added to the
transaction amount immediately or the transaction may be saved then recalled later and the
amount of the gratuity added later. See section 6.10.4.2.4 Gratuity.

B.5.17 Key entry real-time (LOGAND)

This parameter indicates for each card issuer, card product and acquirer whether or not on
manual entry of the card details the transactions shall be sent real-time for authorisation
where the value is under the pre-comms floor limit. In the event of a call failure the terminal
shall not authorise and shall attempt to generate a voice referral.

B.5.18 Manual entry of card details (LOGAND)

This parameter enables or disables (for each card issuer, card product and acquirer) manual
entry of the card details.

B.5.19 Refund no cardholder request (LOGAND)

This parameter enables or disables the request message type allocated for refund
transactions where the cardholder is not present.

B.5.20 Reversals (LOGAND)

This parameter enables or disables the ability of the terminal to process and transmit
reversal message types.

B.5.21 Sale with cashback (LOGAND)

This parameter enables or disables the ability of the terminal to process and transmit sale
with cashback transactions.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 95

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


B.5.22 Transmit transaction variable data (LOGAND)

Transaction variable data allows for the printing and optional transmission of data such as
ticket numbers or cashier numbers; its use is dependent on the presence of the data in the
card acceptor dataset. It shall be used as defined in Table 9 — Transaction variable data

Table 9 — Transaction variable data

Configuration Terminal Operation


a) Empty/un-initialised No prompt shall be displayed
No input allowed
b) Fixed alphanumeric No prompt.
The alphanumeric characters are taken as fixed TVD (i.e. CASHIER 6).
c) Alphanumeric prompt The prompt shall be displayed as soon as an account number is entered.
d) Alphanumeric prompt A prompt is supplied for the input of variable data.
plus fixed alphanumeric
Fixed TVD may be present and the variable part added to it.
The prompt shall be displayed as soon as the account number is entered.

B.5.23 Authorisation post-event (LOGOR)

This parameter enables or disables the ability to complete the transaction post-event after a
communications failure. The default is that post-event authorisation is allowed.

B.6 POLLED ENVIRONMENT

B.6.1. Other card data (ISSUER)

This parameter enables or disables the collection and transmission of additional


discretionary track 2 data, for certain card products, in the data capture message.

B.6.2 Reference data (ISSUER)

This parameter enables or disables the prompting for and collection of additional transaction
reference data, for example seat number, that shall be sent in the data capture message.

B.6.3 Vehicle data (ISSUER)

This parameter enables or disables the collection and transmission of additional vehicle data
for the transaction. It shall be possible to configure and prompt for the collection of the
vehicle registration number and/or the vehicle mileage.

B.6.4 Airline ticket number (LOGAND)

This parameter enables or disables the prompting for and collection of an airline ticket
number that shall be sent in the data capture message.

B.6.5 EPOS transaction data (LOGAND)

This parameter enables or disables the transmission of EPOS card acceptor, location,
identity and voucher number the data capture message.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 96

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


B.6.6 Purchasing customer reference (LOGAND)

This parameter enables or disables the prompting for and collection of a purchasing
customers references number that shall be sent in the data capture message.

B.6.7 IC terminal configuration data

The introduction of IC Cards means that additional data elements and configuration values
have to be supplied to terminals. Table 10 — IC terminal configuration data lists those data
elements that need to be present and the configurations that need to be supported but not
how this will be achieved. The data elements quoted are those in EMV tables of data
elements and are of the same size.

Table 10 — IC terminal configuration data


Data element Notes
Acquirer identifier
Additional terminal capabilities
Application identifier (AID) (See Note 1)
Application version number
Certification authority public key
Certification authority public key check sum
Certification authority public key exponent
Certification authority public key index
Certification authority public key modulus
Default transaction certificate data objects list (TDOL) (See Note 2)
Maximum target percentage to be used for biased random selection
Card acceptor category code
Target percentage to be used for biased random selection
Terminal action codes
Terminal capabilities
Terminal country code
Terminal identification
Terminal risk management data
Terminal type
Threshold value for biased random selection
Transaction currency code (See Note 3)
Transaction currency exponent (See Note 3)

Note 1: The AID shall be used to determine which applications presented by an IC, are
supported by the terminal. However, the terminal can perform transaction routing via
the AID or the IIN, as preferred by the terminal design.

Note 2: An optional default TDOL list would be required for each scheme supported by the
terminal.

Note 3: These to be used as the default currency code and exponent unless replace by other
values selected as part of a multi-currency environment.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 97

APPENDIX C: TRANSACTION TIMES 1 June 2007


C. TRANSACTION TIMES

C.1 REQUIREMENT

APACS require that transaction times for an IC card used with a PIN shall be 'neutral' with
respect to a base transaction time, measured in a magnetic stripe environment. For further
guidance on the underlying architecture recommendations, see 'An integrated systems
architecture for acceptance of chip cards' (Teconomica Ltd for the British Retail Consortium,
July 1999).

This annex summarises best practice and recommends when and how transaction times can
be measured and assessed. It is acknowledged that the numerical measurement is only part
of the story and that qualitative impressions of relative timings are equally important.

The measurement of transaction times applies to all IC card and PIN transaction types and IC
card and PIN card types. Transactions that result in an exception condition (e.g. PIN retry,
PIN locked, referral) should be ignored, although they will have an effect on average
transaction times. The management of exception conditions will be treated separately from
that of transaction times.

C.2 MEASUREMENT OF TRANSACTION TIMES

Transaction times shall be measured from card insertion to card ejection.

For the manual readers that are used in the majority of points of sale, the card is not ejected
but removed by the card acceptor or cardholder. It is therefore recommended that where
timing is to be measured electronically, it be measured from the time the card is powered up
to the time it is powered down.

Similarly, the base transaction time for magnetic stripe cards should be measured from the
start of swiping to the completion of transaction processing. This completion processing
includes the printing of the voucher, signature by cardholder and acceptance by the card
acceptor, and the terminal returning to the ‘ready’ state for the next transaction.

In many environments, these times can be measured directly, with the help of a diagnostic or
'trace' mode set within the terminal software. An allowance should be made for the effects of
this diagnostic mode, which is likely to affect magnetic stripe and PIN transactions differently.

In other environments, it will not be possible to measure timings electronically; in these cases
a stopwatch may be used to measure the time from card insertion to the appearance of the
prompt 'Remove Card'.

A note should be taken of:

a) the average transaction time,

b) the spread of times (preferably as a standard deviation),

c) unit of measurement or resolution of measurement (stop-watch times should be taken


as accurate to no better than 0.25 seconds),

d) sample size, date and time and any other conditions relevant to the measurement
(e.g. was this measurement effected in a test or live environment?).

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 98

APPENDIX C: TRANSACTION TIMES ! June 2007


Where testing is carried out in live environments, it is also recommended that any
transactions in which exception conditions were met (including cardholder pressing CLEAR or
CANCEL) be recorded separately.

C.3 TRANSACTION TIME COMPONENTS

Thus defined, the transaction time includes:

a) card power-up and ATR,

b) application selection and fetch data (Get Processing Options),

c) card and terminal risk management,

d) PIN entry,

e) first cryptogram generation,

f) on-line authorisation (where necessary),

g) second cryptogram generation (where necessary),

h) card issuer script processing (where applicable),

i) completion processing (in this context includes the printing of the voucher and
powering down the card).

The card speed, terminal speed or both affect most elements of the transaction time. The PIN
entry is primarily a function of the cardholder, and it is expected that most cardholders will
become faster at PIN entry as they become used to the process. Each individual cardholder
may, however, be slower for the first one or two transactions, as the process is explained to
them. For benchmarking purposes, an experienced cardholder should be assumed, i.e. there
are no unnecessary delays or hesitations during PIN entry.

The real-time authorisation time is dependent on external networks, acquirer system loadings
etc, as well as the level of authorisations undertaken. It is recommended that these be
measured separately where practical, so that the effect of these factors can be understood.

Other factors such as printer speeds and the use of hot-card lists will cause transaction times
to vary among card acceptors, and local environmental factors will always come into play, so
that absolute figures are likely to be meaningless. It is also possible for some combinations of
card and terminal to be unusually fast or slow (Card A may be faster than Card B in terminal
X, but slower in terminal Y). However, some benchmark times will be valuable, and this
annex proposes some benchmark processes, with the aim of obtaining comparable figures at
card acceptor level.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 99

APPENDIX C: TRANSACTION TIMES ! June 2007


C.4 OPTIMISING TRANSACTION TIMES

C.4.1 Cards

It is found that different cards produce radically different transaction times. Many of the UKIS
cards used from 1997 to 2001 had very small RAM memory sizes, slow communications
paths, and whilst built to be EMV compliant were not optimised for speed. Most current-
generation cards (typified by VSDC and M/CHIP 4.0) are very much faster. UKIS cards
cannot be used for IC and PIN.

In order to optimise transaction times, card manufacturers, personalisation bureaux and


issuers should give attention to the following factors:

a) card hardware characteristics: cards shall have adequate RAM memory for
communications, and shall be able to undertake limited communications activities
(loading/unloading buffers) during processor activity,

b) communications protocols: cards shall support the maximum clock and


communications speeds permitted by EMV 4 (It is recommended that cards respond
to a cold reset with TA1=D4 in specific mode). However, APACS has concluded that
there is little difference in speed between character mode (T=0) and block mode
(T=1), and either may be supported (all UK card issuers are planning to use T=0
cards),

c) card file structure and data mapping: cards shall present their data to the terminal in
the order: Track 2 equivalent data, CVM list, RSA certificates, other data – see
Table 11 — Proposed card file read order. The data shall be contained in as few
records as possible consistent with this requirement.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 100

APPENDIX C: TRANSACTION TIMES ! June 2007


Table 11 — Proposed card file read order
Read only Data element Required for
1 Track 2 equivalent data
2 Issuer Country CVM list CVM
3 Application currency code CVM
4 Certification public key index SDA
5 Issuer public key certificate SDA
6 Issuer public key exponent SDA
7 Issuer public key remainder SDA
8 Signed application data SDA
9 Application effective date Processing restrictions
10 Application expiration data Processing restrictions
11 PAN Terminal risk management
12 PAN sequence number Real-time authorisation
13 IAC default Terminal action analysis
14 IAC denial Terminal action analysis
15 IAC on-line Terminal action analysis
16 Application usage control Processing restrictions
17 Issuer country code Processing restrictions
18 CDOL 1 Terminal action analysis
19 CDOL 2 Terminal action analysis
20 Application version number Processing restrictions
21 Cardholder name
22 Track 1 discretionary
23 Service code

Data not required for POS transaction processing should not be included in the application
data for card applications used only for POS transactions:

a) script processing: card issuers should only under very exceptional circumstances
send multiple scripts to cards. There are few practical instances where more than one
script will fit logically together,

b) cryptography: UK card issuers have agreed to use static data authentication (SDA)
initially. Dynamic data authentication (DDA) or combined dynamic data authentication
(CDA) should not be used except with higher specification cards incorporating a
dedicated cryptographic processor. The use of cards with Chinese remainder theorem
(a technique for improving processing times for RSA) is also likely to be a necessity
and is thus recommended,

c) multi-application cards: cards using a Multi-application operating system (e.g. Multos


or Javacard) are currently significantly slower than native operating systems. Next-
generation versions of these card types are expected to be more highly optimised and
should overcome these problems. Card issuers should ensure that any future plans to
issue multi-application cards require the use of fully optimised cards.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 101

APPENDIX C: TRANSACTION TIMES ! June 2007


C.4.2 Terminals and EPOS systems

The EPOS system, terminal and communications network also plays a major part in ensuring
a fast transaction time.

Hardware and software vendors, card acceptors and acquirers are advised to consider the
following points in order to optimise transaction times:

a) hardware characteristics: some EMV Level 1 IFDs are known to be slow, and this is
probably a function of any micro-controller, communications devices and buffer sizes.
8-bit micro-controllers are to be avoided, and 32-bit devices offer best performance.

b) technical architecture: it is impossible to be prescriptive about specific cases. Many


card acceptors will be constrained by existing equipment, by in-store network
architectures, etc. In some cases, the need for flexibility and future proofing may
dictate a sub-optimal timing solution, and this is the card acceptors decision. In
general, the fastest transaction times will be obtained by:

1. minimising the number of communications interfaces, particularly those


requiring buffering of card messages (APDUs),

2. ensuring that any cryptographic processes are carried out in the fastest
available hardware,

3. ensuring that as many activities as possible take place in parallel (through


multi-processing or the use of multiple processors). It is particularly important
that card communications and terminal processing should take place in
parallel.

c) communications speeds: for best performance, all terminals should support the
highest speeds allowed by EMV 4 (i.e. 38,400 bps) for communication with the card
(terminals should support specific mode and TA1 = D4.); all higher-level interfaces
should be at least as fast as this, and preferably considerably faster,

d) Cryptography: hardware and software implementations are both capable of achieving


good performance; however general-purpose microcontrollers in terminals will
frequently require a cryptographic co-processor. Benchmark times for a single RSA
verification on an 896-bit key are approximately 100 ms. Terminals shall be capable of
handling key lengths up to 2048 bits without serious degradation of performance,

e) printing operations: printing should, wherever possible, take place whilst the card data
is being read, terminal risk management is being carried out and during real-time
authorisation. The perception of transaction time is often as important to the
cardholder as the actual time taken,

f) hot card list: where a central hot card list is held by the card acceptor, any checks
carried out on this list for IC card transactions shall not form part of the terminal risk
management process; if the check fails, but the transaction has been allowed to
proceed locally, then the transaction shall be reversed and resubmitted with the
appropriate flag set,

g) cardholder insertion: card acceptors should consider modifying their processes in


order to permit cardholders to insert their cards earlier in the transaction, and thereby
allow card authentication to take place sooner.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 102

APPENDIX C: TRANSACTION TIMES ! June 2007

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 103

APPENDIX D: DISPLAYABLE MESSAGES 1 June 2007


D. DISPLAYABLE MESSAGES

The messages shown in this Standard are the basic message requirements of a device
complying with this Standard and are mostly generated by that device. Other messages may
need to be displayed as dictated by other standards e.g. EMV has a list of messages that a
device must display. Further messages will be returned as part of the authorisation response
by the card acquirer and their definition is also outside the scope of this Standard but they
shall also be displayed.

However, the messages defined here are, despite the use of the word “shall”, intended to
show minimum requirements and may be expanded upon if space permits on the card
acceptor and cardholder displays, subject to not losing the meaning of the message or its
clarity. An example of this would be to change “WIPE CARD” to “PLEASE SWIPE CARD”.

All messages shall be presented as the circumstances dictate, e.g. the prompt for PIN entry,
to effect the transaction process.

Not all messages will be shown to both cardholder and card acceptor e.g. “STORE FULL”
would only be appropriate for the card acceptor.

The ordering of messages may be dictated by the card schemes and this shall be followed
e.g. in the PIN messages.

As there may be a conflict between the message returned by the acquirer’s system and the
message to be displayed after final communication with an IC card the terminal shall not
display the message returned from the acquirer system until the final outcome of the
transaction is known.

There are, however, a number of messages that a terminal shall use in order that the general
application of real-time processing as defined in Standard 70 can be supported with a
multiplicity of terminal and computer systems.

Table 12 — Specific messages lists the messages that a terminal shall support and
Table 13 — Default messages lists the default messages and the conditions under which
they shall be used.

The messages contained in Table 12 — Specific messages and Table 13 — Default


messages are shown in upper case to identify them as display messages. It is preferable to
display messages, on the terminal or PIN pad, in mixed upper and lower case letters to
improve readability. It is also preferable to capitalise the first letter of all words in a key
instruction, for example the message shown as ‘PLEASE WAIT’ in this standard should
appear as ‘Please Wait’ on the terminal display.

Messages shall be displayed for 30 seconds when the display shall be cleared. The last
message shall be displayable once only upon depression of a recall button. This shall clear
the message so that it cannot be displayed again.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 104

APPENDIX D: DISPLAYABLE MESSAGES 1 June 2007


Table 12 — Specific messages

Message text Usage


AUTH CODE: nnnnn Used to display the contents of the Authorisation code data element or, where a
transaction is approved by the terminal, the calculated code as defined in
Appendix J
CALL AUTH CENTRE Used whenever a transaction has begun but a connection cannot be established
with the relevant acquirer.
This may be because the transaction fails internal validations or that it is not
possible to establish a communications link or the link fails at any stage up to
the time a response message is received from the acquirer.
This message shall also be displayed where the acquirer has requested a voice
referral but a handset facility is not available
CALL CARD ISSUER Used whenever a card issuer is the only organisation that can assist the
cardholder
CALL HELP DESK Used when it is a terminal problem that needs specialist assistance to resolve.
CARD NOT AUTHORISED Transaction not approved (see DECLINED)
CASHBACK Used to prompt cashier or cardholder to request cashback
CHECK SIGNATURE Used to prompt for visual verification of the signature when a cheque guarantee
authorisation has been requested
COMPLETED Used on the PINPAD display to indicate that the transaction has finished.
This message shall be displayed when the contents of the PINPAD data data
element is displayed on the terminal
CONNECTION MADE Used when the terminal receives the ENQ message.
If the data entry phase has still not been completed at this stage, the terminal
shall wait until data entry has been completed before continuing with the
transmitted sequence.
CONNECTION MADE shall not be displayed until data entry has been
completed but the card issuer or acquirer name shall be omitted if the
CONNECTION MADE stage has been reached
DECLINED Printed/displayed on completion of a voice referral where the acquirer/issuer/
card has declined the transaction and the card acceptor has indicated this to the
terminal
DECLINED BY CARD – Printed/displayed when a transaction is terminated by the card prior to any
CARDHOLDER SHOULD connection to the acquirer. This is controlled by internal IC security parameters
CONTACT ISSUER
DIALLING or Used on receipt of a response including a value in the down-line loaded
LIFT RECEIVER telephone number data element.
The terminal shall display DIALLING and the number dialled, which shall change
to LIFT RECEIVER at the appropriate time, followed by any message in the
Message data element
DO NOT REMOVE CARD Warns cardholder/cashier not to remove card
ENTER AMOUNT Used to prompt for amount entry
ENTER PIN Used whenever cardholder is required to enter their PIN number
ESTIMATED MAXIMUM Used in hotels and card hire when the cardholder checks in
AMOUNT £XXX.XX or
MAX AMOUNT £XXX.XX
EXPIRES MM/YY Used to prompt for expiry input from the keyboard

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 105

APPENDIX D: DISPLAYABLE MESSAGES 1 June 2007

Message text Usage


GRATUITY? Used in restaurants to allow cardholders the opportunity to give a gratuity
ENTER/CANCEL
INSERT AGAIN Used to indicate that the IC has not been read successfully
INSERT CARD Used in the point in the procedure where card input is required for an IC card
ISSUER DECLINE – Printed/displayed on completion of a transaction where the issuer has declined
CARDHOLDER SHOULD the transaction
CONTACT ISSUER
ISSUE NUMBER Used to prompt for entry of the issue number from the keyboard
KEY CARD NUMBER Used to indicate that the magnetic stripe has not been read successfully three
times
LAST PIN TRY Warns cardholder that they are about to have a final attempt at entry before the
PIN maybe locked
LINE BUSY ‘Used to indicate that the telephone line to which the terminal is connected is
already in use
LOADING Used to indicate the terminal is receiving configuration data from a remote
computer
MANUAL PROCEDURE or Used when a transaction is started but the terminal has no configuration data
PLEASE INITIALISE too enable a call to be initiated.
Terminal manufacturers may include a facility for the terminal to recognise a
completely un-initialised state and display an appropriate prompt to force
initialisation by displaying 'PLEASE INITIALISE' (or 'PSE INITIALISE' if only 16
digits of display are available)
MAXIMUM £XX – PLEASE Used in petrol pumps to indicate the maximum value that the transaction can be
ENTER PIN' completed for
OPEN TAB MAXIMUM Used in bars and restaurants to advise the cardholder of the maximum amount
£XX.XX ENTER PIN' they may be charged, when a card is held behind the bar until the final payment
is made.
PASS CARD TO CASHIER Used to prompt cardholder to hand card to cashier
PIN ERROR or INVALID PIN Used to indicate an incorrect PIN has been input
PIN LOCKED Where a PIN is locked in the current or previous transaction
PIN OK Use to signify that PIN entry was correct
PLEASE WAIT Used on receipt of a 'hold' message with an empty Message data element
otherwise the terminal shall display the Message data element contents.
PREPARE VOUCHER Used to prompt the card acceptor to complete a voucher set when the terminal
has only been configured for authorisation for that card
REFERRAL Used to inform the card acceptor that a referral is needed or is underway
REMOVE CARD Used to prompt either cardholder or cashier to remove card from chip reader
REQUEST INVALID Used to indicate that the requested transaction is not supported for the card
presented
RIGHT WAY ROUND A terminal manufacturer option. Used to indicate no stripe detected.
SELECT PAYMENT TYPE Used were multiple payment options are available from a single card e.g. credit,
debit or purse

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 106

APPENDIX D: DISPLAYABLE MESSAGES 1 June 2007

Message text Usage


SESSION TOTALS Used during a reconciliation to advise the card acceptor of the status of the
reconciliation transaction
NOT AGREED
UNCONFIRMED
CANNOT
CONFIRM
SORRY FOR DELAY Used after any failed call attempt. It shall be displayed until connection is made
or all call attempts fail when either CONNECTION MADE or CALL AUTH
CENTRE shall be displayed
STORE FULL Used to advise the card acceptor that the post-event store of transactions is full
and the terminal needs to call the relevant acquirer.
SUPERVISOR CARD Used to prompt the swiping or insertion of the supervisor card in order that
certain functions can proceed
SWIPE AGAIN Used to indicate that the magnetic stripe has not been read successfully
SWIPE CARD Used at the point in the procedure where card input is required for a magnetic
stripe card
TRANSACTION COMPLETE Signifies that transaction has been completed
TRANSACTION VOID Used if the transaction is cancelled at the terminal prior to completion of a voice
referral
UNABLE TO AUTHORISE Used if the transaction is cancelled by the IC card after real-time authorisation.
UNABLE TO GO ONLINE, Maybe used to provide futher advice on how the transaction has been
OFFLINE APPROVED processed
UNABLE TO GO ONLINE, Maybe used to provide futher advice on how the transaction has been
OFFLINE DECLINED processed
VALID FROM MM/YY Used to prompt for the start date from the keyboard

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 107

APPENDIX D: DISPLAYABLE MESSAGES 1 June 2007


Table 13 — Default messages
RESPONSE CODE CARD ACCEPTOR PRINTER PINPAD
DISPLAY
00) Contents of Card acceptor Contents of Card acceptor COMPLETED
08) Authorised display data element printer data data element
11) (see Note 2) (see Note 2 and 3)
01) PLEASE WAIT AUTH CODE:nnnnn or PLEASE WAIT
02) Referral followed by DECLINED or followed by
60) Contents of Card acceptor TRANSACTION VOID COMPLETED or
display data data element (see Note 1) DECLINED
(see Note 2) (see Note 1)
55 (PIN retry) PIN ERROR (No Printing) ENTER VALID PIN
Comms failure AUTH CODE:nnnnn As card acceptor display COMPLETED
(below floor limit)
Comms failure CALL AUTH CENTRE TRANSACTION VOID TRANSACTION VOID
(above floor limit)
Cancellation CANCELLED TRANSACTION VOID CANCELLED
Hold message PLEASE WAIT (No Printing) PLEASE WAIT
Reconciliation COMPLETED COMPLETED COMPLETED
Any other Contents of Card acceptor Contents of Card acceptor DECLINED
display data data element printer data data element
(see Note 2) (see Note 2 and 3)

Note 1: Message printed/displayed on completion of voice referral. 'nnnnn' represents the


authorisation code entered by the card acceptor. Replaced for the following
transaction types, e.g.

a) refund: REFUND ACCEPTED,

b) refund reversal: REFUND REVERSAL ACCEPTED,

c) other reversal: REVERSAL ACCEPTED,

d) on the display, the word 'ACCEPTED' is always displayed on the second line.

Note 2: The Card acceptor display data and Card acceptor printer data data elements are
both part of the Message data element. The construction of the Message data
element is shown in Standard 70 Book 2.

Note 3: Contents of Card acceptor display data data element may be used if Card acceptor
printer data data element is not present.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 108

APPENDIX D: DISPLAYABLE MESSAGES 1 June 2007

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 109

APPENDIX E: TERMINAL FALLBACK PROCEDURES 1 June 2007

E. TERMINAL FALLBACK PROCEDURES

There is a preferred hierarchy of data input methods with decreasing security features i.e. IC
read, magnetic stripe read, manual key entry.

Terminals shall use the highest method available based on card and terminal capabilities.
Increasingly this will be IC read with fallback to magnetic stripe read. Fall back to manual key
entry is being phased out as IC cards are introduced. Terminal suppliers and card acceptors
shall confirm with their acquirer which options are acceptable and configure their terminals
accordingly

E.1 CONDITIONS FOR IC FALLBACK TO MAGNETIC STRIPE

Scheme rules shall determine the situations when fallback from IC to magnetic stripe is
allowable from the situations when the card shall be rejected e.g. if the terminal processing
fails, due to a card error, after an IC application has successfully been selected then fallback
shall not be allowed, i.e. the transactions shall be rejected.

When fallback takes place in an IC capable terminal the transaction shall be flagged as
fallback to the acquirer so that the issuer can identify it is a fallback transaction.

Note: the terminal can flag fallback to the acquirer in the POS entry mode (value 8n Swipe –
IC failure) data element (See Standard 70 Book 3) and/or the Reason Code (value 04
– terminal not able to process IC) data element (See Standard 70 Book 2).

All IC / magnetic stripe fallback transactions at chip enabled attended payment terminals shall
be authorised either real-time or by a voice referral.

Fallback from IC to magnetic stripe shall not be available at chip enabled unattended
payments terminals (CAT’s). These terminals shall reject a magnetic stripe card with a
service code of 2xx or 6xx.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 110

APPENDIX E: TERMINAL FALLBACK PROCEDURE 1 June 2007

ICC MSR

Check Service Code

Read Failure?

Reset last read


Yes 2 or 6? No
failure

Set "last read failure"


indicator
Yes Continue with
MSR

Prom pt ICC "Last Read


No
Reader Failure" set?

Prom pt for MSR


STOP
No

Prom pt Op. for


Override, Y/N
STOP

Optional

Override Reset last


No
option taken read failure

Yes Reject

Reset last read failure

Continue with ICC


Continue on MSR
following conditions
detailed below

Figure 20 - Processing flow for IC read failures

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 111

APPENDIX F: CARD SCHEME IDENTIFICATION 1 June 2007

F. CARD SCHEME IDENTIFICATION

F.1 INTRODUCTION

It is the responsibility of the acquirer to advise how to identify the cards for which he takes
responsibility.

In the normal course of events this is achieved by means of Operating Instructions, which
display the various card scheme logos for easy visual identification. These may include Visa,
MasterCard, UK UK Maestro, Maestro International, JCB, Solo, Diners Club, American
Express, plus the relevant private label card plans.

With the ever-increasing range of cards on the market, it is becoming increasingly complex
for a card acceptor to be sure that the correct cards are accepted, and perhaps more
importantly, not accepting incorrect cards.

This complexity is reflected at the electronic level where it is becoming increasingly difficult for
terminal suppliers and software providers to easily identify cards and their appropriate card
schemes.

This annex seeks to identify how cards can be related to card schemes. However the final
point of contact shall be the card acceptor’s acquirer(s).

This document supports financial payment cards. It is not intended to support other card
products e.g. ATM only and/or E-top-up cards. Card acceptors need to differentiate between
card products to:

a) identify the acquirer,

b) apply appropriate POS rules (e.g. cashback),

c) correctly group transactions for reconciliation,

d) display correct narrative on receipts/displays.

F.2 ISSUER IDENTIFICATION NUMBER

Card issuers allocate numbers to cardholders that may be embossed and encoded on the
cards they issue (Note some cards need not be embossed).

These numbers consist of an IIN followed by a cardholder number, followed by a LUHN check
digit. Full details can be found in the International Standard Number ISO 7812-1.

The point of significance is that the IIN is an issuer number and not specifically a card
scheme number.

It is emphasised that this is a fast changing environment. Details shall always be confirmed
with the relevant acquirer.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 112

APPENDIX F: CARD SCHEME IDENTIFICATION 1 June 2007


F.3 REGISTRATION AUTHORITIES

IIN's are allocated under the authority of ISO by Registration Authorities. Each national
standards body has authority over its own national ranges. In the UK the national registration
authority is provided by APACS.

For further information on airline, store, fuel and other card types, please contact APACS and
request: ‘List of UK Card Issuer Identification Numbers – Alpha and Numeric Listing’.

F.4 CURRENT CARD SCHEME IIN'S

These tables shows the specific checks required to identify the cards scheme and/or product,
the validation checks required, the transaction types and any additional checks that are
required when they are not permitted.

They have been separated into Visa, MasterCard/Maestro, Solo, JCB, American Express and
Diners.

In all instances the acquirer will be able to provide further details (e.g. on the layouts of Track
2) and will have the most up to date information.

It is strongly recommend that all these elements are configurable

F.4.1 General Notes

Service Codes: The location of the service code may vary on Track 2 and is only used on
a magnetic stripe read of the card.

Details on how to check the service codes are outlined in Appendix I:


Use of Service Codes; the acquirer may have more specific
requirements.

PAN Length : PAN Lengths may vary and this will impact on the layout of Track2.

LUHN check: Details of the LUHN check digit formula can be found in Appendix G:
LUHN Formula

Expiry Date: The location of the expiry date varies according to the PAN length.

Contact the acquirer for a suggested expiry date checking algorithm.

Issue Number: The location of the issue number, when available in Track 2, varies.

Contact the acquirer for further details.

Validity The location and format of the start date, when present on Track 2,
Period/Start Date: varies according to the issuer.

Contact the acquirer for a suggested checking algorithm and for Track 2
layouts.

Card Security See Standard 70 Part 2 and contact the acquirer for more information on
Code: the Card Security Code processes.

Address See Standard 70 Part 2 and contact the acquirer for more information on
Verification: the Address Verification processes.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 113

APPENDIX F: CARD SCHEME IDENTIFICATION 1 June 2007


F.4.2 Glossary

Yes Check must be performed

No Check must not be performed – data may not be present, is not reliable
or is not supported by the scheme.

Optional If appropriate to the processing environment eg Card Security Code is


usually only checked in a keyed CNP environment.

If present The presence of the data depends on the specific IIN range and shall be
checked if present. The acquirer will be able to provide more detail on
when this data can be expected.

Barred The use of this scheme for this function is prohibited.

By Agreement The use of this scheme for this function (eg purchase with cashback)
requires special agreement of the acquirer.

Supported The device can expect to provide this functionality for this scheme.

Not Supported The scheme does not currently support this functionality.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 114

APPENDIX F: CARD SCHEME IDENTIFICATION 1 June 2007


Table 14 – Visa IIN ranges
Visa
UK Visa UK Visa V-PAY Visa
Debit Card Electron
Standards ISO 7810-3 7810-3 7810-3
Scheme IIN ranges: 413733-37 450875 V-PAY product All remaining IIN’s
Identification IINs may start with beginning with 4,
446200-99 484406-08 a’5’ or ‘6’. except those listed
453978-79 484411-55 below.
V-PAY cards have
454313 491730-59 two AIDs (V-PAY
and Electron),
454432-35 491880
454742
456725-45
465830-79
465901-50
484409-10
490960-79
492181-82
498824
Validation Service Codes: Yes Yes Yes Yes
PAN length: 16-19 16-19 16-19 16-19
LUHN check: Yes Yes Yes Yes
Expiry date: Yes Yes Yes Yes
Issue number: No No No No
Validity period: No No No No
Card security Optional Optional Optional Optional
code:
Address Optional Optional Optional Optional
verification:
Transaction Purchase with By By By Agreement Barred
Types Cash Agreement Agreement
Method of Entry Magnetic Supported Supported Not supported Supported
Stripe Read
Keyed Card Supported Supported Not supported Supported
Not Present
Keyed Swipe Supported Supported Not supported Supported
Failure
Cardholder Supported Supported Not supported Supported
Keyed to
Internet
EMV Chip Supported Supported Supported with Supported
PIN verification
Internet 3D Secure Supported Supported Supported Supported
Cardholder
Verification

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 115

APPENDIX F: CARD SCHEME IDENTIFICATION 1 June 2007


The following table provides known UK Visa ATM BIN ranges. Please bear in mind that this
is not a full range and that your terminal/equipment should be reading the application usage
control and service code.

Table 15 – Visa exceptions


Exceptions
(Known UK Visa ATM only Cards)
490300-1 491100-02
490310-34 491103-73
490340-99 491183-99
490400-09 492183
490419 492800-99
490451
490459
490467
490475-78
490500-99
491001

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 116

APPENDIX F: CARD SCHEME IDENTIFICATION 1 June 2007


Table 16 - MasterCard IIN ranges
MasterCard & Maestro

MasterCard UK Maestro Maestro


International

Standards ISO 7810-3 7810-3 7810-3

Scheme Identification IIN ranges: Note 1 510000- 500000-509999


559999
675900-99 560000-589999

600000-699999

Validation Service Codes: Yes Yes No

PAN length: 16 16, 18 or 19 Any

LUHN check: Yes Yes No

Expiry date: Yes Yes No

Issue number: No If Present No

Validity period: No If Present No

Card security code: Optional Optional No

Address verification: Optional Optional No

Transaction Types

Shows where additional checks are required and when they are not permitted

Financial Purchase with Cash Barred By By Agreement


Agreement

Method of Entry Magnetic Stripe Read Supported Supported Supported

Keyed Card Not Present Supported Supported Refunds only

Keyed Swipe Failure Supported Supported Refunds only

Cardholder Keyed to Supported Supported By Agreement


Internet

EMV Chip Supported Supported Supported

Internet Cardholder 3D Secure Supported Supported Supported


Verification

Note 1: Where the UK Maestro IIN Ranges fall within the Maestro International Ranges, the
UK Maestro processing takes precedence.

Note 2: All International Maestro purchase transactions must be sent to the acquirer for
authorisation; card-acceptor stand-in is not permitted.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 117

APPENDIX F: CARD SCHEME IDENTIFICATION 1 June 2007


Table 17 - Solo IIN ranges
Solo

Standards ISO 7810-3

Scheme Identification IIN ranges

676700-99

Validation Service Codes: Yes

PAN length: 16, 18 or 19

LUHN check: Yes

Expiry date: Yes

Issue number: If Present

Validity period: If Present

Card security code: Optional

Address verification: Optional

Transaction Types

Shows where additional checks are required and when they are not permitted

Financial Purchase with Cash By Agreement

Method of Entry Magnetic Stripe Read Supported

Keyed Card Not Present Supported

Keyed Swipe Failure Supported

Cardholder Keyed to Internet Supported

EMV Chip Supported

Internet Cardholder Verification 3D Secure Supported

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 118

APPENDIX F: CARD SCHEME IDENTIFICATION 1 June 2007


Table 18 - JCB IIN ranges
JCB

Standards ISO 7810-3

Scheme Identification IIN ranges: Note 1 352800-358999

Validation Service Codes: Only check on a chip-


enabled device.

PAN length: 16

LUHN check: Yes

Expiry date: Yes

Issue number: No

Validity period: No

Card security code: Optional

Address verification: No

Transaction Types

Shows where additional checks are required and when they are not permitted

Financial Purchase with Cash Barred

Method of Entry Magnetic Stripe Read Supported

Keyed Card Not Present Supported

Keyed Swipe Failure Supported

Cardholder Keyed to Internet Supported

EMV Chip Supported

Internet Cardholder Verification 3D Secure Optional

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 119

APPENDIX F: CARD SCHEME IDENTIFICATION 1 June 2007


Table 19 - American Express IIN ranges
American Express

Standards ISO 7810-13

ANSI

Scheme Identification IIN ranges: 370000 - 99

340000 - 99

Validation Service Codes: Yes

PAN length: 15

LUHN check: Yes

Expiry date: Yes

Issue number: No

Validity period: No

Card security code: Optional

Address verification: Optional

Transaction Types

Shows where additional checks are required and when they are not permitted

Financial Purchase with Cash Barred

Method of Entry Magnetic Stripe Read Supported

Keyed Card Not Present Supported

Keyed Swipe Failure Supported

Cardholder Keyed to Internet Supported

EMV Chip Supported

Internet Cardholder Verification 3D Secure No

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 120

APPENDIX F: CARD SCHEME IDENTIFICATION 1 June 2007


Table 20 – Diners IIN ranges
Diners

Standards ISO 7810-3

Scheme Identification IIN ranges: 3045


36
38

Validation Service Codes: Yes

PAN length: 14

LUHN check: Yes

Expiry date: Yes

Issue number: No

Validity period: Yes

Card security code: Yes

Address verification: No

Transaction Types

Shows where additional checks are required and when they are not permitted

Diners

Financial Purchase with Cash No (Cash Advance permitted)

Method of Entry Magnetic Stripe Read Supported

Keyed Card Not Present Supported

Keyed Swipe Failure Supported

Cardholder Keyed to Internet Supported

EMV Chip Not supported

Internet Cardholder Verification 3D Secure Not supported

Notes:
1 Transactions initiated with a card may not be declined by the terminal or card acceptor
processors as a result of edits or validations performed. There is an Exceptions table,
Table 15 – Visa exceptions which identifies known UK ATM Visa IIN exceptions.
2 Track 2 layouts vary. For further details please contact your Acquirer
3 Available for magnetic stripe read transactions.
4 The LUHN Check algorithm is available from your Acquirer.
5 Details of service code checking and failure responses are available from your acquirer.
6 A suggested expiry date algorithm is available from your acquirer.
7 Details of how to check the validity period are available from your acquirer.
8 Specifications are available from your Acquirer.
9 UK Maestro/Solo ranges take precedence over International Maestro ranges i.e. use
Domestic Maestro rules
10 Visa propose to utilise longer PAN lengths in the future. We recommend this attribute is
configurable

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 121

APPENDIX F: CARD SCHEME IDENTIFICATION 1 June 2007

11 Transactions initiated with a card may not be declined by the terminal or card acceptor
processors as a result of edits or validations performed
12 JCB service codes must only be validated if the device is capable of processing JCB
chip cards
13 The customer must have prior agreement from your acquirer
14 The purchase element must be greater than zero and the cash element may have an
upper limit.

F.5 IDENTIFICATION OF UK/FOREIGN ISSUED IC CARDS

With the introduction of IC cards it is possible to determine the country of origin of the card by
interrogating the Issuer country code data element. This is important, as scheme rules for
fallback may differ between UK and overseas issued cards, e.g. for CVM fallback.

It is possible to identify UK cards by an Issuer country code of value 826. However, this data
element is optional for the card and, therefore, terminals cannot rely on its being present.

If the IC card encoding does not contain the Issuer country code then the terminal will not be
able to identify a card as being UK issued.

Only cards that contain the Issuer country code with a value of ‘826’ shall be regarded as a
UK card. All other cards shall be considered as non-UK in of terms of following scheme
requirements.

With regard to technology fallback, it is not possible to identify UK cards reliably through the
magnetic stripe only, and terminals shall not attempt to do this.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 122

APPENDIX F: CARD SCHEME IDENTIFICATION 1 June 2007

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 123

APPENDIX G: LUHN FORMULA 1 June 2007

G. LUHN FORMULA

G.1 LUHN FORMULA FOR CALCULATING THE PAN CHECK DIGIT

The following steps are involved in this calculation, which applies to any length PAN:

a) double the value of alternate digits beginning with the first right-hand digit (low order),

b) add the individual digits comprising the products obtained in a) to each of the
unaffected digits in the original number,

c) subtract the total obtained in a) from the next higher number ending in 0 (this is the
equivalent of calculating the 'ten complement' of the low order digit (unit digit) of the
total),

d) the resultant digit is the PAN check digit that should equal the last digit of the PAN.

Note: If the total obtained in a) is a number ending in zero (30, 40 etc.), the check digit is 0.

G.2 EXAMPLE CALCULATION

Account Number without check digit 4992 739 871

4 9 9 2 7 3 9 8 7 1 Step

x2 x2 x2 x2 x2 1 – double value of alternating


digits

18 4 6 16 2

4+ 1+8 +9 +4 +7 +6 +9 +1+6 +7 +2 = 64 2 – Add individual digits

3 – Subtract 64 from 70 = 6

Account number is therefore 4992 739 8716

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 124

APPENDIX G: LUHN FORMULA 1 June 2007

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 125

APPENDIX H: PRINTED DATA 1 June 2007

H. PRINTED DATA

H.1 GENERAL REQUIREMENTS

H.1.1 Number of copies

A paper record shall be produced for every transaction performed and this shall contain all
the information necessary to provide a completed audit trail enabling cardholders, card
acceptors or acquirers to resolve queries or disputes.

Where the cardholder uses their signature for cardholder verification at least two copies of the
paper record shall be produced; one copy for the cardholder to enable reconciliation against a
statement and the other for retention by the card acceptor, which must have space for the
cardholder's signature.

Where PIN is used for cardholder verification at least one copy of the paper record shall be
produced for the cardholder to enable reconciliation against a statement. The card acceptor
may require a copy for use in the point of sale back office reconciliation.

Some retail operations may require three copies to be produced.

H.1.2 Transaction types

The type of transaction recorded shall appear in words and be clearly visible. Acceptable
transaction types include, SALE, REFUND, CANCELLED SALE, CANCELLED REFUND,
DECLINED SALE, and PURCHASE WITH CASHBACK.

For refunds, cancelled and declined transactions, the non-standard nature of the transaction
shall be highlighted. This may be achieved, for example, by the use of red print, double height
characters, delineation with asterisks or bold text, depending on printer capabilities.

H.1.3 Transaction data source

As there are three different methods of obtaining the card details for the transaction it is
necessary to identify the method of data collection on the voucher. The three methods and
recommended narratives are:

a) ICC read; print ICC,

b) magnetic stripe read; print SWIPED,

c) key entered; print KEYED.

H.1.4 Card number (PAN)

To protect cardholders from fraud resulting from people stealing information from point of sale
receipts, the PAN on cardholder copies shall be masked.

Cardholder receipts shall only reflect the last four digits of the PAN, replacing all preceding
digits with fill characters such as X, * or # [blank spaces or numeric characters must not be
used].

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 126

APPENDIX H: PRINTED DATA 1 June 2007


H.1.5 Labelling

To assist in the process of dealing with enquiries and to avoid confusion, the following
labelling system could be used as an optional feature on all data elements.

The card acceptor number for the acquirer could be preceded by Merchant:, terminal
identification number by TID:, and the transaction reference number by Ref:. If the
authorisation code is printed, it may be preceded by Auth.

H.1.6 Layout

The only mandatory requirements in connection with the layout of text on a voucher are that
the declaration signature and amount are adjacent to each other. Every effort shall be made
to ensure that other information is presented logically and clearly, e.g. date and time shall be
adjacent to each other as shall card number and expiry date. Where there is no reason to the
contrary, the layout of the following examples shall be used.

H.1.7 Retention

Card acceptor copies bearing the cardholder's signature shall be retained for a period of time
in accordance with acquirer's and legislative requirements. These copies shall be kept in a
manner that enables retrieval in the event of a query or dispute but securely to prevent fraud
by misuse of the card details.

For PIN transactions there is no requirement to retain the copy produced at the time of the
transaction, provided that this can be recreated from stored electronic data if required.

H.1.8 Printer failure

To cover the possibility of printer failure or 'paper out', the card acceptor shall ensure that
adequate substitute or duplicate vouchers can be created to meet the needs of card
acceptors, cardholders and acquirers. Duplicate vouchers printed after the re-loading of
paper shall be clearly marked DUPLICATE and shall not result in the duplication of financial
entries.

H.1.9 Transaction void

The card acceptor has the capability of cancelling a transaction at any time prior to the
completion of the transaction.

In such cases the data format for the specific transaction type shall be provided subject to the
authorisation code data element being over written with the words 'TRANSACTION VOID' or
'CANCELLED' which shall be highlighted (an optional audible warning is suggested for card
acceptor convenience).

H.1.10 Dynamic currency conversion

Dynamic currency conversion has a requirement to support card scheme disclaimers for
MasterCard and Visa. MasterCard have both a long and short version disclaimer statement.
The terminal shall print the appropriate card scheme disclaimer on both the cardholder and
card acceptor copies of the receipt. If the receipt is signed then the disclaimer shall appear
before the signature panel. Contact the acquirer to determine how these messages should be
used.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 127

APPENDIX H: PRINTED DATA 1 June 2007


H.1.10.1 MasterCard long disclaimer statement

The MasterCard long disclaimer statement is as follows:

“I understand that MasterCard has a currency conversion process and that I have chosen not
to use the MasterCard currency conversion process and I will have no recourse against
MasterCard with respect to any matter related to the currency conversion or disclosure
thereof”

H.1.10.2 MasterCard short disclaimer statement

The MasterCard short disclaimer statement is as follows:

“I have chosen not to use the MasterCard has a currency conversion process and agree that I
will have no recourse against MasterCard concerning the currency conversion or its
disclosure”

H.1.10.3 Visa disclaimer statement

The Visa disclaimer statement is as follows:

“I accept that I have been offered a choice of currencies for payment and that this choice is
final. I accept the conversion rate and final amount and that the selected Transaction
Currency is <currency symbol> <currency name>.”

Note 1: the words ‘and’ may be replaced with an ampersand (&) to reduce the number of
printed characters.

Note 2: <currency symbol> shall be replaced with the currency symbol if one exists and the
printer is able to reproduce it for example € for Euros or ¥ for Yen.

Note 3: <currency name> shall be replaced with the currency name for example US Dollars.

H.2 CHARACTERISTICS OF THE PRINTED TEXT

H.2.1 Character set

The character set used shall comprise the following:

a) alphabetic characters A to Z, upper and lower case. Note that characters from other
alphabets e.g. Cyrillic, may be supported,

b) numeric characters 0 to 9,

c) currency symbols,

d) parentheses (square brackets, curly brackets, greater than and less than symbols),

e) hyphen, apostrophe, period (full stop), solidus (slash),

f) ampersand, asterisk, hash (or gate).

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 128

APPENDIX H: PRINTED DATA 1 June 2007


H.2.2 Legibility of print

For impact printers (using printer ribbons or encapsulated ink paper) and for multiple ply
printing using carbon copies the minimum height of any alpha/numeric characters shall be
2.5mm and the number of characters per inch shall not exceed 15.

For thermal printers using single ply paper the minimum height of any alpha/numeric
characters shall be 2.0mm and the number of characters per inch shall not exceed 23.

The colour of the printed characters and backgrounds shall enable legibility in normal
ambient light conditions. All carbon copies (where applicable) shall be legible.

H.2.3 Security of print

The characters shall be printed by means that ensure that they do not fade or otherwise
degrade during the required life span of the document (minimum 6 months). Carbonless
multi-part sets may have a limited shelf life before use; this shall not be exceeded. It shall be
borne in mind that the conditions encountered in mass storage systems for paper documents
can encompass extremes of temperature and humidity.

H.3 RECEIPT CONTENTS

H.3.1 Mandatory requirements

The following items shall appear on all vouchers;

a) card acceptor/outlet number,

b) card acceptor name,

c) card acceptor address (may be town name only, but shall be comprehensible),

d) transaction type e.g. SALE/REFUND,

e) PAN (see Section H.1.4 Card Number [PAN]),

f) expiry date of card (MMYY) (swiped or keyed transactions) or application expiration


date (IC transactions) (MMYY),

g) start date of card (swiped or keyed transactions) or application effective date (IC
transactions), if present on card (MMYY),

h) card issue number (swiped or keyed transactions) or application PAN sequence


number (IC transactions), if present on card,

i) card scheme name (see Note 1),

j) transaction data source ICC, SWIPE or KEYED,

k) date of transaction,

l) time of transaction,

m) terminal number (TID),

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 129

APPENDIX H: PRINTED DATA 1 June 2007


n) transaction number,

o) transaction response e.g. Authorisation code,

p) amount of transaction (including currency symbol),

q) cardholder interface details (see Note 2),

r) declaration (signature transactions only) e.g. Please debit (or credit, for refunds) my
account (card acceptor copy only),

s) retention reminder (cardholder copy only),

t) application identifier (AID) (IC transactions only),

u) gratuity amount (where a gratuity is added to the original amount),

v) amount of cash (for purchase with cashback transaction).

Note 1: For a swiped or keyed transaction, the card scheme name shall be determined from
the IIN of the card.

For an IC read transaction, the card scheme name shall be the Application Preferred
Name from the IC. If the code table required for this name is not supported, then the
Application Label shall be used instead

Note 2: The cardholder interface details printed are dependent on the cardholder verification
method used.

For Signature CVM: Request for cardholder signature (card acceptor copy only)
Space for cardholder signature (card acceptor copy only) “Signature verified”
(cardholder copy only)

For PIN CVM: “PIN Verified” (both copies)

For No CVM: No verification statement (both copies)

For refunds, where signature is used, it may be the card acceptor who signs. In this
case, the request for signature must take account of this

For the purpose of audit trails a record shall be made where the PAN is key entered to
indicate that the cardholder was not present (e.g. telephone or mail order), and where not
printed by the device 'TELEPHONE ORDER' or 'MAIL ORDER' written in the appropriate
signature space.

Some card schemes require the card acceptor to sign refund vouchers and the wording of the
declaration shall take account of this.

See H.4 for how a voucher could look.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 130

APPENDIX H: PRINTED DATA 1 June 2007


H.3.2 Optional requirements

The following items are optional:

1. diagnostic message (not required on cardholder copy),

2. start date of card (not required on card acceptor copy),

3. VAT registration number,

4. receipt number (not transaction number),

5. goods amount (itemised billing),

6. goods description (itemised billing),

7. VAT rate,

8. hot card file version number,

9. terminal software version number.

The requirement for the optional items may vary between card schemes, and detailed
guidance shall be sought from the acquirer.

It is important for security reasons to avoid printing excessive amounts of data from the
magnetic stripe. The keyed entry of issue number/sequence number may be required for
some card schemes but is dependent on the information being embossed on the card and the
terminal's ability to accept entry.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 131

APPENDIX H: PRINTED DATA 1 June 2007


H.4 EXAMPLE RECEIPTS
Table 21 - Example Receipt Layout (Signature CVM) - Card Acceptor Copy

MANDATORY OPTIONAL
Merchant Name b) A RETAILER
Merchant Address c) ANY TOWN
VAT No: 123 4567 89 c) VAT Registration Number
Miscellaneous Goods £16.00 e) f) Goods Amount and Description
VAT Rate: 17.50% g) VAT Rate
Application Identifier t) AID: A1234567890123456
Card Scheme i) VISA CREDIT
Card Number e) Card: 492912345678
Sequence Number h) PAN Seq Nr: 02
Start Date Expiry Date g) f) Start: 12/99 Expiry: 12/05
Transaction Data Source j) ICC
Transaction Type d) SALE
Amount p) £16.00
Cardholder Interface Details q) PLEASE SIGN BELOW
-----------------------------------------
Declaration e.g. r) PLEASE DEBIT MY ACCOUNT
WITH TOTAL SHOWN
Transaction Response o) Auth: 045678
Transaction Number n) Ref: M1500398
Merchant Number a) Merchant: 1234567
Terminal ID. m) TID: 16000001
Receipt: 0082 d) Receipt Number
ABCDEF0123456789 40 j) k) Cryptogram, Cryptogram Type
Date and Time k) l) Date 01/01/05 Time: 13:15
OAX4 03 0140 a) h) i) Diagnostic Message, Hot Card
Version Number, Terminal
Software Version Number

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 132

APPENDIX H: PRINTED DATA 1 June 2007


Table 22 - Example Receipt Layout (Signature CVM) - Cardholder Copy

MANDATORY OPTIONAL
Merchant Name b) A RETAILER
Merchant Address c) ANY TOWN
VAT No: 123 4567 89 c) VAT Registration Number
Miscellaneous Goods £16.00 e) f) Goods Amount and Description
VAT Rate: 17.50% g) VAT Rate
Application Identifier t) AID: A1234567890123456
Card Scheme i) VISA CREDIT
Card Number e) Card: ********5678
Sequence Number h) PAN Seq Nr: 02
Start Date Expiry Date g) f) Start: 12/99 Expiry: 12/05
Transaction Data Source j) ICC
Transaction Type d) SALE
Amount p) £16.00
Cardholder Interface Details q) SIGNATURE VERIFIED
Transaction Response o) Auth: 045678
Transaction Number n) Ref: M1500398
Merchant Number a) Merchant: 1234567
Terminal ID. m) TID: 16000001
Receipt: 0082 d) Receipt Number
ABCDEF0123456789 40 j) k) Cryptogram, Cryptogram Type
Date and Time k) l) Date 01/01/05 Time: 13:15
Retention Reminder s) Please retain for you records
Thank You b) Courtesy Message
03 0140 h) i) Hot Card Version Number,
Terminal Software Version
Number

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 133

APPENDIX H: PRINTED DATA 1 June 2007


Table 23 - Example Receipt Layout (PIN CVM) - Card Acceptor Copy

MANDATORY OPTIONAL
Merchant Name b) A RETAILER
Merchant Address c) ANY TOWN
VAT No: 123 4567 89 c) VAT Registration Number
Miscellaneous Goods £17.00 e) f) Goods Amount and Description
VAT Rate: 17.50% g) VAT Rate
Application Identifier t) AID: A1234567890123456
Card Scheme i) VISA CREDIT
Card Number e) Card: 492912345678
Sequence Number h) PAN Seq Nr: 02
Start Date Expiry Date g) f) Start: 12/99 Expiry: 12/05
Transaction Data Source j) ICC
Transaction Type d) SALE
Amount p) £17.00
Cardholder Interface Details q) PIN VERIFIED

Transaction Response o) Auth: 243090


Transaction Number n) Ref: M1600499
Merchant Number a) Merchant: 1234567
Terminal ID. m) TID: 16000002
Receipt: 0165 d) Receipt Number
1234567890ABCDEF 40 j) k) Cryptogram, Cryptogram Type
Date and Time k) l) Date 01/01/05 Time: 16:29
OAX4 03 0140 a) h) i) Diagnostic Message, Hot Card
Version Number, Terminal
Software Version Number

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 134

APPENDIX H: PRINTED DATA 1 June 2007


Table 24 - Example Receipt Layout (PIN CVM) - Cardholder Copy

MANDATORY OPTIONAL
Merchant Name b) A RETAILER
Merchant Address c) ANY TOWN
VAT No: 123 4567 89 c) VAT Registration Number
Miscellaneous Goods £17.00 e) f) Goods Amount and Description
VAT Rate: 17.50% g) VAT Rate
Application Identifier t) AID: A1234567890123456
Card Scheme i) VISA CREDIT
Card Number e) Card: ********5678
Sequence Number h) PAN Seq Nr: 02
Start Date Expiry Date g) f) Start: 12/99 Expiry: 12/05
Transaction Data Source j) ICC
Transaction Type d) SALE
Amount p) £17.00
Cardholder Interface Details q) PIN VERIFIED
Transaction Response o) Auth: 243090
Transaction Number n) Ref: M1600499
Merchant Number a) Merchant: 1234567
Terminal ID. m) TID: 16000002
Receipt: 0165 d) Receipt Number
1234567890ABCDEF 40 j) k) Cryptogram, Cryptogram Type
Date and Time k) l) Date 01/01/05 Time: 16:29
Retention Reminder s) Please retain for your records
Thank You b) Courtesy Message
03 0140 h) i) Hot Card Version Number,
Terminal Software Version
Number

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 135

APPENDIX H: PRINTED DATA 1 June 2007


Table 25 - Example Receipt Layout (No CVM) - Card Acceptor Copy

MANDATORY OPTIONAL
Merchant Name b) A RETAILER
Merchant Address c) ANY TOWN
VAT No: 123 4567 89 c) VAT Registration Number
Miscellaneous Goods £19.00 e) f) Goods Amount and Description
VAT Rate: 17.50% g) VAT Rate
Application Identifier t) AID: A1234567890123456
Card Scheme i) VISA CREDIT
Card Number e) Card: 492912345678
Sequence Number h) PAN Seq Nr: 02
Start Date Expiry Date g) f) Start: 12/99 Expiry: 12/05
Transaction Data Source j) ICC
Transaction Type d) SALE
Amount p) £19.00
Cardholder Interface Details q) NO CARDHOLDER VERIFICATION

Transaction Response o) Auth: 000943


Transaction Number n) Ref: M5309002
Merchant Number a) Merchant: 1234567
Terminal ID. m) TID: 16000003
Receipt: 7654 d) Receipt Number
12345ABCDEF67890 40 j) k) Cryptogram, Cryptogram Type
Date and Time k) l) Date 01/01/05 Time: 09:54
OAX4 03 0140 a) h) i) Diagnostic Message, Hot Card
Version Number, Terminal
Software Version Number

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 136

APPENDIX H: PRINTED DATA 1 June 2007


Table 26 - Example Receipt Layout (No CVM) - Cardholder Copy

MANDATORY OPTIONAL
Merchant Name b) A RETAILER
Merchant Address c) ANY TOWN
VAT No: 123 4567 89 c) VAT Registration Number
Miscellaneous Goods £19.00 e) f) Goods Amount and Description
VAT Rate: 17.50% g) VAT Rate
Application Identifier t) AID: A1234567890123456
Card Scheme i) VISA CREDIT
Card Number e) Card: ********5678
Sequence Number h) PAN Seq Nr: 02
Start Date Expiry Date g) f) Start: 12/99 Expiry: 12/05
Transaction Data Source j) ICC
Transaction Type d) SALE
Amount p) £19.00
Cardholder Interface Details q) NO CARDHOLDER VERIFICATION
Transaction Response o) Auth: 000943
Transaction Number n) Ref: M5309002
Merchant Number a) Merchant: 1234567
Terminal ID. m) TID: 16000002
Receipt: 7654 d) Receipt Number
12345ABCDEF67890 40 j) k) Cryptogram, Cryptogram Type
Date and Time k) l) Date 01/01/05 Time: 09:54
Retention Reminder s) Please retain for your records
Thank You b) Courtesy Message
03 0140 h) i) Hot Card Version Number,
Terminal Software Version
Number

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 137

APPENDIX H: PRINTED DATA 1 June 2007


H.5 RECONCILIATION

Where the card acceptor and acquirer are using real-time processing with real-time
transaction capture by the acquirer regular reconciliation transactions occur. The layout in
Table 27 - Reconciliation data shall be printed.

Unconfirmed and not agreed reconciliation’s shall indicate this fact by their words being
highlighted on the printout. Both the terminal totals and the acquirers totals shall be printed to
aid query resolution.

Additional issuer datasets are a repeat of the acquirer's dataset with the exception of stored
details and transaction numbers that are only applicable to acquirers.

Table 27 - Reconciliation data

Printed data Reconciliation


Narrative line 1 Reconciliation
Narrative line 2 Overall reconciliation status e.g. completed
Card acceptor name
Card acceptor address
Acquirer name Repeat as per configuration.
Time HHMM
Date DD/MM/YY
Reconciliation status e.g. Completed datasets
Terminal identity
Transaction number
Previous Debits Previous session totals
Credits
Net value (number & value see note 2)

Transactions from / to
Current Debits Current session totals
Credits
Net value (number & value see note 2)

Current session number


Transactions from / to
Stored Debits Stored transactions
Credits
Net value (number & value see note 2)

Total net value


Transactions from / to
Diagnostic message (see note 1)

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 138

APPENDIX H: PRINTED DATA 1 June 2007


H.5.1 X and Z balances

X and Z balances are provided to enable the card acceptor to balance the totals from a
terminal with his internal systems and procedures.Table 28 - X and Z balances gives the
details required on a balance voucher.

Table 28 - X and Z balances


Printed data X balance Z balance
Diagnostic message (see note 1) (see note 1)
Time HHMM HHMM
Date DD/MM/YY DD/MM/YY
Narrative line 1 X balances Z balances
2 Totals not reset Totals reset
Card acceptor name YES YES
Card acceptor address YES YES
Terminal identity YES YES
The Grand total Debits & Credits. All card transactions (see Note 2) All card transactions (see Note 2)
Debits (see Note 2) (see Note 2)
Credits (see Note 2) (see Note 2)
Card issuer name
The Grand total Debits & Credits. By card issuer (see Note 2) By card issuer (see Note 4)
Debits (see Note 2) (see Note 2)
Credits (see Note 2) (see Note 2)
Transaction number from/to

H.5.2 Notes to printed data tables

The following notes apply to Table 27 - Reconciliation data, and Table 28 - X and Z balances

Note 1: Provision shall be made to print a diagnostic code (see Table 31 — Diagnostic codes)
to aid users in identifying the nature of difficulties. Also the session number shall be
printed on change of session as indicated in the response message.

Note 2: Printed numeric digits with a decimal point separating the currency unit and the lowest
denomination of the transaction currency, where leading zeros are suppressed and
the appropriate transaction currency symbol is printed next to the most significant
digit.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 139

APPENDIX I: USE OF SERVICE CODES 1 June 2007

I. USE OF SERVICE CODES

The following procedures describe the interpretations and actions a POS system shall take
for magnetic stripe transactions for those card schemes that use service code definitions as
described in ISO 7813.

The service code is the three numeric digits immediately after the expiry date in track 2.

I.1 POS PROCEDURES

The POS system shall validate and act upon each digit of the service code individually:

a) read service code,

b) evaluate digit 1,

c) evaluate digit 2,

d) evaluate digit 3,

e) process transaction based on results.

I.2 SERVICE CODE VALUES

The meaning attributed to the value of each digit of the service code is given in Table 27 –
Service code values. The following conditions apply:

a) in the event of a communications failure where the service code value indicates real-
time, the transaction shall go real-time to the acquirer or shall be rejected,

b) if a non-numeric service code is encountered the transaction shall be reject,

c) if card schemes issue cards that are outside the ISO standards, then service code
checking shall not be undertaken for that card,

d) service code checking cannot be undertaken where the card details are key entered
or for forced transactions. In these cases accept,

e) the processing order of priority is:

1. reject - overrides real-time authorisation,

2. real-time authorisation – overrides accept,

e.g. a service code of 123 shall result in a rejection, even though the value in digit 1 is
'ACCEPT' and the value in digit 2 is 'Real-time Authorisation' because the value in digit 3
indicates it is an ATM only card.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 140

APPENDIX I: USE OF SERVICE CODES 1 June 2007


Table 29 — Service code values
Interchange Technology Digit 1 Digit 2 Digit 3 Comments
Unspecified 0 Real-time authorisation required
International Card 1 Accept
International card - alternative technology 2 If no IC verification available at the
(integrated circuit card) POS, revert to magnetic stripe
Unspecified 3 Real-time authorisation required
Unspecified 4 Real-time authorisation required
National use only 5 Real-time authorisation required
National use only - alternative technology 6 Real-time authorisation required
(integrated circuit card)
Private card 7 Real-time authorisation required
Unspecified 8 Real-time authorisation required
Test Card 9 Real-time authorisation required
Authorisation processing Digit 1 Digit 2 Digit 3 Comments
Normal Authorisation 0 Accept
Unspecified 1 Real-time authorisation required
Real-time authorisation mandatory 2 Real-time authorisation required (see
Note 1)
Unspecified 3 Real-time authorisation required
Positive (real-time/telephone) 4 Real-time authorisation required (see
authorisation procedures, unless national Note 1)
or regional agreements apply
Unspecified 5 Real-time authorisation required
Unspecified 6 Real-time authorisation required
Unspecified 7 Real-time authorisation required
Unspecified 8 Real-time authorisation required
Unspecified 9 Real-time authorisation required
Range of service/ONLINE MSR PIN Digit 1 Digit 2 Digit 3 Comments
requirements
ONLINE MSR PIN required 0 Reject if no ONLINE MSR PIN
verification available
Normal cardholder verification, no 1 Accept
restrictions
Normal cardholder verification - goods & 2 Reject if purchase with cashback
services at the POS requested, otherwise accept
ATM only 3 Reject
Cash only 4 Accept only if cash advance requested
ONLINE MSR PIN required - goods & 5 Reject if no ONLINE MSR PIN
services only at the POS verification available. Reject if
purchase with cashback
Prompt for ONLINE MSR PIN if ONLINE 6 Prompt for ONLINE MSR PIN if
MSR PINPAD present ONLINE MSR PIN verification
available. Accept.
Prompt for ONLINE MSR PIN if ONLINE 7 Prompt for ONLINE MSR PIN if
MSR PINPAD present - goods & services ONLINE MSR PIN verification
only at the POS available. Reject if purchase with
cashback requested, otherwise accept.
Unspecified 8 Real-time authorisation required
Unspecified 9 Real-time authorisation required

Note 1: A terminal cannot distinguish between values 2 & 4

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 141

APPENDIX J: AUTHORISATION CODE ALGORITHM 1 June 2007

J. AUTHORISATION CODE ALGORITHM

Where a terminal authorises a transaction because the amount is less than the floor limit, an
authorisation code shall be generated as follows:

a) take the sequential message number which would be assigned to the message and
add the lower order 4 digits of the amount,

b) the resultant 4-digit number (ignore overflows) shall be used to generate a modulus
10 check digit according to the LUHN formula (see G) to form a 5-digit authorisation
code.

J.1 EXAMPLE AUTHORISATION CODE

Message number 6821

Amount (in pence) 4763

Message number and amount (1) 1584

Modulus 10 check digit 2

Authorisation code 15842

For American Express the first 3 digits are ignored and only the last two are displayed in the
form AUTH CODE: nn followed by three blanks.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 142

APPENDIX J: AUTHORISATION CODE ALGORITHM 1 June 2007

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 143

APPENDIX K: REFERRAL TELEPHONE NUMBER PROCESSING 1 June 2007

K. REFERRAL TELEPHONE NUMBER PROCESSING

The down-line loaded telephone number is an optional data element in the acquirer's
response message. The data element and any accompanying text messages shall be used in
conjunction with the structured voice referral telephone number held in the terminal. A
number of combinations of downloaded data and stored data are defined in Table 30 —
Referral telephone number processing and the appropriate terminal process specified.

Table 30 — Referral telephone number processing

No. Voice referral telephone number Downloaded Terminal response


contents telephone
number contents
1 Any Not Present Display text message (if any) in response
message. Disconnect from line.
2 Any US US Hold line open for voice communications.
(PSTN mode). Display 'LIFT RECEIVER'.
Signal audio alarm. Display text message
when the telephone handset is raised. Reset
terminal after 20 seconds if telephone
handset not lifted.
3 ABC US Set on-hook condition; time 3 seconds, set
off-hook condition. Dial A B C with
appropriate pauses; continue as 2.
4 BC US As 3 but dial B C with appropriate pauses.
5 ABC bc As 3 but dial A b c
AB
A
6 BC bc As 3 but dial b c with appropriate pauses.
B
7 ABC US c As 3 but dial A B c
AB
8 BC US As 3 but dial B with appropriate pause.
9 AC US As 3 but dial A C
10 AC bc As 3 but dial A b c
11 AC US c As 3 but dial A c
12 C US As 3 but dial C
13 C bc As 3 but dial b c
14 C US c As 3 but dial c
15 Not set (no numeric value entered) US c As 3 but dial c
16 Not set (no numeric value entered) bc As 3 but dial b c
17 A US c As 3 but dial A c
18 Remaining combinations Set on-hook condition display 'CALL CARD
ISSUER'.

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 144

APPENDIX K: REFERRAL TELEPHONE NUMBER PROCESSING 1 June 2007

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 145

APPENDIX L: DIAGNOSTIC CODES 1 June 2007

L. DIAGNOSTIC CODES

Table 31 — Diagnostic codes list of diagnostic codes that cover the most important reasons
for faults or particular operations. This does not preclude manufacturers using additional
diagnostic codes if required.

Table 31 — Diagnostic codes

Code Reason Environment


19 Transaction failed due to power failure Auth. Financial presentment
20 Modem carrier failed before end of transmission Auth. Financial presentment
21 No modem tone detected after dialling, e.g. call routed to incorrect Auth. Financial presentment
number
30 Transaction failed after re-dialling Auth. Financial presentment
31 Line busy, e.g. other user on the same line Auth. Financial presentment
35 Confirmation message requested but could not be sent Auth. Financial presentment
40 Modem tone detected but no response from PAD Auth. Financial presentment
41 PAD advised it was not able to contact card company, i.e. EOT Auth. Financial presentment
received in response to NUA
42 No response received from card company, i.e. Timer 'C' has Auth. Financial presentment
expired
43 Insufficient or invalid data to compile a voice referral number or no Auth. Financial presentment
phone present
44 Terminal has received an EOT, i.e. remote close down by card Auth. Financial presentment
company or PAD after CONNECTION MADE.
If a security error has occurred this code is followed by the non
zero response code of the hold message -- Financial presentment

45 Message cannot be sent, e.g. too many errors real-time Auth. Financial presentment
46 Terminal has received an invalid message type Auth. Financial presentment
47 Terminal has received an invalid message header or confirmation Auth. Financial presentment
request
48 Terminal has sent a not-confirm message (Down-line loading Auth. Financial presentment
only)
49 Invalid message contents Auth. Financial presentment
50 Acquirer has not cleared down after confirmation message sent Auth. Financial presentment
52 Force transaction, i.e. the authorisation was obtained before the -- Financial presentment
transaction was performed
53 Post-event store full --
70 Security error. Terminal has detected an invalid MAC on a -- Financial presentment
received message
72 Card acceptor has indicated an invalid signature -- Financial presentment
73 Totals out of balance between terminal and acquirer -- Financial presentment
76 Terminal has performed an real-time reconciliation - Financial presentment

APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 146

APPENDIX L: DIAGNOSTIC CODES 1 June 2007

APACS
© APACS (Administration) Ltd

You might also like