Standard 70 Book 1 - 1 June 2007

STANDARD 70 - BOOK 1 CARD ACCEPTOR TO ACQUIRER INTERFACE STANDARDS Business Rules for Card Processing

1 June 2007

APACS Mercury House, Triton Court

14 Finsbury Square London EC2A 1LQ

Telephone: 020 7711 6200 Facsimile: 020 7256 5527

© APACS (Administration) Limited 2004

COPYRIGHT Copyright in this document lies with APACS (Administration) Limited. Without the express written permission of APACS (Administration) Limited, it must not be: 1) altered or amended in any way; 2) copied or reproduced in whole or in part in paper form, electronically or otherwise (other than as is reasonably necessary for the application of this standard by the purchaser); 3) re-sold in whole or in part. Copies of this standard are available exclusively from: The Standards Administrator APACS Mercury House, Triton Court 14 Finsbury Square, LONDON EC2A 1LQ United Kingdom Telephone: 020 7711 6319 (International: + 44 (0)20 7711 6319) Facsimile: 020 7711 6299 (International: + 44 (0)20 7711 6299) E-mail: [email protected]

STANDARD 70 Book 1 PAGE: 1

CONTENTS 1 June 2007

APACS © APACS (Administration) Ltd

FOREWORD

INTRODUCTION

1 SCOPE 7

2 NORMATIVE REFERENCES 9

3 TERMS AND DEFINITIONS 11

4 SYMBOLS (AND ABBREVIATED TERMS) 13

5 POS ENVIRONMENTS 15 5.1 Data Security 16 5.2 EMV Certification 16

5.2.1 General 16 5.2.2 EMV level 1 (hardware) certification 16 5.2.3 EMV level 2 certification 16

6 BUSINESS RULES 19 6.1 General 19 6.2 IC card process 20

6.2.1 Scope 20 6.2.2 Displays used in transactions 20 6.2.3 Transaction selection 20 6.2.4 Capture card data 20 6.2.5 Process card data 21 6.2.6 Capture transaction amount 23 6.2.7 Cardholder verification 24 6.2.8 Issuer and terminal action codes 26 6.2.9 Premature card removal 26 6.2.10 Terminals with no real-time capability 27 6.2.11 Unable to do a real-time authorisation 27

6.3 Proximity card process 28 6.3.1 Scope 28 6.3.2 Displays used in transactions 30 6.3.3 Transaction selection 30 6.3.4 Capture card data 30 6.3.5 Process card data 31 6.3.6 Capture transaction amount 31 6.3.7 Cardholder verification 31 6.3.8 Other comments about the process 31

6.4 Magnetic stripe process 32 6.4.1 Scope 32 6.4.2 Displays used in transactions 32 6.4.3 Transaction selection 32 6.4.4 Capture card data 33 6.4.5 Process card data 33 6.4.6 Capture transaction amount 34 6.4.7 Cardholder verification 34

6.5 Key entry process 35 6.5.1 Scope 35 6.5.2 Displays used in transactions 36 6.5.3 Transaction selection 36 6.5.4 Capture card data 36 6.5.5 Process card data 36 6.5.6 Capture transaction amount 37


CONTENTS 1 June 2007


6.5.7 Cardholder verification 37 6.6 Authorise the transaction 38

6.6.1 General 38 6.6.2 Local processing by the terminal 39 6.6.3 Real-time processing remotely by the acquirer 42 6.6.4 Local processing by the terminal after a call failure 44 6.6.5 Manual procedures 46

6.7 Printing 46 6.8 Submit transaction for settlement 46

6.8.1 General 46 6.8.2 Card acceptor capture of transactions 47 6.8.3 Acquirer capture of transactions 47 6.8.4 Message number 48 6.8.5 Delayed cancel 48

6.9 Exception transactions 48 6.9.1 General 48 6.9.2 Declined transactions 48 6.9.3 Voice referrals 50 6.9.4 Refund processing 51 6.9.5 Stand-in processing 53 6.9.6 Reversals 53

6.10 Industry specific transactions 55 6.10.1 General 55 6.10.2 Unattended Terminals (excluding ATMs) 55 6.10.3 Authorisations with an unknown final amount 57 6.10.4 Hospitality, hotel & car hire 57 6.10.5 Fast food 64

6.11 Dynamic currency conversion (DCC) 64

7 CARD ACCEPTOR FACILITIES 67 7.1 General 67 7.2 X and Z balances 67 7.3 Reconciliation 67

7.3.1 Outline 67 7.3.2 Sessions 68 7.3.3 Balancing with the acquirers 68 7.3.4 Balancing card issuer datasets 71

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


FOREWORD 1 June 2007


FOREWORD

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

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

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

Book 1 - Business rules for card processing

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

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

Book 4 - Communications

Book 5 - Security and key management.

Book 6 - Data port interface

Book 7 - Terminal Identities

Standard 70 is a redrafting of a number of previous APACS standards (Standard 29-4, 30, 40, 50 and the Common Attachment) into a consistent format, which matches that used in Standard 60.

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

The requirements of Standard 70 Books 1, 4, 5, 6 and 7 shall still apply regardless of whether Standard 60 or Standard 70 Books 2 and 3 message formats are used.


FOREWORD 1 June 2007



INTRODUCTION 1 June 2007


INTRODUCTION

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

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

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

Table 1 — APACS standards functional comparison

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

protocol being implemented within the messages defined.

Table 2 — APACS standards message flows

Standard Initiation request Purpose Transaction level 30 From POS to acquirer Authorisation One transaction per message, real time 40 From POS to acquirer Authorisation and

capture One transaction per message, real time

50 From acquirer to POS Capture Batch of transactions per connection post-event

29 From card acceptor to acquirer

Capture File of transactions post-event

60 Bi directional Authorisation and capture

All options concurrently

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.


INTRODUCTION 1 June 2007


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

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

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

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

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

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

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


PART 1: SCOPE 1 June 2007


1 SCOPE

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

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

a) select the appropriate transaction type,

b) capture the card data,

c) capture the transaction data,

d) validate the cardholder,

e) authorise the transaction,

f) print and display any relevant messages or vouchers,

g) submit the transaction for settlement.

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


PART 1: SCOPE 1 June 2007



PART 2: NORMATIVE REFERENCES 1 June 2007


2 NORMATIVE REFERENCES

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

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

Access to ATMs UK Design Guidelines. (Available from Centre for Accessible Environments Tel +44 20 7357 8182 email [email protected]

DDA Disability Discrimination Act(1995) with subsequent amendments

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

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

ISO 7813 Identification cards – Financial transaction cards.

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

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

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

ANSI X9.19 Financial institution retail message authentication.

ANSI X9.8 Banking – Personal identification number management and security – Part 1 PIN protection principles and techniques for on-line PIN verification in ATM and POS systems.

ANSI X3.92 Data Encryption Algorithm – DES.

EMV Integrated Circuit Card Specification for Payment Systems (see www.emvco.com).

PCI:DSS Payment Card Industry: Data Security Standards


PART 2: NORMATIVE REFERENCES 1 June 2007



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


3 TERMS AND DEFINITIONS

acquirer financial institution (or its agent) which acquires from the card acceptor the data relating to a transaction and initiates that data into an interchange system

card acceptor party accepting the card and presenting transaction data to an acquirer

card issuer financial institution (or its agent) which issues the financial transaction card to the cardholder

data capture act of collecting the details of a financial transaction

dataset set of data elements logically grouped together, stored in a terminal to control its actions during transaction processing

interface device (IFD)

that part of a terminal in which the IC card is inserted including such 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 capture

not connected to an acquirer’s computer or data communications network for transaction submission at the time the cardholder transaction takes place

proximity coupling device (PCD)

that part of a terminal that connects using radio frequencies to the IC card including such mechanical and electrical devices that may be considered 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 management group (SMG)

group set up by the APACS Acquirer's POS group to manage the development of APACS POS standards

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.




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




4 SYMBOLS AND ABBREVIATED TERMS

Abbreviations when used within this document have the following meanings:

ATM Automated teller machine

Auth. Authorisation

AVS Address Verification Services

CAT Cardholder activated terminal

CSC Card security code

CVM Cardholder verification method

DTMF Dual tone multi frequency

EPOS Electronic point of sale

FD Field divider

FS Field separator

HCF Hot card file

IC Integrated circuit

IFD Interface device

IIN Issuer identification number

LRC Longitudinal redundancy check

MAC Message authentication code

MSR Magnetic stripe read

NUA Network user address

PABX Private automatic branch exchange

PAD Packet assembler/disassembler

PAN Primary account number

PCD Proximity coupling device

PIN Personal identification number

POS Point of sale (also known as point of service)

PSTN Public switched telephone network

PWCB Purchase with cashback

STD Subscriber trunk dialling

TVD Transaction variable data


PART 5: POS ENVIRONMENTS 1 June 2007


5 POS ENVIRONMENTS

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

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

a) easier staff training and recruitment,

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

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

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

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

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

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

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

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




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

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

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

5.1 Data Security

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

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

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

5.2 EMV Certification

5.2.1 General

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

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

5.2.2 EMV level 1 (hardware) certification

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

5.2.3 EMV level 2 certification

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

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




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

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

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


PART 6: BUSINESS RULES 1 June 2007


6 BUSINESS RULES

6.1 General

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

a) select the appropriate transaction type,

b) capture the card data,

c) process the card data,

d) capture the transaction amount,

e) validate the cardholder,

f) authorise the transaction,

g) print and display any relevant messages or vouchers,

h) submit the transaction for settlement.

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

In order to better understand the operation of a terminal, a typical transaction is described, along with a number of alternative courses of action where:

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

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

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

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

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

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

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




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

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

6.2 IC card process

6.2.1 Scope

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

6.2.2 Displays used in transactions

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

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

6.2.3 Transaction selection

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

6.2.4 Capture card data

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

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




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

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

6.2.5 Process card data

6.2.5.1 Application selection

6.2.5.1.1 Coding of application data file (ADF)

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

6.2.5.1.2 Terminal selection of application

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

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

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

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

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

6.2.5.2 Multi-application cards and application selection

6.2.5.2.1 General

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




6.2.5.2.2 Card acceptor selection

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

Method of Payment?

Credit

Debit

Purse

Figure 1 — Card acceptor selection, limited display

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

Debit Card £25.35

ENTER PIN

Figure 2 — Card acceptor selection, PINPAD display

6.2.5.2.3 Cardholder selection

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

Select Payment Type

1. Credit

2. Debit

3. Purse

Figure 3 — Cardholder selection, multi-line display

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

Pay by Credit

Yes = E No = C

Press Cancel

Pay by Debit




Yes = E No = C

Press Cancel

Pay by Purse

Yes = E No = C

Figure 4 — Cardholder selection, scrolling display

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

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

Debit Card £25.35

ENTER PIN

Figure 5 — Cardholder transaction acceptance

6.2.5.3 Transaction type validation

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

6.2.6 Capture transaction amount

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

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

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

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




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

6.2.7 Cardholder verification

6.2.7.1 General

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

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

6.2.7.2 Cheque guarantee cards

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

The current process using cheque guarantee cards involves the cashier:

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

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

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

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

3. seeking authorisation from a cheque guarantee service provider.

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

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

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

6.2.7.3 Processing Terminal Capabilities

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




a) Off-line encrypted PIN,

b) Off-line plaintext PIN,

c) Signature (see section 6.4.7.4 Signature validation),

d) No CVM.

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

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

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

6.2.7.4 PIN input

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

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

6.2.7.5 PIN retries

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

6.2.7.6 PIN bypass

6.2.7.6.1 Provision of PIN bypass

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

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

PIN bypass shall only be able to be performed if:

a) the terminal is configured to provide the facility;

b) the card acceptor agrees to support it;

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




d) the function is allowed in this environment.

6.2.7.6.2 Implementation of PIN bypass

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

It is recommended that a special key be provided or a combination of key depressions used to initiate bypass and that it may be configured either to require a supervisor card/password to be used to enable the bypass or to allow the card acceptor to initiate the bypass without other authority.

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

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

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

6.2.7.7 PIN Locked

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

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

6.2.8 Issuer and terminal action codes

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

6.2.9 Premature card removal

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




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

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

6.2.10 Terminals with no real-time capability

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

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

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

6.2.11 Unable to do a real-time authorisation

6.2.11.1 General

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

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

6.2.11.2 Cardholder messaging

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

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

6.2.11.3 HCF Checking

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




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

6.2.11.4 EPOS systems

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

6.2.11.5 Completion at card acceptor risk

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

TVR values that should normally result in a decline are:

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

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

byte 1 – bit 5: card on hot list,

byte 1 – bit 6: ICC data missing,

byte 1 – bit 7: SDA failed,

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

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

byte 2 – bit 6: application not yet effective,

byte 2 – bit 7: expired application,

byte 3 – bit 6: PIN try limit exceeded,

byte 3 – bit 8: cardholder verification unsuccessful,

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

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

6.3 Proximity card process

6.3.1 Scope

6.3.1.1 General

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




6.3.1.2 Electrical and protocol standards

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

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

6.3.1.3 Form factors and formats

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

6.3.1.4 Data and message formats

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

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

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

6.3.1.5 Payment product type

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




What form factor? What protocol?What data and

message standard?

What payment type?

Card (ID1)Mini-cardKey-fobButtonMobile phone… other

ISO 14443A or BNFCPayPass… other

RFID tags

Wired-logic cards: MiFare, FeliCa, magstripe image

EMV variants(Card Scheme Specific)

Debit/CreditPrepaidPre-authorised debit

Figure 6 - Options below illustrate the range of options

6.3.1.6 Proximity cards in Standard 70

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

6.3.1.7 Proximity cards only

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


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.

The method of payment (contact or contactless) will normally be selected automatically using the business rules associated with the respective payment methods. However,




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


6.3.5.1 Application selection

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

6.3.5.2 Transaction type validation

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


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

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


Cardholder verification shall be handled as described in scheme specifications.

6.3.8 Other comments about the process

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

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




6.4 Magnetic stripe process

6.4.1 Scope

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


TransactionAmount known

Transaction Type orCard Payment Selected

Operator Promptedfor Card Swipre

CardholderHands over Card

Operator PerformsVisual Checks

OperatorSwipes Card

Operator ‘keyslast four digits’

Operator Prompted‘PLEASE WAIT’

Transaction Processedincluding Authorisation

VoucherProduced

Cardholder SignsVoucher

