Professional Documents
Culture Documents
1 June 2007
APACS
Mercury House, Triton Court
14 Finsbury Square
London EC2A 1LQ
Telephone: 020 7711 6200
Facsimile: 020 7256 5527
Copyright in this document lies with APACS (Administration) Limited. Without the express written permission of
APACS (Administration) Limited, it must not be:
FOREWORD
INTRODUCTION
1 SCOPE 7
2 NORMATIVE REFERENCES 9
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
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
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 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
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.
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 4
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 5
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).
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
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
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:
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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 9
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)
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.
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 10
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 11
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
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
Abbreviations when used within this document have the following meanings:
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 14
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 15
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:
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
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.
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.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
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.
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
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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 19
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.:
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.
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
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.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.
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.
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’.
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
Technical fallback cannot take place if the card is blocked, all applications present are
blocked or if the chip transaction has already been declined.
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.
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.
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.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
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
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
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.
1. Credit
2. Debit
3. Purse
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
Yes = E No = C
Press Cancel
Pay by Purse
Yes = E No = C
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
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'.
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
6.2.7.1 General
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:
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;
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.
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
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.
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'.
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.
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.
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 26
CVM fallback from off-line PIN to signature may be provided where both the terminal and
card support off-line PIN and signature.
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.
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.
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.
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
If it is not possible to send a reversal message, then the transaction shall be voided and no
settlement data shall be sent.
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.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.
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.
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
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.
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').
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
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.
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.
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.
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
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.
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.
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.
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.
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.
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 31
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.
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'.
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.
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
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.
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 ‘keys
Operator Acknowledges
last four digits’
Signature OK
Receipt Produced,
Operator Prompted
Card Returned to
‘PLEASE WAIT’
Cardholder with receipt
Transaction
Complete
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
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:
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).
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),
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,
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
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.1 General
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.
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
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.
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.
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.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.;
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 36
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.
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’.
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).
When the PAN is entered, the following checks may be performed, depending on card
scheme product requirements (see Appendix F):
a) a valid IIN,
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:
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 37
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:
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'.
The process is identical to that for a magnetic stripe read transaction (see section 6.4.6
Capture transaction amount).
6.5.7.1 General
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 38
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.
The process is identical to that for a magnetic stripe read transaction (see section 6.4.7.4
Signature validation).
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.
6.6.1 General
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
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),
Note: Refunds may be processed locally by the terminal (see section 6.9.4 Refund
processing).
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
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).
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.
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:
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 41
c) the expiry date has not been exceeded or other expiry date checks fail,
e) the service code is valid and does not require real-time authorisation (see Appendix
I),
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,
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),
Additionally if the terminal supports acquirer capture of transactions the following conditions
shall also be met:
d) the number of transactions stored locally is not one less than or equal to the local
count,
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
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.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.
b) message exchange.
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 43
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.
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.
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
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,
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.
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.
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.
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
c) the expiry date of the card has not been exceeded or other expiry date checks fail,
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.
Additionally if the terminal supports acquirer capture of transactions the following conditions
shall also be met:
d) the number of transactions stored locally does not equal the local count,
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
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,
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.
6.7 Printing
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.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),
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 47
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.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.
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,
f) establishes that the acquirer approved the transaction for the requested value,
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 48
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.
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.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.
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
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.:
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).
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.
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
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.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
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.
The card shall be returned to the cardholder along with the completed transaction voucher.
If the transaction is declined:
b) no further processing shall be done with the card (i.e. the IC believes it has
completed the transaction),
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.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.
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
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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
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.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.
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.
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 56
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’.
a) Petrol pumps
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.
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.
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:
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 57
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.
b) Unit Amount - Authorise the lowest significant unit amount (e.g. minimum dispense
of petrol, first night in a hotel, first days car hire),
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.
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
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.
When a card is presented at check-in at a hotel it is used to perform one or both of two
functions:
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.
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
Check-in
Express Check-out Submit transaction using Final Amount using stored card
details, Auth Code n and TC and supporting data stored
from *
Check-in
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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 60
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
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
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:
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.
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
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.
Terminal Displays
Amount £XXX.XX
Add Gratuity?
Yes = Enter Optionally the terminal may
prompt for the gratuity amount
No = Clear to be entered
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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 62
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.
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
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
Closing Tab
nd
PoS request AAC for final amount on 2 Generate AC (to
complete the transaction off-line)
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 64
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
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.
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.
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.
b) POS to read PAN and use IIN number table and / or AID and other card data to
identify offer of DCC transaction,
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 65
v. Commission Fee
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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 67
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).
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).
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
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),
c) STORED (Only printed if stored transactions are present). The total business
stored in the terminal not yet advised to the acquirer.
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
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,
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.
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'.
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
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
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.
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
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,
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
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
a) integrated circuit reader/writer capable of handling ISO 7816 / EMV compliant cards,
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,
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,
3. the interface between the PINPAD and the terminal shall be via a secure
connection,
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
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.
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).
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
In addition any stored number entered prior to setting of the call barring facility shall be able
to be dialled.
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.
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.
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
b) permanent (general data) - this category includes the basic microprocessor code and
a set of pre-defined data,
1. common data - a single set of data locations that are accessed during a
transaction for any card or for simple telephone operations,
An audible alarm shall be provided to enable card acceptor attention to be drawn to the
terminal, invalid data or message received as appropriate.
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).
c) automatic correction for the number of days in a month and leap years,
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
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.
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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 79
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.
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) 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
Issuer
Issuer Issuer
Issuer Issuer
Issuer 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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 81
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
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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 82
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
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:
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 83
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
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
Alternatively a clear key may also be provided that shall clear the transaction at a single
stroke.
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.
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:
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.
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.
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
Used by card acceptor for his or her own optional message e.g. 'Sale Starts Next Week'.
Alphanumeric characters used to input transaction data such as cashier/ticket number etc.
If the terminal supports integrated voice facilities then it shall support the storing of
commonly used telephone numbers.
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.
Identifies type of signalling used (i.e. pulse or tone dialling) and if a telephone is used.
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.
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,
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,
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 86
B.3.1 General
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.)
If a terminal supports IC cards then the application identity (AIDs) of each of the card
applications supported shall be stored.
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.
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
For each of the data telephone numbers configured the terminal shall allow for dial-up
communications with:
d) BT Special PAD.
If the terminal is only configured with one data telephone number then only two call attempts
shall be made.
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.
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
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.
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.
For each acquirer the terminal shall be configured with a number of value 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
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
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.
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.
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.
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
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.
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.
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.
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.
There are no specific data requirements for issuer datasets that are not shared by equivalent
requirements for acquirer 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
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.
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.
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.
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.
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
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.
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.
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.
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).
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:
b) no expiry date,
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
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.
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.
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.
This parameter enables or disables the ability of the terminal to process and transmit
balance enquiry message types.
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,
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.
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
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.
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.
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.
This parameter enables or disables (for each card issuer, card product and acquirer) manual
entry of the card details.
This parameter enables or disables the request message type allocated for refund
transactions where the cardholder is not present.
This parameter enables or disables the ability of the terminal to process and transmit
reversal message types.
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
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
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.
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.
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.
This parameter enables or disables the prompting for and collection of an airline ticket
number that shall be sent in the data capture message.
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
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.
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.
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
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.
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'.
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
d) PIN entry,
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
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.
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,
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
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,
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 101
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.
2. ensuring that any cryptographic processes are carried out in the fastest
available hardware,
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,
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,
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 102
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 103
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.
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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 105
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 106
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 107
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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 109
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
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
ICC MSR
Read Failure?
Optional
Yes Reject
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 111
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:
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
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’.
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.
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.
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.
Issue Number: The location of the issue number, when available in Track 2, varies.
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
No Check must not be performed – data may not be present, is not reliable
or is not supported by the scheme.
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.
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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 115
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 116
600000-699999
Transaction Types
Shows where additional checks are required and when they are not permitted
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
676700-99
Transaction Types
Shows where additional checks are required and when they are not permitted
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 118
PAN length: 16
Issue number: No
Validity period: No
Address verification: No
Transaction Types
Shows where additional checks are required and when they are not permitted
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 119
ANSI
340000 - 99
PAN length: 15
Issue number: No
Validity period: No
Transaction Types
Shows where additional checks are required and when they are not permitted
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 120
PAN length: 14
Issue number: No
Address verification: No
Transaction Types
Shows where additional checks are required and when they are not permitted
Diners
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
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.
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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 123
G. LUHN FORMULA
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.
4 9 9 2 7 3 9 8 7 1 Step
18 4 6 16 2
3 – Subtract 64 from 70 = 6
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 124
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 125
H. PRINTED DATA
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.
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.
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:
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
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.
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.
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).
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
“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”
“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”
“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.
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),
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 128
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.
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.
c) card acceptor address (may be town name only, but shall be comprehensible),
g) start date of card (swiped or keyed transactions) or application effective date (IC
transactions), if present on card (MMYY),
k) date of transaction,
l) time of transaction,
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 129
r) declaration (signature transactions only) e.g. Please debit (or credit, for refunds) my
account (card acceptor copy only),
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 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.
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 130
7. VAT rate,
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
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
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
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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 134
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
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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 136
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
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.
Transactions from / to
Current Debits Current session totals
Credits
Net value (number & value see note 2)
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 138
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.
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
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.
The POS system shall validate and act upon each digit of the service code individually:
b) evaluate digit 1,
c) evaluate digit 2,
d) evaluate digit 3,
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,
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.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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 141
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.
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
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 143
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.
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 144
APACS
© APACS (Administration) Ltd
STANDARD 70 Book 1 PAGE: 145
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.
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
APACS
© APACS (Administration) Ltd