local handling for spdh_060404

Local handlingfor

SPDH-connected terminals

2006-04-04

Version 1.4

Local handling for SPDH-connected terminals version 1.4 Page: 1

Revision History

VERSION DATE DESCRIPTION ISSUED BY0.3 2002-01-21 Initial draft for internal

reviewBörje Thörne

0.4 2002-03-20 Response groups, display messages and response codes are updated

Börje Thörne

0.5 2002-06-04 Response groups, display messages and response codes are updated

Börje Thörne

0.6 2002-11-24 Response code 897 added under special system handling error codes

Börje Thörne

1.0 2003-12-30 The following updates are performed.

- Response group I changed, response code 971 removed and 970 added.

- Response code 236 added in response group E.

- Response code 240 moves from response group J to group K.

- Response code 241 moves from response group K to group J.

- EMV card handling updated.

- Handling of local data added.

- Automatic reconciliation added.

Börje Thörne

1.1 2004-05-25 Under chapter 3 local parameters and general handling the following items are added

- unknown tag handling in the parameter files

- Display messages- Receipts and reports- Transaction log- Re-conciliation- Date and time

synchronisation- Communication

handling

Börje Thörne


- PIN by pass- Change to double

length keys for PIN and MAC

- Card verify- VAT handling- Password handling- Error handling

Under chip cardThe following items are updated or added

- Referrals- Card removal- Cash back- PIN online- Event log

Display texts for response groups removed.

1.2 2004-12-07 Minor editorial changes and the following updates are performed.

- Referrals initiated by host and Post registered transaction shall have message subtype = “F”.

- Manual registered approval code after voice authorisation shall be between 2-6 characters.

- No extra report shall be printed, if a mismatch is detected when close batch is sent as an advice from S&F queue.

- Processing of a chip card shall start as early as possible.

- Cash back handling updated.

- CV2 handling added.- Print of last

transaction added.

Börje Thörne

1.3 2005-04-04 Minor editorial changes and the following updates are performed.

- 898 added

Babs/CEKAB


- 4.2 updated - 4.3 updated- 4.4 updated - 4.9.4 updated - 4.11.1 updated- 4.11.2 updated- 4.13 updated- VAT handling

updated- 4.16 updated - 7.3 updated- 7.4 updated- 7.10 updated- 7.11 updated

1.4 2006-04-04 - 3 updated- 4.6, chapter name

changed- 4.9.4 updated- 4.11 – 4.11.2

updated- 4.11.2, chapter name

changed - 4.16 updated- 4.18-21 added- 5.3 deleted- 6.1, flow chart

deleted- 6.2 updated- 6.5 changed- 7.1.1 updated- 7.1.2.2, flow chart

deleted- 7, chapter name

changed- 7.5 updated- 7.8 updated- 7.10, chapter name

changed and chapter updated

- 7.11, chapter name changed and chapter updated

- 8 and 9.4, action for response group D deleted

Babs/CEKAB


1 About this document

The purpose of this document is to be a guide together with other documents, when developing a terminal that is going to be connected to Babs or CEKAB using the SPDH interface. This document describes important implementation and functionality issues together with a description of the SPDH response code handling. Furthermore the document gives some details of the processing flow in some special situations.

This document is primarily intended for stand alone terminals, but contains information also valid for integrated solutions. There is also a difference in terminals that use draft capture compared with authorisation only terminals with batch capture.

1.1 Reference documents

SPDH Terminal Interface for POS-transactionsBabs and CEKAB Common Interfaces: Software and Parameter DownloadCardholder and Operator interface

1.2 Outstanding issues


CONTENT

1 ABOUT THIS DOCUMENT............................................................................................................5

1.1 REFERENCE DOCUMENTS............................................................................................................51.2 OUTSTANDING ISSUES................................................................................................................5

2 TERMINAL LOADING AND PREPARATION.........................................................................8

3 LOCAL DATA.................................................................................................................................9

4 LOCAL PARAMETERS AND GENERAL HANDLING.........................................................10

4.1 DISPLAY MESSAGES..................................................................................................................104.2 RECEIPTS AND REPORTS...........................................................................................................104.3 PRINT OF LAST TRANSACTION..................................................................................................104.4 TRANSACTION LOG...................................................................................................................114.5 REFERRALS INITIATED FROM HOST..........................................................................................114.6 POST REGISTERED (PURCHASE ADVICE)...................................................................................114.7 MANUAL REGISTERED APPROVAL CODE...................................................................................114.8 CV2..........................................................................................................................................114.9 CLOSE BATCH FOR STAND ALONE TERMINALS.........................................................................11

4.9.1 Automatic close batch set by host....................................................................................124.9.2 Automatic close batch set locally in the terminal............................................................124.9.3 Manually initiated close batch.........................................................................................124.9.4 Close batch triggered by software download..................................................................12

4.10 DATE AND TIME SYNCHRONISATION........................................................................................124.11 COMMUNICATION HANDLING...................................................................................................12

