Standard 70 Book 1 - 1 June 2007 4u2qe

[email protected]

£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 d maximum of £XXvalue – the PIN entry signifying that a sum up to that £XXvalue is agreed as the maximum sum to be debited,

3.

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

4.

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

b)

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

c)

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

6.10.2.5

Transaction vouchers

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

Card retention

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

remains mandatory for Magnetic Stripe only unattended devices,

b)

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

APACS © APACS (istration) Ltd

STANDARD 70 Book 1

PAGE: 57

PART 6: BUSINESS RULES 6.10.3

1 June 2007

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 preauthorisation 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 ed, 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).


STANDARD 70 Book 1

PAGE: 58

PART 6: BUSINESS RULES 6.10.4.1

1 June 2007

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


STANDARD 70 Book 1

PAGE: 59

PART 6: BUSINESS RULES

1 June 2007

Check-in

Full EMV transaction for Estimate Amount * Card details, TC and ing data stored for later use. Auth Code 1 Saved.

Incremental Authorisation

Using stored card details. Auth Code 2 Saved


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 ing 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


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


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


STANDARD 70 Book 1

PAGE: 60


1 June 2007

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

Full EMV transaction for Final Amount st PoS request ARQC for final amount on 1 Generate AC

nd

PoS request AAC on 2

Cardholder Checked-out

Generate AC

Submit transaction Post Event using Final Amount, Auth Code n and ARQC and ing 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 s: a)

At the table using a portable terminal,

b)

At the cash (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 ing gratuity value processing:


STANDARD 70 Book 1

PAGE: 61


1 June 2007

a)

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

b)

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

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

Terminal Displays Amount £XXX.XX Add Gratuity? Yes = Enter No = Clear

Cardholder pressed Enter

Optionally the terminal may prompt for the gratuity amount to be entered

Yes

Terminal Displays Enter New Total Amount £XXX.XX then press Enter

No

Terminal Displays Amount £XXX.XX Add Gratuity? Enter PIN

Complete transaction for original amount

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

Cardholder pressed Enter

Yes Terminal Displays Amount £XXX.XX

Complete transaction for new amount

Figure 11 - Gratuity transaction flow


No

STANDARD 70 Book 1

PAGE: 62


1 June 2007

6.10.4.2.6 Magnetic stripe and key entry gratuity transaction processing If the authorisation is obtained before the addition of any gratuity then specific card scheme rules apply to any subsequent processing. In this case acquirer capture and submission of transactions is not possible (as the transaction protocol does not allow for transactions to be amended after they have been authorised and captured by the acquirer) so the capture and submission of transactions shall be as defined in Standard 70 Book 3 or Standard 60. Authorisation rules governing the addition of the gratuity are set by each card scheme. The general authorisation requirement involves a percentage (X) set by the scheme. If the amount of the transaction, before the gratuity is added: a)

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

b)

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

c)

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

Note: The card acceptor shall, where possible, indicate both authorisation numbers and amounts on the sales voucher. The terminal shall allow a configurable voucher message to be printed, such as 'service' or 'gratuity', to allow the cardholder to add a gratuity when the voucher is signed. The addition of a gratuity breaks the transaction into two parts. The terminal shall therefore allow transactions to be recalled in order that the gratuity may be added. Restaurants operate in different environments, such as single or multi-waiter, and payment at the table or at a central checkout. In order to meet these requirements the terminal shall assign a unique reference to each transaction to allow any transaction to be recalled at any time. The terminal shall allow for the gratuity to be deleted and re-entered if a mistake is made. End of day reconciliation shall not be allowed if any transactions are left in an incomplete state. All transactions shall be recalled and completed even if no gratuity has been added. End of day reporting shall show a breakdown of the day's business of base meal amount and gratuities by card scheme. Optionally, the terminal may provide a full audit trail of each gratuity, identifying individual waiters, dependent on the waiter I.D.


STANDARD 70 Book 1

PAGE: 63


1 June 2007

6.10.4.2.7 Bar tab process To combat the practice of retaining cardholder’s cards ‘behind the bar’ (where they are vulnerable to skimming or theft) the following process is described as a means of performing transactions where the final amount may not be known. The authorisation performed at the beginning of the transaction must be for an amount agreed between the card acceptor and the cardholder. If the cardholder’s spending reaches the agreed amount then the transaction must be completed and a new transaction started if the cardholder wishes to continue spending. Care must be taken to ensure the date used in the settlement transaction is the same as the date used in creating the cryptographic data. Particularly in the hospitality environment the closing of the bar tab may occur after midnight and therefore be on a different day to when it was opened. Open Tab

Full EMV Authorisation transaction for Agreed Amount * Card details, TC and ing data stored for later use. Auth Code 1 saved.

Closing Tab

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

nd

PoS request AAC for final amount on 2 complete the transaction off-line)

Tab Closed

Generate AC (to

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

Figure 12 - Closing bar tab cardholder


STANDARD 70 Book 1

PAGE: 64


1 June 2007

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

Full EMV transaction for Agreed Amount * Card details, TC and ing data stored for later use. Auth Code 1saved.

Closing Tab

Submit transaction using Final Amount, stored card details, Auth Code 1 and TC and ing 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 ed 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,


STANDARD 70 Book 1

PAGE: 65

PART 6: BUSINESS RULES d)

e)

1 June 2007

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,

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


STANDARD 70 Book 1

PAGE: 66


1 June 2007


STANDARD 70 Book 1

PAGE: 67

PART 7: CARD ACCEPTOR FACILITIES

1 June 2007

7

CARD ACCEPTOR FACILITIES

7.1

General

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

X and Z balances

In order to assist card acceptors in periodic and end of day reconciliation with their EPOS systems, terminals may 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 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 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).


STANDARD 70 Book 1

PAGE: 68


1 June 2007

Timing of these processes is important if the amounts appearing on the card acceptor's bank statement are to be reconciled with those appearing on the terminal, but they can be done as often as the card acceptor requires. Totals are printed in the order determined by the terminals configuration data. 7.2.1

Sessions

When an acquirer captures transactions for a card acceptor it is necessary, at some point in a business day, to collect the captured transactions together and forward them for settlement. This activity is usually undertaken once a day, often late in the evening. In order for terminals to understand which transactions have been collected and which are still awaiting collection, a control mechanism is required. This mechanism is the session number. This relates to the business done within the acquirers' business day (or session) and is used to show the card acceptor on the reconciliation printout which transactions have been credited and which will not be credited to his 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


