IFSF H2H Interface v1.32

Document name ........... IFSF Host to Host interface version 1.32.doc Last saved date ................................................................. 2008-09-10 Revision number.................................................................................1 Printed date ....................................................................... 2008-09-19 Part Number 3-20

Document title

IFSF Host to Host InterfaceSection Page

IntroductionVersion no. Prepared by Date Approved by Date

2/104

1.0 1.1 1.2draft 1.3 1.31 1.32

BMC BMC IMTB IMTB IMTB IMTB

24/04/2002 01/07/2002 08/12/2005 06/01/2006 03/08/2007 10/09/2008

Change History24/04/2002 Version 1.0 First draft of document

24/04/2002

Version 1.1

Amendments as a result of detailed discussions with card issuers. Endorsed by the IFSF meeting 26/06/2002

08/12/2005

Version 1.2 Draft

Endorsed by EFT working group meetings but never formally published.

05/01/2006

Version 1.3

Second formal release of IFSF document Inclusion of EMV functionality Inclusion of ec-debit outdoor functionality Inclusion of new functionality for loyalty, discounts, additional balances, tax and booking/settlement date. Minor corrections and code additions

03/09/2007

Version 1.31

Addition of DE 54 Minor updates

10/09/2008

Version 1.32

Moved Mixed OLTC to Appendix Minor corrections and additions

10 Sep 2008 version 1.32

Part No 3-20

Document title


Introduction

3/104

Table of Contents1 INTRODUCTION.................................................................................................................7 1.1 Glossary of Terms .................................................................................................................... 7 1.2 Context ................................................................................................................................... 10 1.3 References .............................................................................................................................. 11 1.4 Scope ...................................................................................................................................... 11 TRANSACTION OVERVIEW............................................................................................13 2.1 Card Transactions ................................................................................................................... 13 2.2 Administrative Transactions................................................................................................... 15 2.3 Reconciliation......................................................................................................................... 15 2.4 Network Management ............................................................................................................ 16 IMPLEMENTATION SCENARIOS....................................................................................18 3.1 Online Authorisation .............................................................................................................. 18 3.2 Online Authorisation and Transaction Capture ...................................................................... 19 3.3 Central Product Control.......................................................................................................... 20 3.4 Loyalty Data ........................................................................................................................... 20 3.5 Finance Only Cards ................................................................................................................ 20 3.6 ICC Data................................................................................................................................. 21 3.7 Security................................................................................................................................... 21 3.8 Pass-through Data................................................................................................................... 22 MESSAGE FLOWS ..........................................................................................................23 4.1 Outdoor POS-OIL FEP-Acquirer/card issuer Message Flow (OLTC) ................................... 24 4.2 Indoor POS OIL FEP-Acquirer/card issuer Message Flow (OLTC/OLA)............................. 32 4.3 Outdoor POS-OIL FEP-Acquirer/card issuer Message Flow (OLA) ..................................... 38 4.4 Outdoor POS-OIL FEP-Acquirer/card issuer Message Flow (Mixed) ................................... 42 4.5 Indoor POS OIL FEP-Acquirer/card issuer Message Flow (Mixed) ...................................... 45 DATA ELEMENT DEFINITIONS ......................................................................................49 5.1 Attribute specification ............................................................................................................ 49 5.2 Message Control Data Elements (BIT 48 - reserved for private use) ..................................... 49 5.3 Product sets and message data (BIT 62 - reserved for private use) ....................................... 53 5.4 Product data - Industry specific (BIT 63 - reserved for private use)...................................... 53 5.5 (BIT 63 - RESPONSE MESSAGES) ..................................................................................... 55 5.6 Cardholder account identification........................................................................................... 59 5.7 Card acceptor identification.................................................................................................... 59 5.8 Currency code mandatory value (BIT 49) .............................................................................. 59 5.9 EMV related data (BIT 55).................................................................................................... 59 5.10 Proprietary reconciliation totals (BIT 123)............................................................................. 61 5.11 Other fields ............................................................................................................................. 61 MESSAGE CONTENT ......................................................................................................62 6.1 Authorization messages .......................................................................................................... 63 6.2 Financial transaction messages............................................................................................... 71 6.3 Reversal messages .................................................................................................................. 79 6.4 Reconciliation control messages............................................................................................. 83 6.5 Network management messages............................................................................................. 86

2

3

4

5

6

APPENDIX A ACCEPTABLE VALUES FOR DATA ELEMENTS..........................................89 A.1 BIT 3 Processing Code ........................................................................................................... 89 A.2 BIT 22 Point of Service Data Code ........................................................................................ 90 A.3 BIT 24 Function Code ............................................................................................................ 94


Part No 3-20

Document title


Introduction A.4 A.5 A.6 A.7 A.8

4/104

BIT 25 Message Reason Code................................................................................................ 94 BIT 26 Card Acceptor Business Code.................................................................................... 96 BIT 39 Action Code ............................................................................................................... 96 BIT 48-8-2 Customer data ..................................................................................................... 99 BIT 54 Amounts, Additional ................................................................................................ 100

APPENDIX B PRODUCT CONTROL ....................................................................................102 B.1 Central Product Control........................................................................................................ 102 B.2 Customer Product Restrictions ............................................................................................. 102 APPENDIX C ADDITIONAL INFORMATION........................................................................104 C.1 Mixed OLA and OLTC ........................................................................................................ 104


Part No 3-20

Document title


Introduction

5/104

TABLES Table 1 Glossary terms ......................................................................................................................... 7 Table 2 Message overview ................................................................................................................. 13 Table 3 Administrative message overview......................................................................................... 15 Table 4 The rules for accrual of Transaction Amounts in reconciliations .......................................... 15 Table 5 Rules for the accrual of Reversal Transaction Amounts in reconciliations ........................... 16 Table 6 Message control data elements (BIT 48) ............................................................................... 50 Table 7 Hardware and software configuration data elements............................................................. 50 Table 8 Customer data elements......................................................................................................... 51 Table 9 Key management data values ................................................................................................ 52 Table 10 Cryptographic algorithm data values................................................................................... 52 Table 11 Allowed product sets and message data .............................................................................. 53 Table 12 Data elements for product data ............................................................................................ 54 Table 13 ICC System Related Data (FIELD 55) ................................................................................ 60 Table 13 Data elements for proprietary reconciliation total ............................................................... 61 Table 14 Data element usage classification codes.............................................................................. 62 Table 15 Authorization request (1100)............................................................................................... 64 Table 16 Authorization request response (1110) ................................................................................ 66 Table 17 Authorization transaction advice (1120).............................................................................. 68 Table 18Authorization transaction advice response (1130)................................................................ 70 Table 19 Financial transaction request (1200).................................................................................... 72 Table 20 Financial transaction request response (1210)..................................................................... 74 Table 21 Financial transaction advice (1220)..................................................................................... 75 Table 22 Financial transaction advice response (1230) ...................................................................... 78 Table 23 Reversal advice (1420) ........................................................................................................ 80 Table 24 Reversal advice response (1430) ......................................................................................... 82 Table 25 Reconciliation advice (1520)............................................................................................... 84 Table 26 Reconciliation advice response (1530) ................................................................................ 85 Table 27 Network management advice (1820)................................................................................... 87 Table 28 Network management advice response (1830) .................................................................... 88


Part No 3-20

Document title


Introduction

6/104

FIGURES Figure 1 Outdoor Sale Message Flow ..................................................................................... 24 Figure 2 Customer Aborts Outdoor Sale ................................................................................. 28 Figure 3 Normal Indoor Sale Message Flow ........................................................................... 32 Figure 4 Customer Aborts Indoor Sale .................................................................................... 34 Figure 5 OIL FEP Stands-in for acquirer/card issuer .............................................................. 36 Figure 6 OLA Outdoor Sale Message Flow............................................................................. 38 Figure 7 Customer Aborts Outdoor Sale (OLA) ...................................................................... 40 Figure 8 Mixed Outdoor Sale Message Flow .......................................................................... 42 Figure 9 Customer Aborts Sale (Mixed) .................................................................................. 44 Figure 10 Mixed Indoor Sale Message Flow ........................................................................... 46 Figure 11 OIL FEP Stand-in (Mixed) ....................................................................................... 47


Part No 3-20

Document title