4.11.1 Communication handling authorisation host...................................................................134.11.2 Communication handling for software and parameter download...................................13

4.12 PIN BY PASS.............................................................................................................................134.13 CHANGE OF KEY LENGTH FOR PIN AND MAC.........................................................................134.14 CARD VERIFY............................................................................................................................134.15 VAT HANDLING.......................................................................................................................144.16 PASSWORD HANDLING..............................................................................................................144.17 ERROR HANDLING.....................................................................................................................154.18 REVERSAL TRANSACTION.........................................................................................................154.19 MERCHANDISE RETURN TRANSACTION....................................................................................154.20 THE S&F QUEUE......................................................................................................................154.21 CASH BACK...............................................................................................................................16

5 TECHNOLOGY SELECTION....................................................................................................17

5.1 PREFERRED TECHNOLOGY........................................................................................................175.2 NORMAL AND FALLBACK PROCEDURES...................................................................................175.3 CHIP CARD IS NOT INSERTED CORRECTLY................................................................................175.4 FAULTY CHIP OR CHIP READER – FORCING FALLBACK.............................................................18

6 MAGNETIC STRIPE PROCESSING.........................................................................................19

6.1 APPLICATION SELECTION (MAGNETIC CARD)..........................................................................196.2 BINPAR FILE...........................................................................................................................196.3 SERVICE CODES........................................................................................................................196.4 PURCHASE WHEN ONLINE TOWARDS HOST...............................................................................206.5 PURCHASE WHEN OFFLINE TOWARDS HOST.............................................................................20

7 PROCESSING OF CHIP CARDS...............................................................................................22

7.1 APPLICATION SELECTION (CHIP CARD)....................................................................................227.1.1 Handling of non-EMV chip cards....................................................................................227.1.2 Handling of non-payment cards.......................................................................................22

7.2 EMV APPLICATION SELECTION................................................................................................227.3 PROCESSING OF A CHIP CARD...................................................................................................237.4 READING BINPAR...................................................................................................................237.5 REMOVAL OF CHIP CARD..........................................................................................................23


7.6 EVENT LOG...............................................................................................................................237.7 CASH BACK ON DOMESTIC CARDS............................................................................................237.8 PIN ONLINE..............................................................................................................................247.9 ONLINE ONLY...........................................................................................................................247.10 REFERRALS INITIATED BY HOST...............................................................................................247.11 UNABLE TO GO ONLINE (TERMINAL INITIATED REFERRALS)....................................................257.12 STAND-IN PROCESSING FOR EMV CARDS................................................................................257.13 MANDATORY CHECKS IN SCHEME TESTS (TIP, ADVT ETC)....................................................25

8 RESPONSE CODES AND RELATED ACTIONS....................................................................26

8.1 DISPLAY TEXTS.........................................................................................................................27

9 RESPONSE CODES BY RESPONSE GROUPS.......................................................................28

9.1 RESPONSE GROUP A: APPROVED TRANSACTIONS...........................................................289.2 RESPONSE GROUP B: DECLINED, REFERRAL TO ACQUIRER.........................................299.3 RESPONSE GROUP C: DECLINED, ISSUE CALL TO TECHNICAL HELPDESK...............299.4 RESPONSE GROUP D: CAPTURE DECLINE...........................................................................309.5 RESPONSE GROUP E: UNABLE TO VERIFY PIN..................................................................319.6 RESPONSE GROUP F: DECLINED, CARD NOT VALID HERE............................................319.7 RESPONSE GROUP G: GENERAL DECLINE..........................................................................329.8 RESPONSE GROUP H: DECLINED, WRONG PIN..................................................................339.9 RESPONSE GROUP I: CLOSE BATCH TOTALS MISMATCH...............................................339.10 RESPONSE GROUP J: AUTHORISATION NOT POSSIBLE...................................................339.11 RESPONSE GROUP K: DECLINED, WRONG PIN ONE ATTEMPT LEFT...........................339.12 SPECIAL SYSTEM ACTION................................................................................................33


2 Terminal Loading and preparation

The terminal is expected to follow the handling described in the document, BABS and CEKAB Common Interfaces: Software and Parameter Download.


3 Local dataThe terminal and associated systems shall take great care to protect sensitive data such as PAN, expire date, track2 etc.

- PAN shall be truncated on receipts according to the document “CARDHOLDER AND OPERATOR INTERFACE”.

- The complete PAN shall be considered as sensitive transaction data and shall only be available electronically at the retailer for a limited number of days.

- The complete Track2 data must only be used during the transaction and stored in the Store and Forward queue (S&F queue). The complete Track2 data must never be stored in any other way (e.g. in the transaction log or debug logs).


4 Local parameters and general handling

In the document BABS and CEKAB Common Interfaces: Software and Parameter Download, all parameters are described that is supplied to the terminal from the central side.

If a tag in the parameter files is unknown to the terminal the terminal shall ignore and drop the tag and the data belonging to that tag.