STANDARD 70 Book 1

PAGE: 69


1 June 2007

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

Post-event versus real-time reconciliation

Once the decision (for selective or complete reconciliation) has been made by the card acceptor, the terminal decides whether it needs to the acquirer and perform a realtime reconciliation or whether the totals can be reconciled locally and then repeated as a post-event repeat the next time the terminal s 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.


STANDARD 70 Book 1

PAGE: 70


1 June 2007

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

Examples of session and reconciliation totals

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

ACQUIRER ACQUIRER

SESSION 1

CARD ACCEPTOR

2

A

B

3

C

Rec 1

D

E

Rec 2

4

F

G

Rec 3

Rec 4

H

5

I 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


STANDARD 70 Book 1

PAGE: 71


1 June 2007

when a reconciliation transaction or acquirer delete occurs. (Message numbers are an acquirer function unaffected by deleting and initialising card issuer datasets). In b) and c) two arrangements of the prints are considered: a)

card issuer and acquirer totals printed together,

b)

totals printed separately.

Table 4 — Example reconciliation gives details where the totals represent simplified sections of the printed slips. The stored transactions are repeated real-time. The totals 'PREVIOUS', 'CURRENT' and 'STORED' are represented by the symbols P, C and S respectively with the suffixes 'a' and 'c' referring to acquirer and card issuer respectively. The following applies: a)

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

b)

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

c)

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

d)

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

e)

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

f)

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

g)

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

7.2.3

Balancing card issuer datasets

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


STANDARD 70 Book 1

PAGE: 72


1 June 2007

Table 4 — Example reconciliation slips 1. Totals Together Normal Reconciliation slips ACQUIRER PREVIOUS TOTAL XXXX-YYYY-1 CURRENT 0 TOTAL YYYY-ZZZZ

2. Totals Separate

Pa+Pc Ca+Cc+Sa+Sc

ACQUIRER PREVIOUS TOTAL XXXX-YYYY-1 CURRENT 0 TOTAL YYYY-ZZZZ CARD ISSUER PREVIOUS CURRENT 0

Pa Ca+Sa

Pc Cc+Sc

Delete C.I. dataset DELETE CARD ISSUER PREVIOUS CURRENT STORED RECONCILIATION ACQUIRER PREVIOUS TOTAL XXXX-YYYY-1 CURRENT 0 TOTAL YYYY-ZZZZ

As 'Together' Pc Cc Sc As 'Together' Pa Ca+Sa

Reset Acquirer RESET ACQUIRER PREVIOUS TOTAL XXXX-YYYY-1 CURRENT TOTAL YYYY-ZZZZ STORED RECONCILIATION ACQUIRER PREVIOUS TOTAL 0000-0000 CURRENT 0 TOTAL 0001-0001 (No extra business for sake of example)

Pa

As 'Together'

Ca Sa+Sc

Pc Cc

RECONCILIATION ACQUIRER PREVIOUS TOTAL 0000-0000 CURRENT 0 TOTAL 0001-0001 CARD ISSUER PREVIOUS CURRENT 0


0

Pc Cc

STANDARD 70 Book 1

PAGE: 73

APPENDIX A: MINIMUM TERMINAL HARDWARE REQUIREMENTS A.

MINIMUM TERMINAL HARDWARE REQUIREMENTS

A.1

EPOS SYSTEMS AND POST-EVENT TERMINALS

1 June 2007

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,

c)

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,

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 of a card to enter a PIN for the purposes of ing the of the card,

g)

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,

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.


STANDARD 70 Book 1

PAGE: 74

APPENDIX A: MINIMUM TERMINAL HARDWARE REQUIREMENTS h)

1 June 2007

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 byed,

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.


STANDARD 70 Book 1

PAGE: 75

APPENDIX A: MINIMUM TERMINAL HARDWARE REQUIREMENTS

1 June 2007

Where a telephone is connected (and the terminal is used dial) to prevent unauthorised use of the telephone for outgoing calls it shall be possible to bar calls (by configuration option), whilst still allowing the use of dialling facilities for transactions, voice referrals and specific numbers as specified by the telecommunications provider e.g. 999. In addition any stored number entered prior to setting of the call barring facility shall be able to be dialled. A.2.4

Data communications capability

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

Additional keys

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

Function keys

Sale

Reconciliation

Numeric keys 0 to 9

X balances

Refund

Z balances

Reversal

Duplicate

Cash Advance

Paper-feed

Cheque Guarantee

Enter

Authorisation only

Clear

Force

Delete Cancel Programme Alpha Alternative Identification

Note: The above keys may be replaced by display prompts selected by such as a 'enter' key. At the discretion of the manufacturer terminals may provide other functions that are not required in the handling of a transaction.


STANDARD 70 Book 1

PAGE: 76

APPENDIX A: MINIMUM TERMINAL HARDWARE REQUIREMENTS A.2.6

1 June 2007

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 'semipermanent' 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 ed remain operational.


STANDARD 70 Book 1

PAGE: 77

APPENDIX A: MINIMUM TERMINAL HARDWARE REQUIREMENTS A.2.11

1 June 2007

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.


STANDARD 70 Book 1

PAGE: 78

APPENDIX A: MINIMUM TERMINAL HARDWARE REQUIREMENTS


1 June 2007

STANDARD 70 Book 1

PAGE: 79

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS B.

MINIMUM SOFTWARE REQUIREMENTS

B.1

GENERAL

1 June 2007

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


STANDARD 70 Book 1

PAGE: 80

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS B.1.3

1 June 2007

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 multiple card schemes, may one complex card scheme or may multiple card schemes and card products. Simple Acquirer/ Issuer

Merchant

Acquirer

Multiple Card Schemes

Complex Card Schemes

Acquirer

Multiple Card Schemes & Products

Acquirer

Issuer

Acquirer

Issuer

Issuer

Issuer

Issuer

Issuer

Issuer

Issuer

Issuer

Issuer Issuer

Issuer

Issuer

Issuer

Figure 15 - Dataset relationships B.1.3.1

Simple acquirer/issuer

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