Introduction

7/104

1 Introduction1.1 Glossary of Terms The following terms are used extensively in this document:

Table 1 Glossary termsTerm ANSI AAC AC Acquirer Description American National Standards Institute Application Authentication Cryptogram Application Cryptogram Institution that receives card transactions from a retailer switching transactions out for authorisation by a third party. It also refers to a third party who switches card transactions to a card issuer for Authorisation. ARPC ARQC BIN Authorisation Request Response Cryptogram Authorisation Request Cryptogram Bank Identification Number. First part of PAN identifies type of card and issuing bank or other organisation. List of all stopped card numbers (of a particular card type). Transaction should not be allowed on these cards and liability for losses accepted on blocked cards lies with the merchant. Bank Note Acceptor. A machine that accepts notes as payment. Institution that issues cards and authorises transactions on behalf on its portfolio. They are switched to by acquirers. Card Reader in Dispenser. This equates to an outdoor payment terminal (OPT) per pump. Cardholder Verification Method Data Encryption Standard. An algorithm or encryption method commonly used for creating, encrypting, decrypting and verifying card PIN data. Depends on secret keys for security. Increased key length increases security. Normally 64 bits, of which 56 are effective. Derived Unique Key Per Transaction. Encryption method where the secret key used changes with each transaction. More secure method than the predecessor, zone keys. Electronic Funds Transfer. Card transaction or plastic money. Also includes loyalty card transaction. Europay, Mastercard, Visa. Organisation formed by 3 members to promote new standards for ICC.

Blocklist

BNA

Card Issuer

CRIND

CVM DES

DUKPT

EFT

EMV


Part No 3-20

Document title


Introduction Term FEP

8/104 Description Front End Processor. A computer used to respond to card authorisation requests and capture card sales data. In this document it specifically refers to a computer that manages a POS terminal population on behalf of an acquirer.

HSM

Hardware Security Module. A tamper-proof box that may be attached to the FEP or part of a PIN pad. Contains secret keys used for PIN verification, encryption, MAC'ing and other security related purposes. Integrated Circuit Cards. Chip or Smart cards containing a microprocessor. Interface Device Indoor Payment Terminal. Card reader and PIN pad indoors attached to or part of a POS. International Standards Organisation. ISO standard for Financial transaction (card originated) interchange. First part of PAN which identifies card type. International Standards Organisation (ISO) allocates codes to different organisations for their use. Final (check) digit of PAN. Used to ensure PAN recorded correctly and detect false cards. Retailer who has card acceptance agreement with an OilFEP/host (or sometimes directly with an issuer). If merchant follows card acceptance rules he is guaranteed settlement for the value of card transaction. Message Authentication Code. A code generated from the message by use of a secret key, which is known to both sender and receiver. The code is appended to the message and checked by the receiver. Term that refers to Financial Transactions that are verified and authorised on the FEP.. Not on-us is used to denote transactions that are routed elsewhere for authorisation. Outdoor Payment Terminal. Card Reader and (usually) PIN pad outdoors allowing customer to pay in unattended mode. May also contain a BNA. Primary Account Number. Card number, usually 16 or 19 digits. Personal Identification Number. Number linked (normally) to an individual card that is used to verify the correct identity of the user instead of signature verification. Depends on an algorithm such as DES using secret keys.

ICC

IFD IPT

ISO ISO8583

ISO-code

Luhn

Merchant

MAC

On-us

OPT

PAN

PIN


Part No 3-20

Document title


Introduction Term PIN pad Description Numeric keypad for customer to input PIN. Normally integrated with HSM and often with card reader.

9/104

PKE

PAN Key Entry. Recording a card transaction by keying the embossed card details (PAN, expiry date, etc) into the POS to create an electronic transaction even for a card which cannot be swiped eg: because it is damaged. Point of Sale (Terminal) Data fields in the ISO8583 specification for private use to be agreed between the sender and receiver of the message. Transmission Control Protocol/Internet Protocol. A telecomms protocol (standard) for transmission of data between two computers. One of 4 (0, 1, 2, 3) tracks on magnetic stripe of a card. Most commonly used track is Track 2, which contains 37 characters. One of 4 (0, 1, 2, 3) tracks on magnetic stripe of a card. Track 3 is relatively uncommon and mostly used for Bank Debit /ATM cards in some countries like Norway and Germany (or to carry extra customer information to print on receipt). Contains 107 digits. Significantly more secure implementation of DES algorithm and becoming an increasingly common bank requirement. Plaintext is enciphered, deciphered and re-enciphered using 3 different keys. Terminal Verification Results

POS Private fields.

TCP/IP

Track 2

Track 3

Triple DES

TVR


Part No 3-20

Document title


Introduction 1.2 Context

10/104

The objective of this document is to define a Host to Host interface, which adheres to current international standards but fulfils the particular requirements of the Oil industry, which are: Best possible authorisation basis Industry best practice security Central PIN Central product control Support for fuel cards Version 1.2 adds support for EMV whether authorisation is supported centrally or locally. To obtain authorisation of cards that are not authorised on the OilFEP, transactions are routed out to third parties (eg Acquirers or Card issuers). Where accepted by a third party, Oil companies will use the specification defined in this document for Host to Host transactions. This specification is based on the [3]. It is hoped that this specification will also be adopted by IFSF for Oil company host to acquirer/card issuer transactions. The objective is to reduce costs by standardising interfaces.

The principle that underlies this specification and [3] is that all transactions are routed on-line for authorisation and settlement by the appropriate authority. All transaction collection from the POS will be on-line. Offline processing at the POS may only happen in the event that the Oil FEP is not available, however with EMV processing the card/terminal can carry out more checks on the card/cardholder offline which would normally be associated with online processing. It will be limited to those card types where the scheme/Oil FEP/host rules allow it and a business decision has been made to support it. The Oil FEP/Host can support stand-in processing between it and the acquirer/card issuer if allowed. It encompasses the full range of payment cards: Credit cards (e.g. VISA, Mastercard) Debit cards, as required in the countries of operation Charge cards (eg Amex, Diners) Oil company and fuel cards A Point of Sale terminal (POS) at service stations controls pumps and may be linked to both Outdoor Payment Terminals/PIN Pads (OPT, including CRINDs) and their equivalent indoor (IPT). The operation of the OPT dictates the financial requests that it can support. When the customer initiates the sale, the value of the sale is not known, therefore a transaction is sent to reserve funds for a set amount (Authorization Request). When the sale is successfully completed, the POS sends a further transaction to inform the Oil FEP of the actual value of the Sale (Financial Advice). This is what is used to settle the transaction. In the IPT environment the value of the sale is known before the payment transaction is initiated. Therefore, the transaction does not indicate the reservation of funds but that the funds have been spent (Financial Request). In the rare instances when a terminal cannot communicate with the FEP, the terminal may have the capability to continue to process off-line for card types that allow this. When communications are re-established, the terminal can then communicate (store and forward) the transactions it has performed off-line, to the FEP (Financial Advices). To service this terminal context, the facilities to route equivalent transactions from the Oil FEP/host to acquirers/card issuers is required. Similar transactions are required as discussed above, as are appropriate reconciliation facilities.


Part No 3-20

Document title


Introduction

11/104

This interface specification must be sufficiently flexible to support on-line or batch capture by the acquirer/card issuer, or even to phase implementation of transaction capture. This specification can also be used to facilitate a two-way exchange of transactions. That is the Oil FEP sends transactions to an acquirer/card issuer, however the Oil company is also a card issuer and receives transactions from the acquirer. In this case the both roles will apply to the Oil company FEP.

1.3 References This document is based on the following reference documents: [1] Financial Transaction Card Originated Messages Interchange Specifications. ISO 8583 1993 (E), dated 15 December 1993. Message

[2] Implementation Guide for ISO 8583-Based Card Acceptor to Host Messages [2], Part 1 Convenience Store and Petroleum Marketing Industry. ASC X9-TG-23-Part 11999 dated May 20, 1999. [3] IFSF POS to FEP interface version 1.42 Part No 3-18 [4] EMV 2000 Integrated Circuit Card Specification for Payment Systems [5] IFSF Recommended Security Standards for POS to FEP and Host to Host EFT Interfaces. Part No 3-21

These documents are referred to, in the text, by their number contained in square brackets e.g. [1].