Operator Prompted‘Check Signature’

Operator ChecksSignature

Operator AcknowledgesSignature OK

Receipt Produced,Card Returned to

Cardholder with receipt

TransactionComplete

Figure 7 - Magnetic Stripe transaction


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’.





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

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

a) no data present on track 2,

b) LRC check fail,

c) parity failure on one or more characters,

d) no start sentinel,

e) no end sentinel.

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

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


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

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

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

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

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

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

f) track length: track 2 may contain up to 40 characters, of which 3 are control characters (start sentinel (SS), end sentinel (ES) and longitudinal redundancy check (LRC)).

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




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


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

Cardholder verification is required for financial transactions (except refunds, reversals or when the cardholder is not present) but not for authorisation only transactions. The type of validation depends upon the configuration of the terminal and shall be prompted for once the card and transaction details have been successfully entered.



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

6.4.7.3 PIN validation

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

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

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




6.4.7.4 Signature validation

6.4.7.4.1 General

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

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

6.4.7.4.2 Delaying signature validation option

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

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

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

6.4.7.4.3 Additional verification

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

6.5 Key entry process

6.5.1 Scope

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

a) following a magnetic stripe card swipe failure,

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

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





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,

b) a PAN of the correct length,

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

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

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

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

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




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

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

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

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

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

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

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

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

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

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

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

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


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

Cardholder verification is required for financial transactions (except refunds, reversals or when the cardholder is not present) but not for authorisation only transactions. The type of verification depends upon the configuration of the terminal and shall be prompted for once the card and transaction details have been successfully entered.






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

6.5.7.3 Signature validation

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

6.5.7.4 Address/CSC verification

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

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

This information may be passed to a participating scheme acquirer as part of the authorisation request for onward submission to the card issuer. The card issuer, if participating, will then check the data against that held against the account.

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

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

6.6 Authorise the transaction

6.6.1 General

Authorisation may be undertaken:

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

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

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




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

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

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

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

b) All technical fallback transactions,

c) All magnetic stripe transactions.

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

6.6.2 Local processing by the terminal

6.6.2.1 Terminal checks

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




Table 3 – Terminal checks

Terminal check Description

Floor Limit Checking

For magnetic stripe and key entered transactions, a transaction shall not be 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 Used Off-Line Per Day

The maximum number of transactions on one card that can be processed locally by the terminal during a trading day. When this limit has been reached subsequent transactions on the card for that trading day shall not be processed locally by the terminal.

Maximum Times Used Per Day

The maximum number of transactions on one card that can be performed during a 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 Required

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

Hot Card File Checking

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

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

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

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

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

6.6.2.2 Local authorisation

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

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

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

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

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

a) floor limit checking is enabled in the terminal,




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

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

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

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

f) the transaction is an authorisation transaction and the facility to allow local authorisation by the terminal has been enabled,

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

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

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

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

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

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

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

a) in balance with the acquirer,

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

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

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

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

f) this is not a balance enquiry transaction.

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




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

If the transaction is a financial presentment transaction (except a refund or a reversal) the terminal shall wait for cardholder validation to be completed before generating an authorisation code.

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

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

6.6.3 Real-time processing remotely by the acquirer

6.6.3.1 General

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

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

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

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

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

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

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

The communications phase contains two separate processes:

a) connection to the acquirer system,

b) message exchange.




6.6.3.2 Connection to the acquirer system

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

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

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

6.6.3.3 Message exchange

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

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

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

6.6.3.4 Post-event advices

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

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

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

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




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

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

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

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

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

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

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

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

6.6.4 Local processing by the terminal after a call failure

6.6.4.1 Unsuccessful call attempts

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

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

After second failed attempt:

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

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

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

6.6.4.2 Call failure processing

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




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

a) floor limit checking is enabled in the terminal,

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

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

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

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

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

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

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

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

j) this is not a cheque guarantee transaction.

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

a) in balance with the acquirer,

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

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

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

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

f) this is not a balance enquiry transaction.

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

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

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




6.6.5 Manual procedures

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

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

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

b) the card PAN appears on the local HCF.

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

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

Use of a manual procedure by a merchant using a totally off-line terminal is subject to agreement with their acquirer and must not require specific customisation of the transaction flow at the terminal.

6.7 Printing

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

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

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

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

6.8 Submit transaction for settlement

6.8.1 General

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

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

b) the acquirer on a transaction by transaction basis as part of the authorisation process (see section 6.8.3 Acquirer capture of transactions).




6.8.2 Card acceptor capture of transactions

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

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

6.8.3 Acquirer capture of transactions

6.8.3.1 General

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

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

6.8.3.2 Use of the transaction key system

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

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

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

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

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

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

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




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

h) the MAC provides error protection.

6.8.4 Message number

The message number shall be incremented on satisfactory link-level acknowledgement (see Standard 70 Book 4) of the final application level message of a transaction provided that the response message is not invalid.

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

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

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

6.8.5 Delayed cancel

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

6.9 Exception transactions

6.9.1 General

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

6.9.2 Declined transactions

6.9.2.1 IC card decline only

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

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

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

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




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

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

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

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

a) transaction declined by the IC – before real-time authorisation - DECLINED BY CARD - CARDHOLDER SHOULD CONTACT ISSUER,

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

c) transaction declined after real-time authorisation – additional display ISSUER DECLINE - CARDHOLDER SHOULD CONTACT ISSUER,

d) transaction declined by the IC after real-time authorisation – UNABLE TO AUTHORISE – CARDHOLDER SHOULD CONTACT ISSUER.

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

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

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

6.9.2.2 IC card decline and retain

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

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

6.9.2.3 Magnetic stripe and key entry decline

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




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

b) transaction declined after real-time authorisation – additional display ISSUER DECLINE - CARDHOLDER SHOULD CONTACT ISSUER.

6.9.2.4 Magnetic stripe and key entry decline and retain

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

6.9.3 Voice referrals

6.9.3.1 General

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

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

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

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

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

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

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




6.9.3.2 IC card referrals

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

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

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

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

An AAC shall not be submitted in a settlement message.

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

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

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

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

6.9.3.3 Magnetic stripe and key entry referrals

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

6.9.4 Refund processing

6.9.4.1 General

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

6.9.4.2 IC card refund processing

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




The following options are available for processing refunds:

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

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

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

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

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

6.9.4.3 Magnetic stripe and key entry refund processing

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

6.9.4.4 Data validation for refunds

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

6.9.4.5 Cardholder verification for refunds

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




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

6.9.4.6 Transaction presentment for refunds

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

6.9.5 Stand-in processing

6.9.5.1 IC card stand-in processing

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

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

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

6.9.5.2 Magnetic stripe and key entry stand-in processing

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

6.9.6 Reversals

6.9.6.1 General

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

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

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

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




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

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

6.9.6.2 IC card reversals

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

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

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

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

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

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

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

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

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

6.9.6.3 Magnetic stripe and key entry reversals

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




It shall be possible to reverse this transaction by:

a) cancelling the transaction before confirming the signature,

b) selecting the reversal function on the terminal.

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

6.10 Industry specific transactions

6.10.1 General

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

6.10.2 Unattended Terminals (excluding ATMs)

6.10.2.1 Rules for cardholder activated terminals

Table 3 - Cardholder activated terminal

Note 1: A real-time authorisation may not be appropriate in all environments, even if the IC is set to request one e.g. at a road toll unattended terminal, where throughput speed and low transaction value need to be kept in perspective. This would be an exception to the principle proposed. The merchant shall agree with the acquirer the Terminal Action Code – Default settings appropriate for the terminal environment.

Note 2: IC only terminal option: Where it is possible to redirect all magnetic stripe cards (and fallback transactions) to an attended kiosk then the unattended terminal owner can satisfy the card schemes 'honour all cards' rule.

6.10.2.2 PIN pad (PED) requirements

Unless the PED is handheld / portable in an unattended terminal, a privacy shield is required. Refer to Standard 70 Book 5 for further guidance on PIN pad certification.

Magstripe only Terminals Chip only Terminals Hybrid (chip and magstripe)

Floor Limits Zero floor limit May support non-zero floor limit for IC card and PIN

Zero limit for magstripe May support non-zero floor limit for IC card and PIN

Motorised IFD Required Optional Optional

Card Retention capability Required (except payphones)

Optional Optional

Technical Fallback (Chip read failure)

No No No -– but waiver may be granted on application to acquirer unless agreed by bi-lateral agreement

CVM support Cardholder Verification Off-line PIN No CVM

Off-line PIN No CVM

Authorisation capability Real-time required Real-time required Real-time required




6.10.2.3 Support for ‘No CVM’

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

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

6.10.2.4 Unattended terminals in specific environments

The following specific environments are considered:

a) Petrol pumps

1. the cardholder is prompted to enter card into dispenser, IC is read, display reads MAXIMUM <value> £XX – PLEASE ENTER PIN', PIN is entered and an authorisation for one unit of the major denomination of the default currency, e.g. £1 is generated,

2. petrol is dispensed, up to the advertised maximum of £XXvalue – the PIN entry signifying that a sum up to that £XXvalue is agreed as the maximum sum to be debited,

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

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

b) Motorway tolls. Terminals in this type of environment should be limited amount terminals (LATs) and have their own existing rules and procedures.

c) Payphones. Operators may wish to introduce combined readers into payphones, to enable the magnetic stripe to be read if the IC is unreadable.

6.10.2.5 Transaction vouchers

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

6.10.2.6 Card retention

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

a) remains mandatory for Magnetic Stripe only unattended devices,

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




6.10.3 Authorisations with an unknown final amount

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

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

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

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

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

6.10.3.1 Amount selection

There are three options for population of the amount:

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

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

c) Estimated Amount - Authorise the estimated final amount at first customer interaction (e.g. 3 nights in a hotel +20%, £30.00 of petrol, one week’s car hire).

6.10.3.2 Final amount greater / incremental authorisation

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

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

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

6.10.4 Hospitality, hotel & car hire

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




6.10.4.1 Hotel advance bookings and deposits

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

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

6.10.4.2 Hotel transaction process

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

a) Authentication of the card and cardholder,

b) Authorisation of an estimated amount.

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

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

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

6.10.4.2.1 Cardholder not present at check-out

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




Check-in

Full EMV transaction for Estimate Amount

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

Incremental Authorisation Using stored card details. Auth Code 2 Saved

Incremental Authorisation Using stored card details. Auth Code n Saved

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

Figure 8 - Systems able to store cryptographic data

Check-in

Full EMV transaction for Estimate Amount

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

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

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

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

Figure 9 - Systems NOT able to store cryptograhic data




6.10.4.2.2 Cardholder present at check-out

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

Check-out

Full EMV transaction for Final Amount

PoS request ARQC for final amount on 1st Generate AC

PoS request AAC on 2nd Generate AC

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

Figure 10 - Cardholder present at check-out

6.10.4.2.3 Restaurants – General

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

a) At the table using a portable terminal,

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

6.10.4.2.4 Gratuity

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

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

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

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

Note: this standard only considers option c).

6.10.4.2.5 Gratuity transaction processing

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




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

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

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

Card Inserted andamount Entered

Terminal DisplaysOriginal Amount £XXX.XXGratuity Amount £XXX.XX

Total Amount £XXX.XXOK = Enter

Not OK = Clear

Terminal DisplaysAmount £XXX.XX

Complete transactionfor new amount

Complete transactionfor original amount


Add Gratuity?Enter PIN


Add Gratuity?Yes = EnterNo = Clear

Cardholderpressed

Enter

Terminal Displays EnterNew Total

Amount £XXX.XXthen press Enter

Cardholderpressed

Enter

Yes

No

Yes

No

Optionally the terminal mayprompt for the gratuity amount

to be entered

Figure 11 - Gratuity transaction flow




6.10.4.2.6 Magnetic stripe and key entry gratuity transaction processing

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

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

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

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

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

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

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

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

Restaurants operate in different environments, such as single or multi-waiter, and payment at the table or at a central checkout. In order to meet these requirements the terminal shall assign a unique reference to each transaction to allow any transaction to be recalled at any time.

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

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

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

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




6.10.4.2.7 Bar tab process

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

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

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

Open Tab

Full EMV Authorisation transaction for Agreed Amount

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

Closing Tab

Full EMV transaction for Final Amount

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

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

Tab Closed Submit transaction off-line using Final Amount, Auth Code 1 and TC and supporting data from *

Figure 12 - Closing bar tab cardholder




6.10.4.2.8 Bar tab completion no cardholder

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

Open Tab

Full EMV transaction for Agreed Amount

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

Closing Tab Submit transaction using Final Amount, stored card details, Auth Code 1 and TC and supporting data stored from * including ‘agreed amount’ as cryptogram amount.

Figure 13 - Closing bar tab cardholder not present

6.10.4.3 Car Hire

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

6.10.5 Fast food

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

6.11 Dynamic currency conversion (DCC)

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

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

The PoS process shall be:

a) Card read by swipe or insertion,

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

c) Amount in the Card Acceptor Currency, in the Cardholder Currency, description of the Cardholder Currency (e.g.€ or EUR) and the Exchange Rate used to be shown on the display,




d) Customer Decision Point Yes / No

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

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

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

i. Card Acceptor Currency Amount

ii. Cardholder Currency Amount (including description)

iii. Conversion rate applied

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

v. Commission Fee

vi. Any mark-up fee applied

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

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

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

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


PART 7: CARD ACCEPTOR FACILITIES 1 June 2007


7 CARD ACCEPTOR FACILITIES

7.1 General

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

7.2 X and Z balances

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

For this set of totals two functions shall be available:

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

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

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

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

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

7.1 Reconciliation

7.1.1 Outline

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

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

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




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

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

7.2.1 Sessions

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

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

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

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

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

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

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

Each total is held under five headings:

a) Total value of debits - 11 digits max,

b) Total value of credits - 11 digits max,

c) Total quantity of debits - 4 digits max,

d) Total quantity of credits - 4 digits max,

e) The message numbers enclosing each total.

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

7.2.2 Balancing with the acquirers

7.2.2.1 Selective reconciliation

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




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

7.2.2.2 Post-event versus real-time reconciliation

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

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

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

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

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

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

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

7.2.2.3 Totals out of balance

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

7.2.2.4 Communications failure

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




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

7.2.2.5 Examples of session and reconciliation totals

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

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

ACQUIRER

ACQUIRER

SESSION

1

2

3

4

5

CARD ACCEPTOR A B C D E F G H I