Acquirer / Issuer American Express

Merchant

Figure 16 - Simple acquirer/issuer


STANDARD 70 Book 1

PAGE: 81

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS B.1.3.2

1 June 2007

Multiple simple card schemes

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

M e rc h a n t

A c q u ir e r

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

Is s u e r JC B

Figure 17 - Multiple simple card schemes B.1.3.3

Complex card scheme

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

M e rc h a n t

A c q u ir e r

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





Figure 18 - Complex card scheme


STANDARD 70 Book 1

PAGE: 82


1 June 2007

Multiple card schemes and products

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

Merchant

Issuer JCB

Issuer MasterCard

Acquirer

Issuer Visa Delta Range 1

Issuer Visa

Issuer Switch Range 1

Issuer Switch Solo Range 1

Issuer Range 2

Issuer Range 3

Issuer Range 2

Issuer Range 3

Issuer Range 2

Issuer Range 3

Issuer Range 4

Issuer Range 5

Issuer Range 4

Issuer Range 5

Issuer Range 4

Issuer Range 5

Figure 19 - Multiple card schemes and products B.1.4

Dataset interaction

As facilities and functions can be configured at both acquirer and issuer level, rules have to be established for the interaction between these datasets. In a complex configuration like that shown in Figure 19 - Multiple card schemes and products acquirer may wish to 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

N

N

N

N

Y

N

Y

N

N

Y

Y

Y

LOGOR (Logical Or)

ACQ (Acquirer Override)

ISSUER (Issuer Override)

Use acquirer dataset value and ignore issuer. Use issuer dataset value and ignore acquirer


STANDARD 70 Book 1

PAGE: 83


1 June 2007

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

B.1.6

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

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


STANDARD 70 Book 1

PAGE: 84

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS

1 June 2007

to be entered only one keystroke is required to cancel the entire input. Similarly, if there is no data entered only one keystroke is required to cancel the transaction. Alternatively a clear key may also be provided that shall clear the transaction at a single stroke. B.1.8

Communications via multiple systems

The assumption is that a terminal is communicating directly with an acquirer over a communications network. However it is possible that messages are routed via intermediate systems or third party processor. In this situation the message shall be ed 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 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.


STANDARD 70 Book 1

PAGE: 85


1 June 2007

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 s integrated voice facilities then it shall 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 s integrated voice facilities, it shall the ability to bar certain call types. Calls barred that shall be ed 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).


STANDARD 70 Book 1

PAGE: 86

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS B.3

ACQUIRER DATASET

B.3.1

General

1 June 2007

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 , 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 s IC cards then the application identity (AIDs) of each of the card applications ed shall be stored. B.3.4

Card scheme public keys

If the terminal s 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 (ed 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 the correct value and installation of a scheme public key.

B.3.5

Data telephone numbers

Where the terminal s 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.


STANDARD 70 Book 1

PAGE: 87


1 June 2007

If all three attempts fail then communications shall be deemed to have failed. For each of the data telephone numbers configured the terminal shall allow for dial-up communications with: a)

PSTN access port to acquirer,

b)

PSS PAD port access,

c)

proprietary PAD access,

d)

BT Special PAD.

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

Data network 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 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:


STANDARD 70 Book 1

PAGE: 88

APPENDIX B: MINIMUM SOFTWARE REQUIREMENTS a)

A = PABX to exchange line access digit,

b)

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

c)

C = Destination telephone number.

1 June 2007

Table 8 — Voice referral telephone number Contents

Input sequence

ABC

(Num sequence) (FD) (Num sequence) (FD) (Num sequence)

AB

(Num sequence) (FD) (Num sequence) (FD)

AC

(Num sequence) (FD) (FD) (Num sequence)

A

(Num sequence) (FD) (FD)

B

(FD) (Num sequence) (FD)

BC

(FD) (Num sequence) (FD) (Num sequence)

C

(FD) (FD) (Num sequence)

Empty

NOT SET (Not set means no numeric value entered)

If the terminal does not 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 a minimum of one floor limit per acquirer ('pre-comms' limit) but preferably two ('pre-comms' and 'post-comms' limits).


STANDARD 70 Book 1

PAGE: 89


1 June 2007

Down-line loaded terminal floor limit

Some acquirers provide an updated floor limit in the response message. Where a terminal s 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 s 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 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 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 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 realtime authorisation. The default shall be no cash floor limit. B.3.9.6

Cash-ceiling limit

The terminal shall 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 cashceiling limit.


STANDARD 70 Book 1

PAGE: 90


1 June 2007

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.


STANDARD 70 Book 1

PAGE: 91


1 June 2007

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


STANDARD 70 Book 1

PAGE: 92


1 June 2007

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 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 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 s 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).


STANDARD 70 Book 1

PAGE: 93


1 June 2007

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 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 s 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 the following transaction types individually and in any combination: a)

sale,

b)

refund.


STANDARD 70 Book 1

PAGE: 94


1 June 2007

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

Floor limit operative (LOGAND)

Indicates if the use of floor limits is allowed. B.5.15

Force enabled (LOGAND)

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

Gratuities (LOGAND)

This parameter enables or disables the ability to 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.


STANDARD 70 Book 1

PAGE: 95


1 June 2007

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)

No prompt shall be displayed

Empty/un-initialised

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


STANDARD 70 Book 1

PAGE: 96


1 June 2007

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 ed 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 ed 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 ed 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 C.

TRANSACTION TIMES

C.1

REQUIREMENT

1 June 2007

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?).


STANDARD 70 Book 1

PAGE: 98

APPENDIX C: TRANSACTION TIMES

! June 2007

Where testing is carried out in live environments, it is also recommended that any transactions in which exception conditions were met (including cardholder pressing CLEAR or CANCEL) be recorded separately. C.3

TRANSACTION TIME COMPONENTS

Thus defined, the transaction time includes: a)

card power-up and ATR,

b)

application selection and fetch data (Get Processing Options),

c)

card and terminal risk management,

d)

PIN entry,

e)

first cryptogram generation,

f)

on-line authorisation (where necessary),

g)

second cryptogram generation (where necessary),

h)

card issuer script processing (where applicable),

i)

completion processing (in this context includes the printing of the voucher and powering down the card).