The terminal should operate according to the operation regulations valid for the brands (Visa, Mastercard, etc) accepted in the terminal both handling magnetic cards and EMV cards.

4.1 Display messages

The terminal should follow the messages defined in the document “CARDHOLDER AND OPERATOR INTERFACE”, as far as possible.

4.2 Receipts and reports

The receipts and reports should follow the definitions specified in “CARDHOLDER AND OPERATOR INTERFACE”. A declined receipt must be produced if the PAN is known and the BINPAR has been successfully (PAN is present) checked.

4.3 Print of last transaction

The terminal must have a function in the menu to print the last transaction according to requirements from the card schemes. The print out must contain the following data from the last transaction, if available:

- Application Identifier, AID (EMV tag 4F)

- Card Primary Account Number, PAN (EMV tag 5A)- Card PAN sequence number (EMV tag 5F34)- Application Cryptogram (EMV tag 9F26)- Cryptogram Info Data (EMV tag 9F27)- Issuer Application Data (EMV tag 9F10)- Unpredictable number (EMV tag 9F37)- Application Transaction Counter (EMV tag 9F36)- Terminal Verification Results (EMV tag 95)- Transaction Date (EMV tag 9A)- Transaction Type (EMV tag 9C)- Amount Authorized (EMV tag 9F02) - Transaction Currency Code (EMV tag 5F2A)- Application Interchange Profile (EMV tag 82)- Terminal Country Code (EMV tag 9F1A)- Amount Other (EMV tag 9F04)- Terminal Capabilities (EMV tag 9F33)- CVM Results (EMV tag 9F34)- Terminal Type (EMV tag 9F35)- IFD Serial number (EMV tag 9F1E)- Transaction Category Code (EMV tag 9F53)- Dedicated File Name (EMV tag 84)


- Terminal Application Version Number (EMV tag 9F09)- Transaction Sequence number (EMV tag 9F41)- Issuer Authentication Data (EMV tag 91)- Issuer Script Template 1 (EMV tag 71)- Issuer script Template 2 (EMV tag 72)- Terminal action codes, TAC - Issuer action codes, IAC (EMV tag 9F0D, 9F0E, 9F0F)

4.4 Transaction log

The transaction log must be cyclic and contain at least 1000 transactions. All transactions must be logged (approved, declined and close batches). The definition of a declined transaction in the log is a transaction that results in a receipt and that the PAN is known at that time and present in the BINPAR file. Only the data specified in the transaction list (according to Cardholder and Operator Interface) is allowed to be logged in the transaction log. The transaction log must be protected with the local password.

4.5 Referrals initiated from host

Transactions that receive a response code belonging to response group B, referral to host, must be treated as follows. If the transaction is approved by voice authorisation it must be sent to the host immediately as an advice with the message subtype set to “F”.

If unable to go online, the transaction must be stored in the S&F queue (the message subtype must be changed to “S” and the transmission number changed to “00”) disregarding any terminal limits. Note this is the first transaction in the S&F queue according to other rules.

4.6 Post registered (purchase advice)

A post registered transaction must be sent to the host immediately as an advice with the message subtype set to “F”. If unable to go online, an attempt must be done to store the transaction in the S&F queue (the message subtype must be changed to “S” and the transmission number changed to “00”). If it is not possible to store the transaction in the S&F queue according to the rules defined for the S&F queue, the registration must not be accepted. A new attempt can be performed as soon as the communication is re-established.

4.7 Manual registered approval code

A manual registered approval code must be between 2- 6 characters long. Valid input is numeric characters or capital letters.

4.8 CV2

If the PAN is entered manually, a request for the CV2 value to be registered could be retrieved from the BINPAR file. CV2 must never be requested for a refund or a post registered transaction (purchase advice).

4.9 Close batch for stand alone terminals

The following section is written for draft capture terminals but some parts are also relevant for other terminals.


A terminal is not allowed to perform more than two days with transactions without performing close batch.

Close batch could only be performed as a batch settlement. That means that a close batch transaction must be created whenever close batch is performed.If there is a mismatch between the terminals totals and the host totals, both the terminals totals and the host totals must be printed on the report. If unable to go online at the time for close batch, the close batch must still be performed, the report printed and the close batch transaction should be stored in the S&F queue. If there is a mismatch of totals when the S&F transaction is sent to host no extra report shall be printed.

The report layout is defined in Cardholder and Operator interface.

The terminal must support automatic close batch in the shop as described below.

4.9.1 Automatic close batch set by host

If the parameter Close_Batch_Time in DCPAR contains a valid time (0000-2359) an automatic close batch should be performed by the terminal. If Close_Batch_Time is set to 9999 the local settings are valid.

4.9.2 Automatic close batch set locally in the terminal

It should be possible to set a time for automatic close batch locally in the terminal. This option should only be possible if the Close_Batch_Time in DCPAR is equal to 9999, otherwise the setting by the host overrule the local setting.

4.9.3 Manually initiated close batch

It should always be possible to manually initiate the close batch.

4.9.4 Close batch triggered by software download