Rec 1 Rec

2 Rec 3

Rec 4 Rec

5

REC PREVIOUS TOTALS CURRENT TOTALS RECONCILIATION TOTALS

1 Unknown A Unknown

2 A + B C B + C

3 C + D E D + E

4 C + D E + F F

5 E+F+G+H I G + H + I

Figure 14 - Acquirer Sessions

7.2.2.6 Effect of deletion on reconciliation

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

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

a) delete card issuer and acquirer datasets,

b) delete a card issuer dataset,

c) reset acquirer dataset.

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




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

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

a) card issuer and acquirer totals printed together,

b) totals printed separately.

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

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

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

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

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

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

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

f) Card acquirer/issuer delete slips can be identified by the presence/absence of message numbers printed within the totals respectively,

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

7.2.3 Balancing card issuer datasets

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




Table 4 — Example reconciliation slips

1. Totals Together 2. Totals Separate Normal Reconciliation slips ACQUIRER ACQUIRER PREVIOUS Pa+Pc PREVIOUS Pa TOTAL XXXX-YYYY-1 TOTAL XXXX-YYYY-1 CURRENT 0 Ca+Cc+Sa+Sc CURRENT 0 Ca+Sa TOTAL YYYY-ZZZZ TOTAL YYYY-ZZZZ CARD ISSUER PREVIOUS Pc CURRENT 0 Cc+Sc Delete C.I. dataset DELETE CARD ISSUER As 'Together' PREVIOUS Pc CURRENT Cc STORED Sc RECONCILIATION As 'Together' ACQUIRER PREVIOUS Pa TOTAL XXXX-YYYY-1 CURRENT 0 Ca+Sa TOTAL YYYY-ZZZZ Reset Acquirer RESET ACQUIRER PREVIOUS Pa As 'Together' TOTAL XXXX-YYYY-1 CURRENT Ca TOTAL YYYY-ZZZZ STORED Sa+Sc RECONCILIATION RECONCILIATION ACQUIRER ACQUIRER PREVIOUS Pc PREVIOUS 0 TOTAL 0000-0000 TOTAL 0000-0000 CURRENT 0 Cc CURRENT 0 TOTAL 0001-0001 TOTAL 0001-0001 CARD ISSUER (No extra business for sake of example)

PREVIOUS Pc

CURRENT 0 Cc


APPENDIX A: MINIMUM TERMINAL HARDWARE REQUIREMENTS 1 June 2007


A. MINIMUM TERMINAL HARDWARE REQUIREMENTS

A.1 EPOS SYSTEMS AND POST-EVENT TERMINALS

The principal components that shall be present are:

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

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

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

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

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

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

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

d) display with a minimum of 16 characters and preferably 32 (either as one line of 32 characters or 2 lines of 16 characters each),

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

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

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

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

2. it shall be designed to enable secure entry of the PIN in whatever position it is located in normal operational use,

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

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

g) modem or other communications interface for communications with an acquirer to authorise and subsequently submit transactions,

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




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

A.2 REAL-TIME TERMINALS

A.2.1 General

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

A.2.2 Connection to acquirer system

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

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

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

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

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

A.2.3 Telephone network compatibility

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

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

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

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

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

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

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




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

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

A.2.4 Data communications capability

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

A.2.5 Additional keys

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

Table 5 — Keys required

Transaction keys Function keys

Sale Reconciliation

Numeric keys 0 to 9 X balances

Refund Z balances

Reversal Duplicate

Cash Advance Paper-feed

Cheque Guarantee Enter

Authorisation only Clear

Force Delete

Cancel

Programme

Alpha

Alternative Identification

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

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




A.2.6 Memory

The terminal memory requirements fall into three distinct categories:

a) permanent (terminal specific) - the terminal identity is an eight digit numeric sequence. Each terminal shall have a unique identity (see Standard 70 Book 7),

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

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

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

2. datasets - each dataset shall consist of a number of locations for temporary data that are updated during each transaction, and a number of 'semi-permanent' values that provide the necessary parameters for processing a transaction.

The operation of datasets is defined in Appendix B.

A.2.7 Audible alarm

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

A.2.8 Data port

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

A.2.9 Real-time clock

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

a) hours, minutes, seconds,

b) calendar - days, months, years,

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

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

e) accuracy + 3 seconds per day.

A.2.10 Power supply

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

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




A.2.11 Terminal identity

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

A.2.12 Diagnostic codes

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


APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS 1 June 2007


B. MINIMUM SOFTWARE REQUIREMENTS

B.1 GENERAL

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

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

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

B.1.2 Dataset types

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

A terminal is required to have three types of dataset:

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

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

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




B.1.3 Dataset relationships

Figure 15 - Dataset relationships shows the relationships between datasets of different types. The single card acceptor dataset is related to all acquirer datasets and the data contained within it is available to all. The acquirer datasets may be a simple acquirer/issuer, may support multiple card schemes, may support one complex card scheme or may support multiple card schemes and card products.

Merchant Acquirer Acquirer

Multiple Card Schemes

Issuer

Acquirer Acquirer

Complex Card Schemes

Issuer

Issuer

Issuer

Issuer

Issuer

Issuer

Issuer

Issuer

Issuer

Issuer Issuer

Issuer Issuer

Simple Acquirer/ Issuer Multiple Card Schemes& Products

Figure 15 - Dataset relationships

B.1.3.1 Simple acquirer/issuer

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

Figure 16 - Simple acquirer/issuer

Merchant Acquirer / IssuerAmerican Express




B.1.3.2 Multiple simple card schemes

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

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

I s s u e rM a s te r C a r d

Is s u e rJ C B

Figure 17 - Multiple simple card schemes

B.1.3.3 Complex card scheme

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

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

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





Figure 18 - Complex card scheme




B.1.3.4 Multiple card schemes and products

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

Figure 19 - Multiple card schemes and products

B.1.4 Dataset interaction

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

Table 6 — Dataset interaction rules

Interaction Acquirer Issuer Result

LOGAND (Logical And) N N N N Y N Y N N Y Y Y LOGOR (Logical Or) N N N N Y N Y N N Y Y Y ACQ (Acquirer Override) Use acquirer dataset

value and ignore issuer.

ISSUER (Issuer Override) Use issuer dataset value and ignore acquirer

Merchant Acquirer

IssuerJCB

IssuerMasterCard

IssuerVisa

IssuerVisa DeltaRange 1

IssuerSwitch

Range 1

IssuerSwitch Solo

Range 1

IssuerRange 2

IssuerRange 3

IssuerRange 4

IssuerRange 5

IssuerRange 2

IssuerRange 4

IssuerRange 3

IssuerRange 5

IssuerRange 2

IssuerRange 3

IssuerRange 4

IssuerRange 5




B.1.5 Totals linking

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

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

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

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

Table 7 — Totals linking

Dataset Link value

Acquirer Not set (implicit link value 00)

Card Issuer 1 Not set (implicit link value 00)

Card Issuer 2 01

Card Issuer 3 00

Card Issuer 4 01

Card Issuer 5 02

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

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

Totals printed 3. C.I. 5 under C.I. 5 name

B.1.6 Security of terminal and data

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

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

B.1.7 Corrections

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




to be entered only one keystroke is required to cancel the entire input. Similarly, if there is no data entered only one keystroke is required to cancel the transaction.

Alternatively a clear key may also be provided that shall clear the transaction at a single stroke.

B.1.8 Communications via multiple systems

The assumption is that a terminal is communicating directly with an acquirer over a communications network. However it is possible that messages are routed via intermediate systems or third party processor.

In this situation the message shall be passed through untouched except for the Message type data element that shall indicate that the transmission is a retry only if the intermediate system itself has had to retransmit. It is, therefore, the responsibility of the intermediate system to reset the message type received from the terminal and generate the correct one for onward transmission.

Individual acquirers shall give approval to the use of intermediate systems and some may not wish to accept authorisation requests resulting from such a configuration.

B.1.9 Use with multiple acquirers

Card acceptors are free to agree commercial terms with any number of acquirers. As such cards processed under these agreements need to be routed to the correct acquirer.

The terminal shall automatically route transactions to different acquirers according to the issuer of the card presented. The terminal will need to hold data in terminal memory for each acquirer for such information as:

a) how to recognise the issuer and which is the relevant acquirer,

b) the scheme or scheme product name (for printing),

c) how to route calls to the acquirer.

B.2 CARD ACCEPTOR DATASET

B.2.1 General

The Card acceptor dataset contains global information that may be used by any of the other datasets configured on the terminal. The data shall include some or all of the data elements described in the following sections.

B.2.1.1 Card acceptor name

The trading name of the card acceptor, that is generally up to 16 alphanumeric characters. This data shall be printed in bold letters on vouchers.

B.2.1.2 Card acceptor address

The address of the card acceptor outlet, that is generally up to 32 alphanumeric characters, which shall be printed on vouchers.




B.2.1.3 Courtesy message

The message printed on the voucher e.g. 'Thank you'.

B.2.1.4 Card acceptor message

Used by card acceptor for his or her own optional message e.g. 'Sale Starts Next Week'.

B.2.1.5 Transaction variable data

Alphanumeric characters used to input transaction data such as cashier/ticket number etc.

B.2.1.6 Stored telephone numbers

If the terminal supports integrated voice facilities then it shall support the storing of commonly used telephone numbers.

B.1.2.7 PABX access digits

If the terminal is connected to the communications network by a PABX then the digits used to access an outside line shall be stored here for use by all acquirer datasets.

B.2.1.8 Telephone signalling type

Identifies type of signalling used (i.e. pulse or tone dialling) and if a telephone is used.

B.2.1.9 Dial pause parameters

A parameter used to indicate a time delay between seizing the line and dialling, and/or between dialling access digit/s and the main number.

B.2.1.10 Data port parameters

A parameter used to control a communications port to either an attached EPOS system or an external modem (may include modem set-up strings).

B.2.1.11 Call barring indicator

If the terminal supports integrated voice facilities, it shall support the ability to bar certain call types. Calls barred that shall be supported are:

a) None,

b) Numbers up to 5 digits but not beginning with 0 or 9,

c) Numbers up to 8 digits but not beginning with 0, 90, 100, 155, 9100, or 9155,

d) Numbers up to 11 digits but not beginning with 00, 155, 900 or 9155,

e) Numbers up to 4 digits but not beginning with 9,

f) All. Up to 16 digits if a stored number facility is used. Up to 24 digits if stored number facility is not used. (Numbers 0, 151, 999, 9:999, 9999, 112, 9112 and 9:112 shall always be allowed).




B.3 ACQUIRER DATASET

B.3.1 General

The acquirer dataset is used to store data specific to an acquirer.

B.3.2 Random transaction selection

The acquirer may, in addition to the floor limit, specify values that are to be used in calculating whether the transaction shall be randomly sent real-time for authorisation:

a) target percentage to be used for random selection (in the range of 0 to 99),

b) threshold value for biased random selection (which shall be zero or a positive number less than the floor limit),

c) maximum target percentage to be used for biased random selection (also in the range of 0 to 99).

These values shall take into account, for each application, the relevant payment system specified values. (See EMV Application Specification for detailed explanation of use.)

B.3.3 Application identities

If a terminal supports IC cards then the application identity (AIDs) of each of the card applications supported shall be stored.

B.3.4 Card scheme public keys

If the terminal supports IC cards then it shall contain card scheme public key data. Refer to EMV for maximum key sizes. Terminals shall be able to store a minimum of 40 scheme public keys. For each key the terminal shall store:

a) RID (registered application provider identifier). Each scheme shall have its own RID, and is the method of identifying which card scheme is used at the terminal. Scheme products are further identified by the concatenation of a PIX to the RID that further identifies scheme products,

b) exponent. A value assigned by the card issuer on card creation. Values are 3, 216+1,

c) hash check sum. An algorithm check installed in the terminal to verify the correct value and installation of a scheme public key.

B.3.5 Data telephone numbers

Where the terminal supports dial-up operation the terminal shall store up to two telephone numbers for each acquirer. The numbers may be the whole number required (including PABX access digits) or just the PSTN portion of the number with the PABX access digits being obtained from the card acceptor dataset.

When performing transactions the terminal shall try to establish communication with the acquirer using the first data telephone number. If this first attempt fails the same number shall be used for the second attempt. If a third attempt were required then the second data telephone number shall be used.




If all three attempts fail then communications shall be deemed to have failed.

For each of the data telephone numbers configured the terminal shall allow for dial-up communications with:

a) PSTN access port to acquirer,

b) PSS PAD port access,

c) proprietary PAD access,

d) BT Special PAD.

If the terminal is only configured with one data telephone number then only two call attempts shall be made.

B.3.6 Data network user addresses

When an X.25 packet switched network is used as the communications method, either in conjunction with the data telephone numbers or via a communications port, a network user address (NUA) is required. The terminal shall contain up to two NUAs with the first NUA being used in conjunction with the first data telephone number or communications port call attempts, and the second NUA with the second data telephone number or communications port final call attempt. If only one NUA is present, this shall be used for both data telephone numbers and all communications port call attempts.

B.3.7 Voice referral telephone number

It is possible the acquirer may require human intervention during the authorisation process. This is indicated by a value in the Referral telephone number data element. It is possible that a 'hold' message may be sent to lengthen the transaction timeout timer while an acquirer decision is made. The final response message from the acquirer may then indicate if a voice referral is required.

A 'hold' message (see Standard 70 Book 2) is an additional message sent prior to the final response message to extend any terminal timeout timer and warn the card acceptor that the response will take a little longer.

A voice referral shall cause the terminal to disconnect its data path and dial a separate speech telephone number or indicate a telephone number to be dialled on a separate telephone.

The card acceptor can then enter the transaction result via the keyboard for subsequent submission.

For each acquirer it shall be possible to configure the terminal with a default telephone number that is either dialled automatically or displayed if either a referral request be sent in Referral telephone number data element as a response message as indicated in Appendix K or the terminal is unable to complete the transaction without additional manual intervention.

The telephone number shall be stored as a three-part sequence that shall be indicated using the field divider character (FD) to enable the number to be dynamically updated as part of any referral response (the FD character is a Hexadecimal 12). The telephone number format shall be as shown in Table 8 — Voice referral telephone number where:




a) A = PABX to exchange line access digit,

b) B = STD (Area) code for a trunk call,

c) C = Destination telephone number.

Table 8 — Voice referral telephone number

Contents Input sequence