The card speed, terminal speed or both affect most elements of the transaction time. The PIN entry is primarily a function of the cardholder, and it is expected that most cardholders will become faster at PIN entry as they become used to the process. Each individual cardholder may, however, be slower for the first one or two transactions, as the process is explained to them. For benchmarking purposes, an experienced cardholder should be assumed, i.e. there are no unnecessary delays or hesitations during PIN entry. The real-time authorisation time is dependent on external networks, acquirer system loadings etc, as well as the level of authorisations undertaken. It is recommended that these be measured separately where practical, so that the effect of these factors can be understood. Other factors such as printer speeds and the use of hot-card lists will cause transaction times to vary among card acceptors, and local environmental factors will always come into play, so that absolute figures are likely to be meaningless. It is also possible for some combinations of card and terminal to be unusually fast or slow (Card A may be faster than Card B in terminal X, but slower in terminal Y). However, some benchmark times will be valuable, and this annex proposes some benchmark processes, with the aim of obtaining comparable figures at card acceptor level.


STANDARD 70 Book 1

PAGE: 99


! June 2007

C.4

OPTIMISING TRANSACTION TIMES

C.4.1

Cards

It is found that different cards produce radically different transaction times. Many of the UKIS cards used from 1997 to 2001 had very small RAM memory sizes, slow communications paths, and whilst built to be EMV compliant were not optimised for speed. Most currentgeneration 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 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 ed (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.


STANDARD 70 Book 1

PAGE: 100


! June 2007

Table 11 — Proposed card file read order Read only

Data element

1

Track 2 equivalent data

Required for

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


11

PAN

Terminal risk management

12

PAN sequence number

Real-time authorisation

13

IAC default

Terminal action analysis

14

IAC denial


15

IAC on-line


16

Application usage control


17

Issuer country code


18

CDOL 1


19

CDOL 2


20

Application version number


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


STANDARD 70 Book 1

PAGE: 101


! June 2007

C.4.2

Terminals and EPOS systems

The EPOS system, terminal and communications network also plays a major part in ensuring a fast transaction time. Hardware and software vendors, card acceptors and acquirers are advised to consider the following points in order to optimise transaction times: a)

hardware characteristics: some EMV Level 1 IFDs are known to be slow, and this is probably a function of any micro-controller, communications devices and buffer sizes. 8-bit micro-controllers are to be avoided, and 32-bit devices offer best performance.

b)

technical architecture: it is impossible to be prescriptive about specific cases. Many card acceptors will be constrained by existing equipment, by in-store network architectures, etc. In some cases, the need for flexibility and future proofing may dictate a sub-optimal timing solution, and this is the card acceptors decision. In general, the fastest transaction times will be obtained by: 1.

minimising the number of communications interfaces, particularly those requiring buffering of card messages (APDUs),

2.

ensuring that any cryptographic processes are carried out in the fastest available hardware,

3.

ensuring that as many activities as possible take place in parallel (through multi-processing or the use of multiple processors). It is particularly important that card communications and terminal processing should take place in parallel.

c)