1.4 Scope This Host/Host interface is based on the ISO8583 [1] standard and will use TCP/IP and X.25 as the protocols for telecommunications. As a response to difficulties identifying the extent of the message in a TCP/IP environment, it is proposed that there should be a length field (4 bytes, Ascii), which includes everything in the message (from the message identifier to the final field). This is mandatory for TCP/IP only. Please note that this document describes the messages and the message flows between the Hosts. It does not describe: The communications protocol or any other aspect of the communications layer. This protocol is entirely concerned with the logical message interface. The detailed operation and processing of the terminal, except where it is implied by the message flows. The detailed operation of the hosts or the processing of the messages it sends/receives. In this document two terms are used extensively; Oil FEP/host is used to indicate the entity, which has the relationship with the POS. The Oil FEP/host will initiate the transaction to the acquirer/card issuer; the acquirer/card issuer either authorises the transaction or switches out to another authoriser. The acquirer/card issuer provides the response to the Oil FEP/Host . This implementation supports only the following:


Part No 3-20

Document title


Introduction Authorisation Request/Response Authorisation Advice/Response Financial Request/Response Financial Advice/Response Reversal Request/Response Reconciliation Advice /Response Network Management Advice/Response

12/104

[1] supports a variety of other transactions that can be used between an Oil FEP and an acquirer/issuer. These will not be implemented at this time: Chargebacks Administrative messages Fee collection This implementation also supports transmission of loyalty (cash) or other non reimbursable (cash) transactions. PIN change transactions are not supported between the Oil Host/FEP and the acquirer/issuer, even though these transactions are supported at the POS.


Part No 3-20

Document title


Transaction Overview

13/104

2 Transaction OverviewThis chapter describes the transaction set employed by an Oil FEP in a Host to Host interface. 2.1 Card Transactions

Table 2 Message overview Message Description Type1100 Authorization Request

CommentSale; amount not known (Preauthorisation) Original Transaction has timed out Approval or denial

1101

Authorization Request Repeat

1110 1120 1121 1130 1200

Authorization Request Response Authorisation Advice Authorization Advice Repeat Authorization Advice Response Financial Request

Includes Sale Cash Withdrawal Sale and Cashback Returns In all cases the actual value is known

1201

Financial Request Repeat

Original Transaction Response has timed out Approval or denial Sale; amount known (Sale complete) Original Transaction has timed out

1210 1220

Financial Request Response Financial Advice

1221

Financial Advice Repeat

1230 1420 1421

Financial Advice Response Reversal Advice Reversal Advice Repeat

Reverse a preceding transaction Original Transaction has timed out

1430

Reversal Response

The terminal initiates an 1100 Authorization Request to the Oil FEP to reserve funds on the customers chosen payment card. An 1100 authorisasion request in this environment mean an outdoor payment. The amount that is reserved is dependent on local circumstances therefore the POS must either send a default amount from the POS or a zero amount. In the


Part No 3-20

Document title



14/104