A B C (Num sequence) (FD) (Num sequence) (FD) (Num sequence)

A B (Num sequence) (FD) (Num sequence) (FD)

A C (Num sequence) (FD) (FD) (Num sequence)

A (Num sequence) (FD) (FD)

B (FD) (Num sequence) (FD)

B C (FD) (Num sequence) (FD) (Num sequence)

C (FD) (FD) (Num sequence)

Empty NOT SET (Not set means no numeric value entered)

If the terminal does not support the use of updating referral numbers by the acquirer it shall ignore any referral numbers sent in response messages and shall ensure that card acceptors are prompted to dial the appropriate referral number if requested to do so by the acquirer.

Note: Card acceptors with sophisticated EPOS systems may, subject to agreement by their acquirers ignore the down-line loaded value in preference to using their own system values.

B.3.8 Local count

The local count is the maximum number of transactions that can be stored locally in a terminal for a particular acquirer and its associated issuers. Real-time authorisation is required when the number of transactions stored is one less than or equal to the local count.

In the event of communications failure the terminal shall void the transaction if the number of transactions stored is equal to the local count. Default value = 05.

B.3.9 Transaction limits and counts

For each acquirer the terminal shall be configured with a number of value limits.

B.3.9.1 Floor limits

The terminal shall support a minimum of one floor limit per acquirer ('pre-comms' limit) but preferably two ('pre-comms' and 'post-comms' limits).




B.3.9.2 Down-line loaded terminal floor limit

Some acquirers provide an updated floor limit in the response message. Where a terminal supports the use of down line loaded floor limits it shall hold a floor limit for each acquirer. All floor limits shall initially be set to zero and may be updated by each subsequent response from the acquirer in the Floor limit (pre comms) data element if it is an authorisation transaction or Floor limit (pre comms and post comms) if it is a financial presentment transaction.

The floor limit is one of the elements used to determine if a transaction is suitable for authorisation by the terminal. The 'pre-comms' floor limit is used to manage communications costs and the peak load on the acquirer. The 'post-comms' floor limit is normally higher and is used to minimise the number of times the card acceptor has to revert to manual procedures as a result of temporary acquirer or network unavailability.

In both cases, the terminal stores any financial presentment transactions for transmission next time it contacts the appropriate acquirer. Such messages are identified as 'post-event repeat' messages

Note: Card acceptors with sophisticated EPOS systems (who capture and submit their own transactions) may, subject to agreement by their acquirers, ignore the down-line loaded value in preference to using their own system values

B.3.9.3 Ceiling limit

The terminal shall support a maximum transaction value or ceiling limit of up to five digits that defines the maximum value permitted for this acquirer and its associated issuers. The default configuration shall be ceiling limit checking is disabled.

B.3.9.4 Exclusion band

The terminal shall support a band of values (in whole currency units, e.g. pounds) that shall always require authorisation. The band shall contain a three digits lower transaction amount limit and a three digit the upper transaction amount limit. Amounts greater than or equal to the lower limit and less than the upper limit require real-time authorisation. The default shall be that no checking takes place.

B.3.9.5 Cash pre-communications floor limit

The terminal shall support a pre-communications limit (in whole currency units, e.g. pounds) for cash advances or the cash element of sale plus cash transactions. The limit shall be a maximum of three digits and cash amounts greater than or equal to this value require real-time authorisation. The default shall be no cash floor limit.

B.3.9.6 Cash-ceiling limit

The terminal shall support a cash ceiling limit (in whole currency units, e.g. pounds) for cash advances or the cash element of sale plus cash transactions. Cash amounts greater than this value shall cause the terminal to terminate the transaction. The default shall be no cash-ceiling limit.




B.3.10 Delay signature verification until end of transaction

This parameter enables or disables delaying the collection of the cardholder’s signature until the transaction has been authorised/captured in environment where it is not possible for the cardholder to sign on the terminal while the transaction is in progress.

B.3.11 Delay call set up until after amount entry

This parameter enables or disables the requirement to delay the setting up of the communications link until the amount of the transaction has been entered.

B.3.12 Post-event reconciliation allowed

This parameter enables or disables the ability to perform post-event reconciliation.

B.3.13 Delayed cancel

This parameter enables or disables the ability to delay the termination of the communication to the acquirer until after the response has been received and/or the confirmation message has been sent.

B.3.14 Down-line loaded date

Some acquirers provide a date in the response message to enable a terminal to keep an accurate local date in its memory. The date shall initially be set to zero and may be updated by each subsequent response from the acquirer in the Date data element. The date shall be used to check the validity of the expiry and start dates.

When the floor limit facility is in operation, the check is applied to all transactions subject to local authorisation. Where the date entered is less than the stored date, the terminal shall display an appropriate message (e.g. CALL CARD ISSUER). The date check operation is linked to the floor limit indicator and is therefore disabled if the floor limit facility has been disabled.

Note: Card acceptors with sophisticated EPOS systems may, subject to agreement by their acquirers ignore the down-line loaded value in preference to using their own system date.

B.4 ISSUER DATASET

There are no specific data requirements for issuer datasets that are not shared by equivalent requirements for acquirer datasets.

B.5 ACQUIRER AND ISSUER DATASETS

B.5.1 General

It is possible for both an acquirer and an issuer dataset to be configured differently for the same requirement. Appendix B.1.4 for how to decide which dataset takes precedence.




B.5.2 Card ranges (ISSUER)

The terminal shall contain some form of card range identification that shall allow it to correctly process and route transactions. This information shall be used to ensure that the correct data in the correct format is collected.

B.5.2.1 IIN Ranges

The terminal shall be configured with the IIN ranges of the cards that it is able to accept and process, this may also be known as a card ranging table.

When seeking a match between card PAN and dataset the terminal shall first scan the longest numeric sequence and then others in descending length order until a match is found. When configuring a terminal it is important to check for and ensure that there no overlapping IIN numeric sequences.

B.5.2.2 PAN lengths

The configuration shall be able to define for each IIN range the PAN lengths for the cards associated with that IIN. It shall be noted that some card schemes and therefore IINs support more than one PAN length. A default of no PAN length checking may be used.

B.5.2.3 Issue numbers

Some card schemes use card issue numbers and it is necessary to be able to identify the position and length of this number on track 2 of the magnetic stripe. Configuration of this parameter shall also allow the determination of whether to prompt for the input of an issue number on manual key entry of the data.

It is recommended that the configuration indicate the number of characters between the start sentinel and the issue number and also the length of the number.

B.5.2.4 Start date checking

Some card schemes use either a start date or a validity period encoded on the magnetic stripe and it shall be possible to define the position and format of the start date within the card details.

It is recommended that the configuration indicate the number of characters between the start sentinel and the start date data. Additionally the configuration shall define the format of the data that may be in the format of:

a) MMYY,

b) YYMM,

c) A two-digit number at the assigned position on the account card representing the number of months for which the card is valid. The validity check is to subtract the number of months encoded from the expiry date and add 1, giving a calculated start date.




B.5.2.5 Service code checking

The terminal shall be configured to show if service code checking (see Appendix I) is enabled. It is assumed that the service code is the first three digits immediately following the expiry date on track 2.

B.5.2.6 Excluded card ranges

The excluded card ranges for an acquirer shall only be scanned once a match has been found in the card issuer range. When seeking a match between card PAN and the dataset the terminal shall first scan the longest numeric sequence and then others in descending order until a match is found. If an equal or better match is found within the excluded ranges than that found within the card issuer range the card shall be rejected.

B.5.3 Debit message printed (ISSUER)

Some card schemes require that formal messages 'Please Debit my account with the amount shown' and 'Please keep a copy for your records' be printed on the cardholder’s voucher. It shall be possible to configure these messages on or off by card issuer.

B.5.4 LUHN check operative (ISSUER)

Indicates if a LUHN check is to be performed.

B.5.5 OCD length (ISSUER)

This parameter defines the number of digits on track 2 that are not to be transmitted. (See Standard 70 Book 6 for full description of end-to-end/break forward protection).

B.5.6 Position of expiry date (ISSUER)

Not all cards will be encoded with an expiry date on the magnetic stripe and if a date is encoded its position, on the magnetic stripe, may vary. It shall support three conditions:

a) expiry date follows CFS (recommended default value),

b) no expiry date,

c) the number of characters on card between CFS and expiry date.

B.5.7 Terminal action codes (ISSUER)

If the POS supports IC cards then it shall be necessary to configure the terminal with terminal action codes (TAC) that are used, in conjunction with IC data, to determine the preferred actions and processing for the transaction. As acquirers may process a number of different card types and products the acquirer dataset may contain TAC settings that define the general processing requirements. Some card issuers or products may demand different processing and this can be achieved by defining TACs at card issuer level (see EMV for details of TAC definitions).




B.5.8 Track 2 printing (ISSUER)

This parameter defines the number of digits from track 2 that shall be printed on the voucher. The count starts with the digit after the expiry date and does not include separators. Default value shall be zero.

B.5.9 Address verification data collection (LOGAND)

This parameter enables or disables the requirement to collect CSC and address data on PAN key entered cardholder not present transactions. If the data is collected then it shall be sent in the Descriptive data data element of the request message.

B.5.10 Authorisation transaction types (LOGAND)

The terminal shall support at least the authorisation transaction type individually and in any combination. For a full list of all permitted transaction types see Standard 70 Book 2, message type codes.

B.5.11 Balance enquiry (LOGAND)

This parameter enables or disables the ability of the terminal to process and transmit balance enquiry message types.

B.5.12 Cardholder verification (LOGAND)

For magnetic stripe initiated transactions if the terminal supports a PINPAD for (on-line enciphered PIN with magnetic stripe use) then the method of cardholder verification (PIN or signature) shall be configurable. The terminal shall be able to accept on-line enciphered PIN, signature or both. If the terminal is able to accept both on-line enciphered PIN and signature it shall also be possible to configure which is the default verification method. It shall be possible to configure the following conditions:

a) signature only,

b) on-line enciphered PIN and signature - default signature,

c) on-line enciphered PIN only,

d) on-line enciphered PIN and signature – default on-line enciphered PIN.

If the acquirer dataset is configured for on-line enciphered PIN only or signature only then the issuer dataset shall be configured in the same way to avoid conflict.

If cash advance is allowed as an authorisation only (i.e. non financial presentment) function it shall not be allowed as a data capture function and vice versa.

B.5.13 Financial presentment transaction types (LOGAND)

The terminal shall support the following transaction types individually and in any combination:

a) sale,

b) refund.




For a full list of all permitted transaction types see Standard 70 Book 2, message type codes.

B.5.14 Floor limit operative (LOGAND)

Indicates if the use of floor limits is allowed.

B.5.15 Force enabled (LOGAND)

This parameter enables or disables the ability of the terminal to accept transaction data for transactions that have been previously authorised by an alternative method. All floor limit and other value checks are not used and the transaction is stored for later transmission.

B.5.16 Gratuities (LOGAND)

This parameter enables or disables the ability to support a gratuity function. How this is achieved will depend on the operating environment but in all cases space shall be allowed on the voucher for the cardholder to enter a gratuity amount. This may be added to the transaction amount immediately or the transaction may be saved then recalled later and the amount of the gratuity added later. See section 6.10.4.2.4 Gratuity.

B.5.17 Key entry real-time (LOGAND)

This parameter indicates for each card issuer, card product and acquirer whether or not on manual entry of the card details the transactions shall be sent real-time for authorisation where the value is under the pre-comms floor limit. In the event of a call failure the terminal shall not authorise and shall attempt to generate a voice referral.

B.5.18 Manual entry of card details (LOGAND)

This parameter enables or disables (for each card issuer, card product and acquirer) manual entry of the card details.

B.5.19 Refund no cardholder request (LOGAND)

This parameter enables or disables the request message type allocated for refund transactions where the cardholder is not present.

B.5.20 Reversals (LOGAND)

This parameter enables or disables the ability of the terminal to process and transmit reversal message types.

B.5.21 Sale with cashback (LOGAND)

This parameter enables or disables the ability of the terminal to process and transmit sale with cashback transactions.




B.5.22 Transmit transaction variable data (LOGAND)

Transaction variable data allows for the printing and optional transmission of data such as ticket numbers or cashier numbers; its use is dependent on the presence of the data in the card acceptor dataset. It shall be used as defined in Table 9 — Transaction variable data

Table 9 — Transaction variable data

Configuration Terminal Operation

a) Empty/un-initialised No prompt shall be displayed

No input allowed

b) Fixed alphanumeric No prompt.

The alphanumeric characters are taken as fixed TVD (i.e. CASHIER 6).

c) Alphanumeric prompt The prompt shall be displayed as soon as an account number is entered.

d) Alphanumeric prompt plus fixed alphanumeric

A prompt is supplied for the input of variable data.

Fixed TVD may be present and the variable part added to it.

The prompt shall be displayed as soon as the account number is entered.

B.5.23 Authorisation post-event (LOGOR)

This parameter enables or disables the ability to complete the transaction post-event after a communications failure. The default is that post-event authorisation is allowed.

B.6 POLLED ENVIRONMENT

B.6.1. Other card data (ISSUER)

This parameter enables or disables the collection and transmission of additional discretionary track 2 data, for certain card products, in the data capture message.

B.6.2 Reference data (ISSUER)

This parameter enables or disables the prompting for and collection of additional transaction reference data, for example seat number, that shall be sent in the data capture message.

B.6.3 Vehicle data (ISSUER)

This parameter enables or disables the collection and transmission of additional vehicle data for the transaction. It shall be possible to configure and prompt for the collection of the vehicle registration number and/or the vehicle mileage.

B.6.4 Airline ticket number (LOGAND)

This parameter enables or disables the prompting for and collection of an airline ticket number that shall be sent in the data capture message.

B.6.5 EPOS transaction data (LOGAND)

This parameter enables or disables the transmission of EPOS card acceptor, location, identity and voucher number the data capture message.




B.6.6 Purchasing customer reference (LOGAND)

This parameter enables or disables the prompting for and collection of a purchasing customers references number that shall be sent in the data capture message.

B.6.7 IC terminal configuration data

The introduction of IC Cards means that additional data elements and configuration values have to be supplied to terminals. Table 10 — IC terminal configuration data lists those data elements that need to be present and the configurations that need to be supported but not how this will be achieved. The data elements quoted are those in EMV tables of data elements and are of the same size.

Table 10 — IC terminal configuration data

Data element Notes Acquirer identifier