communications speeds: for best performance, all terminals should the highest speeds allowed by EMV 4 (i.e. 38,400 bps) for communication with the card (terminals should 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: 102


! June 2007


STANDARD 70 Book 1

PAGE: 103

APPENDIX D: DISPLAYABLE MESSAGES D.

1 June 2007

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 ed with a multiplicity of terminal and computer systems. Table 12 — Specific messages lists the messages that a terminal shall 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.


STANDARD 70 Book 1

PAGE: 104

APPENDIX D: DISPLAYABLE MESSAGES

1 June 2007

Table 12 — Specific messages Message text

Usage

AUTH CODE: nnnnn

Used to display the contents of the Authorisation code data element or, where a transaction is approved by the terminal, the calculated code as defined in Appendix J

CALL AUTH CENTRE

Used whenever a transaction has begun but a connection cannot be established with the relevant acquirer. This may be because the transaction fails internal validations or that it is not possible to establish a communications link or the link fails at any stage up to the time a response message is received from the acquirer. This message shall also be displayed where the acquirer has requested a voice referral but a handset facility is not available

CALL CARD ISSUER

Used whenever a card issuer is the only organisation that can assist the cardholder

CALL HELP DESK

Used when it is a terminal problem that needs specialist assistance to resolve.

CARD NOT AUTHORISED

Transaction not approved (see DECLINED)

CASHBACK

Used to prompt cashier or cardholder to request cashback

CHECK SIGNATURE

Used to prompt for visual verification of the signature when a cheque guarantee authorisation has been requested

COMPLETED

Used on the PINPAD display to indicate that the transaction has finished. This message shall be displayed when the contents of the PINPAD data data element is displayed on the terminal

CONNECTION MADE

Used when the terminal receives the ENQ message. If the data entry phase has still not been completed at this stage, the terminal shall wait until data entry has been completed before continuing with the transmitted sequence. CONNECTION MADE shall not be displayed until data entry has been completed but the card issuer or acquirer name shall be omitted if the CONNECTION MADE stage has been reached

DECLINED

Printed/displayed on completion of a voice referral where the acquirer/issuer/ card has declined the transaction and the card acceptor has indicated this to the terminal

DECLINED BY CARD – CARDHOLDER SHOULD 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


STANDARD 70 Book 1

PAGE: 105


1 June 2007

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

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 ed 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


STANDARD 70 Book 1

PAGE: 106


1 June 2007

Message text

Usage

SESSION TOTALS

Used during a reconciliation to advise the card acceptor of the status of the reconciliation transaction

NOT AGREED UNCONFIRMED CANNOT CONFIRM SORRY FOR DELAY

Used after any failed call attempt. It shall be displayed until connection is made or all call attempts fail when either CONNECTION MADE or CALL AUTH CENTRE shall be displayed

STORE FULL

Used to advise the card acceptor that the post-event store of transactions is full and the terminal needs to call the relevant acquirer.

SUPERVISOR CARD

Used to prompt the swiping or insertion of the supervisor card in order that certain functions can proceed

SWIPE AGAIN

Used to indicate that the magnetic stripe has not been read successfully

SWIPE CARD

Used at the point in the procedure where card input is required for a magnetic stripe card

TRANSACTION COMPLETE

Signifies that transaction has been completed

TRANSACTION VOID

Used if the transaction is cancelled at the terminal prior to completion of a voice referral

UNABLE TO AUTHORISE

Used if the transaction is cancelled by the IC card after real-time authorisation.

UNABLE TO GO ONLINE, 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


STANDARD 70 Book 1

PAGE: 107


1 June 2007

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



1 June 2007

STANDARD 70 Book 1

PAGE: 109

APPENDIX E: TERMINAL FALLBACK PROCEDURES E.

1 June 2007

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.


STANDARD 70 Book 1

PAGE: 110

APPENDIX E: TERMINAL FALLBACK PROCEDURE ICC

1 June 2007 MSR

Check Service Code Read Failure?

Yes

2 or 6?

Set "last read failure" indicator

No

Yes

Prom pt ICC Reader

No

Reset last read failure

Continue with MSR

"Last Read Failure" set?

Prom pt for MSR STOP No Prom pt Op. for Override, Y/N

STOP

Optional

Override option taken

Yes Reset last read failure

Continue with ICC Continue on MSR following conditions detailed below

Figure 20 - Processing flow for IC read failures


No

Reset last read failure

Reject

STANDARD 70 Book 1

PAGE: 111

APPENDIX F: CARD SCHEME IDENTIFICATION F.

CARD SCHEME IDENTIFICATION

F.1

INTRODUCTION

1 June 2007

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 shall be the card acceptor’s acquirer(s). This document s financial payment cards. It is not intended to 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.


STANDARD 70 Book 1

PAGE: 112

APPENDIX F: CARD SCHEME IDENTIFICATION F.3

1 June 2007

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 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. the acquirer for a suggested expiry date checking algorithm.

Issue Number:

The location of the issue number, when available in Track 2, varies. 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. the acquirer for a suggested checking algorithm and for Track 2 layouts.

Card Security Code:

See Standard 70 Part 2 and the acquirer for more information on the Card Security Code processes.

Address Verification:

See Standard 70 Part 2 and the acquirer for more information on the Address Verification processes.


STANDARD 70 Book 1

PAGE: 113

APPENDIX F: CARD SCHEME IDENTIFICATION F.4.2

1 June 2007

Glossary

Yes

Check must be performed

No

Check must not be performed – data may not be present, is not reliable or is not ed 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.

ed

The device can expect to provide this functionality for this scheme.

Not ed

The scheme does not currently this functionality.


STANDARD 70 Book 1

PAGE: 114

APPENDIX F: CARD SCHEME IDENTIFICATION

1 June 2007

Table 14 – Visa IIN ranges Visa UK Visa Debit Card

UK Visa Electron

Standards

ISO

7810-3

7810-3

Scheme Identification

IIN ranges:

413733-37

450875

446200-99

484406-08

453978-79

484411-55

454313

491730-59

454432-35

491880

V-PAY

Visa 7810-3

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.

454742 456725-45 465830-79 465901-50 484409-10 490960-79 492181-82 498824 Validation

Service Codes:

Yes

Yes

Yes

Yes

PAN length:

16-19

16-19

16-19

16-19

LUHN check:

Yes

Yes

Yes

Yes

Expiry date:

Yes

Yes

Yes

Yes

Issue number:

No

No

No

No

Validity period:

No

No

No

No

Card security 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

ed

ed

Not ed

ed

Keyed Card Not Present

ed

ed

Not ed

ed

Keyed Swipe Failure

ed

ed

Not ed

ed

Cardholder Keyed to Internet

ed

ed

Not ed

ed

EMV Chip

ed

ed

ed with PIN verification

ed

3D Secure

ed

ed

ed

ed

Internet Cardholder Verification


STANDARD 70 Book 1

PAGE: 115


1 June 2007

The following table provides known UK Visa ATM BIN ranges. Please bear in mind that this is not a full range and that your terminal/equipment should be reading the application usage control and service code. Table 15 – Visa exceptions Exceptions (Known UK Visa ATM only Cards) 490300-1

491100-02

490310-34

491103-73

490340-99

491183-99

490400-09

492183

490419

492800-99

490451 490459 490467 490475-78 490500-99 491001


STANDARD 70 Book 1

PAGE: 116


1 June 2007

Table 16 - MasterCard IIN ranges MasterCard & Maestro MasterCard

UK Maestro

Maestro International

7810-3

7810-3

Standards

ISO

7810-3


IIN ranges: Note 1

510000559999

500000-509999 675900-99

560000-589999 600000-699999

Validation

Service Codes:

Yes

Yes

No

PAN length:

16

16, 18 or 19

Any

LUHN check:

Yes

Yes

No

Expiry date:

Yes

Yes

No

Issue number:

No

If Present

No

Validity period:

No

If Present

No

Card security code:

Optional

Optional

No


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


ed

ed

ed


ed

ed

Refunds only

Keyed Swipe Failure

ed

ed

Refunds only


ed

ed

By Agreement

EMV Chip

ed

ed

ed

3D Secure

ed

ed

ed


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.


STANDARD 70 Book 1

PAGE: 117


1 June 2007

Table 17 - Solo IIN ranges Solo Standards

ISO


IIN ranges

7810-3

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


Optional


Purchase with Cash

By Agreement

Method of Entry


ed


ed

Keyed Swipe Failure

ed


ed

EMV Chip

ed

3D Secure

ed



STANDARD 70 Book 1

PAGE: 118


1 June 2007

Table 18 - JCB IIN ranges JCB Standards

ISO

7810-3


IIN ranges: Note 1

352800-358999

Validation

Service Codes:

Only check on a chipenabled device.

PAN length:

16

LUHN check:

Yes

Expiry date:

Yes

Issue number:

No

Validity period:

No

Card security code:

Optional


No


Purchase with Cash

Barred

Method of Entry


ed


ed

Keyed Swipe Failure

ed


ed

EMV Chip

ed

3D Secure

Optional



STANDARD 70 Book 1

PAGE: 119


1 June 2007

Table 19 - American Express IIN ranges American Express Standards

ISO

7810-13

ANSI Scheme Identification

IIN ranges:

370000 - 99 340000 - 99

Validation

Service Codes:

Yes

PAN length:

15

LUHN check:

Yes

Expiry date:

Yes

Issue number:

No

Validity period:

No

Card security code:

Optional


Optional


Purchase with Cash

Barred

Method of Entry


ed


ed

Keyed Swipe Failure

ed


ed

EMV Chip

ed

3D Secure

No



STANDARD 70 Book 1

PAGE: 120


1 June 2007

Table 20 – Diners IIN ranges Diners Standards

ISO

7810-3


IIN ranges:

3045 36 38

Validation

Service Codes:

Yes

PAN length:

14

LUHN check:

Yes

Expiry date:

Yes

Issue number:

No

Validity period:

Yes

Card security code:

Yes


No

Transaction Types Shows where additional checks are required and when they are not permitted Diners Financial

Purchase with Cash

No (Cash Advance permitted)

Method of Entry


ed


ed

Keyed Swipe Failure

ed


ed

EMV Chip

Not ed

3D Secure

Not ed


Notes: 1

2 3 4 5 6 7 8 9 10

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. Track 2 layouts vary. For further details please your Acquirer Available for magnetic stripe read transactions. The LUHN Check algorithm is available from your Acquirer. Details of service code checking and failure responses are available from your acquirer. A suggested expiry date algorithm is available from your acquirer. Details of how to check the validity period are available from your acquirer. Specifications are available from your Acquirer. UK Maestro/Solo ranges take precedence over International Maestro ranges i.e. use Domestic Maestro rules Visa propose to utilise longer PAN lengths in the future. We recommend this attribute is configurable


STANDARD 70 Book 1

PAGE: 121

APPENDIX F: CARD SCHEME IDENTIFICATION 11 12 13 14

F.5

1 June 2007

Transactions initiated with a card may not be declined by the terminal or card acceptor processors as a result of edits or validations performed JCB service codes must only be validated if the device is capable of processing JCB chip cards The customer must have prior agreement from your acquirer The purchase element must be greater than zero and the cash element may have an upper limit. 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 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.


STANDARD 70 Book 1

PAGE: 122



1 June 2007

STANDARD 70 Book 1

PAGE: 123

APPENDIX G: LUHN FORMULA

1 June 2007

G.

LUHN FORMULA

G.1

LUHN FORMULA FOR CALCULATING THE PAN CHECK DIGIT

The following steps are involved in this calculation, which applies to any length PAN: a)