If a download of new software is initiated manually or trigged by a control file (i.e. handling code 01, 02 or 03) a close batch must be performed online prior to the update.

If the terminal is unable to perform a close batch online due to technical problems the terminal must request a call to helpdesk. The terminal must continue by requesting the daily password and then print out the S&F queue (Swedish “ej överförda transaktioner”). If the print-out of the S&F queue is confirmed, the terminal should perform the software download.

4.10 Date and time synchronisation

The terminal shall synchronise date and time with every transaction response received from the authorisation host.

4.11 Communication handling

The communication normally consists of three different types, communication with the authorisation host, communication for software download and communication for parameter download.


4.11.1 Communication handling authorisation host

During normal transaction handling (including logon transaction) with the authorisation host one retry should be performed when a communication error occur. The retry must use the secondary phone number or address. If the line is busy during the first attempt one retry with the same phone number or address must be performed.

Predial is only allowed if it is possible to turn off and on the function using the parameter in DCPAR.

4.11.2 Communication handling for software and parameter download

Communication error handling that occurs during software and parameter loading should be performed as described below.

Three automatic retries should be performed. The third attempt could be performed with the secondary phone number or address (only valid for parameter download). If still communication error a receipt should be printed with the reason for the communication failure and contain the phone number to the technical helpdesk. If the attempt is triggered by trigger 11x or 12x the terminal must not accept any transactions and the next attempt must be manually initiated. If the attempt is triggered by other triggers the terminal is allowed to continue accepting transactions.

After one hour three new automatic retries should be performed, if still unsuccessful a new receipt should be printed.

24 hours after the first attempt, three new automatic retries should be performed. If still unsuccessful a new receipt should be printed. No more automatic retries should be performed by the software. The terminal must not accept any transactions and the next attempt must be manually initiated.

4.12 PIN by pass

A PIN terminal must support “PIN BY PASS” initiated by the cardholder and the operator.

4.13 Change of key length for PIN and MAC

Within near future all terminals with PIN must use double length keys for PIN and MAC. Therefore all terminals must support both single length keys as well as double length keys for PIN and MAC during a migration period. The method used is defined by the key length received in the download file for initial keys. The terminal must support key download according to BABS and CEKAB Common Interfaces: Software and Parameter Download. Switch to support the double length key implementation is then achieved by key download when the key length is changed. Note that the implementation of the VDUKT MAC is not supported for double length keys.

The MAC in the response should not be checked if the message is sent from the S&F queue.

4.14 Card verify

The function ‘card verify’ (Swedish “kortkontroll”) is not allowed.


4.15 VAT handling

The handling of VAT for a stand alone terminal is controlled by 3 downloaded parameters. The parameters are:

MASPAR, option flags, ”VAT display option” MASPAR, ”VAT percentage” BINPAR, bitfield2, ”always prompt for VAT”

The handling of VAT can also be controlled by local configuration for certain functions. The local configuration generally consists of functions for:

Changing VAT percentage rate Configure the function to show/change VAT-amount in the display to

ON/OFF

The principle for VAT handling is that the local configuration always overrides downloaded parameters. However, there is one important exception from that, i.e. when the terminal get ”always prompt for VAT” from the BINPAR file. In this case the terminal always has to show and make it possible to change the VAT-amount in the display.

If the local configuration for showing/change VAT-amount is switched OFF, the terminal must not print any line for VAT on the receipt.

If the local VAT percentage is set to 99.99 %, the terminal must recapture the latest downloaded VAT percentage.

The field for VAT (fid a, subfid E) must be set to zero if VAT is not calculated. The percentage supplied in MASPAR for VAT is the VAT % for the net amount (excluding VAT). Since the entered amount is the amount including VAT the terminal must calculate the VAT % used for that amount using the VAT % in MASPAR. E. g. if the VAT % in MASPAR is 25 % the terminal should use VAT % = 20 on the entered amount.

4.16 Password handling

There must be two types of passwords in the terminal, a daily password that is supplied to the operator after a phone call to the technical helpdesk and a local password to protect different types of terminal functions.

The daily passwords that changes for every day are calculated with an algorithm supplied by the acquirer at request. The daily password must at least be used in the following situations:

Changing the communication parameters Software upgrade Changing the TSP-ID Print-out of the last transaction Print-out of the S&F queue (Swedish “ej överförda transaktioner”)

The local password is used to limit the access to different transactions/functions in the terminal. An initial password is downloaded in MASPAR. This password is valid if


not changed locally in the terminal. If the password is changed locally the new password is valid until changed again locally. The password in MASPAR is not allowed to overwrite the changed password. If the operator has forgotten the password a function should be available in the terminal to enter a new password after entering the daily password received from the technical helpdesk.

4.17 Error handling

The terminal shall have a sufficient error handling. Normally the error situation shall be described with a display message and a printed receipt with more detailed information. If error codes are used to specify an error situation, the error codes must be well documented and supplied before the testing of the terminal.

4.18 Reversal transaction