case of a zero amount a default is added at the Oil FEP before it is routed to the acquirer/card Issuer. The 1110 Authorization Request Response is received from the acquirer/card issuer indicating whether the funds are available. Ideally the response from the acquirer/card issuer should indicate the amount of funds available for the transaction so that the pump may limit the sale to this amount. However if the response only indicates an approval or denial, in the case of an approval the sale can continue to the POS, but the Oil FEP must implement a limit (either at the FEP in the response to the POS or at the POS). If it is declined, a decline is returned to the terminal. An 1110 may also contain a list of valid fuel grades when central product control is used. If so the POS restricts fuelling to only these. When the customer has completed the sale and the value is known a 1220 Financial Advice is sent to the Oil FEP to confirm the details of the transaction. The FEP cannot decline this advice except for limited technical reasons. In an on-line transaction capture environment, the 1220 Financial Advice is routed to the acquirer/card issuer. This cannot be declined (unless there are format problems). In a batch capture environment the 1220 Financial Advice remains on the Oil FEP to be included in the transaction capture batch. In the current indoor sales environment in Europe, the value of the transaction is known before the customer tenders their payment card. In this case it is possible to inform the acquirer/card issuer of the exact value of the sale so the customer can be debited using a 1200 Financial Request transaction. In the case of a 4 message EMV transaction (see [3] a non-reimbusable 1200 message (code 17) would be used from the POS to OIL FEP. This 1200 (code 17) would either be sent to the Host as is or rebuilt as an 1100 message and sent to the Host. This specification caters for both options. As well as the normal data required for card authorisation; the product codes that comprise the sale are also passed to the Oil FEP (BIT 63) for all card types. These can be passed on to the acquirer/card issuer to enable central product control used for all fuel and oil company cards. Depending on the card used, 1200 Financial Request is routed to the appropriate destination for authorization. The acquirer/card issuer approves or declines the full amount and all products. Partial approvals for 1200 Financial Requests will not be supported in this interface. When denied due to illegal products the codes of the legal products are returned in the response. Where codes (eg product codes) are passed from the Oil FEP to the acquirer/card issuer, it is assumed that the same code set is used in the response. In some circumstances, e.g. where a customer aborts the sale, it is necessary for the Oil FEP to reverse transactions to the acquirer/card issuer so that any allocation of funds is reversed. This is achieved by use of a 1420 Reversal Advice. Where the Oil FEP times out the acquirer/card issuer response, a repeat message can be sent. This is exactly the same as the original message except for the message identifier (1101, 1201, 1221, and 1421). When the acquirer/card issuer receives this message it will send the same response as it sent for the original, assuming it received the original. If it did not, it processes the repeat as a new transaction. Where this response is also timed out by the Oil FEP a further repeat can be sent, if no response is received to this, the it will assume there is a failure in communication and initiate Stand-in procedures. Stand-in depends on commercial bi-lateral agreements between the Oil FEP and acquirer/card issuer and is not discussed further in this document. Subsequent transactions will attempt delivery to the acquirer/card issuer. This means if the acquirer/card issuer is off-line for a period of time transactions will still retry. Where parties agree, the retry count can be varied by parameter (including zero). Approved transactions that take place at the Oil FEP as a result of Stand-in can be delivered to the acquirer/card issuer via a store and forward mechanism, using 1220 messages.


Part No 3-20

Document title



15/104

Approved authorisations that take place at the Oil FEP as a result of Stand-in can be delivered to the acquirer/card issuer via a store and forward mechanism, using 1120 messages if the acquirer/card issuer requires them. 2.2 Administrative Transactions

Table 3 Administrative message overviewMessage Type 1520 Description Reconciliation Advice Comment Transfer totals from the Oil FEP/host to the acquirer/card issuer Original Transaction has timed out To transfer encryption keys and to check status Original Transaction has timed out

1530 1521

Reconciliation Advice Response Reconciliation Advice Repeat

1820 1830 1821

Network Management Advice Network Management Response Network Management Advice Repeat

2.3 Reconciliation 1520 Reconciliation Advice is the transaction that is used to verify that all the transactions that have been sent since the last Reconciliation are present at the acquirer/card issuer. The Reconciliation Advice contains the totals accumulated by the Oil FEP/host since the last Reconciliation. The Oil FEP/host initiates the Reconciliation Advice. If the acquirer/card issuer uses the same method of accumulation it should get the same results. The value in BIT 4 (Amount, Transaction) in the response from the acquirer/card issuer is used in the accumulation, if this field is always the same currency. If there is not a common transaction currency a reconciliation currency can be identified. Reconciliation takes place in that currency. Each transaction will include BIT 5 (Amount, Reconciliation). This will be accumulated rather than the Amount, Transaction. The rules are as follows:

Table 4 The rules for accrual of Transaction Amounts in reconciliationsMessage Type Identifier 1200 1200 1200 1200 1200 1200 Processing Code 00 Sale 01 Cash withdrawal 09 Sale with Cashback 17 Cash Sale (private value) 20 Returns 28 Returns Credits Amt BIT 86 Debits Amt BIT 88 Total Net Card BIT 123-1 Total Net Loy Cash BIT 123-2


Part No 3-20

Document title


Transaction Overview Message Type Identifier 1220 1220 1220 1220 1220 1220 Processing Code (Private Value) 00 Sale 01 Cash with 09 Sale with Cashback 17 Cash Sale (private value) 20 Returns 28 Returns (Private Value) Credits Amt BIT 86 Debits Amt BIT 88 Total Net Card BIT 123-1

16/104 Total Net Loy Cash BIT 123-2

Similarly, with reversals:

Table 5 Rules for the accrual of Reversal Transaction Amounts in reconciliationsMessage Type Identifier 1420 1420 1420 1420 Processing Code Credits, Reversal Amt BIT 87 Debits, Reversal Amt BIT 89 Total Net Card BIT 123-1 Total Net Loy Cash BIT 123-2

1420 1420

00 Sale 01 Cash withdrawal 09 Sale with Cashback 17 Cash Sale (private value) 20 Returns 28 Returns (Private Value)

This example assumes that the POS only operates in one currency. Where a POS operates in more than one currency then a Reconciliation Advice is required for each currency. An alternative method of reconciliation would be a reconciliation for each acquirer id. 1100 Authorisation Request/Response are not accumulated to the reconciliation Amounts. BIT 97 Amount, Net Reconciliation is calculated by netting the debit and credit. (Credits less Debits; contents of BIT (86 + 87) BIT (88 + 89). This is as per [1] 4.4.11. Repeat messages are not added to the totals. Counts are consistent with the tables above (eg Reversals have their own counts BIT 75 and 77). BIT 123-1 (Total Reimbursable) is the value that is paid to the retailer. Reconciliation messages do not require reversal.

2.4

Network Management


Part No 3-20

Document title



17/104

After a parameter number of transaction failures to the acquirer/card issuer, the Oil FEP/host will mark the interface as unavailable and immediately go to Stand-in. It can send periodic 1820 messages to check the status of the acquirer/card issuer. When a response is received it can mark the link as available again. There may be a requirement to use Network Management messages to transport encryption keys. The Network Management message can also be used to allow each entity using the interface to inform each other of scheduled down time. This allows one entity to send the other a log-off message. This informs the receiver that the link is unavailable until a Network Management message indicating log-on is received. The processes associated with the use of these messages are by bilateral agreement.


Part No 3-20

Document title


Implementation Scenarios

18/104

3 Implementation ScenariosThe purpose of this document is to provide a protocol, which is sufficiently functionally rich to satisfy a variety of Oil FEP/host to acquirer/card issuer interfaces. Whereas the interface between POS and the Oil FEP/host is standard, the Oil FEP/host and acquirer/card issuer can use this specification to tailor the interface to their particular requirements. The transactions that were described in the previous chapter and the private use fields described later can be used in a number of different ways to achieve this objective. These could include: Online authorisation only (OLA) Online authorisation with transaction capture (OLTC) Mixed for the same acquirer/card issuer by terminal (See Appendix C 1) Each of these types can be further tailored for particular functions, including: Central product control Financial cards only Encrypted PINs and Security Pass through data The following sections will describe each in turn.

3.1

Online Authorisation

In this scenario the Oil FEP/host to acquirer/card issuer interface accepts transactions for online Authorisation however transaction capture takes place via an alternative method (e.g batch to legacy systems). The main transactions: Message Type 1100 1101 1110 1120 Description Authorisation Request Authorisation Request Repeat Authorisation Request Response Authorisation Advice Comment Required Required Required Required, if the acquirer/card issuer requires advice of authorisations approved by the Oil FEP while in stand-in mode. As 1120. Required. If acquirer/card issuer supports them in an Authorisation only environment. 1200 from the POS may be converted to 1100 to the acquirer/card issuer. Required. As 1200. Required. As 1200. Not required but may be used to maintain velocity control totals on acquirer if link to issuer is lost. Pre-authorisation completions and terminal approved (offline) transactions are captured via an alternative method Not required. As above.

1130 1200

Authorisation Advice Response Financial Request

1201 1210 1220

Financial Request Repeat Financial Request Response Financial Advice

1221

Financial Advice Repeat


Part No 3-20

Document title


Implementation Scenarios Message Type 1230 1420 1421 1430 1520 1521 1530 1820 1830 Description Financial Advice Response Reversal Advice Reversal Advice Repeat Reversal Advice Repeat Reconciliation Advice Reconciliation Advice Repeat Reconciliation Advice Response Network Management Advice Network Management Advice Response Comment Not required. As above.

19/104

Required Required Required Not required. Reconciliation is performed via the alternative capture interface. Not required. As above. Not required. As above. Optional Optional

3.2

Online Authorisation and Transaction Capture

In this scenario the Oil FEP/host to acquirer/card issuer interface accepts transactions for online Authorisation. Transaction capture also takes place via this interface. The main transactions: Message Type 1100 1101 1110 1120 Description Authorisation Request Authorisation Request Repeat Authorisation Request Response Authorisation Advice Comment Required Required Required Required, if the acquirer/card issuer requires advice of authorisations approved by the Oil FEP while in stand-in mode. As 1120. Required Required Required Required Required Required Required Required Required Required Required Required Optional

1130 1200 1201 1210 1220 1221 1230 1420 1421 1430 1520 1521 1530 1820

Authorisation Advice Response Financial Request Financial Request Repeat Financial Request Response Financial Advice Financial Advice Repeat Financial Advice Response Reversal Advice Reversal Advice Repeat Reversal Advice Repeat Reconciliation Advice Reconciliation Advice Repeat Reconciliation Advice Response Network Management Advice


Part No 3-20

Document title


Implementation Scenarios Message Type 1830 Description Network Management Advice Response Comment Optional

20/104

3.3 Central Product Control This interface supports all the fields necessary for the fuel card issuer to perform central product control on there own system. This allows issuers to have product restriction checking totally under their own control based on the latest information. The following fields are used for this option: Field 62-1 63 Description Allowed product sets Product data Comment See section 5.3 for a further description See section 5.4 for a further description Used in transaction 1110, 1210 1200, 1220

If required the option is implemented as follows: The 1110 Authorisation Response from the acquirer/card issuer can contain the Product Codes of those fuel products that card issuer deems as valid for this card (ie taken from the card issuers positive card). These are passed on by the OIL FEP to the POS. The POS then enforces only selection of those valid products (see Appendix B Product Control for more information). The 1200 Financial Request that is sent to the acquirer/card issuer for approval could contain the Product Codes of the sale. The acquirer/card issuer can then validate the products and approve or decline the transaction on that basis. If the transaction is declined, the acquirer/card issuer can send back in the response the valid Product Codes. The 1220 Financial Advice that is sent to the acquirer/card issuer contains the Product Codes of the sale that has taken place.

If an acquirer/card issuer has cards with product restrictions and opts not to implement Central Product Control, product restriction checking must continue to be done by the POS or the Oil FEP/hostbased on the contents of the Magnetic stripe or integrated circuit on the card.

3.4 Loyalty Data This interface supports all the fields necessary to support certain forms of loyalty processing. 63 Loyalty data See section 5.4 for a further description 1110, 1210, 1230

3.5

Finance Only Cards

For those acquirer/card issuers who do not require central product control and who are not fuel card issuers/acquirer a number of specific fields can be omitted. These include:


Part No 3-20

Document title


Implementation Scenarios Field Description Comment

21/104 Used in transaction

48-8

Customer data

48-9

Track 2 for second card

48-37

Vehicle identification mode Pump linked indicator

48-38

62-1

Allowed product sets

63

Product/Loyalty data

Used for fuel cards. Not required for finance only cards. Used for second card in a transaction. Not required for finance only cards. Used for second card in a transaction. Not required for finance only cards. Used for fuel cards. Not required for finance only cards. Used for central product control. Not required for finance only cards. Used for central product control and loyalty functions. Not normally required for finance only cards.

1100, 1120, 1200, 1220

1100, 1120, 1200, 1220

1100, 1120, 1200, 1220

1100, 1120, 1200, 1220

1110, 1210

1110, 1200, 1210,1220, 1230

3.6 ICC Data This specification can be used to transmit to the acquirer/card issuer, both transactions including ICC (chip/smart card) data and for those that only include magnetic stripe data depending on the requirements of the acquirer/card issuer. ICC data will be contained within field 55 and where applicable is mapped to existing fields . Transactions may or may not include it depending on bilateral agreement with the acquirer/card issuer. The layout for field 55 is shown in the message content section of this specification

3.7 Security The preferred method of security between the POS and the Oil FEP/host is Visa DUKPT. Ideally there will be a separate key management zone between the Oil FEP/host and the acquirer/card issuer, using Master/Session key management. However security arrangements between an Oil FEP/host and an acquirer/card issuer are subject to bilateral agreement and may encompass particular card scheme rules. The detailed requirements will be identified in separate documents and not this specification.

The possible options for security within transactions are: Option MAC but no PIN Comments No encrypted PIN block included in transactions. The following fields are not required: Field 48-14 Field 52 PIN encryption methodology PIN

The following fields are conditional (on the key management): Field 53 Security related control information


Part No 3-20

Document title


Implementation Scenarios Option Comments Field 48-40 Encryption parameter

22/104

No PIN or MAC

No key management associated with the transactions. The following fields are not required: Field 48-14 PIN encryption methodology Field 52 PIN Field 53Security related control information Field 48-40 Encryption parameter Field 64 Message authentication code Field 128 Message authentication code (extended bit map)

PIN and no MAC

No MAC but the transaction contains an encrypted PIN block. This is not a recommended option. The following fields are not required: Field 64 Field 128 Message authentication code Message authentication code (extended bit map)

The following fields are conditional (on the method of key management): Field 53 Security related control information Field 48-40 Encryption parameter PIN and MAC Encrypted PIN and MAC are present in the transaction: The following fields are conditional (on the method of key management): Field 53 Security related control information Field 48-40 Encryption parameter The following field is conditional (on the presence of a secondary bit map): Field 128 Message authentication code (extended bit map)

The data that is MACed is agreed between the parties. See [5] for further information 3.8 Pass-through Data A potential scenario is that the agreement with the acquirer/card issuer may be that Oil FEP/host switches through transactions received from the POS without change. This is not recommended as it has some implications: Acquirer/card issuer must mirror the Oil FEP terminal identification data. The fields would relate to an individual POS, so cannot be used to validate the Oil FEP/host to acquirer/card issuer interface (for example, field 7 date and time transmission, field 11 Systems trace audit number). May cause difficulties with reconciliation. Field 48-4 Batch/sequence number cannot be used to determine the transactions included within a 1520 Reconciliation Advice as the field will relate to the POS. Another mechanism must be used for this purpose. May reduce security, as there must be a single zone between the POS and the acquirer/card issuer. Data that is totally irrelevant to the acquirer/card issuer is in the transaction.

The layouts described in chapter 6 indicate which fields normally contain unchanged data from the POS.


Part No 3-20

4 Message FlowsThis chapter describes the message flows between the POS, Oil FEP/host and acquirer/card issuer in selected cases. For the main transactions the chapter is split between OPT, IPT and other messages. Offline Indoor/Outdoor Sale Message Flow Offline authorised sales (indoors or outdoors) simply use a 1220/1230 message pair to deliver transactions from the Host to Host. Since advice messages may not be reversed, only complete and irrevocable transactions are sent (eg: signature verification, if used, must be complete).

POS Transaction approval sent to issuer.1220 Financial Adv

FEP Transaction sent to issuer/acquirer1230 Financial Advice Resp

Host

Tx completed

Acknowledge Advice

1220 Financial Advice

Transaction processed1230 Financial Advice Resp

Acknowledge Advice

The above case assumes that for a transaction indoors or outdoors the terminal has processed the transaction offline and produced a Transaction Certificate. This would be sent in the 1220 message to the FEP which would in turn send the advice to the host.

Document title


Message Flows

24/104

4.1 4.1.1 POS

Outdoor POS-OIL FEP-Acquirer/card issuer Message Flow (OLTC) Normal Online Outdoor Sale Message Flow OIL FEP1100 Authorization Request

Acquirer/Issuer

Customer initiates Transaction

If Response indicates Approved continue otherwise finish When Sale is complete, confirm amount

Customer selected or default Amount (POS or FEP) routed to the appropriate Authorizer

1100 Authorization Request

Process authn

1110 Auth Request Response

1110 AuthRequest Response


Response to Funds Reservation (from information received from the Issuer or with our own velocity rules) Amount to be debited from customer; route to Acquirer/Issuer. But respond to the POS first (cannot decline) Acknowledge Advice

Response to Funds Reservation (approved, full or partial amount)

1230 Financial Advice Response

Sale completed


Replace approval amount with captured amount


Acknowledge Advice

Complete

Figure 1 Outdoor Sale Message Flow


Part No 3-20

Document title


Message Flows

25/104

Notes: 1. This implies a slight reformatting of the message between Oil FEP/host and Acquirer/card issuer. The following fields are different: BIT 7 Date and time of transmission (time of transaction transmission to the issuer) BIT 11 STAN (Oil FEP/host to issuer specific STAN) BIT 41/42 Terminal IDs(may have specific values for the acquirer/card issuer ie different from the POS to Oil FEP/host interface) BIT 52 PIN Data (changed into the acquirer/card issuers zone key) BIT 64 recalculated 2. There may be additional fields between Oil FEP/host and acquirer/card issuer (eg fees, reconciliation amounts) The Oil FEP/host cannot decline an advice from the POS (except for purely technical reasons eg Mac failure). Similarly, if the link is operating correctly, the acquirer/card issuer cannot decline an advice from an Oil FEP/host (except for the same technical reasons). The acquirer/card issuer cannot decline on commercial grounds. Since an advice simply records what has happened (eg the customer may have already left)


Part No 3-20

Document title


Message Flows

26/104

4.1.2

Online Outdoor Sale Message Flow standin

In this case the OIL FEP will stand in for the Acquirer/Issuer.

POSCustomer initiates Transaction Response indicates an approval or a decline When sale complete confirm the amount in the financial advice 1100 Authorization Request

OIL FEPTx routed to appropriate authorizer No response received before timeout Retry sent times out. Oil FEP stands in for the card issuer. When link available, advise issuer of the approvals that have taken place while link was down (store and forward) 1230 response can be sent to the POS prior to sending 1220 to issuer/acquirer

Acquirer/Issuer


1110 Authorization Response


Sale completed



Issuer receives a financial advice from the Oil FEP. Issuer updates customer accounts


Complete

Ack received 1220

Figure 2 Outdoor Sale Message Flow Standin


Part No 3-20

Document title


Message Flows

27/104

Notes: 3. This implies a slight reformatting of the message between Oil FEP/host and Acquirer/card issuer. The following fields are different: BIT 7 Date and time of transmission (time of transaction transmission to the issuer) BIT 11 STAN (Oil FEP/host to issuer specific STAN) BIT 41/42 Terminal IDs(may have specific values for the acquirer/card issuer ie different from the POS to Oil FEP/host interface) 4. There may be additional fields between Oil FEP/host and acquirer/card issuer (eg fees, reconciliation amounts) 5. The Oil FEP/host cannot decline an advice from the POS (except for purely technical reasons eg Mac failure). Similarly, if the link is operating correctly, the acquirer/card issuer cannot decline an advice from an Oil FEP/host (except for the same technical reasons). The acquirer/card issuer cannot decline on commercial grounds. Since an advice simply records what has happened (eg the customer may have already left) 6. The POS may send a zero amount except for an EMV transaction where a non zero amount would be used. 7. If after receiving an approval the card subsequently declines the transaction a reversal must be sent.


Part No 3-20

Document title


Message Flows

28/104

4.1.3 Customer Aborts Outdoor Sale before authorisation received The following shows the message flow for an outdoor sale transaction aborted by the customer where the response to the 1100 Authorization Request has not been received. POSCustomer initiates transaction Customer aborts transaction; Reversal is sent Response is discarded if it arrives after the Reversal has been sent.1100 Authorization Request

OIL FEPDefault Amount (POS or FEP) routed to the appropriate Authorizer1420 Reversal Advice

Acquirer/Issuer


Process authn

1110 Authorization Request Response

Reverse the Request if approved. If Response has not been sent discard


Response to Funds Reservation (approved, full or partial amount?)

1430 Reversal Advice Response

Acknowledge Advice1420 Reversal Advice

Transaction completed

Send reversal Advice to Issuer/Acquirer1430 Reversal Advice Response

Reverse the Reservation of funds.

Acknowledge Advice

Figure 3 Customer Aborts Outdoor Sale The same rules on re-tries apply to a 1420 Reversal Advice that is reversing an 1100 Authorization Request, as for any other transaction. Though no customer billing takes place as a result of the 1100, funds are reserved, and best practice dictates that every effort should be made to free up those funds. In this scenario it is possible that the POS will receive the 1110 Authorization Request Response even after the 1420 Reversal Advice has been sent. In this case the POS will ignore the 1110 response. If the Oil FEP/host has not generated a 1110 Authorization Request Response by the time it receives the 1420 Reversal Advice it need not send it, but must act on what that response indicated.


Part No 3-20

Document title


Message Flows

29/104

If the acquirer/card issuer's response to the 1100 Authorisation Request was a decline, and it was received by the Oil FEP/host before the 1420 Reversal Advice was received from the POS, the Oil FEP/host need not forward the 1420 Reversal Advice to the Acquirer/card issuer. However if the Oil FEP/host does forward it the acquirer/card issuer must be able to handle it correctly. In the interests of efficient processing, the Oil FEP/host can respond to the 1420 Reversal Advice from the POS before a response is received from the Issuer (ie the acquirer's response to the POS is not dependent on the acquirer/card issuer's response to the acquirer). The customer cannot abort the transaction once the pump is enabled. However the customer can put the nozzle back to complete the transaction without taking any fuels so it is possible to have a zero value 1220 Financial Advice. The POS must deliver a 1220 to the Oil FEP, who must deliver an equivalent advice to the acquirer/issuer.


Part No 3-20

Document title


Message Flows

30/104

4.1.4

Customer Aborts Outdoor Sale after authorisation received

The following shows the message flow for an outdoor sale transaction aborted by the customer where the response to the 1100 Authorization Request has not been received.

POSCustomer initiates transaction1100 Authorization Request

OIL FEPDefault Amount (POS or FEP) routed to the appropriate Authorizer1110 Authorization Request Response

Acquirer/Issuer


Process authn

Response is processed.

Response is passed through to POS


Customer aborts transaction; Reversal is sent Transaction completed


1420 Reversal Advice

Reverse the Request if approved. Acknowledge Advice Send reversal advice to issuer/acquirer Complete1420 Reversal Advice




Acknowledge Advice

Figure 4 Customer Aborts Outdoor Sale The same rules on re-tries apply to a 1420 Reversal Advice that is reversing an 1100 Authorization Request, as for any other transaction. Though no customer billing takes place as a result of the 1100, funds are reserved, and best practice dictates that every effort should be made to free up those funds. In this scenario it is possible that the POS will receive the 1110 Authorization Request Response even after the 1420 Reversal Advice has been sent. In this case the POS will ignore the 1110 response.


Part No 3-20

Document title


Message Flows

31/104

If the Oil FEP/host has not generated a 1110 Authorization Request Response by the time it receives the 1420 Reversal Advice it need not send it, but must act on what that response indicated. If the acquirer/card issuer's response to the 1100 Authorisation Request was a decline, and it was received by the Oil FEP/host before the 1420 Reversal Advice was received from the POS, the Oil FEP/host need not forward the 1420 Reversal Advice to the Acquirer/card issuer. However if the Oil FEP/host does forward it the acquirer/card issuer must be able to handle it correctly. In the interests of efficient processing, the Oil FEP/host can respond to the 1420 Reversal Advice from the POS before a response is received from the Issuer (ie the acquirer's response to the POS is not dependent on the acquirer/card issuer's response to the acquirer). The customer cannot abort the transaction once the pump is enabled. However the customer can put the nozzle back to complete the transaction without taking any fuels so it is possible to have a zero value 1220 Financial Advice. The POS must deliver a 1220 to the Oil FEP, who must deliver an equivalent advice to the acquirer/issuer.


Part No 3-20

Document title


Message Flows

32/104

4.2 4.2.1

Indoor POS OIL FEP-Acquirer/card issuer Message Flow (OLTC/OLA) Normal Indoor Sale Message Flow

The following shows the message flow for a normal indoor sale transaction and a two message EMV transaction. POSCustomer tenders card as payment for a transaction of known amount If Response indicates Approved continue otherwise ask customer for an alternative means of payment.1200 Financial Request

OIL FEPTransaction routed to appropriate authoriser1210 Financial Request Response 1200 Financial Request

Acquirer/card issuerTransaction routed to appropriate authorizer

Respond to the POS based on the card issuer's response

1210 Financial Request Response

Request is approved or declined; if approved its approved for the full amount. If approved; the issuer for the transaction bills customer.

Figure 5 Normal Indoor Sale Message FlowWhere acquirer/card issuer systems cannot support Financial Requests in a OLA environment then these transactions are converted into Authorisation Requests by the Oil FEP.


Part No 3-20

Document title


Message Flows 4.2.2 Indoor Four message flow (EMV specific)

33/104

A four message solution uses a (non-reimbursable) 1200/1210 (using processing code 17) between the POS and the Oil FEP, followed by a normal (reimbursable) 1220/1230). Between the Oil FEP and the Acquirer/Issuer this 1200/1210 non reimbursable message can be used or reconstructed as an 1100 message in order to avoid reconciliation problems.

POSCustomer initiates Transaction from card non zero amount) Response indicates an approval or a decline 1200 Financial Request