double the value of alternate digits beginning with the first right-hand digit (low order),

b)

add the individual digits comprising the products obtained in a) to each of the unaffected digits in the original number,

c)

subtract the total obtained in a) from the next higher number ending in 0 (this is the equivalent of calculating the 'ten complement' of the low order digit (unit digit) of the total),

d)

the resultant digit is the PAN check digit that should equal the last digit of the PAN.

Note: If the total obtained in a) is a number ending in zero (30, 40 etc.), the check digit is 0. G.2

EXAMPLE CALCULATION

Number without check digit 4992 739 871 4

4+

9

9

2

7

3

9

8

7

1

Step 1 – double value of alternating digits

x2

x2

x2

x2

x2

18

4

6

16

2

1+8

+9

+4

+7

+6

+9

+1+6

+7

+2

= 64

2 – Add individual digits

3 – Subtract 64 from 70 = 6

number is therefore 4992 739 8716


STANDARD 70 Book 1

PAGE: 124

APPENDIX G: LUHN FORMULA

1 June 2007


STANDARD 70 Book 1

PAGE: 125

APPENDIX H: PRINTED DATA

1 June 2007

H.

PRINTED DATA

H.1

GENERAL REQUIREMENTS

H.1.1

Number of copies

A paper record shall be produced for every transaction performed and this shall contain all the information necessary to provide a completed audit trail enabling cardholders, card acceptors or acquirers to resolve queries or disputes. Where the cardholder uses their signature for cardholder verification at least two copies of the paper record shall be produced; one copy for the cardholder to enable reconciliation against a statement and the other for retention by the card acceptor, which must have space for the cardholder's signature. Where PIN is used for cardholder verification at least one copy of the paper record shall be produced for the cardholder to enable reconciliation against a statement. The card acceptor may require a copy for use in the point of sale back office reconciliation. Some retail operations may require three copies to be produced. H.1.2

Transaction types

The type of transaction recorded shall appear in words and be clearly visible. Acceptable transaction types include, SALE, REFUND, CANCELLED SALE, CANCELLED REFUND, DECLINED SALE, and PURCHASE WITH CASHBACK. For refunds, cancelled and declined transactions, the non-standard nature of the transaction shall be highlighted. This may be achieved, for example, by the use of red print, double height characters, delineation with asterisks or bold text, depending on printer capabilities. H.1.3

Transaction data source

As there are three different methods of obtaining the card details for the transaction it is necessary to identify the method of data collection on the voucher. The three methods and recommended narratives are: a)

ICC read; print ICC,

b)

magnetic stripe read; print SWIPED,

c)

key entered; print KEYED.

H.1.4

Card number (PAN)

To protect cardholders from fraud resulting from people stealing information from point of sale receipts, the PAN on cardholder copies shall be masked. Cardholder receipts shall only reflect the last four digits of the PAN, replacing all preceding digits with fill characters such as X, * or # [blank spaces or numeric characters must not be used].


STANDARD 70 Book 1

PAGE: 126

APPENDIX H: PRINTED DATA H.1.5

1 June 2007

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 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 . the acquirer to determine how these messages should be used.


STANDARD 70 Book 1

PAGE: 127

APPENDIX H: PRINTED DATA H.1.10.1

1 June 2007

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 ed,

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


STANDARD 70 Book 1

PAGE: 128


1 June 2007

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 encom 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),


STANDARD 70 Book 1

PAGE: 129


1 June 2007

n)

transaction number,

o)

transaction response e.g. Authorisation code,

p)

amount of transaction (including currency symbol),

q)

cardholder interface details (see Note 2),

r)

declaration (signature transactions only) e.g. Please debit (or credit, for refunds) my (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 ed, 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 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 of this. See H.4 for how a voucher could look.


STANDARD 70 Book 1

PAGE: 130


1 June 2007

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.


STANDARD 70 Book 1

PAGE: 131

APPENDIX H: PRINTED DATA H.4

1 June 2007

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

Receipt: 0082

d)

Receipt Number

ABCDEF0123456789 40

j) k)

Cryptogram, Cryptogram Type

a) h) i)