A reversal transaction must be stored in the S&F queue with the message subtype set to “U” for a reversal initiated by the operator or cardholder, “C” for general reversal or “R” for bad mac reversal. If the transaction (the original transaction) that shall be reversed is in the S&F queue, the original transaction must be deleted from the S&F queue along with the matching reversal. Note, both the reversal and the original transaction must be written to the transaction log.

4.19 Merchandise return transaction

A merchandise return transaction must be sent to the host immediately as an advice with the message subtype set to “F”. If unable to go online, an attempt must be done to store the transaction in the S&F queue (the message subtype must be changed to “S” and the transmission number changed to “00”). Note! The merchandise return amount is positive. If it is not possible to store the transaction in the S&F queue according to the rules defined for the S&F queue, the transaction must not be accepted. A new attempt can be performed as soon as the communication is re-established.

A merchandise return transaction can be completed either by chip, magstripe or manual input without checking the service code or the PPL-parameters “only online” and “manual entry is allowed”.

4.20 The S&F queue

For all transactions that are stored in the S&F queue (except reversals), the transmission number must be set to “00” and the message subtype set to “S”. This also includes Close batch transactions put in the S&F queue. For reversals (reversals must always be put in the S&F queue) a copy of the transaction header, with the message subtype set to “C”, “U” or “R” (depending on the reversal reason), must be put in the S&F queue.

If the terminal receives an error code when sending a transaction from the S&F queue, the terminal must handle it as a communication error and continue like an offline situation. The transaction must not be removed from the S&F queue.

4.21 Cash back

A purchase with cash back is performed as a normal purchase transaction (only the amount for cash back in fid a shall be updated with the cash back amount). This


means that a purchase including cash back is allowed to be an offline approved transaction or a referral. See also chapter 7.7 for chip cards.


5 Technology Selection

5.1 Preferred technology

The transaction should be completed with the highest level technology supported by both the terminal and the card. The precedence for accepting technology, highest first, is:

Chip Magnetic stripe Manual imprint/key entry

5.2 Normal and Fallback Procedures

A “normal” transaction takes place when the technology used for a transaction is the highest technology supported by both the card and the terminal.

A “fallback” transaction takes place when the transaction could not be completed using the “normal” technology and one of a lower precedence is used. An online-capable terminal should always force a fallback transaction online.

A summary of normal and fallback procedures is given below:

Card Technology Transaction Technology

Terminal TechnologyPaper/Key entry Magnetic Stripe Hybrid

Magnetic stripe + Embossing

Magnetic stripe not applicable Normal NormalPaper/Keyed a) Normal Fallback Fallback

Chip +Magnetic stripe + Embossing

Chip not applicable not applicable NormalMagnetic stripe not applicable Normal FallbackPaper/Keyed a) Normal Fallback Fallback

Note a) not allowed for online only products e. g. Maestro and Electron.

5.3 Chip card is not inserted correctly

If the chip card is inserted upside down, or with wrong end first, the chip card reader may still (by means of a mechanically actuated switch) detect that a card has been inserted. The IFD (chip card reader with dedicated firmware) will try to activate the card, but there will be no ATR (Answer To Reset). In this case there is an error indication to the application that should respond with a suitable warning message and preferably also with an audible signal (“beep”). The message “CHECK CARD” should direct the cardholder to check the orientation of the card and to reinsert it properly.


5.4 Faulty chip or chip reader – forcing fallback

If the chip or chip reader is faulty, the cardholder could continue following the instructions forever, unless there is some means for the operator to force fallback to magstripe. Any time the magstripe has been read and the service code indicate that the card has an EMV chip, the message “USE CHIP READER” is displayed. At this point it must be possible for the operator to press a button on the operator unit or on the ECR, making the terminal continue with magstripe fallback, using the available track 2 information. This should happen if the cardholder has actually tried the chip first, or if the operator knows the chip reader is faulty. Some spoken interaction between the cardholder and the operator can be expected in this case.


6 Magnetic stripe processing

6.1 Application Selection (Magnetic card)

If the card number was keyed input or the magnetic stripe was read the transaction handling is the same. If the card during the Technology selection has been identified as a magnetic stripe fallback from an EMV card the application selection is still the same as for a normal magnetic stripe card but the parameter in the prefix table must allow magnetic stripe fallback.

The processing of a magnetic stripe is to great extend directed by the local parameters loaded from the PPL-server. The DCPAR table contains parameters for the overall handling of the debit/credit application. The BINPAR file is the table that contains the prefixes for cards accepted in the terminal and their processing. If the card is an EMV card but processed as a fallback magnetic stripe the terminal floor limit should by set to zero.

6.2 BINPAR file

Using the magnetic stripe information extracted from the card (or keyed in input) the terminal should find the entry in the BINPAR file for the card. The terminal must follow the instruction received from the BINPAR file entry. Below is a description of validation of service codes in track 2. In some cases the service code is not correct e. g. Maestro. Because of this there is a special flag in the BINPAR to define cards that require online authorisation.