Additional terminal capabilities

Application identifier (AID) (See Note 1)

Application version number

Certification authority public key

Certification authority public key check sum

Certification authority public key exponent

Certification authority public key index

Certification authority public key modulus

Default transaction certificate data objects list (TDOL) (See Note 2)

Maximum target percentage to be used for biased random selection

Card acceptor category code

Target percentage to be used for biased random selection

Terminal action codes

Terminal capabilities

Terminal country code

Terminal identification

Terminal risk management data

Terminal type

Threshold value for biased random selection

Transaction currency code (See Note 3)

Transaction currency exponent (See Note 3)

Note 1: The AID shall be used to determine which applications presented by an IC, are supported by the terminal. However, the terminal can perform transaction routing via the AID or the IIN, as preferred by the terminal design.

Note 2: An optional default TDOL list would be required for each scheme supported by the terminal.

Note 3: These to be used as the default currency code and exponent unless replace by other values selected as part of a multi-currency environment.

STANDARD 70 Book 1 PAGE: 97 APPENDIX C: TRANSACTION TIMES 1 June 2007


C. TRANSACTION TIMES

C.1 REQUIREMENT

APACS require that transaction times for an IC card used with a PIN shall be 'neutral' with respect to a base transaction time, measured in a magnetic stripe environment. For further guidance on the underlying architecture recommendations, see 'An integrated systems architecture for acceptance of chip cards' (Teconomica Ltd for the British Retail Consortium, July 1999).

This annex summarises best practice and recommends when and how transaction times can be measured and assessed. It is acknowledged that the numerical measurement is only part of the story and that qualitative impressions of relative timings are equally important.

The measurement of transaction times applies to all IC card and PIN transaction types and IC card and PIN card types. Transactions that result in an exception condition (e.g. PIN retry, PIN locked, referral) should be ignored, although they will have an effect on average transaction times. The management of exception conditions will be treated separately from that of transaction times.

C.2 MEASUREMENT OF TRANSACTION TIMES

Transaction times shall be measured from card insertion to card ejection.

For the manual readers that are used in the majority of points of sale, the card is not ejected but removed by the card acceptor or cardholder. It is therefore recommended that where timing is to be measured electronically, it be measured from the time the card is powered up to the time it is powered down.

Similarly, the base transaction time for magnetic stripe cards should be measured from the start of swiping to the completion of transaction processing. This completion processing includes the printing of the voucher, signature by cardholder and acceptance by the card acceptor, and the terminal returning to the ‘ready’ state for the next transaction.

In many environments, these times can be measured directly, with the help of a diagnostic or 'trace' mode set within the terminal software. An allowance should be made for the effects of this diagnostic mode, which is likely to affect magnetic stripe and PIN transactions differently.

In other environments, it will not be possible to measure timings electronically; in these cases a stopwatch may be used to measure the time from card insertion to the appearance of the prompt 'Remove Card'.

A note should be taken of:

a) the average transaction time,

b) the spread of times (preferably as a standard deviation),

c) unit of measurement or resolution of measurement (stop-watch times should be taken as accurate to no better than 0.25 seconds),

d) sample size, date and time and any other conditions relevant to the measurement (e.g. was this measurement effected in a test or live environment?).


APPENDIX C: TRANSACTION TIMES ! June 2007


Where testing is carried out in live environments, it is also recommended that any transactions in which exception conditions were met (including cardholder pressing CLEAR or CANCEL) be recorded separately.

C.3 TRANSACTION TIME COMPONENTS

Thus defined, the transaction time includes:

a) card power-up and ATR,

b) application selection and fetch data (Get Processing Options),

c) card and terminal risk management,

d) PIN entry,

e) first cryptogram generation,

f) on-line authorisation (where necessary),

g) second cryptogram generation (where necessary),

h) card issuer script processing (where applicable),

i) completion processing (in this context includes the printing of the voucher and powering down the card).

The card speed, terminal speed or both affect most elements of the transaction time. The PIN entry is primarily a function of the cardholder, and it is expected that most cardholders will become faster at PIN entry as they become used to the process. Each individual cardholder may, however, be slower for the first one or two transactions, as the process is explained to them. For benchmarking purposes, an experienced cardholder should be assumed, i.e. there are no unnecessary delays or hesitations during PIN entry.

The real-time authorisation time is dependent on external networks, acquirer system loadings etc, as well as the level of authorisations undertaken. It is recommended that these be measured separately where practical, so that the effect of these factors can be understood.

Other factors such as printer speeds and the use of hot-card lists will cause transaction times to vary among card acceptors, and local environmental factors will always come into play, so that absolute figures are likely to be meaningless. It is also possible for some combinations of card and terminal to be unusually fast or slow (Card A may be faster than Card B in terminal X, but slower in terminal Y). However, some benchmark times will be valuable, and this annex proposes some benchmark processes, with the aim of obtaining comparable figures at card acceptor level.




C.4 OPTIMISING TRANSACTION TIMES

C.4.1 Cards

It is found that different cards produce radically different transaction times. Many of the UKIS cards used from 1997 to 2001 had very small RAM memory sizes, slow communications paths, and whilst built to be EMV compliant were not optimised for speed. Most current-generation cards (typified by VSDC and M/CHIP 4.0) are very much faster. UKIS cards cannot be used for IC and PIN.

In order to optimise transaction times, card manufacturers, personalisation bureaux and issuers should give attention to the following factors:

a) card hardware characteristics: cards shall have adequate RAM memory for communications, and shall be able to undertake limited communications activities (loading/unloading buffers) during processor activity,

b) communications protocols: cards shall support the maximum clock and communications speeds permitted by EMV 4 (It is recommended that cards respond to a cold reset with TA1=D4 in specific mode). However, APACS has concluded that there is little difference in speed between character mode (T=0) and block mode (T=1), and either may be supported (all UK card issuers are planning to use T=0 cards),

c) card file structure and data mapping: cards shall present their data to the terminal in the order: Track 2 equivalent data, CVM list, RSA certificates, other data – see Table 11 — Proposed card file read order. The data shall be contained in as few records as possible consistent with this requirement.




Table 11 — Proposed card file read order

Read only Data element Required for 1 Track 2 equivalent data 2 Issuer Country CVM list CVM 3 Application currency code CVM 4 Certification public key index SDA 5 Issuer public key certificate SDA 6 Issuer public key exponent SDA 7 Issuer public key remainder SDA 8 Signed application data SDA 9 Application effective date Processing restrictions 10 Application expiration data Processing restrictions 11 PAN Terminal risk management 12 PAN sequence number Real-time authorisation 13 IAC default Terminal action analysis 14 IAC denial Terminal action analysis 15 IAC on-line Terminal action analysis 16 Application usage control Processing restrictions

17 Issuer country code Processing restrictions 18 CDOL 1 Terminal action analysis 19 CDOL 2 Terminal action analysis 20 Application version number Processing restrictions 21 Cardholder name 22 Track 1 discretionary 23 Service code

Data not required for POS transaction processing should not be included in the application data for card applications used only for POS transactions:

a) script processing: card issuers should only under very exceptional circumstances send multiple scripts to cards. There are few practical instances where more than one script will fit logically together,

b) cryptography: UK card issuers have agreed to use static data authentication (SDA) initially. Dynamic data authentication (DDA) or combined dynamic data authentication (CDA) should not be used except with higher specification cards incorporating a dedicated cryptographic processor. The use of cards with Chinese remainder theorem (a technique for improving processing times for RSA) is also likely to be a necessity and is thus recommended,

c) multi-application cards: cards using a Multi-application operating system (e.g. Multos or Javacard) are currently significantly slower than native operating systems. Next-generation versions of these card types are expected to be more highly optimised and should overcome these problems. Card issuers should ensure that any future plans to issue multi-application cards require the use of fully optimised cards.




C.4.2 Terminals and EPOS systems

The EPOS system, terminal and communications network also plays a major part in ensuring a fast transaction time.

Hardware and software vendors, card acceptors and acquirers are advised to consider the following points in order to optimise transaction times:

a) hardware characteristics: some EMV Level 1 IFDs are known to be slow, and this is probably a function of any micro-controller, communications devices and buffer sizes. 8-bit micro-controllers are to be avoided, and 32-bit devices offer best performance.

b) technical architecture: it is impossible to be prescriptive about specific cases. Many card acceptors will be constrained by existing equipment, by in-store network architectures, etc. In some cases, the need for flexibility and future proofing may dictate a sub-optimal timing solution, and this is the card acceptors decision. In general, the fastest transaction times will be obtained by:

1. minimising the number of communications interfaces, particularly those requiring buffering of card messages (APDUs),

2. ensuring that any cryptographic processes are carried out in the fastest available hardware,

3. ensuring that as many activities as possible take place in parallel (through multi-processing or the use of multiple processors). It is particularly important that card communications and terminal processing should take place in parallel.

c) communications speeds: for best performance, all terminals should support the highest speeds allowed by EMV 4 (i.e. 38,400 bps) for communication with the card (terminals should support specific mode and TA1 = D4.); all higher-level interfaces should be at least as fast as this, and preferably considerably faster,

d) Cryptography: hardware and software implementations are both capable of achieving good performance; however general-purpose microcontrollers in terminals will frequently require a cryptographic co-processor. Benchmark times for a single RSA verification on an 896-bit key are approximately 100 ms. Terminals shall be capable of handling key lengths up to 2048 bits without serious degradation of performance,

e) printing operations: printing should, wherever possible, take place whilst the card data is being read, terminal risk management is being carried out and during real-time authorisation. The perception of transaction time is often as important to the cardholder as the actual time taken,

f) hot card list: where a central hot card list is held by the card acceptor, any checks carried out on this list for IC card transactions shall not form part of the terminal risk management process; if the check fails, but the transaction has been allowed to proceed locally, then the transaction shall be reversed and resubmitted with the appropriate flag set,

g) cardholder insertion: card acceptors should consider modifying their processes in order to permit cardholders to insert their cards earlier in the transaction, and thereby allow card authentication to take place sooner.

STANDARD 70 Book 1 PAGE: 103 APPENDIX D: DISPLAYABLE MESSAGES 1 June 2007


D. DISPLAYABLE MESSAGES

The messages shown in this Standard are the basic message requirements of a device complying with this Standard and are mostly generated by that device. Other messages may need to be displayed as dictated by other standards e.g. EMV has a list of messages that a device must display. Further messages will be returned as part of the authorisation response by the card acquirer and their definition is also outside the scope of this Standard but they shall also be displayed.

However, the messages defined here are, despite the use of the word “shall”, intended to show minimum requirements and may be expanded upon if space permits on the card acceptor and cardholder displays, subject to not losing the meaning of the message or its clarity. An example of this would be to change “WIPE CARD” to “PLEASE SWIPE CARD”.

All messages shall be presented as the circumstances dictate, e.g. the prompt for PIN entry, to effect the transaction process.

Not all messages will be shown to both cardholder and card acceptor e.g. “STORE FULL” would only be appropriate for the card acceptor.

The ordering of messages may be dictated by the card schemes and this shall be followed e.g. in the PIN messages.

As there may be a conflict between the message returned by the acquirer’s system and the message to be displayed after final communication with an IC card the terminal shall not display the message returned from the acquirer system until the final outcome of the transaction is known.

There are, however, a number of messages that a terminal shall use in order that the general application of real-time processing as defined in Standard 70 can be supported with a multiplicity of terminal and computer systems.

Table 12 — Specific messages lists the messages that a terminal shall support and Table 13 — Default messages lists the default messages and the conditions under which they shall be used.

The messages contained in Table 12 — Specific messages and Table 13 — Default messages are shown in upper case to identify them as display messages. It is preferable to display messages, on the terminal or PIN pad, in mixed upper and lower case letters to improve readability. It is also preferable to capitalise the first letter of all words in a key instruction, for example the message shown as ‘PLEASE WAIT’ in this standard should appear as ‘Please Wait’ on the terminal display.

Messages shall be displayed for 30 seconds when the display shall be cleared. The last message shall be displayable once only upon depression of a recall button. This shall clear the message so that it cannot be displayed again.


APPENDIX D: DISPLAYABLE MESSAGES 1 June 2007


Table 12 — Specific messages

Message text Usage

AUTH CODE: nnnnn Used to display the contents of the Authorisation code data element or, where a transaction is approved by the terminal, the calculated code as defined in Appendix J

CALL AUTH CENTRE Used whenever a transaction has begun but a connection cannot be established with the relevant acquirer.

This may be because the transaction fails internal validations or that it is not possible to establish a communications link or the link fails at any stage up to the time a response message is received from the acquirer.

This message shall also be displayed where the acquirer has requested a voice referral but a handset facility is not available

CALL CARD ISSUER Used whenever a card issuer is the only organisation that can assist the cardholder

CALL HELP DESK Used when it is a terminal problem that needs specialist assistance to resolve.

CARD NOT AUTHORISED Transaction not approved (see DECLINED)

CASHBACK Used to prompt cashier or cardholder to request cashback

CHECK SIGNATURE Used to prompt for visual verification of the signature when a cheque guarantee authorisation has been requested

COMPLETED Used on the PINPAD display to indicate that the transaction has finished.

This message shall be displayed when the contents of the PINPAD data data element is displayed on the terminal

CONNECTION MADE Used when the terminal receives the ENQ message.

If the data entry phase has still not been completed at this stage, the terminal shall wait until data entry has been completed before continuing with the transmitted sequence.

CONNECTION MADE shall not be displayed until data entry has been completed but the card issuer or acquirer name shall be omitted if the CONNECTION MADE stage has been reached

DECLINED

Printed/displayed on completion of a voice referral where the acquirer/issuer/ card has declined the transaction and the card acceptor has indicated this to the terminal

DECLINED BY CARD – CARDHOLDER SHOULD CONTACT ISSUER

Printed/displayed when a transaction is terminated by the card prior to any connection to the acquirer. This is controlled by internal IC security parameters

DIALLING or LIFT RECEIVER

Used on receipt of a response including a value in the down-line loaded telephone number data element.

The terminal shall display DIALLING and the number dialled, which shall change to LIFT RECEIVER at the appropriate time, followed by any message in the Message data element

DO NOT REMOVE CARD Warns cardholder/cashier not to remove card

ENTER AMOUNT Used to prompt for amount entry

ENTER PIN Used whenever cardholder is required to enter their PIN number

ESTIMATED MAXIMUM AMOUNT £XXX.XX or MAX AMOUNT £XXX.XX