Diagnostic Message, Hot Card Version Number, Terminal Software Version Number

Application Identifier

t)

AID: A1234567890123456

Card Scheme

i)

VISA CREDIT

Card Number

e)

Card: 492912345678

Sequence Number

h)

PAN Seq Nr: 02

Start Date Expiry Date

g) f)

Start: 12/99 Expiry: 12/05

Transaction Data Source

j)

ICC

Transaction Type

d)

SALE

Amount

p)

£16.00

Cardholder Interface Details

q)

PLEASE SIGN BELOW ----------------------------------------PLEASE DEBIT MY WITH TOTAL SHOWN

Declaration e.g.

r)

Transaction Response

o)

Auth: 045678

Transaction Number

n)

Ref: M1500398

Merchant Number

a)

Merchant: 1234567

Terminal ID.

m)

TID: 16000001

Date and Time

k) l)

Date 01/01/05 Time: 13:15 OAX4

03

0140


STANDARD 70 Book 1

PAGE: 132


1 June 2007

Table 22 - Example Receipt Layout (Signature CVM) - Cardholder Copy MANDATORY

OPTIONAL

Merchant Name

b)

A RETAILER

Merchant Address

c)


c)



e) f)


VAT Rate: 17.50%

g)

VAT Rate

Receipt: 0082

d)

Receipt Number

ABCDEF0123456789 40

j) k)


Thank You

b)

Courtesy Message

03

h) i)

Hot Card Version Number, Terminal Software Version Number


t)

AID: A1234567890123456

Card Scheme

i)

VISA CREDIT

Card Number

e)

Card: ********5678

Sequence Number

h)

PAN Seq Nr: 02


g) f)



j)

ICC

Transaction Type

d)

SALE

Amount

p)

£16.00


q)

SIGNATURE VERIFIED


o)

Auth: 045678

Transaction Number

n)

Ref: M1500398

Merchant Number

a)

Merchant: 1234567

Terminal ID.

m)

TID: 16000001

Date and Time

k) l)

Date 01/01/05 Time: 13:15

Retention Reminder

s)

Please retain for you records

0140


STANDARD 70 Book 1

PAGE: 133


1 June 2007

Table 23 - Example Receipt Layout (PIN CVM) - Card Acceptor Copy MANDATORY

OPTIONAL

Merchant Name

b)

A RETAILER

Merchant Address

c)


c)



e) f)


VAT Rate: 17.50%

g)

VAT Rate

Receipt: 0165

d)

Receipt Number

1234567890ABCDEF 40

j) k)


a) h) i)



t)

AID: A1234567890123456

Card Scheme

i)

VISA CREDIT

Card Number

e)

Card: 492912345678

Sequence Number

h)

PAN Seq Nr: 02


g) f)



j)

ICC

Transaction Type

d)

SALE

Amount

p)

£17.00


q)

PIN VERIFIED


o)

Auth: 243090

Transaction Number

n)

Ref: M1600499

Merchant Number

a)

Merchant: 1234567

Terminal ID.

m)

TID: 16000002

Date and Time

k) l)

Date 01/01/05 Time: 16:29 OAX4

03

0140


STANDARD 70 Book 1

PAGE: 134


1 June 2007

Table 24 - Example Receipt Layout (PIN CVM) - Cardholder Copy MANDATORY

OPTIONAL

Merchant Name

b)

A RETAILER

Merchant Address

c)


c)



e) f)


VAT Rate: 17.50%

g)

VAT Rate

Receipt: 0165

d)

Receipt Number

1234567890ABCDEF 40

j) k)


Thank You

b)

Courtesy Message

03

h) i)



t)

AID: A1234567890123456

Card Scheme

i)

VISA CREDIT

Card Number

e)

Card: ********5678

Sequence Number

h)

PAN Seq Nr: 02


g) f)



j)

ICC

Transaction Type

d)

SALE

Amount

p)

£17.00


q)

PIN VERIFIED


o)

Auth: 243090

Transaction Number

n)

Ref: M1600499

Merchant Number

a)

Merchant: 1234567

Terminal ID.

m)

TID: 16000002

Date and Time

k) l)

Date 01/01/05 Time: 16:29

Retention Reminder

s)

Please retain for your records

0140


STANDARD 70 Book 1

PAGE: 135


1 June 2007

Table 25 - Example Receipt Layout (No CVM) - Card Acceptor Copy MANDATORY

OPTIONAL

Merchant Name

b)

A RETAILER

Merchant Address

c)


c)



e) f)


VAT Rate: 17.50%

g)

VAT Rate

Receipt: 7654

d)

Receipt Number

12345ABCDEF67890 40

j) k)


a) h) i)



t)

AID: A1234567890123456

Card Scheme

i)

VISA CREDIT

Card Number

e)

Card: 492912345678

Sequence Number

h)

PAN Seq Nr: 02


g) f)



j)

ICC

Transaction Type

d)

SALE

Amount

p)

£19.00


q)

NO CARDHOLDER VERIFICATION


o)

Auth: 000943

Transaction Number

n)

Ref: M5309002

Merchant Number

a)

Merchant: 1234567

Terminal ID.

m)

TID: 16000003

Date and Time

k) l)

Date 01/01/05 Time: 09:54 OAX4

03

0140


STANDARD 70 Book 1

PAGE: 136


1 June 2007

Table 26 - Example Receipt Layout (No CVM) - Cardholder Copy MANDATORY

OPTIONAL

Merchant Name

b)

A RETAILER

Merchant Address

c)


c)



e) f)


VAT Rate: 17.50%

g)

VAT Rate

Receipt: 7654

d)

Receipt Number

12345ABCDEF67890 40

j) k)


Thank You

b)

Courtesy Message

03

h) i)



t)

AID: A1234567890123456

Card Scheme

i)

VISA CREDIT

Card Number

e)

Card: ********5678

Sequence Number

h)

PAN Seq Nr: 02


g) f)



j)

ICC

Transaction Type

d)

SALE

Amount

p)

£19.00


q)

NO CARDHOLDER VERIFICATION


o)

Auth: 000943

Transaction Number

n)

Ref: M5309002

Merchant Number

a)

Merchant: 1234567

Terminal ID.

m)

TID: 16000002

Date and Time

k) l)

Date 01/01/05 Time: 09:54