OIL FEPRouted to the appropriate Authoriser As 1100 or 12001210 Financial Request Response 1100Authorisation Request or 1200 Financial Request(code 17)

Acquirer/IssuerProcess authn Response to Funds Reservation approved, full or partial amount)

Pass response to POS as 1210

1110 Auth Request Response or 1210 Financial Request Response

When sale complete confirm the amount in the financial advice


Acknowledge Advice1230 Financial Advice Response

Tx complete

Send acknowledge to POS Send Advice to appropriate Authoriser Complete1220 Financial Advice



Acknowledge Advice

In this case the transaction has to be confirmed to the issuer by sending a 1220 advice with the TC (accept). If present script results would also be included in the 1220. If declined the POS will send a non reimburable 1420 (reversal) for the non-reimbursable 1200 (request). In the case of a refund a non reimbursable 1200 (code 28) would be used followed by a reimbursable 1220.


Part No 3-20

Document title


Message Flows 4.2.3 Customer Aborts Indoor Four message flow (EMV specific)

34/104

Customer Aborts Indoor 4 message Sale before authorisation received The following shows the message flow for an indoor sale transaction aborted by the customer where the response to the 1200 Financial Request has not been received.POSCustomer initiates transaction Customer aborts transaction; Reversal is sent Response is ignored as it arrives after the Reversal has been sent. Transaction completed 1200 (code 17) Fin ancial Req Transaction routed to appropriate authorizer Oil FEP sends response to POS Oil FEP reverses Request transaction to the card issuer Acknowledge Advice (before receiving response from issuer) Send reversal Advice to issuer/acquirer Completed 1420 Reversal Advice Card Issuer reverses request and responds to reversal advice