Used in hotels and card hire when the cardholder checks in

EXPIRES MM/YY Used to prompt for expiry input from the keyboard




Message text Usage

GRATUITY? ENTER/CANCEL

Used in restaurants to allow cardholders the opportunity to give a gratuity

INSERT AGAIN Used to indicate that the IC has not been read successfully

INSERT CARD Used in the point in the procedure where card input is required for an IC card

ISSUER DECLINE – CARDHOLDER SHOULD CONTACT ISSUER

Printed/displayed on completion of a transaction where the issuer has declined the transaction

ISSUE NUMBER Used to prompt for entry of the issue number from the keyboard

KEY CARD NUMBER Used to indicate that the magnetic stripe has not been read successfully three times

LAST PIN TRY Warns cardholder that they are about to have a final attempt at entry before the PIN maybe locked

LINE BUSY ‘Used to indicate that the telephone line to which the terminal is connected is already in use

LOADING Used to indicate the terminal is receiving configuration data from a remote computer

MANUAL PROCEDURE or PLEASE INITIALISE

Used when a transaction is started but the terminal has no configuration data too enable a call to be initiated.

Terminal manufacturers may include a facility for the terminal to recognise a completely un-initialised state and display an appropriate prompt to force initialisation by displaying 'PLEASE INITIALISE' (or 'PSE INITIALISE' if only 16 digits of display are available)

MAXIMUM £XX – PLEASE ENTER PIN'

Used in petrol pumps to indicate the maximum value that the transaction can be completed for

OPEN TAB MAXIMUM £XX.XX ENTER PIN'

Used in bars and restaurants to advise the cardholder of the maximum amount they may be charged, when a card is held behind the bar until the final payment is made.

PASS CARD TO CASHIER Used to prompt cardholder to hand card to cashier

PIN ERROR or INVALID PIN Used to indicate an incorrect PIN has been input

PIN LOCKED Where a PIN is locked in the current or previous transaction

PIN OK Use to signify that PIN entry was correct

PLEASE WAIT Used on receipt of a 'hold' message with an empty Message data element otherwise the terminal shall display the Message data element contents.

PREPARE VOUCHER Used to prompt the card acceptor to complete a voucher set when the terminal has only been configured for authorisation for that card

REFERRAL Used to inform the card acceptor that a referral is needed or is underway

REMOVE CARD Used to prompt either cardholder or cashier to remove card from chip reader

REQUEST INVALID Used to indicate that the requested transaction is not supported for the card presented

RIGHT WAY ROUND A terminal manufacturer option. Used to indicate no stripe detected.

SELECT PAYMENT TYPE Used were multiple payment options are available from a single card e.g. credit, debit or purse




Message text Usage

SESSION TOTALS

NOT AGREED UNCONFIRMED CANNOT CONFIRM

Used during a reconciliation to advise the card acceptor of the status of the reconciliation transaction

SORRY FOR DELAY Used after any failed call attempt. It shall be displayed until connection is made or all call attempts fail when either CONNECTION MADE or CALL AUTH CENTRE shall be displayed

STORE FULL Used to advise the card acceptor that the post-event store of transactions is full and the terminal needs to call the relevant acquirer.

SUPERVISOR CARD Used to prompt the swiping or insertion of the supervisor card in order that certain functions can proceed

SWIPE AGAIN Used to indicate that the magnetic stripe has not been read successfully

SWIPE CARD Used at the point in the procedure where card input is required for a magnetic stripe card

TRANSACTION COMPLETE Signifies that transaction has been completed

TRANSACTION VOID Used if the transaction is cancelled at the terminal prior to completion of a voice referral

UNABLE TO AUTHORISE Used if the transaction is cancelled by the IC card after real-time authorisation.

UNABLE TO GO ONLINE, OFFLINE APPROVED

Maybe used to provide futher advice on how the transaction has been processed

UNABLE TO GO ONLINE, OFFLINE DECLINED

Maybe used to provide futher advice on how the transaction has been processed

VALID FROM MM/YY Used to prompt for the start date from the keyboard




Table 13 — Default messages

RESPONSE CODE CARD ACCEPTOR DISPLAY

PRINTER PINPAD

00) 08) Authorised 11)

Contents of Card acceptor display data element (see Note 2)

Contents of Card acceptor printer data data element (see Note 2 and 3)

COMPLETED

01) 02) Referral 60)

PLEASE WAIT followed by Contents of Card acceptor display data data element (see Note 2)

AUTH CODE:nnnnn or DECLINED or TRANSACTION VOID (see Note 1)

PLEASE WAIT followed by COMPLETED or DECLINED (see Note 1)

55 (PIN retry) PIN ERROR (No Printing) ENTER VALID PIN Comms failure (below floor limit)

AUTH CODE:nnnnn As card acceptor display COMPLETED

Comms failure (above floor limit)

CALL AUTH CENTRE TRANSACTION VOID TRANSACTION VOID

Cancellation CANCELLED TRANSACTION VOID CANCELLED Hold message PLEASE WAIT (No Printing) PLEASE WAIT Reconciliation COMPLETED COMPLETED COMPLETED Any other Contents of Card acceptor

display data data element (see Note 2)

Contents of Card acceptor printer data data element (see Note 2 and 3)

DECLINED

Note 1: Message printed/displayed on completion of voice referral. 'nnnnn' represents the authorisation code entered by the card acceptor. Replaced for the following transaction types, e.g.

a) refund: REFUND ACCEPTED,

b) refund reversal: REFUND REVERSAL ACCEPTED,

c) other reversal: REVERSAL ACCEPTED,

d) on the display, the word 'ACCEPTED' is always displayed on the second line.

Note 2: The Card acceptor display data and Card acceptor printer data data elements are both part of the Message data element. The construction of the Message data element is shown in Standard 70 Book 2.

Note 3: Contents of Card acceptor display data data element may be used if Card acceptor printer data data element is not present.

STANDARD 70 Book 1 PAGE: 108 APPENDIX D: DISPLAYABLE MESSAGES 1 June 2007



APPENDIX E: TERMINAL FALLBACK PROCEDURES 1 June 2007


E. TERMINAL FALLBACK PROCEDURES

There is a preferred hierarchy of data input methods with decreasing security features i.e. IC read, magnetic stripe read, manual key entry.

Terminals shall use the highest method available based on card and terminal capabilities. Increasingly this will be IC read with fallback to magnetic stripe read. Fall back to manual key entry is being phased out as IC cards are introduced. Terminal suppliers and card acceptors shall confirm with their acquirer which options are acceptable and configure their terminals accordingly

E.1 CONDITIONS FOR IC FALLBACK TO MAGNETIC STRIPE

Scheme rules shall determine the situations when fallback from IC to magnetic stripe is allowable from the situations when the card shall be rejected e.g. if the terminal processing fails, due to a card error, after an IC application has successfully been selected then fallback shall not be allowed, i.e. the transactions shall be rejected.

When fallback takes place in an IC capable terminal the transaction shall be flagged as fallback to the acquirer so that the issuer can identify it is a fallback transaction.

Note: the terminal can flag fallback to the acquirer in the POS entry mode (value 8n Swipe – IC failure) data element (See Standard 70 Book 3) and/or the Reason Code (value 04 – terminal not able to process IC) data element (See Standard 70 Book 2).

All IC / magnetic stripe fallback transactions at chip enabled attended payment terminals shall be authorised either real-time or by a voice referral.

Fallback from IC to magnetic stripe shall not be available at chip enabled unattended payments terminals (CAT’s). These terminals shall reject a magnetic stripe card with a service code of 2xx or 6xx.


APPENDIX E: TERMINAL FALLBACK PROCEDURE 1 June 2007


Figure 20 - Processing flow for IC read failures

Read Failure?

Set "last read failure" indicator

Prompt for MSR

Continue with ICC

STOP

ICC

Yes

No

Continue on MSRfollowing conditions

detailed below

MSR

Check Service Code

2 or 6? Reset last readfailure

Continue withMSR

No

"Last ReadFailure" set?

Yes

Prompt ICCReader No

STOP

Prompt Op. forOverride, Y/N

Overrideoption taken

Reject

No

Reset last read failure

Yes

Reset lastread failure

Optional


APPENDIX F: CARD SCHEME IDENTIFICATION 1 June 2007


F. CARD SCHEME IDENTIFICATION

F.1 INTRODUCTION

It is the responsibility of the acquirer to advise how to identify the cards for which he takes responsibility.

In the normal course of events this is achieved by means of Operating Instructions, which display the various card scheme logos for easy visual identification. These may include Visa, MasterCard, UK UK Maestro, Maestro International, JCB, Solo, Diners Club, American Express, plus the relevant private label card plans.

With the ever-increasing range of cards on the market, it is becoming increasingly complex for a card acceptor to be sure that the correct cards are accepted, and perhaps more importantly, not accepting incorrect cards.

This complexity is reflected at the electronic level where it is becoming increasingly difficult for terminal suppliers and software providers to easily identify cards and their appropriate card schemes.

This annex seeks to identify how cards can be related to card schemes. However the final point of contact shall be the card acceptor’s acquirer(s).

This document supports financial payment cards. It is not intended to support other card products e.g. ATM only and/or E-top-up cards. Card acceptors need to differentiate between card products to:

a) identify the acquirer,

b) apply appropriate POS rules (e.g. cashback),

c) correctly group transactions for reconciliation,

d) display correct narrative on receipts/displays.

F.2 ISSUER IDENTIFICATION NUMBER

Card issuers allocate numbers to cardholders that may be embossed and encoded on the cards they issue (Note some cards need not be embossed).

These numbers consist of an IIN followed by a cardholder number, followed by a LUHN check digit. Full details can be found in the International Standard Number ISO 7812-1.

The point of significance is that the IIN is an issuer number and not specifically a card scheme number.

It is emphasised that this is a fast changing environment. Details shall always be confirmed with the relevant acquirer.




F.3 REGISTRATION AUTHORITIES

IIN's are allocated under the authority of ISO by Registration Authorities. Each national standards body has authority over its own national ranges. In the UK the national registration authority is provided by APACS.

For further information on airline, store, fuel and other card types, please contact APACS and request: ‘List of UK Card Issuer Identification Numbers – Alpha and Numeric Listing’.

F.4 CURRENT CARD SCHEME IIN'S

These tables shows the specific checks required to identify the cards scheme and/or product, the validation checks required, the transaction types and any additional checks that are required when they are not permitted.

They have been separated into Visa, MasterCard/Maestro, Solo, JCB, American Express and Diners.

In all instances the acquirer will be able to provide further details (e.g. on the layouts of Track 2) and will have the most up to date information.

It is strongly recommend that all these elements are configurable

F.4.1 General Notes

Service Codes: The location of the service code may vary on Track 2 and is only used on a magnetic stripe read of the card.

Details on how to check the service codes are outlined in Appendix I: Use of Service Codes; the acquirer may have more specific requirements.

PAN Length : PAN Lengths may vary and this will impact on the layout of Track2.

LUHN check: Details of the LUHN check digit formula can be found in Appendix G: LUHN Formula

Expiry Date: The location of the expiry date varies according to the PAN length.

Contact the acquirer for a suggested expiry date checking algorithm.

Issue Number: The location of the issue number, when available in Track 2, varies.

Contact the acquirer for further details.

Validity Period/Start Date:

The location and format of the start date, when present on Track 2, varies according to the issuer.

Contact the acquirer for a suggested checking algorithm and for Track 2 layouts.

Card Security Code:

See Standard 70 Part 2 and contact the acquirer for more information on the Card Security Code processes.

Address Verification:

See Standard 70 Part 2 and contact the acquirer for more information on the Address Verification processes.




F.4.2 Glossary

Yes Check must be performed

No Check must not be performed – data may not be present, is not reliable or is not supported by the scheme.

Optional If appropriate to the processing environment eg Card Security Code is usually only checked in a keyed CNP environment.

If present The presence of the data depends on the specific IIN range and shall be checked if present. The acquirer will be able to provide more detail on when this data can be expected.

Barred The use of this scheme for this function is prohibited.

By Agreement The use of this scheme for this function (eg purchase with cashback) requires special agreement of the acquirer.

Supported The device can expect to provide this functionality for this scheme.

Not Supported The scheme does not currently support this functionality.




Table 14 – Visa IIN ranges

Visa

UK Visa Debit Card

UK Visa Electron

V-PAY Visa

Standards ISO 7810-3 7810-3 7810-3

Scheme Identification

IIN ranges: 413733-37

446200-99

453978-79

454313

454432-35

454742

456725-45

465830-79

465901-50

484409-10

490960-79

492181-82

498824

450875

484406-08

484411-55

491730-59

491880

V-PAY product IINs may start with a’5’ or ‘6’.

V-PAY cards have two AIDs (V-PAY and Electron),

All remaining IIN’s beginning with 4, except those listed below.

Validation Service Codes: Yes Yes Yes Yes

PAN length: 16-19 16-19 16-19 16-19

LUHN check: Yes Yes Yes Yes

Expiry date: Yes Yes Yes Yes

Issue number: No No No No

Validity period: No No No No

Card security code:

Optional Optional Optional Optional

Address verification:

Optional Optional Optional Optional

Transaction Types

Purchase with Cash

By Agreement

By Agreement

By Agreement Barred

Method of Entry Magnetic Stripe Read

Supported Supported Not supported Supported

Keyed Card Not Present


Keyed Swipe Failure


Cardholder Keyed to Internet


EMV Chip Supported Supported Supported with PIN verification

Supported

Internet Cardholder Verification

3D Secure Supported Supported Supported Supported




The following table provides known UK Visa ATM BIN ranges. Please bear in mind that this is not a full range and that your terminal/equipment should be reading the application usage control and service code.

Table 15 – Visa exceptions

Exceptions (Known UK Visa ATM only Cards) 490300-1 491100-02 490310-34 491103-73 490340-99 491183-99 490400-09 492183 490419 492800-99 490451 490459 490467 490475-78 490500-99 491001




Table 16 - MasterCard IIN ranges

MasterCard & Maestro

MasterCard UK Maestro Maestro International

Standards ISO 7810-3 7810-3 7810-3

Scheme Identification IIN ranges: Note 1 510000-559999

675900-99

500000-509999

560000-589999

600000-699999

Validation Service Codes: Yes Yes No

PAN length: 16 16, 18 or 19 Any

LUHN check: Yes Yes No

Expiry date: Yes Yes No