Retention Reminder

s)

Please retain for your records

0140


STANDARD 70 Book 1

PAGE: 137

APPENDIX H: PRINTED DATA H.5

1 June 2007

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


Current session totals (number & value see note 2)

Current session number Transactions from / to Stored


Stored transactions (number & value see note 2)

Total net value Transactions from / to Diagnostic message

(see note 1)


STANDARD 70 Book 1

PAGE: 138


1 June 2007

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 Time Date Narrative line

(see note 1) HHMM DD/MM/YY X balances Totals not reset YES YES YES All card transactions (see Note 2) (see Note 2) (see Note 2)

(see note 1) HHMM DD/MM/YY Z balances Totals reset YES YES YES All card transactions (see Note 2) (see Note 2) (see Note 2)

By card issuer (see Note 2) (see Note 2) (see Note 2)

By card issuer (see Note 4) (see Note 2) (see Note 2)

1 2

Card acceptor name Card acceptor address Terminal identity The Grand total Debits & Credits. Debits Credits Card issuer name The Grand total Debits & Credits. Debits Credits 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 s 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.


STANDARD 70 Book 1

PAGE: 139

APPENDIX I: USE OF SERVICE CODES I.

1 June 2007

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 realtime, 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.


STANDARD 70 Book 1

PAGE: 140

APPENDIX I: USE OF SERVICE CODES

1 June 2007

Table 29 — Service code values Interchange Technology

Digit 1

Unspecified

0

Digit 2

Digit 3

Comments 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


National use only

5


National use only - alternative technology (integrated circuit card)

6


Private card

7


Unspecified

8


Test Card

9

Authorisation processing

Digit 1

Normal Authorisation

Real-time authorisation required Digit 2

Digit 3

0

Comments Accept

Unspecified

1


Real-time authorisation mandatory

2

Real-time authorisation required (see Note 1)

Unspecified

3


Positive (real-time/telephone) authorisation procedures, unless national or regional agreements apply

4

Real-time authorisation required (see Note 1)

Unspecified

5


Unspecified

6


Unspecified

7


Unspecified

8


Unspecified

9


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


Unspecified

9


Note 1: A terminal cannot distinguish between values 2 & 4


STANDARD 70 Book 1

PAGE: 141

APPENDIX J: AUTHORISATION CODE ALGORITHM J.

1 June 2007

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.


STANDARD 70 Book 1

PAGE: 142

APPENDIX J: AUTHORISATION CODE ALGORITHM


1 June 2007

STANDARD 70 Book 1

PAGE: 143

APPENDIX K: REFERRAL TELEPHONE NUMBER PROCESSING K.

1 June 2007

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 ed 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

ed 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

ABC

US

Set on-hook condition; time 3 seconds, set off-hook condition. Dial A B C with appropriate pauses; continue as 2.

4

BC

US

As 3 but dial B C with appropriate pauses.

5

ABC AB A

bc

As 3 but dial A b c

6

BC B

bc

As 3 but dial b c with appropriate pauses.

7

ABC AB

US c

As 3 but dial A B c

8

BC

US

As 3 but dial B with appropriate pause.

9

AC

US

As 3 but dial A C

10

AC

bc

As 3 but dial A b c

11

AC

US c

As 3 but dial A c

12

C

US

As 3 but dial C

13

C

bc

As 3 but dial b c

14

C

US c

As 3 but dial c

15

Not set (no numeric value entered)

US c

As 3 but dial c

16

Not set (no numeric value entered)

bc

As 3 but dial b c

17

A

US c

As 3 but dial A c

18

Remaining combinations

Set on-hook condition display 'CALL CARD ISSUER'.


STANDARD 70 Book 1

PAGE: 144

APPENDIX K: REFERRAL TELEPHONE NUMBER PROCESSING


1 June 2007

STANDARD 70 Book 1

PAGE: 145

APPENDIX L: DIAGNOSTIC CODES L.

1 June 2007

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.


21

No modem tone detected after dialling, e.g. call routed to incorrect number

Auth.


30

Transaction failed after re-dialling

Auth.


31

Line busy, e.g. other on the same line

Auth.


35

Confirmation message requested but could not be sent

Auth.


40

Modem tone detected but no response from PAD

Auth.


41

PAD advised it was not able to card company, i.e. EOT received in response to NUA

Auth.


42

No response received from card company, i.e. Timer 'C' has expired

Auth.


43

Insufficient or invalid data to compile a voice referral number or no phone present

Auth.


44

Terminal has received an EOT, i.e. remote close down by card company or PAD after CONNECTION MADE.

Auth.


If a security error has occurred this code is followed by the non zero response code of the hold message

--


45

Message cannot be sent, e.g. too many errors real-time

Auth.


46

Terminal has received an invalid message type

Auth.


47

Terminal has received an invalid message header or confirmation request

Auth.


48

Terminal has sent a not-confirm message (Down-line loading only)

Auth.


49

Invalid message contents

Auth.


50

Acquirer has not cleared down after confirmation message sent

Auth.


52

Force transaction, i.e. the authorisation was obtained before the transaction was performed

--


53

Post-event store full

--

70

Security error. Terminal has detected an invalid MAC on a received message

--


72

Card acceptor has indicated an invalid signature

--


73

Totals out of balance between terminal and acquirer

--


76

Terminal has performed an real-time reconciliation

-



STANDARD 70 Book 1

PAGE: 146

APPENDIX L: DIAGNOSTIC CODES

1 June 2007


Standard 70 Book 1 - 1 June 2007 4u2qe

Overview 26281t

More details 6y5l6z

Related Documents 3h463d

Standard 70 Book 1 - 1 June 2007 4u2qe

Historia [tp4] 70-1 5b5r3f

D-70[1] 4q4q6l

70-98-1-pb.pdf 1k5f3l

70-412-modulo-1 6k3i10

ionnement 70 - Volume 1 4w424o

More Documents from "Lokesh" 5hs3n

Bgp-4 Command And Configuration Handbook 2z3d3z

Irc 117 2015 5c1i4g

Standard 70 Book 1 - 1 June 2007 4u2qe

Emv Less Communication Protocol V2.0 3m5i4i

9-9 Installing Software Ag Products 2q1x5w

Am-cat-age.pdf e1w4i