OIL FEP1100Authorisation Request or 1200 Financial Request(code 17) 1110 Auth Request Response or 1210 Financial Request Response

Acquirer/card issuerIssuer approves or denies transaction And responds to the acquirer


1210 Financial Request Response 1430 Reversal Advice

1430 Reversal Advice Response Acknowledge Advice

Figure 6 Customer Aborts Indoor Sale


Part No 3-20

Document title


Message Flows

35/104

The same rules on re-tries apply to a 1420 Reversal Advice that is reversing a 1200 Financial Request, as for any other transaction. In this case it is essential to reverse as the customer will be billed by the acquirer/card issuer for this transaction In this example the POS receives the 1210 Financial Request Response after the 1420 Reversal Advice has been sent. In this case the POS will ignore the response. If the Oil FEP/host has not generated a 1210 Financial Request Response by the time it receives the 1420 Reversal Advice it need not send it, but must act on what that response indicated.


Part No 3-20

Document title


Message Flows 4.2.4 Acquirer/card issuer not available OIL FEP/host stands-in

36/104

The following shows the message flow for an indoor sale transaction aborted by the customer where the response to the 1200 Financial Request has not been received.POS1200 Financial Request Customer initiates transaction Response is received Transaction completed 1210 Financial Request Response Transaction routed to appropriate authorizer No response received before timeout Retry sent the Issuer Retry times out. Oil FEP stands in for the card issuer (or declines). Oil FEP responds to the POS If STIP, when link available, advise issuer of the approvals that have taken place while link was down (store and forward) 1220 Financial Advice Issuer receives a financial advice from the Oil FEP. Issuer updates customer accounts.