If an entry in the BINPAR file is not found for the card. The card should be declined with a display message according to Cardholder and Operator Interface.

6.3 Service codes

For the actual entry in the BINPAR file, the first part of the validation is to check bit 5 and 4 in bitfield_1 to find out if the service code should be validated at all.

The second step is to check if it is a domestic or foreign card. This is performed by first checking bit 3 in bitfields_2 to see if the issuer country is known or not. If the bit is set the issuer country is not known. If the bit is not set then check bit 4 in the same bit field to check if it is a Swedish card.

Definition of service codes:

Definition Position 1 Position 2 Position 3

International use, no restrictions 1Smart Card, international use 2National use only 5Smart Card, only national use 6Private cards, invalid for Visa/MC 7Test card, invalid for Visa/MC 9


Normal authorisation according to product rules 0Online authorisation mandatory 2

Pin mandatory 0Normal verification 1Normal verification (no cash back), POS only 2ATM only 3Pin mandatory (no cash back), POS only 5Prompt for Pin if pinpad is present 6Prompt for Pin if pinpad is present (no cash back), POS only 7

Examples:

Service code Definition

101 International use, no restrictions103 International use, only valid in ATM:s121 International use, online authorisation mandatory201 Smart Card, international use501 Only valid in the issuing country

6.4 Purchase when online towards host

The following validations must be performed before sending the transaction to host.

Swiped Card: Key entered Card number:

Prefix validation Prefix validation

Expiry-date validation Expiry-date validation

Service Code validation

6.5 Purchase when offline towards host

In a situation with temporary offline status or when a timeout has occurred towards the host system a purchase might still be possible under certain circumstances.

If the purchase amount is less than or equal to the magnetic stripe floor limit in the prefix table, the transaction can be approved by the local system itself. Signature verification must always be done on locally approved magnetic stripe transactions.

If the purchase amount is greater than the magnetic stripe floor limit a telephone call using the voice authorisation phone number must be done to receive an approval of the transaction. Cards where online authorisation is required shall be declined.

Example 1: Purchase amount is below the magstripe floor limit

Limit set to 1200:- in prefix-table. Purchase amount = 545:50 SEK

1. Initial validation is performed

2. Transaction is ready to be sent to host

3. Host is not available or timeout occurs

4. Cardholder ID, name and signature is checked by the cashier


5. Approval code is generated by the ECR/Terminal. Format ‘L12345’. The approval code is printed on the receipt and the local journal

6. End of purchase

7. An advice transaction with Message Subtype = ‘S’ (‘Store-and Forward’) is queued for transmission to the host system

Example 2: Purchase amount is above the magstripe floor limit

Limit set to 1200:- in prefix-table. Purchase amount = 1267:-SEK

1. Initial validation is performed

2. Transaction is ready to be sent out to host

3. Host is not available or timeout occurs

4. Display text “CALL xx – xxx xx xx”” (“Ring xx – xxx xx xx”) appears (phone number obtained from prefix-table). Not valid for online only cards.

5. Cashier receives approval code from issuer or cancel the transaction

6. Cashier enters the received approval code

7. Cardholder ID, name and signature is checked by cashier

8. End of purchase

9. An advice transaction with Message Subtype = ‘S’ (Store and Forward) is queued for transmission to the host system

The magstripe floor limit in the prefix table will normally be set to 0. In these cases a manual call to acquirer Authorisation Services is needed for all transactions that can’t be approved online.

If it is not possible to store the transaction in the S&F queue according to the rules defined for the S&F queue, the transaction must be declined (valid in example 1 and 2 above).


7 Processing of chip cards

7.1 Application Selection (Chip card)

Assume that the technology selection part has decided that the card is a chip card, but not yet is the card identified as an EMV card or non-EMV card.

7.1.1 Handling of non-EMV chip cards

When a chip card is inserted in an EMV hybrid terminal, the only check made during Technology Selection is that the card responds with a valid ATR. This can be expected from any ISO/IEC 7816 compliant cards and is no guarantee that the card is an EMV card. The terminal will in any case proceed assuming that the card is an EMV card. In the next stage, Application Selection, it will be detected if it is a non-EMV chip, in this case the terminal must fall back to magstripe handling.

7.1.2 Handling of non-payment cards

7.1.2.1 Non-payment (bonus) EMV chip card

TBD

7.1.2.2 Non-payment non-EMV chip card

If the chip is neither an EMV chip, nor a domestic purse application, the handling is outside the scope of this document. The default action is to abort further handling of the card and resume Technology Selection, prompting for another card.

7.2 EMV Application selection

During this phase the terminal selects which application will be used to process the transaction. During the application selection the following steps are performed:

Application List Construction; an application list is constructed with applications that are supported by both the terminal and the card.

Application choice; if there is more than one application in the application list, one application is chosen by the operator or customer.

Application selection; the application chosen is selected to start the transaction processing.

Initiate application; the terminal passes the information requested to the chip. This allows the chip card to decide if it shall proceed with the transaction.