Issue number: No If Present No

Validity period: No If Present No

Card security code: Optional Optional No

Address verification: Optional Optional No

Transaction Types

Shows where additional checks are required and when they are not permitted

Financial Purchase with Cash Barred By Agreement

By Agreement

Method of Entry Magnetic Stripe Read Supported Supported Supported

Keyed Card Not Present Supported Supported Refunds only

Keyed Swipe Failure Supported Supported Refunds only

Cardholder Keyed to Internet

Supported Supported By Agreement

EMV Chip Supported Supported Supported

Internet Cardholder Verification

3D Secure Supported Supported Supported

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.




Table 17 - Solo IIN ranges

Solo

Standards ISO 7810-3

Scheme Identification IIN ranges

676700-99

Validation Service Codes: Yes

PAN length: 16, 18 or 19

LUHN check: Yes

Expiry date: Yes

Issue number: If Present

Validity period: If Present

Card security code: Optional

Address verification: Optional

Transaction Types


Financial Purchase with Cash By Agreement

Method of Entry Magnetic Stripe Read Supported

Keyed Card Not Present Supported

Keyed Swipe Failure Supported

Cardholder Keyed to Internet Supported

EMV Chip Supported

Internet Cardholder Verification 3D Secure Supported




Table 18 - JCB IIN ranges

JCB


Scheme Identification IIN ranges: Note 1 352800-358999

Validation Service Codes: Only check on a chip-enabled device.

PAN length: 16

LUHN check: Yes

Expiry date: Yes

Issue number: No

Validity period: No


Address verification: No

Transaction Types


Financial Purchase with Cash Barred





EMV Chip Supported

Internet Cardholder Verification 3D Secure Optional




Table 19 - American Express IIN ranges

American Express


ANSI

Scheme Identification IIN ranges: 370000 - 99

340000 - 99


PAN length: 15

LUHN check: Yes

Expiry date: Yes

Issue number: No

Validity period: No


Address verification: Optional

Transaction Types


Financial Purchase with Cash Barred





EMV Chip Supported

Internet Cardholder Verification 3D Secure No




Table 20 – Diners IIN ranges

Diners


Scheme Identification IIN ranges: 3045 36 38


PAN length: 14

LUHN check: Yes

Expiry date: Yes

Issue number: No

Validity period: Yes

Card security code: Yes

Address verification: No

Transaction Types


Diners

Financial Purchase with Cash No (Cash Advance permitted)





EMV Chip Not supported

Internet Cardholder Verification 3D Secure Not supported

Notes:

1 Transactions initiated with a card may not be declined by the terminal or card acceptor processors as a result of edits or validations performed. There is an Exceptions table, Table 15 – Visa exceptions which identifies known UK ATM Visa IIN exceptions.

2 Track 2 layouts vary. For further details please contact your Acquirer 3 Available for magnetic stripe read transactions. 4 The LUHN Check algorithm is available from your Acquirer. 5 Details of service code checking and failure responses are available from your acquirer. 6 A suggested expiry date algorithm is available from your acquirer. 7 Details of how to check the validity period are available from your acquirer. 8 Specifications are available from your Acquirer. 9 UK Maestro/Solo ranges take precedence over International Maestro ranges i.e. use

Domestic Maestro rules 10 Visa propose to utilise longer PAN lengths in the future. We recommend this attribute is

configurable




11 Transactions initiated with a card may not be declined by the terminal or card acceptor processors as a result of edits or validations performed

12 JCB service codes must only be validated if the device is capable of processing JCB chip cards

13 The customer must have prior agreement from your acquirer 14 The purchase element must be greater than zero and the cash element may have an

upper limit.

F.5 IDENTIFICATION OF UK/FOREIGN ISSUED IC CARDS

With the introduction of IC cards it is possible to determine the country of origin of the card by interrogating the Issuer country code data element. This is important, as scheme rules for fallback may differ between UK and overseas issued cards, e.g. for CVM fallback.

It is possible to identify UK cards by an Issuer country code of value 826. However, this data element is optional for the card and, therefore, terminals cannot rely on its being present.

If the IC card encoding does not contain the Issuer country code then the terminal will not be able to identify a card as being UK issued.

Only cards that contain the Issuer country code with a value of ‘826’ shall be regarded as a UK card. All other cards shall be considered as non-UK in of terms of following scheme requirements.

With regard to technology fallback, it is not possible to identify UK cards reliably through the magnetic stripe only, and terminals shall not attempt to do this.


APPENDIX G: LUHN FORMULA 1 June 2007


G. LUHN FORMULA

G.1 LUHN FORMULA FOR CALCULATING THE PAN CHECK DIGIT

The following steps are involved in this calculation, which applies to any length PAN:

a) double the value of alternate digits beginning with the first right-hand digit (low order),

b) add the individual digits comprising the products obtained in a) to each of the unaffected digits in the original number,

c) subtract the total obtained in a) from the next higher number ending in 0 (this is the equivalent of calculating the 'ten complement' of the low order digit (unit digit) of the total),

d) the resultant digit is the PAN check digit that should equal the last digit of the PAN. Note: If the total obtained in a) is a number ending in zero (30, 40 etc.), the check digit is 0.

G.2 EXAMPLE CALCULATION

Account Number without check digit 4992 739 871

4 9 9 2 7 3 9 8 7 1 Step

x 2 x 2 x 2 x 2 x 2 1 – double value of alternating digits

18 4 6 16 2

4 + 1 + 8 + 9 + 4 + 7 + 6 + 9 + 1 + 6 + 7 + 2 = 64 2 – Add individual digits

3 – Subtract 64 from 70 = 6

Account number is therefore 4992 739 8716


APPENDIX G: LUHN FORMULA 1 June 2007



APPENDIX H: PRINTED DATA 1 June 2007


H. PRINTED DATA

H.1 GENERAL REQUIREMENTS

H.1.1 Number of copies

A paper record shall be produced for every transaction performed and this shall contain all the information necessary to provide a completed audit trail enabling cardholders, card acceptors or acquirers to resolve queries or disputes.

Where the cardholder uses their signature for cardholder verification at least two copies of the paper record shall be produced; one copy for the cardholder to enable reconciliation against a statement and the other for retention by the card acceptor, which must have space for the cardholder's signature.

Where PIN is used for cardholder verification at least one copy of the paper record shall be produced for the cardholder to enable reconciliation against a statement. The card acceptor may require a copy for use in the point of sale back office reconciliation.

Some retail operations may require three copies to be produced.

H.1.2 Transaction types

The type of transaction recorded shall appear in words and be clearly visible. Acceptable transaction types include, SALE, REFUND, CANCELLED SALE, CANCELLED REFUND, DECLINED SALE, and PURCHASE WITH CASHBACK.

For refunds, cancelled and declined transactions, the non-standard nature of the transaction shall be highlighted. This may be achieved, for example, by the use of red print, double height characters, delineation with asterisks or bold text, depending on printer capabilities.

H.1.3 Transaction data source

As there are three different methods of obtaining the card details for the transaction it is necessary to identify the method of data collection on the voucher. The three methods and recommended narratives are:

a) ICC read; print ICC,

b) magnetic stripe read; print SWIPED,

c) key entered; print KEYED.

H.1.4 Card number (PAN)

To protect cardholders from fraud resulting from people stealing information from point of sale receipts, the PAN on cardholder copies shall be masked.

Cardholder receipts shall only reflect the last four digits of the PAN, replacing all preceding digits with fill characters such as X, * or # [blank spaces or numeric characters must not be used].




H.1.5 Labelling

To assist in the process of dealing with enquiries and to avoid confusion, the following labelling system could be used as an optional feature on all data elements.

The card acceptor number for the acquirer could be preceded by Merchant:, terminal identification number by TID:, and the transaction reference number by Ref:. If the authorisation code is printed, it may be preceded by Auth.

H.1.6 Layout

The only mandatory requirements in connection with the layout of text on a voucher are that the declaration signature and amount are adjacent to each other. Every effort shall be made to ensure that other information is presented logically and clearly, e.g. date and time shall be adjacent to each other as shall card number and expiry date. Where there is no reason to the contrary, the layout of the following examples shall be used.

H.1.7 Retention

Card acceptor copies bearing the cardholder's signature shall be retained for a period of time in accordance with acquirer's and legislative requirements. These copies shall be kept in a manner that enables retrieval in the event of a query or dispute but securely to prevent fraud by misuse of the card details.

For PIN transactions there is no requirement to retain the copy produced at the time of the transaction, provided that this can be recreated from stored electronic data if required.

H.1.8 Printer failure

To cover the possibility of printer failure or 'paper out', the card acceptor shall ensure that adequate substitute or duplicate vouchers can be created to meet the needs of card acceptors, cardholders and acquirers. Duplicate vouchers printed after the re-loading of paper shall be clearly marked DUPLICATE and shall not result in the duplication of financial entries.

H.1.9 Transaction void

The card acceptor has the capability of cancelling a transaction at any time prior to the completion of the transaction.

In such cases the data format for the specific transaction type shall be provided subject to the authorisation code data element being over written with the words 'TRANSACTION VOID' or 'CANCELLED' which shall be highlighted (an optional audible warning is suggested for card acceptor convenience).

H.1.10 Dynamic currency conversion

Dynamic currency conversion has a requirement to support card scheme disclaimers for MasterCard and Visa. MasterCard have both a long and short version disclaimer statement. The terminal shall print the appropriate card scheme disclaimer on both the cardholder and card acceptor copies of the receipt. If the receipt is signed then the disclaimer shall appear before the signature panel. Contact the acquirer to determine how these messages should be used.




H.1.10.1 MasterCard long disclaimer statement

The MasterCard long disclaimer statement is as follows:

“I understand that MasterCard has a currency conversion process and that I have chosen not to use the MasterCard currency conversion process and I will have no recourse against MasterCard with respect to any matter related to the currency conversion or disclosure thereof”

H.1.10.2 MasterCard short disclaimer statement

The MasterCard short disclaimer statement is as follows:

“I have chosen not to use the MasterCard has a currency conversion process and agree that I will have no recourse against MasterCard concerning the currency conversion or its disclosure”

H.1.10.3 Visa disclaimer statement

The Visa disclaimer statement is as follows:

“I accept that I have been offered a choice of currencies for payment and that this choice is final. I accept the conversion rate and final amount and that the selected Transaction Currency is <currency symbol> <currency name>.”

Note 1: the words ‘and’ may be replaced with an ampersand (&) to reduce the number of printed characters.

Note 2: <currency symbol> shall be replaced with the currency symbol if one exists and the printer is able to reproduce it for example € for Euros or ¥ for Yen.

Note 3: <currency name> shall be replaced with the currency name for example US Dollars.

H.2 CHARACTERISTICS OF THE PRINTED TEXT

H.2.1 Character set

The character set used shall comprise the following:

a) alphabetic characters A to Z, upper and lower case. Note that characters from other alphabets e.g. Cyrillic, may be supported,

b) numeric characters 0 to 9,

c) currency symbols,

d) parentheses (square brackets, curly brackets, greater than and less than symbols),

e) hyphen, apostrophe, period (full stop), solidus (slash),

f) ampersand, asterisk, hash (or gate).




H.2.2 Legibility of print

For impact printers (using printer ribbons or encapsulated ink paper) and for multiple ply printing using carbon copies the minimum height of any alpha/numeric characters shall be 2.5mm and the number of characters per inch shall not exceed 15.

For thermal printers using single ply paper the minimum height of any alpha/numeric characters shall be 2.0mm and the number of characters per inch shall not exceed 23.

The colour of the printed characters and backgrounds shall enable legibility in normal ambient light conditions. All carbon copies (where applicable) shall be legible.

H.2.3 Security of print

The characters shall be printed by means that ensure that they do not fade or otherwise degrade during the required life span of the document (minimum 6 months). Carbonless multi-part sets may have a limited shelf life before use; this shall not be exceeded. It shall be borne in mind that the conditions encountered in mass storage systems for paper documents can encompass extremes of temperature and humidity.

H.3 RECEIPT CONTENTS

H.3.1 Mandatory requirements

The following items shall appear on all vouchers;

a) card acceptor/outlet number,

b) card acceptor name,

c) card acceptor address (may be town name only, but shall be comprehensible),

d) transaction type e.g. SALE/REFUND,

e) PAN (see Section H.1.4 Card Number [PAN]),

f) expiry date of card (MMYY) (swiped or keyed transactions) or application expiration date (IC transactions) (MMYY),

g) start date of card (swiped or keyed transactions) or application effective date (IC transactions), if present on card (MMYY),

h) card issue number (swiped or keyed transactions) or application PAN sequence number (IC transactions), if present on card,

i) card scheme name (see Note 1),

j) transaction data source ICC, SWIPE or KEYED,

k) date of transaction,

l) time of transaction,

m) terminal number (TID),




n) transaction number,

o) transaction response e.g. Authorisation code,

p) amount of transaction (including currency symbol),

q) cardholder interface details (see Note 2),

r) declaration (signature transactions only) e.g. Please debit (or credit, for refunds) my account (card acceptor copy only),

s) retention reminder (cardholder copy only),

t) application identifier (AID) (IC transactions only),

u) gratuity amount (where a gratuity is added to the original amount),

v) amount of cash (for purchase with cashback transaction).

Note 1: For a swiped or keyed transaction, the card scheme name shall be determined from the IIN of the card.

For an IC read transaction, the card scheme name shall be the Application Preferred Name from the IC. If the code table required for this name is not supported, then the Application Label shall be used instead

Note 2: The cardholder interface details printed are dependent on the cardholder verification method used.

For Signature CVM: Request for cardholder signature (card acceptor copy only) Space for cardholder signature (card acceptor copy only) “Signature verified” (cardholder copy only)

For PIN CVM: “PIN Verified” (both copies)

For No CVM: No verification statement (both copies)

For refunds, where signature is used, it may be the card acceptor who signs. In this case, the request for signature must take account of this

For the purpose of audit trails a record shall be made where the PAN is key entered to indicate that the cardholder was not present (e.g. telephone or mail order), and where not printed by the device 'TELEPHONE ORDER' or 'MAIL ORDER' written in the appropriate signature space.

Some card schemes require the card acceptor to sign refund vouchers and the wording of the declaration shall take account of this.

See H.4 for how a voucher could look.




H.3.2 Optional requirements

The following items are optional:

1. diagnostic message (not required on cardholder copy),

2. start date of card (not required on card acceptor copy),