OIL FEP1200 Financial Request

Acquirer/card issuer

1201 Financial Request Retry


Figure 7 OIL FEP Stands-in for acquirer/card issuer

If the Oil FEP/host does not stand-in for the acquirer/card issuer, the Oil FEP/host must respond with a decline after a parameter number of retries to the issuer have been exceeded (or a refer to card issuer, if appropriate and supported). When the maximum number of retries to the issuer is exceeded, the Oil FEP/host can initiate a series of 1820 Network Management messages till a response is received from the issuer. This will enable the Oil FEP/host to go to stand-in processing without the delay of the retries. When an


Part No 3-20

Document title


Message Flows

37/104

1830 Network Management Response is received from the issuer, indicating that communications have been restored, normal processing can be resumed. In an OLA environment no 1220 will be sent to the acquirer/card issuer. The transaction will be captured as part of separate settlement arrangements. Where the Oil FEP and acquirer/card issuer support stand-in in an OLA environment and only Authorisation Requests are sent to the acquirer/card issuer, the facility to use Authorisation Advices (1120) is available.


Part No 3-20

Document title


Message Flows

38/104

4.3 4.3.1 POS

Outdoor POS-OIL FEP-Acquirer/card issuer Message Flow (OLA) Normal Outdoor Sale Message Flow (OLA) OIL FEP1100 Authorization Request

Acquirer/Issuer

Customer initiates Transaction If Response indicates Approved continue otherwise finish When Sale is complete, confirm amount

Default Amount (POS or FEP) routed to the appropriate Authorizer Response to Funds Reservation (from information received from the Issuer or with our own velocity rules) Acknowledge Advice


Process authn





Sale completed


Send Acknowledge to POS Send Advice to issuer/acquirer1220 Financial Advice



Complete

Acknowledge Advice

Figure 8 OLA Outdoor Sale Message Flow


Part No 3-20

Document title


Message Flows

39/104

Notes: This implies a slight reformatting of the message between Oil FEP/host and Acquirer/card issuer. The following fields are different: BIT 7 Date and time of transmission (time of transaction transmission to the issuer) BIT 11 STAN (Oil FEP/host to issuer specific STAN) BIT 41/42 Terminal IDs(may have specific values for the acquirer/card issuer ie different from the POS to Oil FEP/host interface) BIT 52 PIN Data (changed into the acquirer/card issuers zone key) BIT 64 recalculated Where the 1220 from the POS indicates that the sale was less than authorised by the acquirer/card issuer, the customer has less available funds than they should. It must be agreed between the Oil FEP and the acquirer/card issuer what should happen in an OLA environment. There are a number of alternatives: - Oil FEP does nothing - correction made at acquirer/card issuer during batch clearing - Oil FEP sends a reversal for the difference. - Oil FEP sends an 1100 message with a replacement value. For this option there must be sufficient information from the original 1110 response for the acquirer/card issuer to replace the original transaction (reverse the previous, add this one).


Part No 3-20

Document title


Message Flows

40/104

4.3.2

Customer Aborts Outdoor Sale (OLA)


POSCustomer initiates transaction Customer aborts transaction; Reversal is sent Response is discarded if it arrives after the Reversal has been sent. Transaction completed1100 Authorization Request

OIL FEPDefault Amount (POS or FEP) routed to the appropriate Authorizer1420 Reversal Advice 1100 Authorization Request

Acquirer/IssuerProcess authn




Response to Funds Reservation (approved, full or partial amount?)


Acknowledge Advice1420 Reversal Advice

Send reversal advice to issuer/acquirer Complete



Acknowledge Advice

Figure 9 Customer Aborts Outdoor Sale (OLA)


Part No 3-20

Document title


Message Flows

41/104

The same rules on re-tries apply to a 1420 Reversal Advice that is reversing an 1100 Authorization Request, as for any other transaction. Though no customer billing takes place as a result of the 1100, funds are reserved, and best practice dictates that every effort should be made to free up those funds. In this scenario it is possible that the POS will receive the 1110 Authorization Request Response even after the 1420 Reversal Advice has been sent. In this case the POS will ignore the 1110 response. If the Oil FEP/host has not generated a 1110 Authorization Request Response by the time it receives the 1420 Reversal Advice it need not send it, but must act on what that response indicated. If the acquirer/card issuer's response to the 1100 Authorisation Request was a decline, and it was received by the Oil FEP/host before the 1420 Reversal Advice was received from the POS, the Oil FEP/host need not forward the 1420 Reversal Advice to the Acquirer/card issuer. However if the Oil FEP/host does forward it the acquirer/card issuer must be able to handle it correctly. In the interests of efficient processing, the Oil FEP/host can respond to the 1420 Reversal Advice from the POS before a response is received from the Issuer (ie the acquirer's response to the POS is not dependent on the acquirer/card issuer's response to the acquirer). The customer cannot abort the transaction once the pump is enabled. However the customer can put the nozzle back to complete the transaction without taking any fuels so it is possible to have a zero value 1220 Financial Advice. The POS must deliver a 1220 to the Oil FEP, who must deliver an equivalent advice to the acquirer/issuer.


Part No 3-20

Document title


Message Flows

42/104

4.4 4.4.1 POS

Outdoor POS-OIL FEP-Acquirer/card issuer Message Flow (Mixed) Normal Outdoor Sale Message Flow (mixed) OIL FEP1100 Authorization Request

Acquirer/Issuer

Customer initiates Transaction

Default Amount (POS or FEP) routed to the appropriate Authorizer


Process authn

If Response indicates Approved continue otherwise finish


When Sale is complete, confirm amount

Response to Funds Reservation (from information received from the Issuer or with our own velocity rules) Amount to be debited from customer; route to Acquirer/Issuer. But respond to the POS first (cannot decline)





Replace approval amount with captured amount if OLTC only Acknowledge Advice



Sale completed

Action code indicating OLA or OLTC

Figure 10 Mixed Outdoor Sale Message

Flow

Notes: This implies a slight reformatting of the message between Oil FEP/host and Acquirer/card issuer. The following fields are different: BIT 7 Date and time of transmission (time of transaction transmission to the issuer) BIT 11 STAN (Oil FEP/host to issuer specific STAN) BIT 41/42 Terminal IDs(may have specific values for the acquirer/card issuer ie different from the POS to Oil FEP/host interface)


Part No 3-20

Document title


Message Flows

43/104

BIT 52 PIN Data (changed into the acquirer/card issuers zone key) BIT 64 recalculated There may be additional fields between Oil FEP/host and acquirer/card issuer (eg fees, reconciliation amounts) for OLTC The Oil FEP/host cannot decline an advice from the POS (except for purely technical reasons eg Mac failure). Similarly, if the link is operating correctly, the acquirer/card issuer cannot decline an advice from an Oil FEP/host (except for the same technical reasons). The acquirer/card issuer cannot decline since an advice simply records what has happened (eg the customer may have already left)


Part No 3-20

Document title


Message Flows 4.4.2 Customer Aborts Outdoor Sale (Mixed)

44/104


POSCustomer initiates transaction Customer aborts transaction; Reversal is sent Response is discarded if it arrives after the Reversal has been sent.1100 Authorization Request

OIL FEPDefault Amount (POS or FEP) routed to the appropriate Authorizer1420 Reversal Advice

Acquirer/Issuer


Process authn




Response to Funds Reservation (approved, full or partial amount) Reverse the Reservation of funds.


Transaction completed


Acknowledge Advice


Acknowledge Advice

Figure 11 Customer Aborts Sale (Mixed) The same rules on re-tries apply to a 1420 Reversal Advice that is reversing an 1100 Authorization Request, as for any other transaction. Though no customer billing takes place as a result of the 1100, funds are reserved, and best practice dictates that every effort should be made to free up those funds. In this scenario it is possible that the POS will receive the 1110 Authorization Request Response even after the 1420 Reversal Advice has been sent. In this case the POS will ignore the 1110 response.


Part No 3-20

Document title


Message Flows

45/104