Every application in a chip card is identified by an Application Identifier (AID). An AID consists of two parts: A Registered Application Provider Identifier (RID) of 5 bytes (hexadecimal). This

number is assigned by the International Organisation for Standardisation (ISO). A Proprietary Application Identifier Extension (PIX) of up to 11 bytes

(hexadecimal). This is assigned by the RID owner.

The following AIDs are some examples of AIDs used in the terminal:


A0000000031010 Visa (Credit and Debit) A0000000032010 Visa Electron A0000000041010 Mastercard A0000000043060 Maestro

The examples above are not complete, the complete AID list is supplied in DCPAR and also contains AIDs for e. g. AMEX and JCB.

EMV uses the TLV-BER format to identify the different data elements. The TAG values are documented in the EMV specification issued by EMVco.

The processing of an EMV chip card should follow the EMV standard and the implementation specification for the actual brand that the card belongs to.

7.3 Processing of a chip card

As soon as the chip card is inserted the terminal should process the application selection and read application even if the amount is not entered at this time. If the card requests the amount in the PDOL, prior to read application, the terminal must set the amount to binary zeroes if the amount is not yet known.

7.4 Reading BINPAR

When the application is read from the chip and the PAN is identified, a check must be performed that the PAN is present in the BINPAR file. All parameters in the BINPAR that are marked for chip use must be considered, such as “always handle as magstripe”.

7.5 Removal of chip card

The terminal software must be able to detect that a card is removed from the card reader. The transaction is not allowed to proceed to the next interaction with the card before the removal of the card is detected.

If the card is removed during a transaction, the transaction can be approved if the terminal has received TC from the card (even if the script handling is not finalised).

7.6 Event log

An event log in the terminal that describes errors during processing of chip cards is recommended but not a demand. The event log could contain the last 20 error events during processing of chip cards. A report could be printed. Such a log will speed up testing procedures and reduce time when handling interoperability cases in production environment.

7.7 Cash back on domestic cards

Terminals shall not perform cash back according to the EMV standard. Cash back shall only be allowed on domestic cards in the same way as for magnetic stripe. That means that if cash back is requested, only the amount for cash back in fid a shall be updated with the cash back amount. The EMV kernel shall handle the transaction as a normal purchase without cash back, amount others shall be equal to zero. Cash back on a fallback transaction to magnetic stripe is not allowed in this case.


7.8 PIN Online

When the terminal detects that it is unable to send a transaction online, the terminal checks if the verification method is PIN online, if this is not the case the terminal performs the normal EMV-processing.

If the verification method was PIN online the terminal completes the transaction in the background as declined and displays a message to the cardholder and operator indicating communication error and that only signature as CVM-method is possible to use. In this case the operator will be allowed to perform a new transaction and now use the PIN BY PASS function. Thus if the card supports signature the new transaction could be successful.

The normal EMV transaction handling shall then take place. If the transaction amount is below the chip floor limit the card in co-operation will decide to decline or approve the transaction. If the transaction amount is above the chip floor limit the transaction can still be approved but a voice authorisation is required.

The implementation shall be performed as described below:

When an EMV transaction is unable to go online or when a referral is initiated by the host:

The terminal shall check if the EMV tag 95, byte 3, bit 3 is set in the TVR (Terminal Verification Result), meaning Online PIN entered. If this condition is valid special handling described below shall be performed. Otherwise the terminal shall perform according to the normal EMV transaction handling.

The terminal shall request an AAC in the second generate AC. The response code (EMV tag 8A) shall either be set to Z3 if unable to go online or 01 if a referral is initiated by the host. The terminal shall display a message according to response group E and a receipt shall be printed stating the reason why the transaction has been denied.

7.9 Online only

It is not allowed to perform voice authorisation for the following AID’s: A0000000032010 Visa Electron A0000000043060 Maestro.

7.10 Referrals initiated by host

Voice authorisation (referrals initiated by host) shall be performed according to the following: If the response from the host initiates a referral, the terminal should complete the transaction by request a second cryptogram from the card of type AAC (decline). On the operator display a message contain the phone number for voice authorisation should be displayed. The card should be removed from the card reader. If the transaction is approved the approval code should be entered.


If the referral was initiated by a response from the host the transaction shall be sent to the host immediately as an advice with the message subtype set to “F”. If unable to go online, the transaction must be stored in the S&F queue (the message subtype must be changed to “S” and the transmission number changed to “00”) disregarding any terminal limits. Note, this is the first transaction in the S&F queue according to other rules.

Note that the cryptogram ARQC should be used in the clearing transaction.

7.11 Unable to go online (terminal initiated referrals)

If the transaction is approved (TC received by the card) after unable to go online in second generate AC and the amount is above chip floor limit, the transaction must additionally be authorised using voice authorisation (if voice authorisation allowed for the product). On the operator display a message containing the phone number for voice authorisation should be displayed. The card should be removed from the card reader. If not approved by voice authorisation the transaction must be declined. If the transaction is approved the approval code should be entered. The approved transaction must be stored in the S&F queue with the message subtype set to “S”. If it is not possible to store the transaction in the S&F queue according to the rules defined for the S&F queue, the transaction must be declined.