3. VAT registration number,

4. receipt number (not transaction number),

5. goods amount (itemised billing),

6. goods description (itemised billing),

7. VAT rate,

8. hot card file version number,

9. terminal software version number.

The requirement for the optional items may vary between card schemes, and detailed guidance shall be sought from the acquirer.

It is important for security reasons to avoid printing excessive amounts of data from the magnetic stripe. The keyed entry of issue number/sequence number may be required for some card schemes but is dependent on the information being embossed on the card and the terminal's ability to accept entry.




H.4 EXAMPLE RECEIPTS Table 21 - Example Receipt Layout (Signature CVM) - Card Acceptor Copy

MANDATORY OPTIONAL

Merchant Name b) A RETAILER

Merchant Address c) ANY TOWN

VAT No: 123 4567 89 c) VAT Registration Number

Miscellaneous Goods £16.00 e) f) Goods Amount and Description

VAT Rate: 17.50% g) VAT Rate

Application Identifier t) AID: A1234567890123456

Card Scheme i) VISA CREDIT

Card Number

Sequence Number

e)

h)

Card: 492912345678

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

Transaction Number

o)

n)

Auth: 045678

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




Table 22 - Example Receipt Layout (Signature CVM) - Cardholder Copy

MANDATORY OPTIONAL








Card Number

Sequence Number

e)

h)

Card: ********5678

PAN Seq Nr: 02




Amount p) £16.00

Cardholder Interface Details q) SIGNATURE VERIFIED


Transaction Number

o)

n)

Auth: 045678

Ref: M1500398




ABCDEF0123456789 40 j) k) Cryptogram, Cryptogram Type


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




Table 23 - Example Receipt Layout (PIN CVM) - Card Acceptor Copy

MANDATORY OPTIONAL








Card Number

Sequence Number

e)

h)

Card: 492912345678

PAN Seq Nr: 02




Amount p) £17.00

Cardholder Interface Details q) PIN VERIFIED


Transaction Number

o)

n)

Auth: 243090

Ref: M1600499




1234567890ABCDEF 40 j) k) Cryptogram, Cryptogram Type






Table 24 - Example Receipt Layout (PIN CVM) - Cardholder Copy

MANDATORY OPTIONAL








Card Number

Sequence Number

e)

h)

Card: ********5678

PAN Seq Nr: 02




Amount p) £17.00

Cardholder Interface Details q) PIN VERIFIED


Transaction Number

o)

n)

Auth: 243090

Ref: M1600499




1234567890ABCDEF 40 j) k) Cryptogram, Cryptogram Type


Retention Reminder s) Please retain for your records

Thank You

b)

Courtesy Message





Table 25 - Example Receipt Layout (No CVM) - Card Acceptor Copy

MANDATORY OPTIONAL








Card Number

Sequence Number

e)

h)

Card: 492912345678

PAN Seq Nr: 02




Amount p) £19.00

Cardholder Interface Details q) NO CARDHOLDER VERIFICATION


Transaction Number

o)

n)

Auth: 000943

Ref: M5309002




12345ABCDEF67890 40 j) k) Cryptogram, Cryptogram Type






Table 26 - Example Receipt Layout (No CVM) - Cardholder Copy

MANDATORY OPTIONAL








Card Number

Sequence Number

e)

h)

Card: ********5678

PAN Seq Nr: 02




Amount p) £19.00

Cardholder Interface Details q) NO CARDHOLDER VERIFICATION


Transaction Number

o)

n)

Auth: 000943

Ref: M5309002




12345ABCDEF67890 40 j) k) Cryptogram, Cryptogram Type


Retention Reminder s) Please retain for your records

Thank You

b)

Courtesy Message





H.5 RECONCILIATION

Where the card acceptor and acquirer are using real-time processing with real-time transaction capture by the acquirer regular reconciliation transactions occur. The layout in Table 27 - Reconciliation data shall be printed.

Unconfirmed and not agreed reconciliation’s shall indicate this fact by their words being highlighted on the printout. Both the terminal totals and the acquirers totals shall be printed to aid query resolution.

Additional issuer datasets are a repeat of the acquirer's dataset with the exception of stored details and transaction numbers that are only applicable to acquirers.

Table 27 - Reconciliation data

Printed data Reconciliation

Narrative line 1 Reconciliation

Narrative line 2 Overall reconciliation status e.g. completed

Card acceptor name

Card acceptor address

Acquirer name Repeat as per configuration.

Time HHMM

Date DD/MM/YY

Reconciliation status e.g. Completed datasets

Terminal identity

Transaction number

Previous Debits Credits Net value

Previous session totals

(number & value see note 2)

Transactions from / to

Current Debits Credits Net value

Current session totals


Current session number


Stored Debits Credits Net value

Stored transactions


Total net value


Diagnostic message (see note 1)




H.5.1 X and Z balances

X and Z balances are provided to enable the card acceptor to balance the totals from a terminal with his internal systems and procedures.Table 28 - X and Z balances gives the details required on a balance voucher.

Table 28 - X and Z balances

Printed data X balance Z balance Diagnostic message (see note 1) (see note 1) Time HHMM HHMM Date DD/MM/YY DD/MM/YY Narrative line 1 X balances Z balances 2 Totals not reset Totals reset Card acceptor name YES YES Card acceptor address YES YES Terminal identity YES YES The Grand total Debits & Credits. All card transactions (see Note 2) All card transactions (see Note 2) Debits (see Note 2) (see Note 2) Credits (see Note 2) (see Note 2) Card issuer name The Grand total Debits & Credits. By card issuer (see Note 2) By card issuer (see Note 4) Debits (see Note 2) (see Note 2) Credits (see Note 2) (see Note 2) Transaction number from/to

H.5.2 Notes to printed data tables

The following notes apply to Table 27 - Reconciliation data, and Table 28 - X and Z balances

Note 1: Provision shall be made to print a diagnostic code (see Table 31 — Diagnostic codes) to aid users in identifying the nature of difficulties. Also the session number shall be printed on change of session as indicated in the response message.

Note 2: Printed numeric digits with a decimal point separating the currency unit and the lowest denomination of the transaction currency, where leading zeros are suppressed and the appropriate transaction currency symbol is printed next to the most significant digit.


APPENDIX I: USE OF SERVICE CODES 1 June 2007


I. USE OF SERVICE CODES

The following procedures describe the interpretations and actions a POS system shall take for magnetic stripe transactions for those card schemes that use service code definitions as described in ISO 7813.

The service code is the three numeric digits immediately after the expiry date in track 2.

I.1 POS PROCEDURES

The POS system shall validate and act upon each digit of the service code individually:

a) read service code,

b) evaluate digit 1,

c) evaluate digit 2,

d) evaluate digit 3,

e) process transaction based on results.

I.2 SERVICE CODE VALUES

The meaning attributed to the value of each digit of the service code is given in Table 27 – Service code values. The following conditions apply:

a) in the event of a communications failure where the service code value indicates real-time, the transaction shall go real-time to the acquirer or shall be rejected,

b) if a non-numeric service code is encountered the transaction shall be reject,

c) if card schemes issue cards that are outside the ISO standards, then service code checking shall not be undertaken for that card,

d) service code checking cannot be undertaken where the card details are key entered or for forced transactions. In these cases accept,

e) the processing order of priority is:

1. reject - overrides real-time authorisation,

2. real-time authorisation – overrides accept,

e.g. a service code of 123 shall result in a rejection, even though the value in digit 1 is 'ACCEPT' and the value in digit 2 is 'Real-time Authorisation' because the value in digit 3 indicates it is an ATM only card.


APPENDIX I: USE OF SERVICE CODES 1 June 2007


Table 29 — Service code values

Interchange Technology Digit 1 Digit 2 Digit 3 Comments Unspecified 0 Real-time authorisation required International Card 1 Accept International card - alternative technology (integrated circuit card)

2 If no IC verification available at the POS, revert to magnetic stripe

Unspecified 3 Real-time authorisation required Unspecified 4 Real-time authorisation required National use only 5 Real-time authorisation required National use only - alternative technology (integrated circuit card)

6 Real-time authorisation required

Private card 7 Real-time authorisation required Unspecified 8 Real-time authorisation required Test Card 9 Real-time authorisation required Authorisation processing Digit 1 Digit 2 Digit 3 Comments Normal Authorisation 0 Accept Unspecified 1 Real-time authorisation required Real-time authorisation mandatory 2 Real-time authorisation required (see

Note 1) Unspecified 3 Real-time authorisation required Positive (real-time/telephone) authorisation procedures, unless national or regional agreements apply

4 Real-time authorisation required (see Note 1)

Unspecified 5 Real-time authorisation required Unspecified 6 Real-time authorisation required Unspecified 7 Real-time authorisation required Unspecified 8 Real-time authorisation required Unspecified 9 Real-time authorisation required Range of service/ONLINE MSR PIN requirements

Digit 1 Digit 2 Digit 3 Comments

ONLINE MSR PIN required 0 Reject if no ONLINE MSR PIN verification available

Normal cardholder verification, no restrictions

1 Accept

Normal cardholder verification - goods & services at the POS

2 Reject if purchase with cashback requested, otherwise accept

ATM only 3 Reject Cash only 4 Accept only if cash advance requested ONLINE MSR PIN required - goods & services only at the POS

5 Reject if no ONLINE MSR PIN verification available. Reject if purchase with cashback

Prompt for ONLINE MSR PIN if ONLINE MSR PINPAD present

6 Prompt for ONLINE MSR PIN if ONLINE MSR PIN verification available. Accept.

Prompt for ONLINE MSR PIN if ONLINE MSR PINPAD present - goods & services only at the POS

7 Prompt for ONLINE MSR PIN if ONLINE MSR PIN verification available. Reject if purchase with cashback requested, otherwise accept.

Unspecified 8 Real-time authorisation required Unspecified 9 Real-time authorisation required

Note 1: A terminal cannot distinguish between values 2 & 4


APPENDIX J: AUTHORISATION CODE ALGORITHM 1 June 2007


J. AUTHORISATION CODE ALGORITHM

Where a terminal authorises a transaction because the amount is less than the floor limit, an authorisation code shall be generated as follows:

a) take the sequential message number which would be assigned to the message and add the lower order 4 digits of the amount,

b) the resultant 4-digit number (ignore overflows) shall be used to generate a modulus 10 check digit according to the LUHN formula (see G) to form a 5-digit authorisation code.

J.1 EXAMPLE AUTHORISATION CODE

Message number 6821

Amount (in pence) 4763

Message number and amount (1) 1584

Modulus 10 check digit 2

Authorisation code 15842

For American Express the first 3 digits are ignored and only the last two are displayed in the form AUTH CODE: nn followed by three blanks.


APPENDIX J: AUTHORISATION CODE ALGORITHM 1 June 2007



APPENDIX K: REFERRAL TELEPHONE NUMBER PROCESSING 1 June 2007


K. REFERRAL TELEPHONE NUMBER PROCESSING

The down-line loaded telephone number is an optional data element in the acquirer's response message. The data element and any accompanying text messages shall be used in conjunction with the structured voice referral telephone number held in the terminal. A number of combinations of downloaded data and stored data are defined in Table 30 — Referral telephone number processing and the appropriate terminal process specified.

Table 30 — Referral telephone number processing

No. Voice referral telephone number contents

Downloaded telephone number contents

Terminal response

1 Any Not Present Display text message (if any) in response message. Disconnect from line.

2 Any US US Hold line open for voice communications. (PSTN mode). Display 'LIFT RECEIVER'. Signal audio alarm. Display text message when the telephone handset is raised. Reset terminal after 20 seconds if telephone handset not lifted.

3 A B C US Set on-hook condition; time 3 seconds, set off-hook condition. Dial A B C with appropriate pauses; continue as 2.

4 B C US As 3 but dial B C with appropriate pauses.

5 A B C A B A

b c As 3 but dial A b c

6 B C B

b c As 3 but dial b c with appropriate pauses.

7 A B C A B

US c As 3 but dial A B c

8 B C US As 3 but dial B with appropriate pause.

9 A C US As 3 but dial A C

10 A C b c As 3 but dial A b c

11 A C US c As 3 but dial A c

12 C US As 3 but dial C

13 C b c As 3 but dial b c

14 C US c As 3 but dial c

15 Not set (no numeric value entered) US c As 3 but dial c

16 Not set (no numeric value entered) b c As 3 but dial b c

17 A US c As 3 but dial A c

18 Remaining combinations Set on-hook condition display 'CALL CARD ISSUER'.


APPENDIX K: REFERRAL TELEPHONE NUMBER PROCESSING 1 June 2007



APPENDIX L: DIAGNOSTIC CODES 1 June 2007


L. DIAGNOSTIC CODES

Table 31 — Diagnostic codes list of diagnostic codes that cover the most important reasons for faults or particular operations. This does not preclude manufacturers using additional diagnostic codes if required.

Table 31 — Diagnostic codes

Code Reason Environment

19 Transaction failed due to power failure Auth. Financial presentment

20 Modem carrier failed before end of transmission Auth. Financial presentment

21 No modem tone detected after dialling, e.g. call routed to incorrect number

Auth. Financial presentment

30 Transaction failed after re-dialling Auth. Financial presentment

31 Line busy, e.g. other user on the same line Auth. Financial presentment

35 Confirmation message requested but could not be sent Auth. Financial presentment

40 Modem tone detected but no response from PAD Auth. Financial presentment

41 PAD advised it was not able to contact card company, i.e. EOT received in response to NUA


42 No response received from card company, i.e. Timer 'C' has expired


43 Insufficient or invalid data to compile a voice referral number or no phone present


44 Terminal has received an EOT, i.e. remote close down by card company or PAD after CONNECTION MADE.

If a security error has occurred this code is followed by the non zero response code of the hold message

Auth.

--

Financial presentment

Financial presentment

45 Message cannot be sent, e.g. too many errors real-time Auth. Financial presentment

46 Terminal has received an invalid message type Auth. Financial presentment

47 Terminal has received an invalid message header or confirmation request


48 Terminal has sent a not-confirm message (Down-line loading 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 transaction was performed

-- Financial presentment

53 Post-event store full --

70 Security error. Terminal has detected an invalid MAC on a received message

-- Financial presentment

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


APPENDIX L: DIAGNOSTIC CODES 1 June 2007


Standard 70 Book 1 - 1 June 2007

Documents

Transcript of Standard 70 Book 1 - 1 June 2007