If the Oil FEP/host has not generated a 1110 Authorization Request Response by the time it receives the 1420 Reversal Advice it need not send it, but must act on what that response indicated. If the acquirer/card issuer's response to the 1100 Authorisation Request was a decline, and it was received by the Oil FEP/host before the 1420 Reversal Advice was received from the POS, the Oil FEP/host need not forward the 1420 Reversal Advice to the Acquirer/card issuer. However if the Oil FEP/host does forward it the acquirer/card issuer must be able to handle it correctly. In the interests of efficient processing, the Oil FEP/host can respond to the 1420 Reversal Advice from the POS before a response is received from the Issuer (ie the acquirer's response to the POS is not dependent on the acquirer/card issuer's response to the acquirer). The customer cannot abort the transaction once the pump is enabled. However the customer can put the nozzle back to complete the transaction without taking any fuels so it is possible to have a zero value 1220 Financial Advice. The POS must deliver a 1220 to the Oil FEP, who must deliver an equivalent advice to the acquirer/issuer in a mixed environment. Th acquirer/card issuer will acknowledge the advice depending on whether OLA or OLTC. Where acquirer/card issuer systems cannot support Financial Requests in an OLA environment then the Oil FEP converts these transactions into Authorisation Requests.


Part No 3-20

Document title


Message Flows 4.5 4.5.1 Indoor POS OIL FEP-Acquirer/card issuer Message Flow (Mixed) Normal Indoor Sale Message Flow (Mixed)

46/104

The following shows the message flow for a normal indoor sale transaction. POSCustomer tenders card as payment for a transaction of known amount If Response indicates Approved continue otherwise ask customer for an alternative means of payment.1200 Financial Request

OIL FEPTransaction routed to appropriate authoriser1210 Financial Request Response 1200 Financial Request

Acquirer/card issuerTransaction routed to appropriate authorizer

Respond to the POS based on the card issuer's response Settlement method with acquirer/card issuer indicated by Action Code.

1210 Financial Request Response

Request is approved or declined; if approved its approved for the full amount.

Action code indicating OLA or OLTC

Figure 12 Mixed Indoor Sale Message Flow


Part No 3-20

Document title


Message Flows 4.5.2 Acquirer/card issuer not available OIL FEP/host stands-in (Mixed)

47/104

The following shows the message flow for an indoor sale transaction aborted by the customer where the response to the 1200 Financial Request has not been received, where the environment is mixed OLA and OLTC.POS1200 Financial Request Customer initiates transaction Response is received Transaction completed 1210 Financial Request Response Transaction routed to appropriate authorizer No response received before timeout Retry sent the Issuer Retry times out. Oil FEP stands in for the card issuer (or declines). Oil FEP responds to the POS If STIP, when link available, advise issuer of the approvals that have taken place while link was down (store and forward) OLA settled separately 1220 Financial Advice Issuer receives a financial advice from the Oil FEP. Issuer updates customer accounts. Action code indicating OLA or OLTC

OIL FEP1200 Financial Request

Acquirer/card issuer

1201 Financial Request Retry


Figure 13 OIL FEP Stand-in (Mixed)

If the Oil FEP/host does not stand-in for the acquirer/card issuer, the Oil FEP/host must respond with a decline after a parameter number of retries to the issuer have been exceeded (or a refer to card issuer, if appropriate and supported). When the maximum number of retries to the issuer is exceeded, the Oil FEP/host can initiate a series of 1820 Network Management messages till a response is received from the issuer. This will enable the Oil FEP/host to go to stand-in processing without the delay of the retries. When an


Part No 3-20

Document title


Message Flows

48/104

1830 Network Management Response is received from the issuer, indicating that communications have been restored, normal processing can be resumed. In an OLA environment though 1220 will be sent to the acquirer/card issuer, the transaction will be captured as part of separate settlement arrangements. Where acquirer/card issuer systems cannot support Financial Requests in an OLA environment then the Oil FEP can send Authorisation Advices rather than Financial Advices.


Part No 3-20

5 Data Element DefinitionsThe data elements used in this standard conform to the definitions specified in ISO 8583 [1] with minor exceptions as described below. The use of the data elements may vary slightly from [1] but the use is clearly described. The conventions for using specific data elements are described in this section. Three data elements that are designated for private use in [1] (BITs 48, 63 and 123) and are used to provide information for the control of the message from the POS to the FEP and for Oil industry specific information. These data elements have a variable length structure that contains a series of data elements with specific code values. The code values are defined in Appendix A. The message control data element (BIT 48) provides information concerning the operation of the POS and any information about a customer that is collected manually. This data element was designed for use with other industry specific standards. The industry requires the ability to report product data to the host for individual transactions. This is provided as a separate data element (BIT 63). Proprietary reconciliation totals (bit 123) provide the ability for industry specific totals. 5.1 Attribute specification The data element format is specified in terms of the data element attributes - the representation, length and explicit or implied structure. Conventions have been established for the values of certain data elements. These attributes and conventions are defined in [1]. In addition, this standard provides for variable length fields less than 10 characters long. This format is denoted LVAR and has a single digit length field (see LLVAR and LLLVAR in [1]). The following conventions shall be applied to all data elements: All fixed length numeric data element values shall be right justified with leading zeroes. All fixed length data elements with alphabetic or special characters shall be left justified with trailing blanks. All fixed length binary data elements shall be right justified with leading zeroes. The position of a character or a bit in a data element shall be counted from the left beginning with one (1). The format of the Track 2 (BIT 35) and Track 3 (BIT 36) data elements is 'ns,' which is different from ISO 8583 where format 'z' is used. All data in this standard is either in a character representation (n, ns, an, anp, ans or x) or in a binary field (b).

5.2 Message Control Data Elements (BIT 48 - reserved for private use) The following data elements have been defined for the control of messages between the POS and the FEP. These are present in field 48 as a variable content data element. It uses a standard bit map to identify the specific data elements present in field 48. The format is LLLVAR with a maximum length of 999. The 8 byte bit map is the first itOil (element 48-0) in the data element. The data elements specified in the bit map are presented below:

Document title


Data Element Definitions

50/104

Table 6 Message control data elements (BIT 48)Element number 48-0 Data element name Bit map Format b Attribute Description 8 Specifies which data elements are present. 20 Software version information Only used for Network Management messages, no validation. 2 Language used for display or print. Values according to ISO 639 10 Current settlement /batch number, used to group a number of transactions for reconciliation between FEP/Host and the card issuer 9 Conditional, parameters to control multiple transaction messages (not required) ..250 Data entered by customer or cashier ..37 Used to specify the second card in a transaction for oil company two card schemes 2 Used to identify the type of encryption methodology. The coding is implementation specific. 8 May be booking period number or date ..91 These are reserved for future use. 1 Indicates how the vehicle identity has been determined: 0 - Manual entry 1 - On the card 1 Indicates whether the fuel pump reading is linked to the payment terminal: 0 - Unspecified 1 - Pump-linked 2 - Pump not linked 10 Number allocated by the terminal given to the customer 8 Conditional - if card scheme requires it. ..99 Implementation specific

48-2

Hardware & software configuration

ans

48-3

Language code

a

48-4

Batch/sequence number

n

48-7

Multiple transaction control

n

48-8 48-9

Customer data Track 2 for second card

LLLVAR ans LLVAR ns

48-14

PIN encryption methodology

ans

48-15 48-16 to 48-32 48-37

Settlement period Reserved for future use Vehicle identification entry mode

n LLVAR ans ans

48-38

Pump linked indicator

n

48-39 48-40 48-41 to 48-64

Delivery note number Encryption parameter Reserved for propriety use

n b LLVAR ans

5.2.1

Hardware and software configuration (element 48-2)

This data element provides information on the current version software. This is often very useful in determining processing actions at the FEP/host or acquirer/card issuer.

Table 7 Hardware and software configuration data elementsElement number 48-2-1 48-2-2 48-2-3 Data element name Hardware level Software level EPROM level Format ans ans ans Attribute 4 Description Not relevant for FEP to card issuer interface 8 Current version of terminal software. 8 Not relevant for FEP to card issuer interface

The following example provides the terminal information as descri

IFSF H2H Interface v1.32

Documents

host interfacesection

generate ac

security methods

key management

card scheme

booking period

card readerpin

proprietary