7.12 Stand-in processing for EMV cards

If it not possible to perform an online authorisation to the card issuer from the processing centre, the processing centre could perform a stand in authorisation if it is agreed with the card issuer. In this case the response transaction from the processing centre to the terminal may not contain any ARPC (in SPDH the fid 6Q will not be present). The terminal shall perform 2nd generate AC without the ARPC.

7.13 Mandatory checks in scheme tests (TIP, ADVT etc)

Mandatory checks that are introduced by the schemes in terminal integration test must be performed, such as MasterCard’s check of the PAN tag 5A and the track2 equivalent data tag 57. These tests are normally expected to be performed for all schemes.


8 Response codes and related actions

Action in the local system should be taken depending on to which response group the received response code belongs.

Resp. group

Description System Action Cashier action

A Approved Transaction completed Approve transactionB Referral to acquirer Transaction referred to

manual authorisationIssue call to Acquirer Authorisation services for approval

C Declined, Issue call to technical helpdesk

Transaction aborted Call technical helpdesk for further information

D Capture decline Transaction aborted Decline transactionE Unable to verify PIN Transaction can only be

completed with signature verification. If the transaction is a signature transaction use response group C

Signature verification needed

F Card not valid in this shop

Transaction aborted Decline transaction – return card - Try other card

G Declined, contact issuer

Transaction aborted Decline transaction – return card - inform customer to contact card issuer

H Declined – wrong PIN

Re-enter the PIN.A new transaction is sent

-

I Close batch totals mismatch

The close batch receipt shall contain information about mismatch

-

J Auth not possible, online required

Transaction aborted Issuer offline. Online auth to issuer mandatory (Electron/Maestro)

K Declined-wrong pin one attempt left

Re-enter pin The customer has only oneattempt left to enter correct pin


8.1 Display texts

Depending on to which response group the received response code belongs, display texts should be given as defined in CARDHOLDER AND OPERATOR INTERFACE.

The display texts should be implemented so that changes can be done easily.


9 Response codes by response groups

The terminal shall recognise and act on the following SPDH codes.

NOTE! New response codes could be added or existing response codes could be moved from one group to another in the future. It is therefore important that such changes could be done with as small impact as possible on the rest of the programme.

9.1 Response group A: APPROVED TRANSACTIONS

SPDH Code000001002003004005006007008009952953954


9.2 Response group B: DECLINED, REFERRAL TO ACQUIRER

Action: Place transaction on hold. Display the telephone number according to prefix table. It should be possible to enter an approval code received via telephone or cancel the transaction.

SPDH Code086088092100101102103104106107110112113120130131132133134202204208212213230232330

9.3 Response group C: DECLINED, ISSUE CALL TO TECHNICAL HELPDESK

Transaction declined. Action: Call Technical Helpdesk for further instructions.

This is the default response group and should be used for all response codes that are not specified in the other response groups.


9.4 Response group D: CAPTURE DECLINE

Transaction declined.

SPDH Code900901902903904905906907908909910911912930931932933934


9.5 Response group E: UNABLE TO VERIFY PIN

Transaction declined, unable to verify PIN. Action: Perform an authorisation transaction with signature

verification. If a response code belonging to response group E is received on a transaction with signature verification, the transaction shall be declined according to response group C.

SPDH Code052122149236

9.6 Response group F: DECLINED, CARD NOT VALID HERE

Action: Decline, contact merchant customer service.

SPDH Code105


9.7 Response group G: GENERAL DECLINE

Transaction declined. Action: Return card to cardholder.

SPDH Codes050051053056057058059060061064066072074076079080081082083084085087089093094095096097206331332333335337338403404405406407408


9.8 Response group H: DECLINED, WRONG PIN

Action: Customer re-enters the PIN.

SPDH Code201

9.9 Response group I: CLOSE BATCH TOTALS MISMATCH

During the day (normally at the end of) the terminal can send a terminal close batch transaction. The purpose of this transaction is to compare the totals held within the terminal with the totals held in Base24. Please check with your processing centre. Any discrepancies will be logged on the central log and the terminal will receive response code “970” indicating close batch totals mismatch. Action: On the close batch receipt, information about mismatch shall be included.

SPDH Code970

9.10 Response group J: AUTHORISATION NOT POSSIBLE

Transaction declined. Issuer not online and online to issuer mandatory (Electron/Maestro).

Action: Decline transaction.

SPDH Code241

9.11 Response group K: DECLINED, WRONG PIN ONE ATTEMPT LEFT

Action: Customer re-enters the PIN.

SPDH Code240249

9.12 SPECIAL SYSTEM ACTION

This response codes will require special system action defined in SPDH Terminal Interface for POS-transactions.

SPDH Code

078899


local handling for spdh_060404

Documents