Confidential December 2011 Page 1 of 144

IFSF POS – EPS Implementation Guidelines

Work Team IFSF EFT Working Group - EPS/POS interface
Work File Location N/A
Document Status First version
Document Version 1.05
Author(s) Paolo Magnoni, Shell Oil Products
Contributor(s) Reiner Kramer, Wincor Nixdorf
Markus Heuser, Thales-eTransaction
Sharon Scace, BP Deutschland
Paul Wilson
Wolfgang Lührsen, BP Deutschland
Louis Jenny, Ingenico
John Carrier, Shell Europe Oil products
Marek Kosinski, Shell Europe Oil products
Bradford Loewy, VeriFone

Composition Date 28 December 2011

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 2 of 144

COPYRIGHT AND INTELLECTUAL PROPERTY RIGHTS STATEMENT

The content (content being images, text or any other medium contained within this document which is eligible of
copyright protection) is Copyright © IFSF Ltd 2011. All rights expressly reserved.

You may print or download to a local hard disk extracts for your own business use. Any other redistribution or
reproduction of part or all of the contents in any form is prohibited.

You may not, except with our express written permission, distribute to any third party.

Where permission to distribute is granted by IFSF, the material must be acknowledged as IFSF copyright and the
document title specified. Where third party material has been identified, permission from the respective copyright holder
must be sought.

You agree to abide by all copyright notices and restrictions attached to the content and not to remove or alter any such
notice or restriction.

USE OF COPYRIGHT MATERIAL

Subject to the following paragraph, you may design, develop and offer for sale products which embody the functionality
described in this document.

No part of the content of this document may be claimed as the Intellectual property of any organisation other than IFSF
Ltd, and you specifically agree not to claim patent rights or other IPR protection that relates to:

the content of this document; or

any design or part thereof that embodies the content of this document whether in whole or part.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 3 of 144

DOCUMENT REVISION SHEET

Version Release Date Details Editor

01 00 25/07/2005 First final version P.Magnoni

01 01 10/05/2006 Revision after IFSF EFT WG meeting on 15 February 2006 M.Kosinski

01 02 08/09/2006 Revision after IFSF EFT WG meeting on 31 May 2006 M.Kosinski

01 03 05/11/2006 Revision after IFSF EFT WG meeting on 19 September 2006 M.Kosinski

01 04 15/04/2007 Revision after IFSF EFT WG meeting on 09 May 2007 M.Kosinski

01 05 28/12/2011 Copyright and IPR Statement added IFSF Admin

Version Releas Detail

e
01 01 Added section 08 “Transaction Identification and Linking”. Base on proposal submitted by Louis Jenny, Wolfgang
Luehrsen, Sharon Scace and Paul Wilson
Added section 09 “POS-EPS Coding-Decoding Rules Base on proposal submitted by Louis Jenny, discuss and
updated on EFT WG meeting.
Added appendix B4 “IFSF Lite Serial Transport Protocol”.
Corrected minor typing errors.
Updated schema diagrams.
01 02 Added section 10 “Loyalty Rabats”. Base on proposal submitted by Louis Jenny, Wolfgang Luehrsen

01 03 Added section 11 “ POS-EPS Version Identification” Base on proposal submitted by John Carrier, Nick
Bradshaw, Marek Kosinski
Added section 12 “Soft Key Solution” Base on proposal submitted by Bradford Loewy
Updated section 3.5 to reflect changes DeviseRequest schema.
Updated section 3.2 to reflect changes to ServiceRequest schema.
01 04 Updated section xx with new POS-EPS Lite Tag’s
Added section 13 “Force Draft Capture” base on proposal submitted by Wolfgang Luehrsen and Sharon Scace
Updated section 3.1 to reflect changes to Card Request for FDC and Cash back function
Added section 14 “Device Proxy Extension” base on proposal submitted by Niessen Heinz
Updated section 3.5 with clarification about Text Line – Erase attribute
Added section 4.9 “XML Encoding”
Added section 4.10 “Boolean Values”
Added section 17. CONFIGURABLE RECONCILIATION FORMATS
01 05 Copyright and IPR Statement added

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 4 of 144

Table of Content
1. INTRODUCTION ....................................................................................................................................................................7

2. ERRATA CORRIGE ............................................................................................................................................................... 7

3. POS EPS INTERFACE XML SCHEMA UPGRADE ............................................................................................................9

3.1 XML SCHEMA - EPS/POS: CARDSERVICEREQUEST .............................................................................................................9
3.2 XML SCHEMA - EPS/POS: CARDSERVICERESPONSE ......................................................................................................... 17
3.3 XML SCHEMA - EPS/POS: SERVICEREQUEST .................................................................................................................... 23
3.4 XML SCHEMA - EPS/POS: SERVICERESPONSE .................................................................................................................. 26
3.5 XML SCHEMA – EPS OR POS / DEVICE PROXY: DEVICEREQUEST ...................................................................................... 30
3.6 XML SCHEMA – EPS OR POS / DEVICE PROXY: DEVICERESPONSE ................................................................................ 3534
4. POS EPS IMPLEMENTATION RULES .......................................................................................................................... 4034
4.1 EPS ADDRESSING.......................................................................................................................................................... 4234
4.2 EPS BACK-UP ................................................................................................................................................................ 4234
4.3 DEVICE STATE TABLE..................................................................................................................................................... 4234
4.4 ARCHITECTURE IMPLEMENTATION AND CONFIGURATION ................................................................................................ 4334
Interface configuration......................................................................................................................................................... 4534
Application Configuration .................................................................................................................................................... 4534
4.5 APPLICATION ISSUES...................................................................................................................................................... 4634
Receipt ................................................................................................................................................................................. 4634
4.6 TRANSPORT .................................................................................................................................................................. 4634
4.6.1 Implementation ..................................................................................................................................................... 4734
4.6.2 Flows and error-handling ..................................................................................................................................... 4834
4.7 CONFIGURATION UPDATE .............................................................................................................................................. 5334
4.8 SW UPDATE .................................................................................................................................................................. 5334
4.9 XML ENCODING............................................................................................................................................................ 5434
4.10 BOOLEAN VALUES ........................................................................................................................................................ 5434
5. POS EPS TESTING INTEROPERABILITY RULES ..................................................................................................... 5534
Example – Receipt................................................................................................................................................................ 5534
Example – Flow for an indoor payment ................................................................................................................................ 5734
6. ADDITIONAL IMPLEMENTATION EXAMPLES ........................................................................................................ 5934
6.1 PRINTING CARD RECEIPTS .............................................................................................................................................. 5934
6.2 TRACK DATA CODING .................................................................................................................................................... 5934
6.3 SWIPE AHEAD ............................................................................................................................................................... 6034
6.4 DEVICEREQUEST FOR MENU .......................................................................................................................................... 6134
6.5 DEVICEREQUEST / EVENT .............................................................................................................................................. 6234
6.6 SERVICEREQUEST / ADMINISTRATION ............................................................................................................................ 6334
6.7 SCENARIO OF HAVING THE SALES/TRANSACTION DETAILS CHANGING DEPENDING ON THE CARD SWIPED........................... 6334
7. EXAMPLE OF IMPLEMENTATION FOR OUTDOOR PAYMENT TERMINAL ..................................................... 6334
7.1 COPT ........................................................................................................................................................................... 6434
7.2 CRID PAYMENT PROCESS.............................................................................................................................................. 6534
7.3 OPT PAYMENT PROCESS ............................................................................................................................................... 6634
7.4 CARDPREAUTHORIZATIONLOYALTYSWIPE (CRID) ....................................................................................................... 6734
Loyalty + Payment ............................................................................................................................................................... 6734
Payment only........................................................................................................................................................................ 6834
7.5 CARDPREAUTHORIZATION (OPT).................................................................................................................................. 6934
Loyalty + Payment ............................................................................................................................................................... 6934
Payment only........................................................................................................................................................................ 7034

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 5 of 144

7.6 LOYALTY SWIPE (CRID + OPT) .................................................................................................................................... 7134

7.7 CARDFINANCIALADVICE (CRID) .................................................................................................................................. 7134
7.8 CARDFINANCIALADVICE (OPT) .................................................................................................................................... 7234
7.9 TICKET PRINT (CRID + OPT)......................................................................................................................................... 7334
7.10 POS EPS XML INTERFACE ........................................................................................................................................... 7334
CardPreAuthorizationLoyaltySwipe Request ........................................................................................................................ 7334
CardPreAuthorizationLoyaltySwipe Response ...................................................................................................................... 7434
CardFinancialAdvice Request .............................................................................................................................................. 7534
CardFinancialAdvice Response ............................................................................................................................................ 7634
CardFinancialAdviceLoyaltyAward ...................................................................................................................................... 7734
CardFinancialAdviceLoyaltyAward Response ...................................................................................................................... 7834
LoyaltySwipe Request ........................................................................................................................................................... 7934
LoyaltySwipe Response......................................................................................................................................................... 7934
Abort Request....................................................................................................................................................................... 8034
Outdoor Events .................................................................................................................................................................... 8034
Device Request Printer status ............................................................................................................................................... 8334
7.11 OPT WITH DIFFERENT FUNCTIONS DEPENDING ON THE CARD SWIPED .............................................................................. 8434
8. POS-EPS TRANSACTION IDENTIFICATION AND LINKING .................................................................................. 8434
8.1 DEFINITIONS ................................................................................................................................................................. 8434
8.2 TRANSACTION IDENTIFICATION BY THE POS .................................................................................................................. 8534
8.3 TRANSACTION IDENTIFICATION BY THE EPS .................................................................................................................. 8534
8.4 USE CASE ...................................................................................................................................................................... 8534
8.4.1 Single Payment or Loyalty Transaction, Single Message ....................................................................................... 8534
8.4.2 Single Payment, PreAuthoryzation ........................................................................................................................ 8634
8.4.3 Multiple Payments, Split Tenders .......................................................................................................................... 8634
8.4.4 Reversal Resulting from an Exception ................................................................................................................... 8734
8.4.5 Reference to a Previous Split Tenders ................................................................................................................... 8734
8.4.6 Reference to a Previous Unique Transaction ........................................................................................................ 8834
8.4.7 Refund Transaction Reference .............................................................................................................................. 8834
9. POS-EPS CODING-DECODING RULES ........................................................................................................................ 8934
9.1 XML MESSAGE DECODING MODEL ............................................................................................................................... 8934
9.2 XML MESSAGE CODING DECODING .............................................................................................................................. 8934
9.3 LITE MESSAGE CODING DECODING ................................................................................................................................ 9034
10. LOYALTY REBATES ................................................................................................................................................... 9034
10.1 STANDARD REBATES PROCESSING ................................................................................................................................. 9034
10.2 OTHER REBATE PROCESSING ......................................................................................................................................... 9134
10.3 EXAMPLES .................................................................................................................................................................... 9334
11. POS-EPS VERSION IDENTIFICATION ..................................................................................................................... 9534

12. SOFT KEY SOLUTION ................................................................................................................................................ 9534

12.1 ATTRIBUTES OF THE SOFTKEY ELEMENT ........................................................................................................................ 9534
12.2 TRANSACTION FLOW FOR SOFT KEY PROMPTING ........................................................................................................... 9634
Example Soft Key Prompt..................................................................................................................................................... 9634
12.3 ADDITIONAL NOTES FOR REQUESTING A CHOICE AMONG DEFINED KEYS ....................................................................... 9734
Example Soft Key Style Request for Device Not Using Soft Keys: ......................................................................................... 9734
12.4 EXCEPTION PROCESSING FAQ ....................................................................................................................................... 9934
13. FORCE DRAFT CAPTURE .......................................................................................................................................... 9934
13.1 FDC USE CASES ............................................................................................................................................................ 9934
14. DEVICE PROXY EXTENSION .................................................................................................................................. 10134

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 6 of 144

14.1 BUTTON FUNCTION ..................................................................................................................................................... 10134

14.2 EXAMPLE FOR BUTTON................................................................................................................................................ 10234
14.3 LED FUNCTION ........................................................................................................................................................... 10334
14.4 EXAMPLE FOR LED ..................................................................................................................................................... 10434
14.5 SCREEN FUNCTION ...................................................................................................................................................... 10434
14.6 EXAMPLE FOR SCREEN ................................................................................................................................................ 10534
14.7 DOOR CONTROL FUNCTION ......................................................................................................................................... 10634
14.8 EXAMPLE FOR DOOR CONTROL ................................................................................................................................... 10734
15. CASH IN DRAWER .................................................................................................................................................... 10834
15.1 BACKGROUND ............................................................................................................................................................. 10834
15.2 CASHAVAILABLE ........................................................................................................................................................ 10834
15.3 POSDATA ELEMENT ................................................................................................................................................... 10834
16. CASH BACK ................................................................................................................................................................ 10934
16.1 CASH BACK IN POST-PAY ............................................................................................................................................. 10934
16.2 CASH BACK IN PRE-PAY............................................................................................................................................... 11034
17. CONFIGURABLE RECONCILIATION FORMATS................................................................................................ 11234
17.1 USE CASE ................................................................................................................................................................... 11334
APPENDIX A TCP/IP BASICS ........................................................................................................................................ 11434
A.1 TCP/IP BASICS ........................................................................................................................................................... 11434
A.2 TCP/IP TRANSMISSION CONTROL PROTOCOL .............................................................................................................. 11534
A.3 IP ADDRESSING ........................................................................................................................................................... 11634
A.4 TCP/IP WORKING PRINCIPLES ..................................................................................................................................... 11734
APPENDIX B IFSF LITE ................................................................................................................................................. 11934
B.1 IFSF LITE DATA CODING............................................................................................................................................. 11934
B.1.1 Introduction ........................................................................................................................................................ 11934
B.1.2 Data Encoding .................................................................................................................................................... 12334
B.1.3 Tag Encoding ..................................................................................................................................................... 12334
B.1.4 Length Encoding ................................................................................................................................................. 12434
B.1.5 Value Encoding .................................................................................................................................................. 12534
B.2 IFSF LITE MESSAGE CODING ....................................................................................................................................... 12734
B.3 IFSF LITE DATA DICTIONNARY ................................................................................................................................... 13334
B.4 IFSF LITE SERIAL TRANSPORT PROTOCOL ................................................................................................................... 13834
B.4.1 Protocol Usage Context ...................................................................................................................................... 13834
B.4.2 Protocol Specification......................................................................................................................................... 13934
B.4.3 Protocol State Table ........................................................................................................................................... 14134

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 7 of 144

1. INTRODUCTION

This document summarises the standard implementation of the IFSF interface; the document gives for granted the
content of the bibliography, so those documents must be read together with this to clarify the specification.
This document considers valid the same hypotheses assumed for the ISO8583 implementation.

Topics covered:
*) Error corrections
*) Extensions as discussed in this analysis
*) More examples for illustration of the interface application, including a generic device state table
*) Testing high level guidelines
*) Implementation rules: high level on the applications and more detailed about the layers lower than application level.

2. ERRATA CORRIGE

3.11 Part A - use case: (loyalty) card balance inquiry

Use case 3.11 - In 7. "both card" are authorized, but in this use case there is only one
card and no authorization. In 10 was referring to PIN change instead of balance inquiry.
The flow must be replaced with the following:

1. Customer brings the loyalty card to the POS to get the balance.
2. Cashier at the POS or the customer himself at the OPT/CRIND selects the Loyalty balance inquiry functionality.
3. If POS fails, the process is aborted and the cashier has to recover the POS (OPT/CRIND not available until that).
4. POS passes to EPS the request of loyalty balance inquiry.
5. If message invalid, it is repeated or the process is aborted and the cashier receives a specific alarm. POS is still at
the initial status.
6. EPS gets loyalty card data
7. EPS authorises the card request (not relevant where or how this is performed).
a. EPS asks for additional data
b. EPS performs any check/functionality according to card/configuration/system status
c. EPS provides the Loyalty balance to be printed.
8. If EPS gets into an exception status, transaction not possible to complete, the transaction gives a negative
response.
9. If POS fails to receive a response from EPS (EPS failure), the transaction is considered as a negative response.
10. If EPS tells POS the loyalty balance response, but POS has failed (e.g. fails to get the acknowledge) the
process is aborted and the cashier has to recover the POS (OPT/CRIND not available until that).
11. If completed, EPS tells POS the loyalty card balance result (positive or negative).
12. If successful and receipt available, the Customer takes the loyalty Ticket.
13. If available, POS is back to normal sale status (same for OPT/CRIND).

3.12 Part A - use case: Loyalty card link

The use case is about loyalty card link, but in 11 a PIN change response is mentioned.
The flow must be replaced with the following:

1. Customer brings the loyalty card and payment card to the POS/OPT/CRIND to link them.
2. Cashier at the POS or the customer himself at the OPT/CRIND selects the functionality.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 8 of 144

3. If POS fails, the process is aborted and the cashier has to recover the POS (OPT/CRIND not available
until that).
4. POS requests to EPS the link to loyalty operation.
5. If message invalid, it is repeated or the process is aborted and the cashier receives a specific alarm. POS
is still at the initial status.
6. EPS gets loyalty card data
7. EPS gets payment card data
8. EPS authorises both card (not relevant where or how this is performed).
a. EPS asks for additional data
b. EPS performs any check/functionality according to card/configuration/system status
c. EPS provides the confirmation to be printed.
9. If EPS gets into an exception status, transaction not possible to complete, the transaction gives a
negative response.
10. If POS fails to receive a response from EPS (EPS failure), it is up to an exception procedure to
understand if the link was successful or not.
11. If EPS tells POS the Link to loyalty response, but POS has failed (e.g. fails to get the
acknowledge) it is up to an exception procedure to understand if the link was successful or not.
12. If completed, EPS tells POS the link result (positive or negative).
13. If available POS (OPT/CRIND) is back to normal status.

5.3 Examples of Card Service Request / Response

Example 1 - the simplest payment

The total amount in the request is 50.00, in the response it is 50.50, while it should
be 50.00 as in the request.

5.3 Examples of Card Service Request / Response

Example 10, LoyaltyBalanceQuery

The response shown in the example is just a copy of the request. Replace with the
following:

Request:

<CardServiceRequest RequestType="LoyaltyBalanceQuery" WorkstationID="POS01" RequestID="01254"

xmlns="http://www.nrf-arts.org/IXRetail/namespace" xmlns:IFSF="http://www.ifsf.org/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=“.\CardRequest.xsd">
<POSdata>
<POSTimeStamp>2002-04-07T18:39:09-08:00</POSTimeStamp>
</POSdata>
<Loyalty LoyaltyFlag="true"/>
</CardServiceRequest>

Response:

<CardServiceResponse RequestType="LoyaltyBalanceQuery" WorkstationID="POS01" RequestID="01254"

OverallResult="Success" xmlns="http://www.nrf-arts.org/IXRetail/namespace" xmlns:IFSF="http://www.ifsf.org/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=“.\CardRequest.xsd">
<Terminal TerminalID="01215034001" TerminalBatch="000126" STAN="125684"/>
<Loyalty LoyaltyFlag="true" LoyaltyTimeStamp="2002-04-07T18:40:18-08:00">
<LoyaltyCard LoyaltyPAN="7004125632144612"/>
<LoyaltyApprovalCode LoyaltyAcquirerID="102002" LoyaltyAcquirerBatch="03050121214">
1002111025</LoyaltyApprovalCode>
</Loyalty>
</CardServiceResponse>

3.7 Part A - use case: Indoor card payment ticket reprint

The outdoor ticket reprint functionality might be used also outdoor.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 9 of 144

Replace the sentence with the following:

The ticket print from the POS journal is POS functionality, so no use case is necessary; also the POS sale receipt copy
reprint is a POS functionality.

The ticket re-print for an Outdoor self-service operation is unusual so it is not included in the Use Case.

The Use case describes the functionality requiring the card to be swiped to identify the
customer and receive the copy of the receipt. This is not a mandatory process, but just
an example.
Replace the Brief Description with the following:

The customer comes back to the cashier requesting a copy of the (POS) EFT receipt.
The cashier verifies the customer right for the request (in the example within the use case, this process requires
swiping the card used in the original transaction; this is not a mandatory process) and select the POS functionality.
The receipt is printed (probably with some specific text on it) and given to the customer.

3. POS EPS INTERFACE XML SCHEMA UPGRADE

3.1 XML schema - EPS/POS: CardServiceRequest

See Appendix for the proper XSD schema specification. Below is summarised the logic of the data and some examples
in the following paragraphs.

element

POS request for service to EPS; the possible requests are identified by the required attribute RequestType:
CardServiceRequest value Comment
CardPayment Payment only.
 TotalAmount mandatory.
 SalesItems: optional (depending on the cards accepted by the system; if any fleet card
with product restrictions, then it becomes mandatory).
 Loyalty: no.
 OriginalTransaction: no.
CardSwipe Generic request for reading a card.
 TotalAmount: no.
 SalesItems: no.
 Loyalty: no.
 OriginalTransaction: no.
LoyaltySwipe Loyalty only necessary for reading the card.
 TotalAmount: no.
 SalesItems: no.
 Loyalty: yes (only the flag).
 OriginalTransaction: no.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 10 of 144

CardPaymentLoyaltyAward Payment + loyalty award (this way the MOP rule is possible).
 TotalAmount mandatory.
 SalesItems: optional (depending on the cards accepted by the system; if any fleet card
with product restrictions, then it becomes mandatory).
 Loyalty: optional (when present, either Card PAN or track is present).
 OriginalTransaction: no.
LoyaltyAward Loyalty award only (payment might have been cash or whatever, or separated in a payment
only request; this way no MOP rule is possible).
 TotalAmount mandatory.
 SalesItems: optional (depending on the cards accepted by the system; if any fleet card
with product restrictions, then it becomes mandatory).
 Loyalty: optional (when present, either Card PAN or track is present).
 OriginalTransaction: no.
CardPreAuthorization Outdoor Self-service or even indoor pre-authorization, without loyalty.
 TotalAmount optional (it would provide a specific pre-authorization maximum amount).
 SalesItems: optional
NOTE: the standard implementation compliant with the IFSF ISO8583 does not use
sales items.
 Loyalty: no.
 OriginalTransaction: Usually NO. Only used for Hospitality.
CardFinancialAdvice Actual payment after the Outdoor Self-service or even indoor pre-authorised refilling, without
loyalty. After a succesful CardPreAuthorization, the POS/Sell application handles the
refilling/sale, then the CardFinancialAdvice is triggered to update the EPS process.
 TotalAmount: mandatory.
 SalesItems: optional (depending on the cards accepted by the system; if any fleet card
with product restrictions, then it becomes mandatory).
 Loyalty: no.
 OriginalTransaction: yes – pointing to the pre-authorization.
CardPreAuthorizationLoyaltySwipe Outdoor Self-service or even indoor pre-authorization, without loyalty.
 TotalAmount optional (it would provide a specific pre-authorization maximum amount).
 SalesItems: optional
NOTE: the standard implementation compliant with the IFSF ISO8583 does not use
sales items.
 Loyalty: yes (only the flag).
 OriginalTransaction: Usually NO. Only used for Hospitality.
CardFinancialAdviceLoyaltyAward Actual payment after the Outdoor Self-service or even indoor pre-authorised refilling, without
loyalty. After a succesful CardPreAuthorizationLoyaltySwipe, the POS/Sell application
handles the refilling/sale, then the CardFinancialAdvice is triggered to update the EPS
process.
 TotalAmount: mandatory.
 SalesItems: optional (depending on the cards accepted by the system; if any fleet card
with product restrictions, then it becomes mandatory).
 Loyalty: conditional (when loyalty is swiped in PreAuthorization phase, then it is used
and either Card PAN or track is used).
 OriginalTransaction: yes – pointing to the pre-authorization
LoyaltyRedemption Loyalty redemption only (no payment integrated functionality; this allows only points
redemption or fixed ratio points/cash but coded in the POS and managed separately). The
assumption is that redemption will be on-line and necessary data is in the host.
 TotalAmount: optional (points).
 SalesItems: mandatory (gift codes).
 Loyalty: yes (Card PAN or track optional: mandatory if managed in a separate loyalty
swipe).
 OriginalTransaction: no.
CardPaymentLoyaltyRedemption Loyalty redemption with optional payment integrated functionality; this allows even the ratio
points/money to be decided centrally by the host). The assumption is that redemption will be
on-line and necessary data is in the host.
 TotalAmount: optional (points decided by the customer).
 SalesItems: mandatory (gift codes).
 Loyalty: yes (Card PAN or track optional: mandatory if managed in a separate loyalty
swipe).
 OriginalTransaction: no.
PaymentReversal OriginalTransaction data necessary, no other. Original requested Payment will be reversed.
 TotalAmount: no.
 SalesItems: no.
 Loyalty: no.
 OriginalTransaction: Mandatory

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 11 of 144

PaymentLoyaltyReversal OriginalTransaction data necessary, no other. Original requested Payment and loyalty award
will be reversed.
 TotalAmount: no.
 SalesItems: no.
 Loyalty: no.
 OriginalTransaction: Mandatory
PaymentRefund OriginalTransaction data necessary. Original requested Payment will be refunded according
to the request detail (it might be a partial refund).
 TotalAmount: Mandatory.
 SalesItems: optional (depending on the cards accepted by the system; if any fleet card
with product restrictions, then it becomes mandatory)..
 Loyalty: no.
 OriginalTransaction: Optional (depending if refund is stand-alone or refers to an original
payment transaction).
PaymentLoyaltyRefund OriginalTransaction data necessary. Original requested Payment will be refunded according
to the request detail (it might be a partial refund) and loyalty points awarded on that will be
withdrawn.
 TotalAmount: Mandatory.
 SalesItems: optional (depending on the cards accepted by the system; if any fleet card
with product restrictions, then it becomes mandatory)..
 Loyalty: yes (Card PAN or track optional: mandatory if managed in a separate
loyaltyswipe).
 OriginalTransaction: Optional (depending if refund is stand-alone or refers to an original
payment transaction)
LoyaltyAwardReversal OriginalTransaction data necessary, no other. Original requested Loyalty award will be
reversed.
 TotalAmount: no.
 SalesItems: no.
 Loyalty: no.
 OriginalTransaction: Mandatory
LoyaltyRedemptionReversal OriginalTransaction data necessary, no other. Original requested Loyalty redemption will be
reversed.
 TotalAmount: no.
 SalesItems: no.
 Loyalty: no.
 OriginalTransaction: Mandatory
LoyaltyBalanceQuery Loyalty balance check request.
 TotalAmount no.
 SalesItems: no.
 Loyalty: yes (Card PAN or track optional: mandatory if managed in a separate
loyaltyswipe).
 OriginalTransaction: no.
LoyaltyLinkCard Linking a payment card to a loyalty card request.
 TotalAmount no.
 SalesItems: no.
 Loyalty: yes.
 OriginalTransaction: no.
LoyaltyPointsTransfer Transfer points from one card to another:
 TotalAmount no.
 SalesItems: no.
 Loyalty: yes.
 OriginalTransaction: no.
PINChange Changing the PIN to a payment card request.
 TotalAmount no.
 SalesItems: no.
 Loyalty: no.
 OriginalTransaction: no.
CardActivate Activate card request (put in whitelist):
 TotalAmount no.
 SalesItems: no.
 Loyalty: no.
 OriginalTransaction: no.
CardStop Activate card request (put in blacklist):
 TotalAmount no.
 SalesItems: no.
 Loyalty: no.
 OriginalTransaction: no.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 12 of 144

StoreValueInCard Store amount onto a SVC:

 TotalAmount: yes.
 SalesItems: no.
 Loyalty: no.
 OriginalTransaction: no.
RefundValueFromCard Take amount from a SVC:
 TotalAmount: yes.
 SalesItems: no.
 Loyalty: no.
 OriginalTransaction: no.
CardBalanceQuery Reports available amount from a SVC, or credit available from credit card:
TotalAmount: no.
SalesItems: no.
Loyalty: no.
OriginalTransaction: no.
TicketReprint Reprinting the referenced EPS ticket (loyalty or payment, provided that it was a ticket issued
by the EPS and stored by the EPS) request.
 TotalAmount no.
 SalesItems: no.
 Loyalty: no.
 OriginalTransaction: no (in case only the last ticket is available to reprint);
yes (in case the Eft/Cards receipt log is stored by the EPS and possible searches are
handled).
AbortRequest Aborting the referenced request
If any abort of the operation is necessary, it must be implemented within the EPS
application. This request was not consistent with the rules of managing request one at a time
and it introduces complexity.
RepeatLastMessage Request to repeat the last message because the response was never received correctly.
This solution enables avoiding Ack/Nak in the message transport. It can be used only once
the Timeout for the response is elapsed.
 TotalAmount no.
 SalesItems: no.
 Loyalty: no.
 OriginalTransaction: no.
attributes Name Type Use Annotation
RequestType CardRequestType Required Gives type of request – see above detail.
ApplicationSender ApplicationType Optional Identifies the application sending the request. Used only for information
logging purpose. (Unlikely more than one POS is present at one cash
desk!)
WorkstationID WorkstationIDType Required Identifies the logical workstation (associated to the socket) sending the
request: it can be only one at a time, sending only one request at a time.
Usually the POS (more than one POS might be present); also an OPT
identifies a logical workstation; in case of CRIND (usually two sides, one
per filling position of the pump) it counts as two logical workstations.
NOTE: Not renamed to avoid recoding in the interface implementation
already in place.
POPID POPIDType Optional Necessary when Point Of Payment is not coincident with Workstation to
address which payment combination EPS/Device to use; it is different
from the TerminalID, that is assigned (statically or dynamically) by the
EPS application in the on-line dialogue with the host.
POPID is mandatory in case the pin-pad to be used is not implicit by the
physical link established. More Pin-pads might be present associated to
one workstation and only one at a time can be addressed.
Configuration mapping WorkstationID/POPID is static in both POS and
EPS applications, together with details of transport level (sockets details).
RequestID RequestIDType Required ID of the request; for univocal referral
ReferenceNumber RequestIDType Optional In case of abort, it gives reference to the original request RequestID

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 13 of 144

diagram

POSdata are data about the POS Sell application. They are data similar to IFSF ISO8583 field 48.
Only the time stamp is compulsory (to manage timeouts).
POSdata value Comment
POSTimeStamp Mandatory
ServiceLevel Optional
 S = self serve (customer refilling)
 F = Full serve(attended on the forecourt)
ShiftNumber Optional. POS shift Number.
ClerkID Optional. CashierID.
ClerkPermission Optional. Identifies the permission of the operator.
High – Can do any operation (refund)
Medium – Can do limited operation (reversal)
Low – Can do only normal operation such as payment.
The exact implementation is custom.
OutdoorPosition Optional. It is used to identify the outdoor pre-authorization: in a pre authorization its
absence determines that the pre-authorization is indoor.
It identifies the pre-authorization as at outdoor terminal in the following manner:
0 means outdoor but position not to be handled
>0 identifies the outdoor device used by the customer and this position number is
handled (e.g. printed on receipt, or simply logged).
TightControl Optional. It is used to force a tight control process, so to involve a higher security
process than normal.
e.g. forcing an on-line payment when usually it is only above a certain floor limit; or
forcing a lower floor limit, etc.. This flag might be triggered by the cashier, otherwise
EPS would implement the standard behaviour.
SplitPayment Optional. Tells if the amount to be paid is the result of a split payment or not. In this
case the sum of line items might differ from the total amount. It is then up to the card
processing rules to allow this or not.
ManualPAN Optional. To force a manual PAN key in for situations where the card is broken or not
readable

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 14 of 144

CardHolderPresent Optional. Use by FDC – chapter 13.

CardPresent Optional. Use by FDC – chapter 13.
VoiceReferral Optional. To force a voice referral for situations specific.
TransactionNumber Optional - sales transaction number – format is alphanumeric xs:string unbounded.
attributes Name Type Use Annotation
LanguageCode LanguageCodeType Optional Language as selected during the Sell session.
diagram

The best practice adviced is to always request for loyalty if potentially applicable, even if the
application will not prompt explicitly for loyalty or if the customer will not use a loyalty card.
This practice is equivalent to using a CardServiceRequest for e.g. only payment, but allowing the
loyalty anyway.

Loyalty value Comment

LoyaltyCard Optional: Mandatory if LoyaltyFlag=yes, a part when LoyaltySwipe is required.
Second loyalty card in case of points transfer is read by the EPS application (first one is receiving points,
second one is giving).
MOPrule Optional. Might be used only when loyalty combined with payment.
LoyaltyAmount Optional. If customer can select the amount of points to redeem.
attributes Name Type Use Annotation
LoyaltyFlag xs:boolean Required Mandatory. The flag states if the functionality is requested for the
transaction (it has to be negative in case no loyalty is requested even if
payment+Loyalty request is used).
 Yes - then loyalty is requested and other fields filled
 No – no further data will be filled.
diagram

It contains the loyalty card ID or track when magnetic stripe.

attributes Name Type Use Annotation
LoyaltyPAN CardPANType Optional If card keyed in manually.
diagram

Method of payment rule: giving the necessary information on the payment with card, might influence
the point ratio calculation.
attributes Name Type Use Annotation
CardPAN CardPANType Required Maybe even the PAN might influence the MOP rule (e.g. cards of a
certain group)
CardCircuit CardCircuitType Required The card circuit might influence the MOP rule:
"euroShell","EssoCard","DKV","UTA"Lomo","Amex","Diners"Visa","Maste
rCard",”Maestro",”NationalDebit",”SiteCard”,"Other", etc.
The list of types enabled by CardCircuitType are free to be extended in
the implementation of the protocol. A German implementation might
require “GermanECcard”, “GermanELV”,etc;an Italian implementation
would involve “Pagobancomat” and so on. It is simply impossible to keep
the standard protocol up to date with a complete list of payment circuits,
so the values are free.
diagram

Optional. Default (not present) any card circuit is allowed.

diagram CardCircuit, CardCircuitType. List of card circuit names allowed for the operation
attributes Name Type Use Annotation
CardCircuitState CardCircuitStateType Optional Default (attribute not present) is “Accepted”
“Denied” disables the card circuit acceptance for the operation

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 15 of 144

diagram PrivateData xs:string

Otional. Buffer to transport implementation specific, additional data. element, alphanumeric, maximum length 256,
contents implementation specific.
diagram

Original transaction data: used only when reversing or refunding or (optional) for Pre-Authorization reference of
the Financial Advice. Values are same as in ISO8583.
attributes Name Type Use Annotation
TerminalID TerminalIDType Required Terminal reference
TerminalBatch BatchCodeType Required Batch of terminal when the original transaction was performed (it
might influence the feasibility)
STAN STANtype Required STAN as given in ISO8583 dialogue.
TimeStamp xs:dateTime Required Acquirer Time stamp of the original transaction.
ApplicationID Numeric <0..99> Optional Optional identifier of a card application handling a
CardPreAuthorization used in the FinancialAdvice to reference the
original pre-authorization. This speeds up the application selection.
diagram
Only for transaction requesting amount operations (e.g. payment or refund).
attributes Name Type Use Annotation
Currency CurrencyCode Optiona In case the amount might be different currency.
PaymentAmount CurrencyCode Optiona Use in case POS controlled cashback to indicated payment part
of total amount
CashBackAmount CurrencyCode Optiona Use in case POS controlled cashback to indicated CashBack part
of total amount. If card don't allow cashback EPS can:
- end request with failure
- request confirmation to proceed authorization with out cash
back
- proceed authorization with out cash back and response to
POS with cash back amount = 0
diagram

All of the line items composing the transaction. It might be one line item per product (barcode can be added as
additional product code) or per product group.

In a simple payment request all attributes have positive values: monetary Amounts and quantities are positive,
therefore coherent with the main CardServiceRequest.
Although the total transaction may be net positive (a payment) or net negative (a refund) individual transaction line
items can also be payments and refunds, therefore not always coherent with the main CardServiceRequest.
The default TypeMovement is always positive: if the line item is coherent with the main CardServiceRequest the
field my be absent, so it is optional. If a line item is not coherent with the CardServiceRequest main movement
(e.g. Payment) then the TypeMovement must be given: it adresses the difference if in amount and/or quantity.
NOTE: a TotalAmount resulting negative due to negative line items greater than positive is not acceptable: this is
compliant to ISO8583 IFSF implementation. In this case the entire transaction becomes a refund (rather than
payment) and the TotalAmount is now positive.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 16 of 144

SaleItem value Comment

ProductCode Mandatory. Coded in 3 digits.
A Rebate can be coded as product line item in the response, so the response message will contain
different line items in case of loyalty Rebate or modified values due to marketing EPS or host controlled
initiatives.
Amount Optional. Gross amount of the single line item – currency is the same of TotalAmount.
UnitMeasure Optional.
UnitPrice Optional
Quantity Optional.
TypeMovement Optional. The default payment TypeMovement is always positive: in this case the field my be absent. If a
line item not coherent with the CardServiceRequest main movement this field is required:
VALUE AMOUNT QUANTITY Example (CardServiceRequest=Payment)
0 + + (Coherent/Default) Stock decrease – Customer debit.
1 + - Stock increase – customer debit (e.g. fee on disposal)
2 - + Stock decrease – customer refund (e.g. give+refund)
3 - - Stock increase – customer debit (e.g. deposit return)
NOTE: this attribute is not supported in V1.20 of ISO8583Oil. In ISO8583 it would limit the viable line
items
TaxCode Optional
AdditionalProductCode Optional. GTIN barcode scan. Only when line item equals to the product.
SaleChannel Optional. This information tells if the product is:
CompanyOwned = company owns the stock in sale
DealerOwned = dealer (i.e. at site) owns the stock in sale
ThirdPartyOwned = owned by a third party
Certain fidelity cards do not allow purchase of 3rd party or dealer products. Dealer cards would allow that
and bankcards too. This information is both for control purpose and for forwarding indication about
reimbursement/invoicing etc.

NOTE: this attribute is not supported in V1.20 of ISO8583Oil. In ISO8583 it limits the viable line items.
AdditionalProductInfo Optional. Unlimited length (was up to 20char) description of the product and private data. The purpose is
forwarding indication about the product (created at the site) for invoicing (e.g. dealer card invoicing on
behalf of the dealer) and transfer implementation specific information.

NOTE: this attribute is not supported in V1.20 of ISO8583Oil. In ISO8583 it limits the viable line items.
attributes Name Type Use Annotation
ItemID Xs:ID required Identifies the line item.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 17 of 144

diagram

Optional.

This data allows the POS application feeding the EPS application with the card data necessary for the
process to be executed by the EPS. The EPS will omit to get the card reading and it will manage the
rest of the process.

NOTE: This solution is not consistent with the decoupling of POS application and EPS application. It
must not be used in situations where a certification is necessary (e.g.EMV), otherwise both
applications should be approved together.
Any new development should not use this feature; it is in the standard only to ease the implementation
of the interface in existing environments (i.e. RFID card data reading managed by POS through
proprietary interface).

Elements Comment
Track1 Optional. Card Track Type (now xs:string; originally it was hexBinary or optionally as ASCII)
Track2 Optional. Card Track Type (now xs:string; originally it was hexBinary or optionally as ASCII)
Track3 Optional. Card Track Type (now xs:string; originally it was hexBinary or optionally as ASCII)
ICC Optional. Secure data flow. Implementation specific.
Barcode Optional. GTIN barcode in digits (8 to 14).
Instring Optional. String
CardPAN Optional. CardPANType The PAN of the card
StartDate Optional. CardDateType Date of starting validity for the card
ExpiryDate Optional. CardDateType Date of ending validity for the card
CardCircuit Optional. Which type of card is depending on the circuit information.

3.2 XML schema - EPS/POS: CardServiceResponse

See Appendix for the proper XSD schema specification. Below is summarised the logic of the data and some examples
in the following paragraphs.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 18 of 144

Diagram

OverallResult value Comment Handling

Success Complete Success. Operation successful
PartialFailure Partial Failure might mean payment If the main operation is denied or fails, then it is recorded as a
ok but loyalty award failure. All of Failure. The PartialFailure is the case when the main operation
the partial failures unacceptable will (e.g. Payment) is succesful and the secondary operation fails (e.g.
have to be reversed. loyalty). The operation continues normally and it is up to the
cashier/customer to reverse it if possible and required by the
customer.
Failure Complete failure. Optionally the Operation denied: for some reason the operation failed. It is up to
ActionCode field will explain the the cashier or the customer to retry, maybe with different input
reason for the failure.
DeviceUnavailable Complete failure. No further request Having a DeviceUnavailable the operation required willalways fail.
will be successful because a device It is application specific to assign this error to a certain situation
is unavailable (e.g. printer) and if involves blocking any operation until the problem is solved or
continue for the operations that do not require mandatorily that
device. The system might try with an application specific strategy
to test if the problem is solved, through a ServiceRequest for
diagnosis. Otherwise it is up to the cashier to reactivate or retry.
Busy Complete failure. It is a temporary The application should retry with an application specific strategy.
state and it is likely that a second
attempt shortly will be successful.
The requesting application is invited
to retry.
Loggedout Complete failure. The application A login is necessary before any operation might be successful. It is
cannot answer since the login was application specific having a Login automatic or manually triggered
never handled. The requesting by the cashier/operator.
application is invited to login.
Aborted Complete failure. The transaction Depending on the reason for aborting the application or the
was aborted by cashier or customer cashier might react retrying, retrying with different input or simply
or an Abort Request. stop. In practice it is a specific version of the Failure.
TimedOut Complete failure. No response from In practice it is a specific version of the DeviceUnavailable where
remote host. It is possible to retry; the device is the host for Card processing; depending on the
the number of attempts and retry implementation (singlehost or multihost) thismight mean that no
interval is application specific. card processing is available or somecards are anyway available.
Requests for Card processes executable by EPS off-line as
fallback, never return this error.
FormatError Complete failure. The request This is a specific version of the Failure. It either means a bug in the
cannot be handled or is mistakenly implementation or the transmission to EPS not delivering the
(unknown) formatted. message with the necessary integrity. The cashier/customer might
retry the operation; it might happen occasionally. Being an
exceptional situation, it might not be necessary to implementan
automatic block of the application: this is an application specific
decision.
ParsingError Complete failure. The request XML This is a specific version of the Failure. It probably means a bug in
is not well formed the implementation (otherwise the transmission to EPS not
delivering the message with the necessary integrity). The
cashier/customer might retry the operation andanyway continue
working; it might happen occasionally. Being an exceptional
situation, it might not be necessary to implementan automatic
block of the application: this is an application specific decision.
CommunicationError OverallResult-value on Diagnosis- it is up to the application to repeat it or ignore the error.
request: host system not available.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 19 of 144

ValidationError Complete failure. The request XML This is a specific version of the Failure. It probably means a bug in
is not validated against the definition the implementation (otherwise the transmission to EPS not
schema delivering the message with the necessary integrity). The
cashier/customer might retry the operation andanyway continue
working; it might happen occasionally. Being an exceptional
situation, it might not be necessary to implementan automatic
block of the application: this is an application specific decision.
MissingMandatoryData Complete failure. The request This is a specific version of the Failure. It probably means a bug in
message is missing necessary data the implementation. The cashier/customer might retry the
operation with different card or input and anyway the system
continue working; it might happen occasionally. Being an
exceptional situation, it might not be necessary to implement an
automatic block of the application: this is an application specific
decision.
UnknownCard Complete failure. A card in a This is a specific kind of Failure that triggers the POS/Sell
recognisable standard format was application reading the card details in the response and trying to
used, but it is not managed by the process itself.
EPS. Optionally the detail of the This practice is not the advice by IFSF, but it is present for existing
card are also sent in the response, systems.
so the POS/Sell application might
manage this process
(no response from Complete failure. The connection to The POS/Sell triggers a RepeatLastMessage request; in case of
EPS) the EPS is not available orthe EPS no response again in general the system is not available (customer
is not available/operational operated terminal will switch to unoperable state following an
implementation specific strategy).
Depending on the implementation, some intervention on the EPS
is necessary before being able to retry.
Attributes Name Type Use Annotation
RequestType CardRequestType Required Gives type of request – echo of request.
ApplicationSender ApplicationType Optional Identifies the application sending the request. Used only for
information logging purpose. (Unlikely more than one POS is
present at one cash desk!)
WorkstationID WorkstationIDType Required Identifies the logical workstation (associated to the socket)
receiving the response. it can be only one at a time, sending
only one request at a time, to be closed by the response or a
time-out.
Usually the POS (more than one POS might be present); also
an OPT identifies a logical workstation; in case of CRIND
(usually two sides, one per filling position of the pump) it counts
as two logical workstations.
NOTE: Not renamed to avoid recoding in the interface
implementation already in place
POPID POPIDType Optional Necessary when Point Of Payment is not coincident with
Workstation to address which payment combination
EPS/Device to use; it is different from the TerminalID, that is
assigned (statically or dynamically) by the EPS application in
the on-line dialogue with the host.
POPID is mandatory in case the pin-pad to be used is not
implicit by the physical link established. More Pin-pads might be
present associated to one workstation and only one at a time
can be addressed.
Configuration mapping WorkstationID/POPID is static in both
POS and EPS applications, together with details of transport
level (sockets details).
RequestID RequestIDType Required ID of the request; for univocal referral Echo.
OverallResult RequestResultType Required It gives the result of the requested operation. See above table
for detail.
Element Terminal
Mandatory. Terminal data contains ISO8583 reference (e.g. useful in case of need to reverse/refund).
attributes Name Type Use Annotation
TerminalID TerminalIDType Required Terminal reference
TerminalBatch BatchCodeType Optional Batch of terminal when the original transaction was performed
(it might influence the feasibility) . Not used in loyalty swipe.
TerminalBatch is to be used as global for all terminals or
dedicated to a terminal. The former is required for
GlobalReconciliation.
STAN STANtype Optional STAN as given in ISO8583 dialogue. Not used in loyalty swipe

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 20 of 144

diagram

Optional. Only when payment, awarding, redemption, refund are involved.

attributes Name Type Use Annotation
LanguageCode LanguageCodeType optiona Optional. If Host requested to use a different language with the
customer (receipt/display).
After the operation thelanguage of the POS/Sell system is
supposed to return automatically to the original value.
Element TotalAmount Mandatory unless LoyaltySwipe
Attributes Name Type Use Annotation
PaymentAmount MonetaryAmount Optional Actual payment of purchase.
CashBackAmount MonetaryAmount Optional If customer requested some cash back (and it was approved by
the Host).
OriginalAmount MonetaryAmount Optional TotalAmount of the request. Used if different in the response,
because the host has the rights to affect it (e.g. discount).
Currency CurrencyCode Optional Currency code of any amount in the response.
Element Authorization

Mandatory unless LoyaltySwipe.

It contains the minimum information for statistics on payments (when forwarded by the POS to the BOS, it
enables some reconciliation reports on acquirer batch and reconciliation).
attributes Name Type Use Annotation
AcquirerID AcquirerType Required Acquirer identification.
CardPAN CardPANType Optional PAN of the payment card (if) approved.
StartDate CardDateType Optional Date of starting validity for the card
ExpiryDate CardDateType Optional Date of ending validity for the card
TimeStamp xs:dateTime Required Timestamp of the host/acquirer
ActionCode ActionCodeType Optional IFSF ISO8583 action code for the response. It can be used also
with other protocol as implementation specific.
It is present also incase of authorization denied.
ActionCode Type is defined as unbounded alphanumeric string
ApprovalCode AuthorizationCodeType Optional Acquirer approval code.
AcquirerBatch BatchCodeType Optional Acquirer batch/session/business day as coded by the acquirer.
CardCircuit CardCircuitType Optional Type of card circuit (“Visa”, “MasterCard”,”Amex”,etc.)
ApplicationID Numeric <0..99> Optional Optional identifier of a card application handling a
CardPreAuthorization used in the FinancialAdvice to reference
the original pre-authorization. This speeds up the application
selection.
FiscalReceipt Xs:Boolean Optional Depending on the card type, the sales receipt might be a
delivery note (invoice will have fiscal relevance) or a fiscal
receipt.
PANprint CardPANPrintType Optional Depending on the card type, the sales receipt might show the
whole PAN, or partial or hide it completely.
This field gives the PAN as it is to be stored and printed by
other application.
e.g. 7077396*********345
TimeDisplay Xs:Boolean Optional According to some acquirer rule, the receipt might compulsory
avoid to print out the time.
LoyaltyAllowed Xs:boolean Optional Flag to specify if on the transaction paid on the card loyalty
points can be issued or not.
ReceiptCopies Xs:numeric Optional Depending on the card type, the Eft/Card receipt provided by
the EPS will be optional to be printed (0 value), or mandatory (in
the number of copies indicated).
Element RestrictionCodes
Optional. It is used when the response is after a pre-authorization, using a card with product restrictions. Product
codes must be known in the POS application.
It can be used also in negative responses due to product restriction violation, to enumerate the correct product
codes sent in the Request.
Even if in the IFSF ISO8583 the line Items and the restriction codes are limited in number, the POS-EPS
implementation as local protocol does not require such limitation.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 21 of 144

diagram

Optional. It is used only when loyalty was in the request.

attributes Name Type Use Annotation
LoyaltyFlag xs:boolean Required Same value as in the request.
LoyaltyTimeStamp xs:dateTime Optional Loyalty acquirer timestamp. Not used in loyalty swipe.
diagram

It contains the loyalty card ID or track when magnetic stripe

attributes Name Type Use Annotation
LoyaltyPAN CardPANType Optional If card keyed in manually.
Element LoyaltyAmount Optional. Used when points are awarded or redeemed.
attributes Name Type Use Annotation
OriginalLoyaltyAmount xs:float Optional Used when points redeemed are different from the request.
Element LoyaltyApprovalCode Optional. Used if the loyalty transaction was approved.
attributes Name Type Use Annotation
LoyaltyAcquirerID AcquirerType Optional Loyalty acquirer identification.
LoyaltyAcquirerBatch BatchCodeType Optional Batch/Session/Business day of the loyalty acquirer.
Element PrivateData xs:string

Otional. Buffer to transport implementation specific, additional data.

element, alphanumeric, maximum length 256, contents implementation specific
Diagram

See Request explanation. Values of price/amount might differ from the original request only in case the system is
designed to enable the host to affect the POS prices/discount.
Even if in the IFSF ISO8583 the line Items and the restriction codes are limited in number, the POS-EPS
implementation as local protocol does not require such limitation.
A Rebate can be handled as a new line item in the CardServiceResponse or as an attribute to the SaleItem
involved.

SaleItem value Comment

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 22 of 144

SaleChannel Optional. This information tells if the product is:

CompanyOwned = company owns the stock in sale
DealerOwned = dealer (i.e. at site) owns the stock in sale
ThirdPartyOwned = owned by a third party
Certain fidelity cards do not allow purchase of 3rd party or dealer products. Dealer cards would allow that
and bankcards too. This information is both for control purpose and for forwarding indication about
reimbursement/invoicing etc.

NOTE: this attribute is not supported in V1.20 of ISO8583Oil. In ISO8583 it would limit the viable line
items.
AdditionalProductInfo Optional. Description of the product. The purpose is forwarding indication about the product (created at
the site) for invoicing (e.g. dealer card invoicing on behalf of the dealer).

NOTE: this attribute is not supported in V1.20 of ISO8583Oil. In ISO8583 it would limit the viable line
items.
TypeMovement Optional. The default payment TypeMovement is always positive: in this case the field my be absent. If a
line item not coherent with the CardServiceRequest main movement this field is required:
VALUE AMOUNT QUANTITY Example (CardServiceRequest=Payment)
0 + + (Coherent/Default) Stock decrease – Customer debit.
1 + - Stock increase – customer debit (e.g. fee on disposal)
2 - + Stock decrease – customer refund (e.g. give+refund)
3 - - Stock increase – customer debit (e.g. deposit return)

NOTE: this attribute is not supported in V1.20 of ISO8583Oil. In ISO8583 it would limit the viable line
items.
RebateLabel Optional xs:string unbound. Describes the rebate type applied to the line item.
Element

Optional. It is required in the answer to the RepeatLastMessage query: it contains the original
response header data (e.g. original message sent by the EPS or prepared/timedout, never received by
the POS).
attributes Name Type Use Annotation
RequestType CardRequestType Required From the original response, now repeated.
ApplicationSender ApplicationType Optional From the original response, now repeated.
WorkstationID WorkstationIDType Required From the original response, now repeated.
POPID POPIDType Optional From the original response, now repeated.
RequestID RequestIDType Required From the original response, now repeated.
OverallResult RequestResultType Required From the original response, now repeated.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 23 of 144

diagram

Optional. This data is the result of the input on the device, delivered by the EPS to the POS application for leaving
the POS managing the card process or part of it.NOTE: This solution is not consistent with the decoupling of POS
application and EPS application. It must not be used in situations where a certification is necessary (e.g. EMV),
otherwise both applications should be approved together. Any new development should not use this feature; it is
in the standard only to ease the implementation of the interface in existing environments (i.e. dealer card process
managed by POS/BOS with local card management).

CardValue value Comment

Track1 Optional Card Track Type (now xs:string; originally it was hexBinary or optionally as ASCII)
Track2 Optional Card Track Type (now xs:string; originally it was hexBinary or optionally as ASCII)
Track3 Optional Card Track Type (now xs:string; originally it was hexBinary or optionally as ASCII)
ICC Optional Secure data flow. Implementation specific
Barcode Optional GTIN barcode in digits (8 to 14).
InString Optional String
CardPAN Optional – CardPANType The PAN of the card
StartDate Optional – CardDateType - Date of starting valididty for the card
ExpiryDate Optional – CardPANType Date of ending valididty for the card
CardCircuit Optional. Which type of card is depending on the circuit information.

3.3 XML schema - EPS/POS: ServiceRequest

See Appendix for the proper XSD schema specification. Below is summarised the logic of the data and some examples
in the following paragraphs.

diagram

POS request for service to EPS; the possible requests are identified by the required attribute RequestType

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 24 of 144

ServiceRequest value Comment

Diagnosis Diagnosis request to check if the system is available; see DiagnosisMethod in POSdata.
POSdata: Mandatory.
TotalAmount: No
Agent: No
SendOfflineTransactions To trigger the forward of off-line transactions from the site to the host. (Regardless the solution
adopted by the EPS; e.g. ftp, etc.)
POSdata: Mandatory.
TotalAmount: No
Agent: No
Reconciliation To reconcile between POS application and EPS application. The batch/Session will remain the
same. Reconciliation works per one pair WorkstationID/POPID; omitting POPID it works per
WorkstationID (the actual reconciliation process happens per each POPID).
This is executed only for one Terminal.
POSdata: Mandatory.
TotalAmount: No
Agent: No
ReconciliationWithClosure To reconcile between POS application and EPS application, but also triggering the
reconciliation between EPS application and the host. The batch/session will be closed and a
new one started. Reconciliation works per one pair WorkstationID/POPID; omitting POPID it
works per WorkstationID (the actual reconciliation process happens per each POPID).
Tthe EPS manages all the TerminalID associated to the POPID involved..
POSdata: Mandatory.
TotalAmount: No
Agent: No
Login POS logon to EPS application. Login operates per Workstation, independently from the
POPID.
Login does not imply any diagnostic process on the devices (processes to be triggered
explicitly through the Diagnosis).
A second login without a prior logoff is accepted every time (e.g. POS crashes).
POSdata: Mandatory.
TotalAmount: No
Agent: No
Logoff POS logoff from EPS application. Used to terminate operations with the POS or in case of
configuration, administration.
Logoff operates per Workstation, independently from the POPID.
POSdata: Mandatory.
TotalAmount: No
Agent: No
Administration Administration is a private field forimplementation specific configuration and setting.
POSdata: Mandatory.
TotalAmount: No
Agent: No
OnlineAgent Many on-lineapplications might be supported; theese applications might relate to cards or not
even. The list of agent is free and can be amended according to the product application.
POSdata: Mandatory.
TotalAmount: Yes
Agent: Yes
CurrentAgent defined: Mobile phone recharge (without payment) ofprepaid card/account.
No reconciliation is performed on such applications.
RepeatLastMessage Eliminated. This value is not supported anymore, being not useful for the ServiceRequest.

Request to repeat the last message because the response was never received correctly. This
solution enables avoiding Ack/Nak in the message transport.
TotalAmount no.
SalesItems: no.
Loyalty: no.
OriginalTransaction: no.
GlobalReconciliation To reconcile between POS application and EPS application on all terminals. For POS-EPS this
is a unique operation valid for any terminal. The EPS will do reconciliation one terminal at the
time and then respond to the POS. The batch/Session will remain the same.
The POPID is omitted and the WorkstationID requiring it is only for reference.
The actual reconciliation process happens per each POPID.
POSdata: Mandatory.
TotalAmount: No
Agent: No

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 25 of 144

GlobalReconciliationWithClosure To reconcile between POS application and EPS application on all terminals. For POS-EPS this
is a unique operation valid for any terminal. The EPS will do reconciliation one terminal at the
time and then respond to the POS. The batch/session will be closed and a new one started
(the EPS manages all the TerminalID associate to the POPID involved).
The POPID is omitted and the WorkstationID requiring it is only for reference.
The actual reconciliation process happens per each POPID.
POSdata: Mandatory.
TotalAmount: No
Agent: No
ChangeCardReaderStatus To enable the functionality: the card reader is automatically enabled to read the card and
process it until possibile, while waiting for a CardServiceRequest.
This ServicEREquest enables the activation or deactivation of the card reader.
Attributes Name Type Use Annotation
RequestType ServiceRequestType Required Gives type of request – see above detail.
ApplicationSender ApplicationType Optional Identifies the application sending the request. Used only for
information logging purpose. (Unlikely more than one POS is
present at one cash desk!)
WorkstationID WorkstationIDType Required Identifies the logical workstation (associated to the socket)
sending the request: it can be only one at a time, sending only
one request at a time.
Usually the POS (more than one POS might be present); also an
OPT identifies a logical workstation; in case of CRIND (usually two
sides, one per filling position of the pump) it counts as two logical
workstations.
NOTE: Not renamed to avoid recoding in the interface
implementation already in place.
POPID POPIDType Optional Necessary when Point Of Payment is not coincident with
Workstation to address which payment combination EPS/Device
to use; it is different from the TerminalID, that is assigned
(statically or dynamically) by the EPS application in the on-line
dialogue with the host.
POPID is mandatory in case the pin-pad to be used is not implicit
by the physical link established. More Pin-pads might be present
associated to one workstation and only one at a time can be
addressed.
Configuration mapping WorkstationID/POPID is static in both POS
and EPS applications, together with details of transport level
(sockets details).
RequestID RequestIDType Required ID of the request; for univocal referral
IFSFVersion Xs:string Optional This new data identifies the IFSF POS-EPS interface version used
by the POS in Login message request, and used by the EPS in
Login message response.A POS or EPS system have to manage
at least the current and previous version of the interface to allow
synchronization of software update in each side of the interface.
The string IFSFVersion has the format v.j[.n] where v is the
version number, j the major release number, and n the minor
release number, each of these values being less than 255, the
value n can be absent in case of zero.
IFSFSchemaVersion Xs:string Optional This new data identifies the IFSF POS-EPS interface schema
version used by the POS in Login message request, and used by
the EPS in Login message response.
The schema version enables a backword compatible change in
the schema definition.
The string IFSFVersion has the format v.j where v is the version
number, j the major release number, each of these values being
less than 255, the value n can be absent in case of zero.
The values are:
Former Releases: v=001, J=any.
This release: v=002, J=001.
Manufacturer_Id Manufacturer_IdType Optional
Model ModelType Optional
DeviceType DeviceType_Type Optional
ProtocolVersion ProtocolVersionType Optional
CommunicationProto CommunicationProtoc Optional
col olVersionType
ApplicatioSoftwareV ApplicatioSoftwareVer Optional
ersion sionType
SWChecksum SWChecksumType Optional

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 26 of 144

diagram

POSdata value Comment

POSTimeStamp Mandatory
ShiftNumber Optional
ClerkID Optional. CashierID
DiagnosisMethod Optional. Optional – mandatory if the request is for Diagnosis.Online = echo EPS to Host to see if the on-
line link is available. The diagnosis also provides the clearing of not finished transactions (e.g. auto
reversal).
Local = verification if the EPS is correctly working.
POPinit = forces a init in case the system is logged out.
POPinitAll = forces a for all POPid in case any is logged out
PrinterStatus = verification of the printer availability.
ClerkPermision Optional. Identifies the permission of the operator.
High – Can do any operation (refund)
Medium – Can do limited operation (reversal)
Low – Can do only normal operation such as payment.
The exact implementation is custom
StatusReqType Optional. used for ChangeCarReaderStatus ServiceRequests between:
- Online
- POPinit
- POPinitAll
- Activate
- Deactivate
Attributes Name Type Use Annotation
LanguageCode LanguageCodeType Optional Language as selected during the sell session.
element TotalAmount. Optional
Attributes Name Type Use Annotation
Currency CurrencyCode Optional In case the amount might be different currency.
element Agent
Used onlyfor OnlineAgent. Free list of application.e.g. MobilePhonePrepaid
element PrivateData
Optional. Mainly used in Administration request, implementation specific.

3.4 XML schema - EPS/POS: ServiceResponse

See Appendix for the proper XSD schema specification. Below is summarised the logic of the data and some examples
in the following paragraphs.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 27 of 144

diagram

EPS response to the POS request for service; the possible results are identified by the required attribute
OverallResult (same as CardServiceResponse):
OverallResult value Comment Handling
Success Complete Success. Operation successful
PartialFailure Partial Failure might mean payment ok but If the main operation is denied or fails, then it is
loyalty award failure. All of the partial failures recorded as a Failure. The PartialFailure is the case
unacceptable will have to be reversed. when the main operation is succesful and the
secondary operation fails. This is unlikely in the
ServiceRequest, but in special request as for
OnlineAgent it might be possible.
The operation continues normally and it is up to the
cashier/customer to reverse it if possible and required
by the customer.
Failure Complete failure. Optionally the ActionCode Operation denied: for some reason the operation
field will explain the reason for the failure. failed. It is up to the cashier or the customer to retry,
maybe with different input
DeviceUnavailable Complete failure. No further request will be Having a DeviceUnavailable the operation required
successful because a device is unavailable (e.g. willalways fail. It is application specific to assign this
printer) error to a certain situation and if involves blocking any
operation until the problem is solved or continue for
the operations that do not require mandatorily that
device. The system might try with an application
specific strategy to test if the problem is solved,
through a ServiceRequest for diagnosis. Otherwise it
is up to the cashier to reactivate or retry.
Busy Complete failure. It is a temporary state and it is The application should retry with an application
likely that a second attempt shortly will be specific strategy.
successful. The requesting application is invited
to retry.
Loggedout Complete failure. The application cannot answer A login is necessary before any operation might be
since the login was never handled. The successful. It is application specific having a Login
requesting application is invited to login. automatic or manually triggered by the
cashier/operator.
Aborted Complete failure. The transaction was aborted Depending on the reason for aborting the application
by cashier or customer or an Abort Request. or the cashier might react retrying, retrying with
different input or simply stop. In practice it is a
specific version of the Failure.
TimedOut Complete failure. No response from remote In practice it is a specific version of the
host. It is possible to retry; the number of DeviceUnavailable where the device is the host for
attempts and retry interval is application Card processing; depending on the implementation
specific. (singlehost or multihost) thismight mean that no card
processing is available or somecards are anyway
available. Requests for Card processes executable
by EPS off-line as fallback, never return this error.
CommunicationError OverallResult-value on Diagnosis-request: host it is up to the application to repeat it or ignore the
system not available. error.
FormatError Complete failure. The request cannot be This is a specific version of the Failure. It either
handled or is mistakenly (unknown) formatted. means a bug in the implementation or the
transmission to EPS not delivering the message with
the necessary integrity. The cashier/customer might
retry the operation; it might happen occasionally.
Being an exceptional situation, it might not be
necessary to implementan automatic block of the
application: this is an application specific decision.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 28 of 144

ParsingError Complete failure. The request XML is not well This is a specific version of the Failure. It probably
formed means a bug in the implementation (otherwise the
transmission to EPS not delivering the message with
the necessary integrity). The cashier/customer might
retry the operation andanyway continue working; it
might happen occasionally. Being an exceptional
situation, it might not be necessary to implementan
automatic block of the application: this is an
application specific decision.
ValidationError Complete failure. The request XML is not This is a specific version of the Failure. It probably
validated against the definition schema means a bug in the implementation (otherwise the
transmission to EPS not delivering the message with
the necessary integrity). The cashier/customer might
retry the operation andanyway continue working; it
might happen occasionally. Being an exceptional
situation, it might not be necessary to implementan
automatic block of the application: this is an
application specific decision.
MissingMandatoryData Complete failure. The request message is This is a specific version of the Failure. It probably
missing necessary data means a bug in the implementation. The
cashier/customer might retry the operation with
different card or input and anyway the system
continue working; it might happen occasionally. Being
an exceptional situation, it might not be necessary to
implement an automatic block of the application: this
is an application specific decision.
(no response from EPS) Complete failure. The connection to the EPS is The POS/Sell triggers a RepeatLastMessage
not available orthe EPS is not request; in case of no response again in general the
available/operational system is not available (customer operated terminal
will switch to unoperable state following an
implementation specific strategy).
Depending on the implementation, some intervention
on the EPS is necessary before being able to retry.
Attributes Name Type Use Annotation
RequestType ServiceRequestType Required Gives type of request – echo of request.
ApplicationSender ApplicationType Optional Identifies the application sending the request. Used
only for information logging purpose. (Unlikely
more than one POS is present at one cash desk!)
WorkstationID WorkstationIDType Required Identifies the logical workstation (associated to the
socket) receiving the response. it can be only one
at a time, sending only one request at a time, to be
closed by the response or a time-out.
Usually the POS (more than one POS might be
present); also an OPT identifies a logical
workstation; in case of CRIND (usually two sides,
one per filling position of the pump) it counts as two
logical workstations.
NOTE: Not renamed to avoid recoding in the
interface implementation already in place
POPID POPIDType Optional Necessary when Point Of Payment is not
coincident with Workstation to address which
payment combination EPS/Device to use; it is
different from the TerminalID, that is assigned
(statically or dynamically) by the EPS application in
the on-line dialogue with the host.
POPID is mandatory in case the pin-pad to be
used is not implicit by the physical link established.
More Pin-pads might be present associated to one
workstation and only one at a time can be
addressed.
Configuration mapping WorkstationID/POPID is
static in both POS and EPS applications, together
with details of transport level (sockets details).
RequestID RequestIDType Required ID of the request; for univocal referral Echo.
OverallResult RequestResultType Required It gives the result of the requested operation. See
above table for detail.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 29 of 144

IFSFVersion Xs:string Optional This new data identifies the IFSF POS-EPS
interface version used by the POS in Login
message request, and used by the EPS in Login
message response.A POS or EPS system have to
manage at least the current and previous version
of the interface to allow synchronization of
software update in each side of the interface.
The string IFSFVersion has the format v.j[.n] where
v is the version number, j the major release
number, and n the minor release number, each of
these values being less than 255, the value n can
be absent in case of zero.
IFSFSchemaVersion Xs:string Optional This new data identifies the IFSF POS-EPS
interface schema version used by the POS in Login
message request, and used by the EPS in Login
message response.
The schema version enables a backword
compatible change in the schema definition.
The string IFSFVersion has the format v.j where v
is the version number, j the major release number,
each of these values being less than 255, the value
n can be absent in case of zero.
The values are:
Former Releases: v=001, J=any.
This release: v=002, J=001.
Element Terminal Optional. Terminal data contains ISO8583 reference.
attributes Name Type Use Annotation
TerminalID TerminalIDType Optional Terminal reference is mandatory only if the operation
refers to a single terminal.
TerminalBatch BatchCodeType Optional Batch of terminal when the original transaction was
performed (it might influence the feasibility).
TerminalBatch is to be used as global for all terminals
or dedicated to a terminal. The former is required for
GlobalReconciliation.
STAN STANtype Optional STAN as given in ISO8583 dialogue.
Element Authorization
Optional. Necessary when on-line link is involved (also for Online agent, but the acquirer will not be the card
acquirer, but the application countpart)..
attributes Name Type Use Annotation
AcquirerID AcquirerType Required Acquirer identification.
TimeStamp xs:dateTime Required Timestamp of the host/acquirer.
ApprovalCode AuthorizationCodeType Optional Acquirer approval code.
AcquirerBatch BatchCodeType Optional Acquirer batch/session/business day as coded by the
acquirer.
diagram

Optional. It is used only in reconciliation between POS and EPS (with or without closure: triggering or not the EPS
reconciliation with the host).
attributes Name Type Use Annotation
LanguageCode LanguageCodeType Optional Language as set within the POS Sell session.
Element TotalAmount
Mandatory. Reconciliation is performed with a detail according to the attributes value.
attributes Name Type Use Annotation
NumberPayments Xs:integer Required Number of payments for that total amount.
PaymentType TransactionType Required As for ISO8583 reconciliation: either Credit or Debit
transaction.
Currency CurrencyCode Optional Necessary if the system is multi-currency
CardCircuit CardCircuitType Optional Discriminates Visa, MasterCard, Amex, etc.
Acquirer AcquirerType Optional Discriminates the Acquirer/Bank
Element DiagnosisResult

Optional. Used in case of ServiceRequest for diagnosis: it contains private values, implementation specific
element OriginalHeader

Optional. It is required in the answer to the RepeatLastMessage query: it contains the original response header
data (e.g. original message sent by the EPS or prepared/timedout, never received by the POS).

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 30 of 144

attributes Name Type Use Annotation

RequestType ServiceRequestType Required From the original response, now repeated.
ApplicationSender ApplicationType Optional From the original response, now repeated.
WorkstationID WorkstationIDType Required From the original response, now repeated.
POPID POPIDType Optional From the original response, now repeated.
RequestID RequestIDType Required From the original response, now repeated.
OverallResult RequestResultType Required From the original response, now repeated.
Element PrivateData
Optional. Mainly used in Administration response, implementation specific.

3.5 XML schema – EPS or POS / Device Proxy: DeviceRequest

See Appendix for the proper XSD schema specification. Below is summarised the logic of the data and some examples
in the following paragraphs.

Diagram

The device request can be atomic to one device or combined to up to 3 devices according to implementation of
device proxy. 2 outputs and 1 input can be combined (e.g. display to cashier update on status of card payment,
display to the customer to swipe the card, wait for card to be swiped).The request type is specified as it follows:
DeviceRequest value Comment
Input Input from the targeted device. It includes combined input/output (because in those requests the output
is always for input request explanation/prompt).
Output Output to the targeted device
SecureInput Secure Input from the targeted device. It is a specific tunnelling: data is forwarded without any process
SecureOutput Secure Output to the targeted device. It is a specific tunnelling: data is forwarded without any process
AbortInput Aborts the Input from the targeted device (and all of the potential output combined).
AbortOutput Aborts the output to the targeted device. It can be used also to abort an output that was combined with
an input.
RepeatLastMessage RepeatLastMessage is notimplemented even if the transport solution does not implement the
Ack/Nak: the managementof missing response is to be solved within the logic of the DeviceProxy
functionality.
Event Message to inform the POS-system about special events
This is the only type of DeviceRequest handling the elements ProductCodes or SaleItems
Below the table of potential devices; the implementation of card process dialogues is easier in case of combined
devices, eg.: PinEntryDeviceCardReader, CashierTerminal, Printer.
Peripheral Annotation
CashierDisplay A pop-up window (or a fixed window) on the POS cashier display, dedicated to these messages
through the device proxy.
CustomerDisplay A temporary full access to the customer display at the POS, or a pop-up/fixed window in case of wider
graphical display. It depends on the POS technology
Printer Stand-alone printer for receipts/tickets.
PrinterReceipt Stand-alone printer for receipts for customer, not shared for other purpose or application
ICCrw Integrated circuit card reader/writer. Stand-alone
CardReader Generic card reader, combining magstripe reader and ICCrw.
PinEntryDeviceCardReader Generic card reader combined with a PinPad.
PinPad Keypad (e.g. for PIN enter) and customer display.(e.g. 16*2 chars or wider 4 lines graphical)
PEDReaderPrinter Generic card reader combined with a PinPad and ticket printer.
MSR Magnetic stripe reader stand alone.
RFID Wireless chip reader/writer for contact less cards/tags
BarcodeScanner Barcode scanner (e.g. to read barcode on a card, or voucher, coupons, etc.)
CashierKeyboard Cashier input device (keyboard or touch screen)
CashierTerminal Cashier input device (keyboard or touch screen) and A pop-up window (or a fixed window) on the POS
cashier display, dedicated to these messages through the device proxy
CustomerKeyboard Customer input device (keyboard or touch screen or custom buttons)
CustomerTerminal Customer input/output device (keyboard and display/window-screen or touch screen) on the POS
customer display, dedicated to these messages through the device proxy.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 31 of 144

Log Device logging the operations. The content of logging is implementation specific: this solution enables
DeviceRequest of Output to the device Log in free text format.
attributes Name Type Use Annotation
RequestType DeviceRequestType Required Gives type of request – see above detail.
ApplicationSender ApplicationType Optional Identifies the application sending the request. Used only for information
logging purpose. (Unlikely more than one POS is present at one cash
desk!)
WorkstationID WorkstationIDType Required Identifies the logical workstation (associated to the socket) sending the
request: it can be only one at a time, sending only one request at a time.
Usually the POS (more than one POS might be present); also an OPT
identifies a logical workstation; in case of CRIND (usually two sides, one
per filling position of the pump) it counts as two logical workstations.
NOTE: Not renamed to avoid recoding in the interface implementation
already in place.
TerminalID TerminalIDType Optional Identifies the terminal/device proxy involved.
POPID POPIDType Optional Necessary when Point Of Payment is not coincident with Workstation to
address which payment combination EPS/Device to use; it is different from
the TerminalID, that is assigned (statically or dynamically) by the EPS
application in the on-line dialogue with the host.
POPID is mandatory in case the pin-pad to be used is not implicit by the
physical link established. More Pin-pads might be present associated to
one workstation and only one at a time can be addressed.
Configuration mapping WorkstationID/POPID is static in both POS and
EPS applications, together with details of transport level (sockets details).
RequestID RequestIDType Required Used for referring to the CardServiceRequest
SequenceID SequenceIDType Optional Used to give correct ID to each DeviceRequest ; this ID gives the sequence
within the common CardServiceRequest RequestID; for univocal referral
(the format is longer, not limited to 0..9)
Diagram

Optional, up to two instances are allowed.

Elements Comment
Textline Optional. Textline are multiple elements that are forwarded to the target device without formatting (e.g. to
display or to printer).
In case of output to the printer, the absence of TextLine means that the printer has to be tested only to know
if it is ready to print so in a correct status). This test is always involving the flag Immediate as true.
SoftKey Optional: Interface for prompting using soft keys (i.e. ATM style keys)
Buzzer Optional. Formatted acoustic output
OutSecureData Optional. Secure flow of data – see below.
MAC Optional. MAC used to sign textlines or more in general the output.
ImageFile Optional. Referring to the path where to find the file and the name/type.
SoundFile Optional. Used on OPTs supporting speech synthesis to tell the OPT application to play a sound file (e.g. a
WAV file). Full or partial path and file name.
attributes Name Type Use Annotation
OutDeviceTarget DeviceType Required See above table for detail.
InputSynchronize xs:boolean Optional Flag to tell if the output must finish when the input within the same
request is completed.
Complete xs:boolean Optional Flag to state that this is the last request of a sequence.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 32 of 144

Immediate xs:boolean Optional For printer output it discriminates output that have to be printed
immediately (i.e. printout is part of the authorization process and
EPS needs it to be fulfilled asap), from output that can be stored
and done later (POS response given immediately but the printout
will be done later; i.e. after CardServiceResponse the POS will
complete the sale receipt and combine it with the EPS card receipt
stored but not yet printed).
CharSet Xs:short optional The Internet Assigned Numbers Authority (IANA) has defined the
numeric coding to identify character sets in a document
(http://www.iana.org/assignments/character-sets); this coding uses
the value range 0 to 2999 (2 bytes necessary per each character in
TextLine). TextLine type remains unchanged but the interpretation is
according to IANA if this field is set to 1, otherwise US-ASCII if it is
not present or 0.
Element TextLine

(Xs:unsignedbyte)TextLine are repeated as necessary, with a set of attributes to format the output. Attributes not
supported by the device are just ignored. Display can be any: customer or cashier display.
attributes Name Type Use Annotation
Row Xs:unsignedbyte Optional Peripheral: Display(/Printer):
Position the text output.
Column Xs:unsignedbyte Optional Peripheral: Display/Printer:
Position the text output.
CharSet Xs:unsignedbyte Optional Peripheral: Display/Printer:
Defines the character set.
Erase Xs:boolean Optional This attribute can be present in the very first text line only in order to
indicate if the display has to be erased before the new output
Define a default in case of absence – is “true”
Peripheral: Display:
Erases the display.
Echo Xs:boolean Optional Peripheral: Display:
Echoes the keyboard entry (no textline value).
Cursor Xs:boolean Optional Peripheral: Display:
shows the cursor or not.
TimeOut Xs:boolean Optional Peripheral: Display:
timeout after which it automatically erases.
Color ColorType Optional Peripheral: Display/Printer:
textcolor; basic colors are used (black or grey if the color is not
supported).
Alignment AlignmentType Optional Peripheral: Display/Printer:
text alignment (left if not supported)
Height HeightType Optional Peripheral: (Display/)Printer:
Text dimension (normal if not supported).
Width WidthType Optional Peripheral: (Display/)Printer:
Text dimension (normal if not supported).
CharStyle1 CharStyleType Optional Peripheral: (Display/)Printer:
Text style (normal if not supported); it can be combined up to three
(e.g. Bold-Italic-Underline).
CharStyle2 CharStyleType Optional Peripheral: (Display/)Printer:
Text style (normal if not supported); it can be combined up to three
(e.g. Bold-Italic-Underline).
CharStyle3 CharStyleType Optional Peripheral: (Display/)Printer:
Text style (normal if not supported); it can be combined up to three
(e.g. Bold-Italic-Underline).
PaperCut Xs:boolean Optional Peripheral: Printer:
paper is cut after printing the textline. (Ignored if no cutting feature)
MenuItem Numeric, 0..99 Optional Peripheral: Terminal
ID of menu item. Marks a textline as a menu item. Every menu item
has a unique value within the message which is returned after
selection.
Indicates a line for the menu as it follows:
0 Menu header
1..98 Menu item that can be selected by user choice
99 prompt for the menu selection
Element SoftKey Optional: Interface for prompting using soft keys (i.e. ATM style keys)
attributes Name Type Use Annotation
SoftKeyReturn xs:string required The value to return, should that soft key be pressed
Row xs:byte optional Peripheral: Display(/Printer):
Position the text output.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 33 of 144

Column xs:byte optional Peripheral: Display/Printer:

Position the text output.
CharSet xs:byte optional Peripheral: Display/Printer:
Defines the character set.
Erase xs:boolean optional Peripheral: Display:
Erases the display.
Echo xs:boolean optional Peripheral: Display:
Echoes the keyboard entry (no textline value).
Cursor xs:boolean optional Peripheral: Display:
shows the cursor or not.
TimeOut xs:integer optional Peripheral: Display:
timeout after which it automatically erases.
Color ColorType optional Peripheral: Display/Printer:
textcolor; basic colors are used (black or grey if the color is not
supported).
Alignment AlignmentType optional Peripheral: Display/Printer:
text alignment (left if not supported)
Height HeightType optional Peripheral: (Display/)Printer:
Text dimension (normal if not supported).
Width WidthType optional Peripheral: (Display/)Printer:
Text dimension (normal if not supported).
CharStyle1 CharStyleType optional Peripheral: (Display/)Printer:
Text style (normal if not supported); it can be combined up to three
(e.g. Bold-Italic-Underline).
CharStyle2 CharStyleType optional Peripheral: (Display/)Printer:
Text style (normal if not supported); it can be combined up to three
(e.g. Bold-Italic-Underline).
CharStyle3 CharStyleType optional Peripheral: (Display/)Printer:
Text style (normal if not supported); it can be combined up to three
(e.g. Bold-Italic-Underline).

Element Buzzer Optional acoustic signal coupling the output on peripheral.

attributes Name Type Use Annotation
DurationBeep Xs:integer Optional Duration of the beep, in milliseconds
CounterBeep Xs:integer Optional Repetition of the beep
DurationPause Xs:integer Optional Duration of the pause between each beep repetition
diagram

Secure data are coded as a chain of hex values, thus they must be forwarded untouched and no processing is
allowed on. This is a potential flow in output to the targeted device. Data is encrypted.
diagram

Optional. To secure the output, granting that it will be delivered unchanged to the device.
Element ImageFile.

Optional. Indicates the fullpath of the image file that can be found on a site server with the name and
estension as in the tag.
Element SoundFile
Optional. Indicates the fullpath of the image file that can be found on a site server with the name and
estension as in the tag
Diagram

Input request might be:

Elements Comment

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 34 of 144

Command Optional. Text command that requests a specific action by an intelligent device. The main example is where
an intelligent pin-pad or a combined PED device is requested to perform an action.
The semantic and the logic of the command is dictated by the device.
The action might be basic (e.g. read a card) or even more complex.
InSecureData Optional. Secure flow of data. It is the same format of the OutSecureData, but this time the flow is from the
device to the application.
attributes Name Type Use Annotation
InDeviceTarget DeviceType Required See above table for detail.
Element Command
Optional. It defines the command that must be accomplished. The list is not complete: pinpad specific command
are allowed (EPS/PinPad supplier specific).
Command value Comment
GetDecimals PinPad/Keyboard: returns a number with decimals
GetChar PinPad/Keyboard: returns a string
GetMenu PinPad/Keyboard: returns the ID of a menu selection
GetAmount PinPad/Keyboard: returns an amount
GetConfirmation PinPad/Keyboard: returns a character (Y or N)
GetAnyKey PinPad/Keyboard: waits a key (any) to be hit
ProcessPIN PinPad: the PIN is entered and encrypted according to the card involved (returns the encrypted secure data)
CheckPIN PinPad: checkPIN offline (return the Boolean result).
RequestCard CardReader. Acts the necessary activity when card is read (e.g. EMV flow)
ReadCard CardReader: Returns the card data
TransferData PinPad/CardReader: provides/returns secure data (not encrypted if normal data)
RequestTypeCard CardReader: Returns the type of card (Magstripe, ChipCard, Hibrid)
ValidateMAC PinPad: using the appropriate keys and algorithm, validates the MAC passed together with the message
data.
CalculateMAC PinPad: using the appropriate keys and algorithm, calculates the MAC on the message data passed.
UpdateKeys PinPad: updates keys upon the forwarded secure data.
Other Other commands are possible
attributes Name Type Use Annotation
Lenght Xs:integer Optional Exact Length of the field retrieved (eg: number of chars in GetChar)
MinLenght Xs:integer Optional Minimum Length of the field retrieved (eg: number of chars in
GetChar)
MaxLenght Xs:integer Optional Maximum Length of the field retrieved (eg: number of chars in
GetChar)
Decimals Xs:integer Optional Number of decimals (GetDecimals)
Separator SeparatorType Optional Type of separator (comma or dot) to be used
CardReadElement CardReadType Optional Forces a specific reading (eg. Track1, track2,etc.) (now xs:string;
originally it was hexBinary or optionally as ASCII)
TimeOut Xs:integer Optional Timeout in seconds before the uncompleted input by the user
involves an automatic abort/cancel of the input
Diagram

Optional. Message to inform the POS-system about special events.

Event value Comment
CardInserted A card was read. Information on the card will be available in the CardValueCardvalue field.
DispenserSelected A dispenser was selected out of the list in the Dispensers fields: the result in in the dispenser tag.
attributes Name Type Use Annotation
EventType DeviceEventType Required Defines the arrived event. Actually two different events are defined:
CardInserted, DispenserSelected
Diagram

Optional. Contains the event-specific data for POS-system.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 35 of 144

Diagram

Optional. Required if EventType=CardInserted

Unique identification number of the inserted card

Note: it is not best practice to use such data in the Sell Application.
CardValue value Comment
Track1 Optional Card Track Type (now xs:string; originally it was hexBinary or optionally as ASCII)
Track2 Optional Card Track Type (now xs:string; originally it was hexBinary or optionally as ASCII)
Track3 Optional Card Track Type (now xs:string; originally it was hexBinary or optionally as ASCII)
ICC Optional Secure data flow. Implementation specific
Barcode Optional GTIN barcode in digits (8 to 14).
InString Optional String
CardPAN Optional – CardPANType The PAN of the card
StartDate Optional – CardDateType - Date of starting valididty for the card
EndDate Optional – CardPANType Date of ending valididty for the card – it is like ExpiryDate
CardCircuit Optional. Which type of card is depending on the circuit information.
Element Dispenser
Optional. Xs:unsignedbyte. Required if EventType=DispenserSelected.
Contains the list of the possible dispensers to be selected.

3.6 XML schema – EPS or POS / Device Proxy: DeviceResponse

See Appendix for the proper XSD schema specification. Below is summarised the logic of the data and some examples
in the following paragraphs.
Diagram

OverallResult value Comment Handling

Success Complete Success. Operation successful

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 36 of 144

PartialFailure Partial Failure might mean payment If the main operation is denied or fails, then it is recorded as a
ok but loyalty award failure. All of Failure. The PartialFailure is the case when the main operation
the partial failures unacceptable will (e.g. input) is succesful and the secondary operation fails (e.g.
have to be reversed. output). The operation continues normally and it is up to the
application to repeat it or ignore the error.
Failure Complete failure. Optionally the Operation denied: for some reason the operation failed. it is up to
ActionCode field will explain the the application to repeat it or ignore the error
reason for the failure.
DeviceUnavailable Complete failure. No further request Having a DeviceUnavailable the operation required will always
will be successful because a device fail. It is application specific to assign this error to a certain
is unavailable (e.g. printer) situation and if involves blocking any operation until the problem is
solved or continue for the operations that do not require
mandatorily that device. The system might try with an application
specific strategy to test if the problem is solved, through a
ServiceRequest for diagnosis. Otherwise it is up to the application
to continue and ignore the error or not.
Busy Complete failure. It is a temporary The application should retry with an application specific strategy.
state and it is likely that a second It is up to the application to repeat it or ignore the error.
attempt shortly will be successful.
The requesting application is invited
to retry.
Aborted Complete failure. The transaction Depending on the reason for aborting and the nature of the
was aborted by cashier or customer request, it is up to the application to repeat it or ignore the error.
or an Abort Request.
TimedOut Complete failure. No response from it is up to the application to repeat it or ignore the error.
remote host. It is possible to retry;
the number of attempts and retry
interval is application specific.
CommunicationError OverallResult-value on Diagnosis- it is up to the application to repeat it or ignore the error.
request: host system not available.
FormatError Complete failure. The request This is a specific version of the Failure. It either means a bug in
cannot be handled or is mistakenly the implementation or the transmission not delivering the
(unknown) formatted. message with the necessary integrity. It is up to the application to
repeat it or continue taking into account the error.
ParsingError Complete failure. The request XML This is a specific version of the Failure. It probably means a bug
is not well formed in the implementation (otherwise the transmission not delivering
the message with the necessary integrity). It is up to the
application to repeat it or continue taking into account the error.
ValidationError Complete failure. The request XML This is a specific version of the Failure. It probably means a bug
is not validated against the definition in the implementation (otherwise the transmission not delivering
schema the message with the necessary integrity). It is up to the
application to repeat it or continue taking into account the error.
MissingMandatoryData Complete failure. The request This is a specific version of the Failure. It probably means a bug
message is missing necessary data in the implementation. The application continues taking into
account the error.
(no response from Complete failure. The connection to it is up to the application to repeat it or ignore the error. It will be
EPS) the EPS is not available orthe EPS the error/timeout on the main request (CardServiceResponse or
is not available/operational ServiceResponse) to trigger the correct handling.
Attributes Name Type Use Annotation
RequestType DeviceRequestType Required Gives type of request – echo of request.
ApplicationSender ApplicationType Required Identifies the application sending the request. Used only for
information logging purpose. (Unlikely more than one POS is
present at one cash desk!)
WorkstationID WorkstationIDType Required Identifies the logical workstation (associated to the socket)
receiving the response. it can be only one at a time, sending
only one request at a time, to be closed by the response or a
time-out.
Usually the POS (more than one POS might be present); also
an OPT identifies a logical workstation; in case of CRIND
(usually two sides, one per filling position of the pump) it counts
as two logical workstations.
NOTE: Not renamed to avoid recoding in the interface
implementation already in place

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 37 of 144

POPID POPIDType Optional Necessary when Point Of Payment is not coincident with
Workstation to address which payment combination
EPS/Device to use; it is different from the TerminalID, that is
assigned (statically or dynamically) by the EPS application in
the on-line dialogue with the host.
POPID is mandatory in case the pin-pad to be used is not
implicit by the physical link established. More Pin-pads might be
present associated to one workstation and only one at a time
can be addressed.
Configuration mapping WorkstationID/POPID is static in both
POS and EPS applications, together with details of transport
level (sockets details).
TerminalID TerminalIDType Required Identifies the terminal/device proxy involved.
RequestID RequestIDType Required ID of the request; for univocal referral Echo.
SequenceID SequenceIDType Optional Used if one request is composed of multiple requests; this ID
gives the sequence within the common RequestID; for univocal
referral
ReferenceRequestID RequestIDType Optional Reference to a request: used in case of abort request.
OverallResult RequestResultType Required It gives the result of the requested operation. See above table
for detail.
Element

Result of the output. (Regardless the overall result, regardless of the result of the other devices targeted)
attributes Name Type Use Annotation
OutDeviceTarget DeviceRequestType Required See above table for detail.
OutResult RequestResultType Required See above table for detail.
Diagram

The input contains the data flow from the device, as requested. In case of success one or both must be present;
in case of failure probably none are available.
attributes Name Type Use Annotation
InDeviceTarget DeviceRequestType Required See above table for detail.
InResult RequestResultType Required See above table for detail.
Diagram

Optional. Encrypted. Data to be processed or forwarded by EPS application.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 38 of 144

Diagram

Optional. Result of the input on the device, delivered to the EPS. Different types specify the nature of the input
value.

InputValue Elements Comment

Track1 Optional Card Track Type (now xs:string; originally it was hexBinary or optionally as ASCII)
Track2 Optional Card Track Type (now xs:string; originally it was hexBinary or optionally as ASCII)
Track3 Optional Card Track Type (now xs:string; originally it was hexBinary or optionally as ASCII)
ICC Optional Secure data flow. Implementation specific
Barcode Optional GTIN barcode in digits (8 to 14).
InString Optional String
InBoolean Optional. Boolean.
InNumber Optional. Decimal number
CardPAN Optional – CardPANType The PAN of the card
StartDate Optional – CardDateType - Date of starting valididty for the card
ExpiryDate Optional – CardPANType Date of ending valididty for the card
Diagram

Optional. It is used for outdoor handling. Contains POS response data: either a Dispenser-list or a
ProductCodelist; it could also contain the SaleItems passed with additional information.
Element Dispenser
Optional. Xs:unsignedbyte. If EventType in DeviceRequest was CardInserted the POS-system can respond with a
list of availabledispensers. The EPS uses this list to ask the customer for a dispenser selection (on PIN-Pad

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 39 of 144

display/keyboard).It is not necessary to response with a Dispenser-list case of :- CRID- OPT with own customer
input/output possibility
Element ProductCode
Optional. Required for outdoor / CardPreAuthorization . POS-system responds with a list of available product
codes of the selected dispenser.
Element ModifiedRequest

Optional. Present only in case the original CardServiceRequest has to change into a different Request
type following the process of reading the card.

Note: this is used only in exceptional cases, where the Sell application selects the function to be
implemented only after knowing which card was swiped. This is not a best practice but it might be
necessary in specific implementations where the Sell application handles some details of card related
functionality.
Attributes Name Type Use Annotation
RequestType CardRequestType Required Gives type of request – see above detail.
Diagram

Optional.
Present only in case the original CardServiceRequest has to change the SaleItems into different
values following the process of reading the card.

Note: this is used only in exceptional cases, where the Sell application modifies the sale items only
after knowing which card was swiped. This is not a best practice but it might be necessary in specific
implementations where the Sell application handles some details of card related functionality.
SaleItem value Comment
SaleChannel Optional. This information tells if the product is:
CompanyOwned = company owns the stock in sale
DealerOwned = dealer (i.e. at site) owns the stock in sale
ThirdPartyOwned = owned by a third party
Certain fidelity cards do not allow purchase of 3rd party or dealer products. Dealer cards would allow that
and bankcards too. This information is both for control purpose and for forwarding indication about
reimbursement/invoicing etc.

NOTE: this attribute is not supported in V1.20 of ISO8583Oil. In ISO8583 it would limit the viable line
items.
AdditionalProductInfo Optional.
The purpose is forwarding indication about the product (created at the site) for invoicing (e.g. dealer card
invoicing on behalf of the dealer).

NOTE: this attribute is not supported in V1.20 of ISO8583Oil. In ISO8583 it would limit the viable line
items.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 40 of 144

TypeMovement Optional. The default payment TypeMovement is always positive: in this case the field my be absent. If a
line item not coherent with the CardServiceRequest main movement this field is required:
VALUE AMOUNT QUANTITY Example (CardServiceRequest=Payment)
0 + + (Coherent/Default) Stock decrease – Customer debit.
1 + - Stock increase – customer debit (e.g. fee on disposal)
2 - + Stock decrease – customer refund (e.g. give+refund)
3 - - Stock increase – customer debit (e.g. deposit return)

NOTE: this attribute is not supported in V1.20 of ISO8583Oil. In ISO8583 it would limit the viable line
items.

4. POS EPS IMPLEMENTATION RULES

The target architecture of the site system involves de-coupling the POS application from the EPS application, with no
implication on each other:
POS manages selling
EPS manages card payment and in general cards (loyalty as exception for awarding points)
The following scheme shows the referred architecture framework:

Cashier display

IFSF
(XML) Site server
Barcode scanner Device Proxy
SELL application

MSR IFSF
(XML)

Pin-Pad
POS
XML proprietary
ICC read/write
IFSF EPS/POS
(XML)
Printer

UPOS +
IFSF add-on

EPS client EPS server

EPS

IFSF/ISO8583-oil

(Remote) Switch/
Authorisation Centres

And the following scheme describes how it is implemented:

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 41 of 144

Remote
SW manager Remote Diagnostic Configuration Head Office
Management

Site border

Car Wash Control

Unit

Site Office
Prime Sign Price Unit

Site server
Tank Level Gauges Applications
or
BOS
or..

Pump Head

Pump Head
Forecourt Controller
(IFSF Lon distributed in any
device)
Pump Head
EPS/
Sell Server
Payment
Pump Head Application
server

Forecourt

Site Server

POS/EPS-A+B

Printer
Customer display Device
SELL application
Cashier display Proxy

Barcode scanner

MSR/RFID POS/EPS-A+B
Device EPS/Payment client
Pin-Pad
Proxy
(Key pad +
customer display)
ICC read/write Point ofSale

Printer Point of Payment (indoor)

Printer
Customer display Device
SELL application
Proxy
Customer buttons/keyboard

MSR/RFID
IFSF-ISO8583
Pin-Pad Device EPS/Payment client
(Key pad + Proxy
customer display)
COPT (OPT or CRIND)
ICC read/write Point of Payment (outdoor)
Site Border

(Remote) Switch/
Authorisation Centres

The device proxy is actually partly implemented within the EPS application, for the peripherals almost dedicated to card
application: Pin-pad, customer display, Printer if dedicated to payment, MSR/ICC card reader
Both POS/Sell and EPS application can access those peripherals through the DeviceRequest messages, each other
behaving as a proxy interface when interrogated. The EPS can access the peripherals under his control also using
other existing protocols. This makes the implementation easier, but it does not decouple the EPS from the peripheral
(i.e. Pin-Pad).

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 42 of 144

The POS/Sell application implements the device proxy for the peripherals dedicated to the sell application: barcode
scanner, cashier display and keyboard (maybe through touch screen), larger customer display for sales information,
printer dedicated to sale receipt (fiscal or normal). This means that the EPS application will be able to access those
peripherals through the Device Proxy interface, while the sell application can keep using them as native (same as for
EPS).

4.1 EPS Addressing

Multiple EPS are managed through different sockets. In the application configuration these sockets are associated to
the right application. The POS application must be aware of the different applications and be able to select the correct
one.

For example the indoor application might be provided by a supplier A, while the outdoor application might be supplied
by a supplier B; the two application and / or the two pin-pads and the EPS applications are not compatible. Therefore
the EPS A will use the pin-pad A and the POS application indoor will use it; the EPS B will use the outdoor pin-pad B
and the POS application for outdoor will use it.

As a transition scenario example more than one EPS application for the same payment position could be used to
manage different cards that a single EPS application does not handle. This might happen in an indoor environment
having a different pin-pad for each EPS application: the EPS A will use the pin-pad A and the EPS B will use the pin-
pad B. The POS application will select in advance which EPS application to use, so the cashier must know the button to
trigger the right application for the right card.

4.2 EPS back-up

The back up EPS is one example of multiple EPS implementation.

The EPS backup could be the same EPS application running on a different PC/Server (or even on the same
PC/Server): it is used when the first application is not available for any reason. This provides more resilience to the
system, of course the best result is obtained installing the two different EPS applications on separate machines.

There are many ways of implementing a back-up solution, depending on which level of resilience and redundancy is
targeted, The basic solution is to implement the back-up EPS using different socket as outlined for the multiple EPS
implementation. The two following examples are just to give an idea of possible implementations.

Example:
The POS might handle two different EPS applications: in case of timeout from the first application, it will abort that
request and engage the second EPS. This requires the two applications using different sockets and the POS
application using the logic to handle the fallback request.
The time outs setting play of course a critical role in the efficient implementation of this solution.

Example:
The EPS might be more complex and be developed as two applications aware of being double and resilient: this
solution requires that both applications receive the message (each one uses a different socket) and activate
themselves if the first one does not answer).
Since this is complex, it is not further addressed.

4.3 Device state table

The device state table of the applications using this protocol is dedicated to the protocol usage and does not include
the whole application state/process.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 43 of 144

CardServiceRequest
Login
ServiceRequest DeviceRequest
DeviceResponse
LoggedOn Engaged or
LoggedOut
Ready Busy time-out
CarServiceResponse
LogOff ServiceResponse
or time-out

For more comprehensive description, refer to the UseCases and the possible sequence diagrams corresponding.

Some basic rules are anyway possible to be described. Any supplier/company is invited to contribute; the so far
discussed big rules are:
Two CardServiceRequest, or a CardServiceRequest and a ServiceRequest, or two ServiceRequest can never be
processed in parallel for the same couple of POS and EPS
Two DeviceRequest can never be processed in parallel for the same couple of POS and EPS
The same Pin-pad can never be used for two requests at the same time. This is valid for a CardServiceRequest,
but within it this is also valid for a DeviceRequest.
Device requests from EPS to POS have to be queued to be correctly handled
A second request can be sent only after receiving the response to the former one, or after a timeout is elapsed.

4.4 Architecture implementation and configuration

The POS-EPS interface is independent from the architecture of POS and from the architecture of EPS, therefore it
applies to the examples illustrated below, but also to other architecture implemented as combination of those.

POS Sell application cases:

POS client server with POS client hosted on the PC (POS device):

Printer Printer
Drawer Cashier Drawer Cashier
Display Desk Display Desk
WorkstationID = 1
IP address = A Sell Client Sell Client

WorkstationID = 2
Ethernet IP address = B

Sell Server

POS hosted on the site server, with no client device a part from peripherals; the POS manages multiple point of
payments (not really a client server SW application architecture, but in practice it makes no difference externally):

Printer
Cashier WorkstationID = 1
Drawer
Display Desk IP address = A

POS/Sell Server

Printer Cashier WorkstationID = 2

POS-Sell Drawer
Display Desk IP address = A

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 44 of 144

POS client server hosted on the site server, with no client device a part from peripherals; each POS client manages
one point of payment (example: the OPT might be implemented this way):

Printer Cashier WorkstationID = 1

Drawer
Display Desk - A IP address = A

POS/SEll Server

POS-Sell - A Printer WorkstationID = 2

Cashier
Drawer IP address = A
Display Desk - B
POS-Sell - B

EPS application cases:

EPS client server with EPS client hosted on the PC (POS device):

POP ID = 1 Printer Printer

Drawer Cashier Cashier POP ID = 2
IP Address = A Drawer
Display Desk Display Desk IP Address = B

EPS Client EPS Client

Ethernet

EPS Server

EPS hosted on the site server:

Pin/Pad Cashier POP ID = 1

MSR/ICC Desk IP Address = A

EPS

EPS Pin/Pad Cashier POP ID = 2

MSR/ICC Desk IP Address = A

EPS client server, but with the client hosted on the site server:

Pin/Pad Cashier POP ID = 1

MSR/ICC Desk - A IP Address = A

EPS

EPS Client -A
Pin/Pad Cashier POP ID = 2
MSR/ICC Desk - B IP Address = A
EPS Client B

The main application logical addresses present as attributes in all XML messages as attribute of the message headline
are:
ApplicationSender: addresses which POS application is talking to the EPS application; it is very unlikely that more
than one POS is present at a point of payment/cashier desk, so this is maintained more to cover theoretical
situations than real ones.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 45 of 144

WorkstationID: Addresses which logical workstation is sending the request (or receiving the response). The logical
workstation is associated to the socket used at transport level to route the message. The POS/EPS supports only
one request at a time for each WorkstationID/POPID; one workstation can send only one message at a time. The
request must be closed by a response or by a time-out. Examples of WorkstationID is the POS device (device
present at the cashier desk); also an OPT identifies a logical workstation; in case of CRIND (usually two sides, one
per filling position of the pump) it counts as two logical workstations.
POPID: it addresses which payment combination EPS/Device to use. An example of usage is the EPS managing
more than one pin-pad per point of payment.

The configuration mapping WorkstationID/POPID (and ApplicationSender) is static in both POS and EPS applications
and it is set together with details of transport level (sockets details).

The POPID is different from the TerminalID, that is assigned (statically or dynamically) by the EPS application in the
on-line dialogue with the host; however the simplest way to implement the EPS is with a one to one correspondence
POPID and TerminalID; more TerminalID associated to a unique POPID might be involved in a multi-host EPS or in
other complex situation where specific cards involve a specific pin-pad. Having one TerminalID associated to many
POPID is possible but very complex (involving a complete decoupling within the EPS from the POS/POPID and the host
interface and the the TerminalID), thus it is not advised.

The table of addresses and the topology for a shop/station can be defined once for the maximum size theoretically
expectable. This table of values can be used whenever a shop/station is created and configured.
The same configuration will be used in any site/shop, with the only variance in the dimension and the number of POPs.

Interface configuration
The configuration of transport level (refer to TCP/Ip and socket description) details is driven by the following rules:
POS listens on one Port, named port (A) – unique per application
EPS listens on one Port, named port (B) – unique per application
IP address is associated to the hosting device (PC) equipped with the Ethernet interface (LAN)

Three channels are identified:

Channel 0 POS->EPS handling CardServiceRequest/Response and ServiceRequest/Reponse

POS listening on Port A0

EPS listening on Port B0

Channel 1 EPS->POS handling DeviceRequest/Response from EPS to POS

POS listening on Port A1

EPS listening on Port B1

Channel 2 POS->EPS handling DeviceRequest/Response from POS to EPS

POS listening on Port A2

EPS listening on Port B2

The port chosen in the interface is defined as a static value in the application configuration; to avoid conflicts the value
is chosen among the values not declared by other applications.

Application Configuration
Even if could be possible to parameterise the application through the interface, or to manage tables of configuration
data in the protocol between the two applications, the strategic solution is to use configuration files delivered
independently.
This solution might seem less efficient, but also simplifies the interface leaving the two applications really decoupled.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 46 of 144

So far no configuration parameter is planned to be inserted in the messages (i.e. Login), since there are very few
chances to exploit such flexibility recovering the complexity created.
Advantages of configuration at login:
Flexibility
Configuration is only from one side, eliminating potential cause of error
Disadvantages of configuration at login:
Additional complexity not clearly justified. The configuration changes in a site do not happen frequently: a new POS
installation does not happen that frequently. The configuration can be a template applicable anywhere the sa me
way depending on the devices really installed; errors are less likely this way.
Configuration files are necessary anyway.

NOTE: Login configuration was parked as non-standard. IFSF TCP/IP configuration (IP address association to
application/devices) is to be reviewed before further discussion.

4.5 Application issues

Receipt
The receipt configuration is part of the application which is responsible for the receipt content.
Also the printer type is configured in the application.
The receipt is intended to be issued separately by the application that is managing the process the receipt refers to.
The two main examples are:
POS handles the sales receipt, including the handling of sales taxes and value added tax.
EPS handles the card payment receipt.
Both applications ensure the correct processing of duplicate receipts, e.g. the word DUPLICATE added to the
receipt, etc.,
In case the loyalty application is handled by the EPS application, its receipt will be issued by the EPS.
One application is in control of the printer, so the other application simply provides the text to be printed: the resulting
receipt could be assembled in a way that it looks as if printed by a unique application. In case the printout is not
immediate when requested through a DeviceRequest, the printer unanvailable feature will be ignored; it will be up to
the application design to implement any feature in case local requirements are mandatory on receipt printing (Eft, fiscal,
etc.).
The DeviceRequest is the tool used by one application to require the printout by the application managing the printer,
therefore the receipt content is passed from one application to the other in text printable format.
The receipt journal can be handled by a unique application in text format, or by the combination of the two applications.
There is no necessity to provide the information to be printed in a data format instead of in a final text printout format.
This method of implementation saves the decoupling of the two applications.

4.6 Transport
TCP/IP is selected as the transport protocol because:
It will run on wide range of hardware, including Ethernet, Token Ring and X.25.
It will work on different computer platforms and operating systems, including Macintosh, Unix, Microsoft,
mainframe and PDA.
It is an open standard that is not owned by any manufacturer
It has a standard method of addressing that can uniquely identify each host on a vast network such as the
Internet.
It can route data via a particular route to reduce traffic or to bypass a faulty link.

Appendix A contains a brief introduction to the TCP/IP. This section describes how TCP/IP protocols are implemented
in the POS-EPS interface.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 47 of 144

4.6.1 Implementation
The only requirement for implementing a socket-based solution is a TCP/IP stack.
The implementation is using a connection-oriented (stream) messaging: the system will use separate connections to
pass card and device messages.
Connections are always client-to-server rather than peer-to-peer. This means that there are different connections for
different types of messages. Messages are initiated by the application acting as a TCP client and are processed and
responded to by the other application acting as a TCP server.
The connections are transaction based or short lived: this means that for each request/response pair a new connection
is initiated; for performance reasons, due to the possible high number of exchanges per transaction (see example on
messages flow), the connection will be alive for the transaction duration including all of the messages involved by it.
The reason for using transaction-based connections is to avoid the need for keep-alive messages and logic for
detecting connection presence/loss. The client side of each connection is responsible for initiating the connection. The
client side is responsible for closing the connection, except in error conditions.
A basic message transport information is added to the XML messages: in order to send and receive variable length
XML messages a simple message header indicating the overall length of the message must be used. This can be
implemented as a 4-byte unsigned integer value that immediately precedes the XML message and indicates the length
of the XML message. This value is transmitted in network byte order. There is no Hex 0 at the end of the message
included.

Connection and Message Timeouts rules complete the implementation together with the error handling rules.
An acknowledge is anyway necessary to grant that the message is correctly received. The TCP connection guarantees
the integrity of messages sent and received but it does not guarantee that a message is actually received and
processed. A successful completion of the socket send() function does not indicate that data was successfully
delivered to a receiving application. It can be difficult or impossible for a sending application to detect that a receiving
application has abnormally disconnected.

The connected EPS-Client can be a server-program or a service. The Start, Restart, and Stop of the EPS-Client (-
System) should be supervised by system-services.

The following description is only an example: The EPS client is started by the POS application right after its start-up. At
this time, the POS has derived its TCP/IP address and knows the TCP/IP address of the site controller. These
addresses and the POSID or WorkstationID is passed from the POS to the EPS client at the start-up (as command line
parameters/ or in a configuration file provided by the POS application). During start-up of the EPS client it registers
itself at the EPS server, which maintains a table with the relationship between POS, TCP/IP address of POS and EPS
client and attached PinPad. By using this table the EPS server can directly address device requests to the
corresponding POS. The only fixed data is the port number of the EPS server for incoming requests and this shall be a
configuration item.

When you have more than one EPS solution on one POS system, you have to define different Port Numbers for each
EPS system.

The system to exchange messages between POS and EPS does not require mechanism of Acknowledge/Not
acknowledge.
The mechanism used is within the XML tags: ‘RepeatLastMessage’ is a message that the application sends when
timing out for the response; the missing response might arrive upon the second request or the request has failed.
This methodology is not within the Device Proxy messages, because such messages are specifically addressing
exceptions.

When an error happens, the response message can be delivered only when the address of the source is available; the
response message will contain the error detail, but the header attributes will be zeroed because potentially corrupted or
not available. This helps and simplifies error handling.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 48 of 144

4.6.2 Flows and error-handling

The following connection types are supported:

CardServiceRequests / ServiceRequests from POS to EPS.

CardServiceResponse / ServiceResponse from EPS to POS.

DeviceRequest from EPS to POS or from POS to EPS

DeviceResponse from POS to EPS or from EPS to POS

The supported connection types will be performed over different TCP connections.

1. The first TCP connection (Channel 0) – connecting from POS side, listening from EPS side - will be used for
the CardService- and ServiceRequests from the POS to the EPS-Client.
The CardServiceResponse or ServiceResponse from the EPS to the POS will be transmitted over the same
TCP connection.

2. The second TCP connection (Channel 1) – listening from POS side, connecting from EPS side - will be used
for the DeviceRequests from the EPS-Client to the POS. The DeviceResponse from the POS to the EPS will be
transmitted over the same TCP connection.

3. The third TCP connection (Channel 2) - connecting from POS side, listening from EPS side - will be used for
the DeviceRequests from the POS to the EPS-Client and the DeviceResponse from the EPS to the POS.

In some implementations 1 and 3 given above may use the same listening channel. In this case the EPS has one
listening post (channel 0).

4.6.2.1 Connection Handling

A connection lives only as long as one Request / Response pair has processed or a Timeout has occurred. The
following sequence is valid for all connection types:

This representation illustrates the possible usage of SocketAPI commands; this level of detail will be then ignored in the
rest of the paragraph to better illustrate the concepts related to the messages transport implementation.
POS / EPS EPS / POS

Channel Channel

OpenSocket() OpenSocket()

Connect() Accept()
ACK

Request
Send() Receive()
ACK

Receive() Response Send()

ACK
Closesocket()
ACK

Closesocket()
ACK

The normal flow gets into an exception when the response does not arrive under a defined time-out: in this case the
response is considered as failed.

Normal Processing: Processing with timeout

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 49 of 144

POS / EPS EPS / POS POS / EPS EPS / POS

Channel Channel Channel Channel

Request
Request

Process
Response
Timeout hangs!

Send()
Response
gets an
error

Processing Sequence
POS EPS
Channel 0 Channel 1 Channel 1 Channel 0

CardRequest/ServiceRequest

DeviceRequest

DeviceResponse

DeviceRequest

DeviceResponse

CardResponse/ServiceResponse

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 50 of 144

Timeout Handling
POS EPS
Channel 0 Channel 1 Channel 1 Channel 0

Connecttion request
Timeout T0
CardRequest/ServiceRequest

Connect

Timeout T0

DeviceRequest
Timeout T2
DeviceResponse

Timeout T1
Connect

Timeout T0

DeviceRequest

Timeout T2

DeviceResponse

CardResponse/ServiceResponse

Timeout T3
CloseSocket

There are several Timeouts on the lower technical level defined.

Timeout T0 means the time on the EPS or POS side between a successful connection and the receiving of a complete
XML-Message.
 After this timeout the EPS will close the socket anyway.

Timeout T1 means the time on the POS side between the CardServiceRequest / ServiceRequest and
CardServiceResponse / ServiceResponse.
 After this timeout the POS will close the socket anyway. The EPS will react on the exception caused by the socket
closure differently according to the process status in handling the CardServiceRequest:
If the process was completed, maintain the result sent in the CardServiceResponse
If the process was not completed and therefore aborted, keep the failure result as it would be sent in a
CardServiceResponse
Timeout T2 means the time on the EPS side between the DeviceRequest from EPS and the DeviceResponse from
POS.
The Timeout T2 is conceptually different from the Timeout tags possibly defined within the DeviceRequest: the Timeout
tag in the XML message defines an application timeout on the user input; even if logically independent, the consequent
relationship is that when the Timeout tag is set, T2 must be greater than it. Another possible Timeout tag is possible as
display timeout to show a message: since it does not mean the DeviceResponse to wait till the message is erased there
is no implication at all.
 After this timeout the EPS will consider the operation failed and react accordingly depending on the application
process that failed:
repeat the request
Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 51 of 144

ignore the exception

send a failure result in the CardServiceResponse
 The POS tries to get the status of the last Request by sending a CardServiceRequest with the RequestType
“RepeatLastMessage”. The EPS-Client sends a CardServiceResponse with the OriginalHeader tag.

Timeout T3 means the time on the EPS side between the CardServiceResponse from EPS and the CloseSocket signal
from POS.
 After this timeout the EPS will close the socket anyway.

The time on the POS side between the last XML-Message from POS to the EPS-Client and the next XML-Message from
the EPS-Client (DeviceRequest) is unpredictable, since depending on the application design; therefore no timeout is
implemented on such sequence.

Setting of the time-out values is implementation specific. Because certain time-outs depend on the application process
and on the Eft Architecture, for example on the response time of on-line switching systems (i.e. bank cards), setting
time-out values is critical to obtain performance and flexibility.

Example of situation when Timeout T0 expires:

POS EPS
Channel 0 Channel 1 Channel 1 Channel 0

Connect
Timeout T0
POS
takes longer
than
Timeout T0 Closesocket()
CardRequest/ServiceRequest

POS gets a send error

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 52 of 144

Example of a situation when Timeout T1 expires:

POS EPS
Channel 0 Channel 1 Channel 1 Channel 0

CardRequest/ServiceRequest

DeviceRequest

DeviceResponse

Timeout T1

DeviceRequest

DeviceResponse

EPS-Client
takes longer
than
Timeout T1

Closesocket()
CardResponse/ServiceResponse

EPS gets a send error

After a Timeout T1 the POS tries to get the status of the last Request by sending a CardServiceRequest with the same
RequestID and the same data of the last Request. If the EPS check, that the RequestID of the new
CardServiceRequest is the same than the last CardServiceRequest it starts no new authorization. Instead of that, it
sends the CardServiceResponse with the data of the last authorization, as it had recorded.
POS EPS

Channel 0 Channel 1 Channel 1 Channel 0

CardRequest/ServiceRequest

DeviceRequest

DeviceResponse

DeviceRequest

DeviceResponse

CardResponse/ServiceResponse
Connection error

CardRequest/ServiceRequest (RepeatLastMessage)

CardResponse/ServiceResponse

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 53 of 144

Example of a situation when Timeout T2 expires:

POS EPS
Channel 0 Channel 1 Channel 1 Channel 0

CardRequest/ServiceRequest

DeviceRequest

Timeout T2
DeviceResponse

DeviceRequest

POS Timeout T2
takes longer
than
Timeout T2
DeviceResponse

EPS gets a Time out error:

Repeats DeviceRequest
or ignores the error or
Sends a CardServiceResponse
/ Service Response with
Result failure.

Asynchronous DeviceRequest
It is possible, that the EPS processes a DeviceRequest without a previous CardServiceRequest or ServiceRequest.
Exactly the same timeouts T0,T2,T3 apply to such message exchange.
POS EPS
Channel 0 Channel 1 Channel 1 Channel 0
Connect

Timeout T0
DeviceRequest

Timeout T2
DeviceResponse

Timeout T3
CloseSocket

4.7 Configuration update

Configuration is to be managed by files delivered in the PC/server agreed location by the chosen application
environment.

4.8 SW Update
SW updates must be managed carefully when the applications work on the same machine.
Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 54 of 144

The system must be logged off before an update can take place.
The update of one application is implemented bothering as less as possible the other application.

4.9 XML encoding

All XML messages are using the processing instruction encoding=”UTF-8”. This allows the transport of Unicode
characters and does not overload the telegram lengths when one byte ASCII characters are being used (UTF -16 would
double the telegram size).

We would recommend explicitly to define UTF-8 encoding in the POSEPS standard for following reasons:

 UTF-8 is suitable for world-wide use due to Unicode character support

 UTF-8 does not blow up the telegram length when using ASCII characters 0...127
Free encoding is not recommended, because then it is necessary to extend the telegram header with an encoding
indicator in order to enable the recipient to distinguish between 1-byte character set (e.g. ANSI), MBCS character set
(e.g. UTF-8) and two-byte character set (e.g. UTF-16)!

4.10 Boolean Values

According to the W3C consortium, Boolean variables may have the values “false” and “true” as well as “0” and “1”. On
the other hand not all parsers are accepting “0” and “1” during validation. Therefore the IFSF POS-EPS interface
accept only “true” and “false” as Boolean values.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 55 of 144

5. POS EPS TESTING INTEROPERABILITY RULES

Even if the syntax of the XML messages is accepted (XML schema compliant), this does not mean that the two
applications are successfully interoperating. The XML schemas were defined without a full definition of dependencies
among data, since this would involve the full definition on how the applications work: the protocol should instead leave
flexibility as ISO8583 does in the on-line standard protocol to the Host.

The Interoperability specification involve then the testability of the applications, so the interoperability is possible to b e
tested only in the phase of system integration.

There is a basic list of actions to achieve a minimum interoperability testing:

Define the topology of the implementation

Define the CardServiceRequest to be managed
Define the ServiceRequest to be managed
Define the DeviceRequest to be managed POS-EPS and for which device
Define the DeviceRequest to be managed POS-EPS and for which device
For each of the defined Request populate the message data clearly stating which of the optional fields are to be
populated, under which condition
Do the same for the responses
For fields that involve definition of acceptable values, define the values to be used

Of course behind this the true interoperability is the application process handled by the POS and by the EPS that must
match.
All the messages to the Pin-pad depend on the interface implemented between the Pin-pad and the EPS application,
thus they cannot be included in an overall interoperability test: this test will operate between the POS and the EPS
applications considering the Pin-pad as part of the EPS application.

Example – Receipt

The receipt is provided by EPS and by definition it is the Eft part only. Both must handle the receipt in a coherent
manner, as in the example below:

Receipt is composed of the fundamental parts:

1. Eft Payment receipt – copy for cashier  EPS

2. Sale (fiscal in most of cases) receipt  POS
3. Eft Payment receipt  EPS
4. Loyalty receipt (awarding or redemption)  EPS
5. Courtesy/Other message  POS

2 is obviously always present when a sale is present.

1 and 3 are always present together in case of successful Eft payment.1 is printed alone with response code error
message in case of failure/decline.
Sale receipt is fiscal receipt unless the Eft payment (e.g. euroShell) or the loyalty redemption involves that receipt is a
delivery note.
Loyalty is present in case of loyalty and is either for awarding or for redemption.
The part 1 is withheld by the cashier (signed by customer if it is the case).
The part 2+3+4 is taken by the customer as a unique piece.
Current courtesy message is fixed (thanking and greetings).
Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 56 of 144

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 57 of 144

Example – Flow for an indoor payment

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 58 of 144

Device
POS/Sell EPS Proxy - AC
PinPad

CardServiceRequest
Loyalty
LoyaltySwipe DeviceRequest
Prompt
IN:CardReader Customer
OUT:'PlsSwipe' Swipes
Card
Magstripe
DeviceResponse Loyalty
Card OK Card
(card Track)
Card
Validation

CardServiceResponse
LoyaltySwipe
Items rang up
completed Magstripe
- Tender selected CardServiceRequest Payment
DeviceRequest
CardPaymentLoyaltyAward Card
IN:CardReader
OUT:'PlsSwipe' Customer
Swipes
Card
DeviceResponse
(card Track)
Card
Validation
Card OK DeviceRequest
IN:ProcessPIN
Customer
OUT:'Pls Insert PIN'
keys PIN in
PIN
verification
Card Dialogue Processing: or
Any specific input/output is PIN
managed. PinPad
encryption
E.g. swipe second card, processes
Insert driverID, PIN
Insert VehicleID, DeviceResponse
Insert replacementcar, (encrypted PIN
etc. or result)
Amount pre-fixed per card
or to be inserted by
customer DeviceRequest
IN:keyb.input Customer
OUT:'Pls Insert mileage' keys
miles in

DeviceResponse
Off-line (mileage)
authorisation
or
On-line DeviceRequest
msg build IN:CalculateMAC
On-line
transaction
DeviceResponse
(MAC)

ISO8583 Acquirer/
1200 Issuer
Authorisation
ISO8583 Process
1210

DeviceRequest
IN:ValidateMAC

DeviceResponse Transaction
(MAC result) Authorisation
OK
DeviceRequest
IN:UpdateKey

DeviceResponse
(result)

DeviceRequest
OUT: Eft + Loyalty
receipt
Printout
DeviceResponse

DeviceRequest
IN/OUT: CashierConfirmation
Cashier
Verification
DeviceResponse

CardServiceResponse
Cashier CardPaymentLoyaltyAward
verification of
receipt and
customer
OK

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 59 of 144

6. ADDITIONAL IMPLEMENTATION EXAMPLES

6.1 Printing card receipts

The card receipts are provided by the EPS. The application logic of the POS and of the EPS must know which is the
conventional flow for the recipt. Both the application can handle the receipt in a coherent manner, as in the example
below:

Receipt is composed of the fundamental parts:

Eft Payment receipt – copy for cashier  EPS

Sale (fiscal in most of cases) receipt  POS
Eft Payment receipt  EPS
Loyalty receipt (awarding or redemption)  EPS
Courtesy/Other message  POS

The POS application then will receive:

One receipt DeviceRequests for all the failed transaction (printout of failure reason to document the customer).
Two receipt DeviceRequest for all the payment only transactions (in case of signature verification, a furrther
DeviceRequest to the cashier devices might enable the signature confirmation prompt; this wuold be sent between
the two receipt DeviceRequest ).
Three receipt DeviceRequest in case of payment and loyalty (plus the optional signature verification). This
example assumes that loyalty is calculated through the EPS application.
One receipt DeviceRequest in case of loyalty only. This example assumes that loyalty is calculated through the
EPS application.

6.2 Track data coding

The latest release of the guidelines has introduced the coding of track data as string, to solve few problems. The coding
is used as for the ISO8583 protocol and the table below clarifies further the coding.

Track 1 The Track1 contains the alphanumeric string of the track 1 converted in UTF 8,
Format without the start sentinel, the end sentinel, and the LRC.
An example XML encoding of the Track1 element is presented below:
<Track1> AVAPENKA CERT. SCHODY ^RAC 01-28 ^
^00</Track1>
0000 3C 54 72 61 63 6B 31 3E 20 41 56 41 50 45 4E 4B |<Track1> AVAPENK|
0010 41 20 43 45 52 54 2E 20 53 43 48 4F 44 59 20 20 |A CERT. SCHODY |
0020 20 20 20 20 5E 52 41 43 20 30 31 2D 32 38 20 20 | ^RAC 01-28 |
0030 20 20 20 20 20 20 20 20 20 20 20 5E 20 20 20 20 | ^ |
0040 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 | |
0050 20 20 5E 30 30 3C 2F 54 72 61 63 6B 31 3E | ^00</Track1> |

Track 2 The Track2 contains the hexadecimal digits converted in UTF 8 (adding the
Format hexadecimal value 30 to each hexadecimal digit) of the track 2, without the start
sentinel, the end sentinel, and the LRC.
The separator is coded as the character '=' (binary value 3D).
An example XML encoding of the Track2 element is presented below:
<Track2>7079322134071003003=93050000000000000</Track2>
0000 3C 54 72 61 63 6B 32 3E 37 30 37 39 33 32 32 31 |<Track2>70793221|
0010 33 34 30 37 31 30 30 33 30 30 33 3D 39 33 30 35 |34071003003=9305|
0020 30 30 30 30 30 30 30 30 30 30 30 30 30 3C 2F 54 |0000000000000</T|
0030 72 61 63 6B 32 3E |rack2> |

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 60 of 144

Track 3 The Track3 field has the same XML format than the Track2 field.
Format Start sentinel, end sentinel, and LRC are absents.

6.3 Swipe Ahead

Processing The standard processing flow of the swipe ahead procedure is presented in the
Flow figure below:
1) The POS scans the items to pay.
2) The customer starts the card payment transaction during the scanning of
the items, and the EPS processing the beginning of the transaction (magstripe
reading, ask question to the cardholder, start smartcard application
transaction, read card data…).
3) The EPS freezes the transaction when a missing POS data is necessary to
the transaction processing.
4) At the end of the scanning, the POS send a CardPayment reaquest tto
process the payment by card.
5) The EPS continues the transaction with the POS data, and answer to the
POS with the result of the payment.
6) The POS finishes the transaction and sends a ChangeCardreaderStatus
request with the StatusReq attribute to "Activate" in the request message.
7) The EPS reinitialise the payment transaction context of the POP, and can
start a new transaction with the customer or the POS.

Notes The payment transaction can contain a loyalty transaction without any change of the
processing flow.
The start of the payment transaction before an explicit request from the POS is only
an option allowing substantial reduction of transaction time. The customer can
alternately start the transaction after the POS request.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 61 of 144

Error Case Two cases of errors can occur:

1) The POS doesn't send a CardPayment request, for instance the cardholder
changes his mind and after the start-up of the payment, and wants to pay
cash. The transaction is reset at the reception of the CardreaderStatus request
message.
2) The cardholder wants to change the flow of the payment, abort the
transaction, or use another card… This case of error is similar to the
processing of the payment without swipe ahead, and is dependant of the EPS
implementation.

Change The ChangeCardreaderStatus message pair is a CardService message, the request

Cardreader contains a mandatory POSData structure with a specific attribute StatusReq
Status containing the requested status of the POP card reader.
Messages The ServiceRequest.xsd includes a new attribute of the POSData element:
<xs:attribute name="StatusReq" type="StatusReqType" use="optional"/>
The IFSF_BasicTypesCards.xsd includes the new simple type StatusReqType:
<xs:simpleType name="StatusReqType"> <xs:annotation> <xs:documentation>
Diagnosis status request</xs:documentation> </xs:annotation>
<xs:restriction base="xs:string">
<xs:enumeration value="Online"/>
<xs:enumeration value="POPinit"/>
<xs:enumeration value="POPinitAll"/>
<xs:enumeration value="Activate"/>
<xs:enumeration value="Deactivate"/>
</xs:restriction> </xs:simpleType>

6.4 DeviceRequest for menu

TextLine-elements with attribute „MenuItem“ are single components of complete menu structure. One or
more preceding TextLine-elements without „MenuItem“ are the headline(s) of the menu.

EPS -> POS:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<DeviceRequest RequestType="Input" WorkstationID="999" ApplicationSender="EPS01" RequestID="1254"
SequenceID="1" TerminalID="15034001" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceRequest.xsd">
<Output InputSynchronize="1" OutDeviceTarget="CashierDisplay">
<TextLine Erase="1">Service menu</TextLine>
<TextLine MenuItem="1">Function A</TextLine>
<TextLine MenuItem="2">Function B</TextLine>
<TextLine MenuItem="5">Function C</TextLine>
</Output>
<Input InDeviceTarget="CashierKeyboard">
<Command>GetMenu</Command>
</Input>
</DeviceRequest>

Cashier selects "Function C" !

POS -> EPS:

<?xml version="1.0"?>
<DeviceResponse RequestType="Input" ApplicationSender="EPS01" OverallResult="Success"
RequestID="1254" SequenceID="1" POPID="10" TerminalID="15034001" WorkstationID="999"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceResponse">
<Output OutDeviceTarget="CashierDisplay" OutResult="Success"/>
<Input InDeviceTarget="CashierKeyboard" InResult="Success">
<InputValue>
<InNumber>5</InNumber>
</InputValue>
</Input>

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 62 of 144

</DeviceResponse>

The number of selected menu item is returned as result !

6.5 DeviceRequest / Event

Example: EventType = CardInserted
Customer inserts a magn. or a chip card.

EPS -> POS:

<?xml version="1.0" encoding="UTF-8"?> <DeviceRequest RequestType="Event" WorkstationID="999"
ApplicationSender="EPS01" RequestID="1255" SequenceID="1" POPID="10" TerminalID="15034001"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceRequest.xsd" >
<Event EventType="CardInserted">
<EventData>
<CardValue>7033136123456789999</CardValue>
</EventData>
</Event>
</DeviceRequest>

POS responds with a list of available dispensers.

POS -> EPS:

<?xml version="1.0" encoding="UTF-8"?> <DeviceResponse RequestType="Event" WorkstationID="999"
ApplicationSender="EPS01" RequestID="1255" SequenceID="1" POPID="10" TerminalID="15034001"
OverallResult="Success" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceResponse.xsd" >
<EventResult>
<Dispenser>1</Dispenser>
<Dispenser>2</Dispenser>
<Dispenser>5</Dispenser>
</EventResult>
</DeviceResponse>

EPS server asks customer to choose the dispenser (on pinpad display).

EPS -> POS:

<?xml version="1.0" encoding="UTF-8"?> <DeviceRequest RequestType="Event" WorkstationID="999"
ApplicationSender="EPS01" RequestID="1255" SequenceID="2" POPID="10" TerminalID="15034001"
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceRequest.xsd" >
<Event EventType="DispenserSelected">
<EventData>
<Dispenser>2</Dispenser>
</EventData>
</Event>
</DeviceRequest>

Customer selected dispenser number „2“.

POS -> EPS:

<?xml version="1.0" encoding="UTF-8"?> <DeviceResponse RequestType="Event" WorkstationID="999"
ApplicationSender="EPS01" RequestID="1255" SequenceID="2" POPID="10" TerminalID="15034001"
OverallResult="Success” xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceResponse.xsd" >
<EventResult>
<ProductCode>12</ProductCode>
<ProductCode>34</ProductCode>
<ProductCode>56</ProductCode>
</EventResult>

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 63 of 144

</DeviceResponse>

POS responds with a list of available product codes for the selected dispenser. EPS server can do a restriction
check.

6.6 ServiceRequest / Administration

POS -> EPS:
<?xml version="1.0" encoding="UTF-8"?> <ServiceRequest RequestType="Administration"
ApplicationSender="POSsel01" WorkstationID="1" RequestID="1254" xmlns="http://www.nrf-
arts.org/IXRetail/namespace" mlns:IFSF=http://www.ifsf.org/
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation="http://www.nrf-
arts.org/IXRetail/namespace C:\Schema\ServiceRequest.xsd">
<POSdata>
<POSTimeStamp>2002-10-07T14:39:09-01:00</POSTimeStamp>
<ClerkID>0</ClerkID>
</POSdata>
</ServiceRequest>

EPS -> POS:

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <ServiceResponse
RequestType="Administration" ApplicationSender="POSsel01" WorkstationID="1" RequestID="1254"
POPID="10" OverallResult="Success" xmlns=http://www.nrf-arts.org/IXRetail/namespace
xmlns:IFSF=http://www.ifsf.org/ mlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace C:\Schema\ServiceResponse.xsd"/>

6.7 Scenario of having the sales/transaction details changing depending on

the card swiped
Exceptional scenarios exist involving the operation details being modified depending on the card swiped for the
operation. One example might be having a different merchant fee depending on the card swiped: this would not be a
problem unless the merchant fee is transferred to the customer. The simplest solution would be to answer in the
CardServiceRespoonse the updated values of the SaleItems.
A further exception would be having a different taxation calculation that only the Sellapplication can calculate: in such
scenario the adviced solution is to use the DeviceRequest message during the process handled by EPS: the EPS will
send the card read information to the Sell application which willreturn the SaleItems correctly updated.

7. EXAMPLE OF IMPLEMENTATION FOR OUTDOOR PAYMENT TERMINAL

The following example addresses the main implementation of POS-EPS for outdoor and customer operated terminals.
First a summary on the COPT activity is given as introduction, then the example is illustrated by all the necessary flows
of messages and message description.
The flows for CRID (CardReader inDispenser) is designed for a payment device dedicate to a refillingposition,while the
flow for OPT is designed for a device that enables a pump/refilling position selection.
The example takes into account a loyalty awarding combined functionality.
No car wash or other different processes are considered in this example, but they can be implemented with simil ar
flows.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 64 of 144

7.1 COPT
Today the POS-EPS protocol can be used outdoor using the following two architectures:

Customer display
And buttons SELL
application
Printer + EPS receipt

MSR

Pin-Pad PED Driver

XML IFSF POS/EPS
ICC read/write over TCP/IP socket

Other applications:
EPS server Sell server or BOS
Etc.

Site Server

IFSF/ISO8583-OIL

Host

XML IFSF POS/EPS

Printer Printer
over TCP/IP socket

MSR MSR
Unmanned SELL Other applications:
EPS server application Sell server or BOS
Pin-Pad Pin-Pad + Etc.
Client + EPS receipt
ICC read/write ICC read/write
Site Server

IFSF/ISO8583-OIL

Host

The IFSF COPT workgroup is working on the possibility to get a plug & play implementation, PINpad independent, so
that area is out of scope for this document.
The available solution through POS-EPS is not optimised for performance over a low bandwidth communication and it
requires system integration effort.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 65 of 144

7.2 CRID Payment process

CardPreAuthorisationLoyaltySwipe

LoyaltySwipe

Refilling

CardFinancialAdvice

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 66 of 144

7.3 OPT Payment process

CardPreAuthorisation-
LoyaltySwipe

CardPreAuthorisation-
LoyaltySwipe

Loyalty CardPreAuthorisation-
Swipe LoyaltySwipe

Loyalty
Swipe

Loyalty
Swipe
Refilling Pump1

Refilling Pump2

Refilling Pump3

CardFinancialAdvice

CardFinancialAdvice

CardFinancialAdvice

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 67 of 144

7.4 CardPreAuthorizationLoyaltySwipe (CRID)

Loyalty + Payment

POS/Sell EPS PINpad Host

CardPreAuthorisationLoyaltySwipe Request
Read Card

Abort Customer
no timeout
Request inserted
endless loop
possible Read Card Resp. Loyalty card

Read Card
Customer
Device Request no timeout inserted
RequestType = Event endless loop Payment card
Read Card Resp.
Customer inserted card

POS decision:
preAuthorisation
Device Response

Device Request
PrinterStatus
Device Response

process preAuthorisation

PreAuthorisation Request (1100)

PreAuthorisation Request Response (1110)

CardPreAuthorisationLoyaltySwipe Response

CardFinancialAdvice Request

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 68 of 144

Payment only

POS/Sell EPS PINpad Host

CardPreAuthorisationLoyaltySwipe Request
Read Card
Customer
Abort Device Request no timeout inserted
Request RequestType = Event endless loop Payment card
Read Card Resp.
possible Customer inserted card

POS decision:
preAuthorisation
Device Response

Device Request
PrinterStatus
Device Response

process preAuthorisation

PreAuthorisation Request (1100)

PreAuthorisation Request Response (1110)

CardPreAuthorisationLoyaltySwipe Response

LoyaltySwipe Request
or
CardFinancialAdvice Request

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 69 of 144

7.5 CardPreAuthorization (OPT)

Loyalty + Payment

POS/Sell EPS PINpad Host

CardPreAuthorisationLoyaltySwipe Request
Read Card
Abort Customer
no timeout
Request inserted
endless loop
possible Read Card Resp. Loyalty card

Read Card

no timeout Customer
Device Request endless loop inserted
Read Card Resp. Payment card
RequestType = Event
Customer inserted card

POS decision:
preAuthorisation Device Response

Device Request
RequestType = Event
Customer selected dispenser

Device Response
Device Request
PrinterStatus

Device Response

process preAuthorisation

PreAuthorisation Request (1100)

PreAuthorisation Request Response (1110)

CardPreAuthorisationLoyaltySwipe Response

CardPreAuthorisationLoyaltySwipe Request
or
LoyaltySwipe Request

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 70 of 144

Payment only

POS/Sell EPS PINpad Host

CardPreAuthorisationLoyaltySwipe Request Read Card

Abort no timeout Customer

Request Device Request endless loop inserted
Read Card Resp. Payment card
possible RequestType = Event
Customer inserted card

POS decision:
preAuthorisation Device Response

Device Request
RequestType = Event
Customer selected dispenser

Device Response
Device Request
PrinterStatus

Device Response

process preAuthorisation

PreAuthorisation Request (1100)

PreAuthorisation Request Response (1110)

CardPreAuthorisationLoyaltySwipe Response

CardPreAuthorisationLoyaltySwipe Request
or
LoyaltySwipe Request

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 71 of 144

7.6 Loyalty Swipe (CRID + OPT)

POS/Sell EPS PINpad Host

LoyaltySwipe Request
Read Card

Abort no timeout
Request endless loop
Read Card Resp.
possible

LoyaltySwipe Response
Customer takes
the nozzle out
(CRID)
Customer select
a pump (OPT)

7.7 CardFinancialAdvice (CRID)

POS/Sell EPS PINpad Host

CardFinancialAdvice Request

Device Request
with ticket data

Device Response

process FinancialAdvice
CardFinancialAdvice Response
CardPreAuthorisation Request
Financial Advice Request(1220)

Financial Advice Request Response (1230)

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 72 of 144

7.8 CardFinancialAdvice (OPT)

POS/Sell EPS PINpad Host

CardPreAuthorisationLoyaltySwipe Request
Read Card

no timeout
endless loop
Read Card Resp.
Abort Request

CardPreAuthorisationLoyaltySwipe Response

CardFinancialAdvice Request

Device Request with ticket data

Device Response

process FinancialAdvice
CardFinancialAdvice Response

CardPreAuthorisation Request
Financial Advice Request(1220)

Financial Advice Request Response (1230)

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 73 of 144

7.9 Ticket print (CRID + OPT)

POS/Sell EPS PINpad Host

CardPreAuthorisationLoyaltySwipe Request
Read Card

Abort no timeout
Request endless loop
Device Request Read Card Resp.
possible
RequestType = Event
Customer inserted card
POS decision:
ticket print

Device Response

CardPreAuthorisationLoyaltySwipe Response

CardPreAuthorisationLoyaltySwipe Request

7.10 POS EPS XML Interface

The following examples are only a possible implementation exemplification.

CardPreAuthorizationLoyaltySwipe Request
This message will be used to trigger a PreAuthorization process in the EPS Server solution. The POS system sends it
after startup and the EPS Server waits till the customer has inserted a card or the timer expired (timer value = for
example 5 minutes). In case of timer expiry the EPS Server sends a CardPreAuthorization response with OverallResult
= TimedOut. The POS starts again a CardPreAuthorization.

The customer has two possiblities:

insert a loyalty card first and then a payment card or
insert immediately the payment card.

In the first case the EPS Server sends the loyalty card data (PAN) to the POS within CardPreAuthLoySwipe-response
message. In the second case the POS sends a separate LoyaltySwipe Request to trigger the Loyalty card reading.

After the customer has inserted a payment card the EPS Server will inform the POS system via the Device request with
RequestType “Event”, that a customer has inserted a payment card. Before the POS receives this request, it is possible
to abort the PreAuthorization request and the EPS will send a CardPreAuthorization response with OverallResult =
Aborted. If the customer change the default language on the dispenser or vending machine, it sends an AbortRequest
message to the EPS server and after a successful abort it sends a new CardPreAuthorization with the correct language
code.

The table describes the XML message layout and the parameter description. It also describes if the parameter is
mandatory or optional.

XML Parameter Presence Description

RequestType M CardPreAuthorizationLoyaltySwipe

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 74 of 144

WorkstationID M Identification of single POS at EPS. Valid values: 1..998

0 and 999 are reserved for EPS.
ApplicationSender M Name of sending application.
RequestID M ID of request for univocal referral.
POSTimeStamp M Date and time.
OutdoorPosition O Number of dispenser.
LanguageCode O PIN-Pad language.
LoyaltyFlag M true
TotalAmount O Amount to pre-authorise.
If present and valid (depending on kind of payment and host
system) it will be used.
If not present or not valid a configuration value will be used.

Example:
<?xml version="1.0"?>
<CardServiceRequest RequestType="CardPreAuthorizationLoyaltySwipe" ApplicationSender="POSctr01"
WorkstationID="1" RequestID="1254" xmlns="http://www.nrf-arts.org/IXRetail/namespace"
xmlns:IFSF="http://www.ifsf.org/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace C:\Schema\CardRequest.xsd">
<POSdata LanguageCode="cs">
<POSTimeStamp>2002-10-07T14:39:09-01:00</POSTimeStamp>
<OutdoorPosition>1</OutdoorPosition>
</POSdata>
<Loyalty LoyaltyFlag="true"/>
<TotalAmount>50.00</TotalAmount>
</CardServiceRequest>

CardPreAuthorizationLoyaltySwipe Response
This message is the corresponding response message to the CardPreAuthorization request and is
sent from the EPS server to the POS. The following OverallResults are possible:
Success CardPreAuthorization was successful
Failure CardPreAuthorization was not successful
Aborted CardPreAuthorization was successful aborted
TimedOut CardPreAuthorization timer was expired
Busy CardPreAuthorization in progress or maintenance processing

XML Parameter Presence Description

RequestType M mirrored from request

WorkstationID M mirrored from request
ApplicationSender M mirrored from request
RequestID M mirrored from request
OverallResult M Result of transaction
TerminalID M
TerminalBatch M
STAN M
TotalAmount M Pre-authorised amount.
AcquirerID M
ApprovalCode M
CardPAN M
TimeStamp M

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 75 of 144

CardCircuit M
LoyaltyAllowed M Flag if loyalty is allowed.
RestrictionCodes C List of allowed product codes.
If not present all products the dispenser supports are allowed.
LoyaltyFlag M mirrored from request
LoyaltyPAN C PAN of loyalty card. Present when customer used loyalty card.

Example:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<CardServiceResponse RequestType="CardPreAuthorizationLoyaltySwipe" ApplicationSender="POSctr01"
WorkstationID="1" RequestID="1254" OverallResult="Success" xmlns:IFSF="http://www.ifsf.org/"
xmlns="http://www.nrf-arts.org/IXRetail/namespace" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace C:\Schema\CardResponse.xsd">
<Terminal TerminalID="15034001" TerminalBatch="0000000126" STAN="000456"/>
<Tender>
<TotalAmount>80.00</TotalAmount>
<Authorization AcquirerID="44" CardPAN="45000000120378901" ApprovalCode=”123456”
TimeStamp="2002-10-07T14:40:06-01:00" CardCircuit="euroShell"
LoyaltyAllowed="1"/>
<RestrictionCodes>12</RestrictionCodes>
<RestrictionCodes>345</RestrictionCodes>
</Tender>
<Loyalty LoyaltyFlag="1">
<LoyaltyCard LoyaltyPAN="70043711111111112"/>
</Loyalty>
</CardServiceResponse>

CardFinancialAdvice Request
This message will be used to trigger a financial advice process in the EPS Server solution. The POS system sends this
message after a completed refilling process or after a timer expiry. For each successful CardPreAuthorization the POS
must send a corresponding CardFinancialAdvice. In case of timer expiry or the customer takes only the nozzle from the
dispenser without refilling, the POS sends a CardFinancialAdvice request message with zero amount.

The table describes the XML message layout and the parameter description. It also describes if the parameter is
mandatory or optional.

XML Parameter Presence Description

RequestType M CardFinancialAdvice
WorkstationID M Identification of single POS at EPS. Valid values: 1..998
0 and 999 are reserved for EPS.
ApplicationSender M Name of sending application.
RequestID M ID of request for univocal referral.
POSTimeStamp M Date and time.
OutdoorPosition M Number of dispenser.
LanguageCode O PIN-Pad language.
OriginalTransaction M Reference data of CardPreAuthorization-response message
-> TerminalID
-> TerminalBatch
-> STAN
-> TimeStamp
TotalAmount M Actual consumed amount.
SaleItem M Selected product on dispenser.
-> ItemID M
-> ProductCode M
-> Amount M

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 76 of 144

-> UnitMeasure M
-> UnitPrice M
-> Quantity M
-> TaxCode M
-> Additional ProductCode O

Example:

<?xml version="1.0"?>
<CardServiceRequest RequestType="CardFinancialAdvice" ApplicationSender="POSctr01" WorkstationID="1"
RequestID="1255" xmlns="http://www.nrf-arts.org/IXRetail/namespace" xmlns:IFSF="http://www.ifsf.org/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace C:\Schema\CardRequest.xsd">
<POSdata LanguageCode="cs">
<POSTimeStamp>2002-10-07T14:39:09-01:00</POSTimeStamp>
<OutdoorPosition>1</OutdoorPosition>
</POSdata>
<OriginalTransaction TerminalID="15034001" TerminalBatch="0000000126" STAN="000456"
TimeStamp="2002-10-07T14:40:06-01:00"/>
<TotalAmount>26.30</TotalAmount>
<SaleItem ItemID="1">
<ProductCode>345</ProductCode>
<Amount>26.30</Amount>
<UnitMeasure>LTR</UnitMeasure>
<UnitPrice>1.000</UnitPrice>
<Quantity>26.30</Quantity>
<TaxCode>1</TaxCode>
<AdditionalProductCode>08813254789873</AdditionalProductCode>
</SaleItem>
</CardServiceRequest>

CardFinancialAdvice Response
The CardFinancialAdivce response message is the corresponding message to the CardFinancialAdvice request
message. The following OverallResults are possible:
Success  Financial advice processing was successful
Busy Financial advice or PreAuthorization in progress
Failure  Financial advice processing wasn’t successful, because CardPreAuthorization transactions not
found.

XML Parameter Presence Description

RequestType M mirrored from request
WorkstationID M mirrored from request
ApplicationSender M mirrored from request
RequestID M mirrored from request
OverallResult M Result of transaction
TerminalID M
TerminalBatch M
STAN M
TotalAmount M
AcquirerID M
CardPAN M
TimeStamp M
FiscalReceipt M Depends on card type.
CardCircuit M

Example:

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 77 of 144

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<CardServiceResponse RequestType="CardFinancialAdvice" ApplicationSender="POSctr01" WorkstationID="1"
RequestID="1255" OverallResult="Success"
xmlns="http://www.nrf-arts.org/IXRetail/namespace" xmlns:IFSF="http://www.ifsf.org/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace C:\Schema\CardResponse.xsd">
<Terminal TerminalID="15034001" TerminalBatch="0000000126" STAN="000457"/>
<Tender>
<TotalAmount Currency="EUR">26.30</TotalAmount>
<Authorization AcquirerID="44" CardPAN="45000000120378901" FiscalReceipt="1"
TimeStamp="2002-10-07T14:45:06-01:00" CardCircuit="euroShell"/>
</Tender>
</CardServiceResponse>

CardFinancialAdviceLoyaltyAward
In case of loyalty awarding the point calculation might be calculated in the central host, as central awarding.
The loyalty card can be hanfdled as full Track data or simply as PAN: the sceond option is considered in the example.
Under this assumptions the above example of CardFinancialAdvice would be modified as it follows:

XML Parameter Presence Description

RequestType M CardFinancialAdvice
WorkstationID M Identification of single POS at EPS. Valid values: 1..998
0 and 999 are reserved for EPS.
ApplicationSender M Name of sending application.
RequestID M ID of request for univocal referral.
POSTimeStamp M Date and time.
OutdoorPosition M Number of dispenser.
LanguageCode O PIN-Pad language.
Loyalty O If loyalty card was swiped
-> LoyaltyFlag
LoyaltyCard O Mandatory if loyalty card swiped
-> LoyaltyPAN
OriginalTransaction M Reference data of CardPreAuthorization-response message
-> TerminalID
-> TerminalBatch
-> STAN
-> TimeStamp
TotalAmount M Actual consumed amount.
SaleItem M Selected product on dispenser.
-> ItemID M
-> ProductCode M
-> Amount M
-> UnitMeasure M
-> UnitPrice M
-> Quantity M
-> TaxCode M
-> Additional ProductCode O

Example:

<?xml version="1.0"?>
<CardServiceRequest RequestType="CardFinancialAdvice" ApplicationSender="POSctr01" WorkstationID="1"
RequestID="1255" xmlns="http://www.nrf-arts.org/IXRetail/namespace" xmlns:IFSF="http://www.ifsf.org/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace C:\Schema\CardRequest.xsd">
<POSdata LanguageCode="cs">

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 78 of 144

<POSTimeStamp>2002-10-07T14:39:09-01:00</POSTimeStamp>
<OutdoorPosition>1</OutdoorPosition>
</POSdata>
<Loyalty LoyaltyFlag=”true”>
<LoyaltyCard LoyaltyPAN=”7004164123456789”></LoyaltyCard>
</Loyalty>
<OriginalTransaction TerminalID="15034001" TerminalBatch="0000000126" STAN="000456"
TimeStamp="2002-10-07T14:40:06-01:00"/>
<TotalAmount>26.30</TotalAmount>
<SaleItem ItemID="1">
<ProductCode>345</ProductCode>
<Amount>26.30</Amount>
<UnitMeasure>LTR</UnitMeasure>
<UnitPrice>1.000</UnitPrice>
<Quantity>26.30</Quantity>
<TaxCode>1</TaxCode>
<AdditionalProductCode>08813254789873</AdditionalProductCode>
</SaleItem>
</CardServiceRequest>

CardFinancialAdviceLoyaltyAward Response
With the same assumptions as above, plus the assumption that loyalty acquirer id and batch are not required in the
implementation and the loyalty PAN or card data has not to be repeated (present in the request).
The response example is the following:

XML Parameter Presence Description

RequestType M mirrored from request
WorkstationID M mirrored from request
ApplicationSender M mirrored from request
RequestID M mirrored from request
OverallResult M Result of transaction
TerminalID M
TerminalBatch M
STAN M
TotalAmount M
AcquirerID M
CardPAN M
TimeStamp M
FiscalReceipt M Depends on card type.
CardCircuit M
Loyalty O If loaylty awarding was required
-> LoyaltyFlag
-> LoyaltyTimeStamp
LoyaltyAmount O If Awarding succesful
LoyaltyApprovalCode O If Awarding succesful

Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<CardServiceResponse RequestType="CardFinancialAdvice" ApplicationSender="POSctr01" WorkstationID="1"
RequestID="1255" OverallResult="Success"
xmlns="http://www.nrf-arts.org/IXRetail/namespace" xmlns:IFSF="http://www.ifsf.org/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace C:\Schema\CardResponse.xsd">
<Terminal TerminalID="15034001" TerminalBatch="0000000126" STAN="000457"/>
<Tender>
<TotalAmount Currency="EUR">26.30</TotalAmount>
<Authorization AcquirerID="44" CardPAN="45000000120378901" FiscalReceipt="1"
TimeStamp="2002-10-07T14:45:06-01:00" CardCircuit="euroShell"/>
</Tender>

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 79 of 144

<Loyalty LoyaltyFlag=”true” LoytaltyTimeStamp="2002-10-07T14:45:07-01:00">

<LoyaltyAmount>55</LoyaltyAmount>
<LoyaltyApprovalCode>1039398478</LoyaltyApprovalCode>
</Loyalty>
</CardServiceResponse>

LoyaltySwipe Request

This message will be used to trigger the reading of the loyalty card data within the EPS server.

XML Parameter Presence Description

RequestType M LoyaltySwipe
WorkstationID M Identification of single POS at EPS. Valid values: 1..998
0 and 999 are reserved for EPS.
ApplicationSender M Name of sending application.
RequestID M ID of request for univocal referral.
POSTimeStamp M Date and time.
LanguageCode O PIN-Pad language.
LoyaltyFlag M

Example:

<CardServiceRequest RequestType="LoyaltySwipe" ApplicationSender="POSctr01" WorkstationID="1" RequestID="1256"

xmlns="http://www.nrf-arts.org/IXRetail/namespace" xmlns:IFSF="http://www.ifsf.org/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace C:\Schema\CardRequest.xsd">
<POSdata LanguageCode="cs">
<POSTimeStamp>2002-10-07T14:39:09-01:00</POSTimeStamp>
</POSdata>
<Loyalty LoyaltyFlag="true"/>
</CardServiceRequest>

LoyaltySwipe Response
The LoyaltySwipe response message is the corresponding message to the LoyaltySwipe request. In case of
OverallResult = Success it contains also the loyalty card data. OverallResult = Failure means the loyalty swipe
processing was not successful and OverallResult = Aborted means the processing was aborted successfully.

XML Parameter Presence Description

RequestType M mirrored from request

WorkstationID M mirrored from request
ApplicationSender M mirrored from request
RequestID M mirrored from request
OverallResult M Result of transaction
TerminalID M
LoyaltyFlag M mirrored from request
LoyaltyPAN M PAN of used loyalty card.

Example:

<CardServiceResponse RequestType="LoyaltySwipe" ApplicationSender="POSctr01" WorkstationID="1" RequestID="1256"

OverallResult="Success" xmlns="http://www.nrf-arts.org/IXRetail/namespace" xmlns:IFSF="http://www.ifsf.org/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.nrf-
arts.org/IXRetail/namespace C:\Schema\CardResponse.xsd">

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 80 of 144

<Terminal TerminalID="15034001"/>
<Loyalty LoyaltyFlag="1">
<LoyaltyCard LoyaltyPAN=”022332211001188”/>
</Loyalty>
</CardServiceResponse>

Abort Request
The AbortRequest will be used to abort a running CardRequest. It is only possible to send it before the POS syste m
receives a DeviceRequest with RequestType “Event”. Afterwards the AbortRequest is not supported and will be
ignored. The AbortRequest has no corresponding response message, in case of a successful aborted transaction the
corresponding CardResponse message will be sent with the OverallResult=Aborted, otherwise it was not possible to
abort the transaction and the request will be ignored.

XML Parameter Presence Description

RequestType M AbortRequest
WorkstationID M Identification of single POS at EPS. Valid values: 1..998
0 and 999 are reserved for EPS.
ApplicationSender M Name of sending application.
RequestID M ID of request for univocal referral.
POSTimeStamp M Date and time.

Example:

<CardServiceRequest RequestType="AbortRequest" ApplicationSender="POSctr01" WorkstationID="1" RequestID="1257"

xmlns="http://www.nrf-arts.org/IXRetail/namespace" xmlns:IFSF="http://www.ifsf.org/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace C:\Schema\CardRequest.xsd">
<POSdata>
<POSTimeStamp>2002-10-07T14:39:09-01:00</POSTimeStamp>
</POSdata>
</CardServiceRequest>

Outdoor Events
This new DeviceRequest type will be used to inform the POS system that the customer has inserted a card. After this
request it is not possible to send an AbortRequest message to abort the transaction. The Device Request handling is
supervised by a timer. If it is expired the EPS Server sends a CardPreAuthorization-response with
OverallResult=Failure and is waiting for a new CardPreAuthorization-request.

CardInserted
The POS uses this DeviceRequest to check if a ticket from a refilling before must be print or if a CardPreAuthorization
must be performed. In case of ticket print the POS sends a DeviceResponse with OverallResult = Aborted. That means
the CardPreAuthorization process is stopped and the EPS server is waiting for a new request. In case of OverallResult
= Success the EPS server will continue with the CardPreAuthorization process.

If the POS has no input device for the customer to select the dispenser, it adds the list of available dispensers to the
Device Response. In that case the EPS server sends the Event described below. Otherwise, if the selected dispenser is
known by the POS (CRID or multimedia display), it adds the productcodelist to the Device Response.

DispenserSelected (optional)
If the EPS receives the DeviceResponse from the CardInserted-Event with a dispenser list it processes the dispenser
selection on the PIN-Pad display. If the customer has choosen one of the available dispensers the EPS generates the
described DeviceRequest with EventType = DispenserSelected and sends it to the POS. The corresponding
DeviceResponse contains the productcode list for the selected dispenser.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 81 of 144

In case of CRID the DispenserSelected Device-Request is not required.

Device Request with RequestType = Event

XML Parameter Presence Description

RequestType M Event
WorkstationID M 999
ApplicationSender M EPS01
RequestID M Mirrored from POS request.
SequenceID M
TerminalID M
EventType M CardInserted, DispenserSelected
CardValue O Unique identifying criteria of card. For magn.cards it can be
PAN, for chip cards it can be ef-id
Track2Data O Track 2 data of inserted magn-card.
Dispenser O Selected dispenser

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 82 of 144

Example:

Event = CardInserted

EPS -> POS:

<?xml version="1.0" encoding="UTF-8"?>
<DeviceRequest RequestType="Event" ApplicationSender="EPS01" WorkstationID="999" TerminalID="15034001"
RequestID="1255" SequenceID="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceRequest.xsd">
<Event EventType="CardInserted">
<EventData>
<CardValue>7033136123456789999</CardValue>
<Track2Data>7033136123456789999=0412 ...</Track2Data>
</EventData>
</Event>
</DeviceRequest>

Event = DispenserSelected

EPS -> POS:

<?xml version="1.0" encoding="UTF-8"?>
<DeviceRequest RequestType="Event" ApplicationSender="EPS01" WorkstationID="999" TerminalID="15034001"
RequestID="1255" SequenceID="1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceRequest.xsd">
<Event EventType="DispenserSelected">
<EventData>
<Dispenser>2</Dispenser>
</EventData>
</Event>
</DeviceRequest>

Device Response with RequestType = Event

XML Parameter Presence Description

RequestType M mirrored from request

WorkstationID M mirrored from request
ApplicationSender M mirrored from request
RequestID M mirrored from request
SequenceID M mirrored from request
TerminalID M mirrored from request
OverallResult M
Dispenser O List of available dispenser
ProductCode O List of product codes (of selected dispenser) for restriction
check

Example:

POS responds with list of available dispenser:

POS -> EPS:

<?xml version="1.0" encoding="UTF-8"?>
<DeviceResponse RequestType="Event" ApplicationSender="EPS01" WorkstationID="999" TerminalID="15034001"
RequestID="1255" SequenceID="1" OverallResult="Success" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceResponse.xsd">
<EventResult>
<Dispenser>1</Dispenser>
<Dispenser>2</Dispenser>
<Dispenser>5</Dispenser>
</EventResult>
</DeviceResponse>

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 83 of 144

POS responds with list of product codes of selected dispenser:

POS -> EPS:

<?xml version="1.0" encoding="UTF-8"?>
<DeviceResponse RequestType="Event" ApplicationSender="EPS01" WorkstationID="999" TerminalID="15034001"
RequestID="1255" SequenceID="1" OverallResult="Success" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceResponse.xsd">
<EventResult>
<ProductCode>12</ProductCode>
<ProductCode>345</ProductCode>
<ProductCode>678</ProductCode>
</EventResult>
</DeviceResponse>

Device Request Printer status

This Device Request is used to trigger the Printer status check.
The printer status check is realised with the help of a DeviceRequest addressed to the printer containing an empty
textline. The value of OverallResult decides if printer is ready or not :
- OverallResult = Success, means printer is ready
- OverallResult Success, means printer is not ready

In case that the printer is not ready the EPS server is able to decide to continue with the current transaction action
without printing or abort it. This behaviour can be configured for each card type.
Request data

XML Parameter Presence Description

RequestType M Output
WorkstationID M 999
ApplicationSender M EPS01
RequestID M Mirrored from POS request.
SequenceID M
TerminalID M
OutDeviceTarget M Printer
TextLine M Empty line

Example:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>

<DeviceRequest RequestType="Output" WorkstationID="999" ApplicationSender="EPS01" RequestID="1254"
SequenceID="3" TerminalID="15034001" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceRequest.xsd">
<Output OutDeviceTarget="Printer">
<TextLine> </TextLine>
</Output>
</DeviceRequest>

Response data

XML Parameter Presence Description

RequestType M mirrored from request

WorkstationID M mirrored from request
ApplicationSender M mirrored from request
RequestID M mirrored from request
SequenceID M mirrored from request
TerminalID M mirrored from request

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 84 of 144

OverallResult M
OutDeviceTarget M Printer
OutResult M

Example:

<?xml version="1.0" encoding="UTF-8"?>

<DeviceResponse RequestType="Output" ApplicationSender="EPS01" OverallResult="Success" RequestID="1254"
SequenceID="3" TerminalID="15034001" WorkstationID="999"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="C:\Schema\DeviceResponse">
<Output OutDeviceTarget="Printer" OutResult="Success"/>
</DeviceResponse>

7.11 OPT with different functions depending on the card swiped

The UseCases in the POS-EPS standard and the examples in the guidelines are based on the assumption that the
function to be implemented by the EPS is known by the Sell application when asking.
It is adviced to design a system working compliant to this assumption, for example:
Having an OPT where a customer can pre-authorise a refilling or can purchase a car-wash can be implemented in
different ways; the simplest solution is to letthe customer select the function required and then the Sell application will
ask the EPS to hendle the correct request, getting the card swiped within the pre-authorization or the payment process.
Working in the opposite sequence, having the card swiped in a process handled by the EPS, then proposing by the Sell
application only the choices of functionality allowed for that card, is not adviced. It brings complexity for the
implementation but also makes the POS application more involved in the card process and in risk of being necessary to
be approved by banks together with the EPS application.
Swiping the card first is a common concept for devices dedicated to a functionality e.g. CRIND/OPT for Refilling at the
pump; when more functionalities are combined in the same device the process required to the customer is more
complex and the more transparent is the procedure that the machine follows, the better is for the customer.
The adviced implementation for a swipe first then select the function scenario is the following:
The pre-authorization request might be the most used function, so it is used at start
After the card is swiped, the EPD uses the DeviceRequest to ask the Sell application to get the correct function
selected
The DeviceResponse will provide the necessary details and the CardServiceRequest will implement the updated
function (e.g. purchase of the newly provided SaleItems)

8. POS-EPS TRANSACTION IDENTIFICATION AND LINKING

Some CardService message pairs need to be linked to a previous one with an identifier because either:
the payment or loyalty transaction is composed of several message pairs (Example: Loyalty and Payment, or
Split Payment)
the transaction must refer to an earlier transaction. (Example: Reversals)
There are no explicit rules in the POS-EPS specifications for identification of the transactions or linking to a previous
one, at the exception of partial cases of reversals or refunds. The POS is forced to maintain a linkage for the
transaction information.

8.1 Definitions
I. Transaction:
a. POS Transaction. From the point of the POS a transaction includes all items purchased and all
payments / loyalty necessary to complete that transaction
b. EPS Transaction. From the point of the EPS a transaction includes a complete or partial payment /
loyalty of the POS transaction.
II. Purpose of fields:

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 85 of 144

a. RequestID: Identifies a pair of messages for a request/response pair. (Current specification)

b. TransactionNumber: Identifies a transaction for a POS. All request/response pairs within a transaction
will have the same TransactionNumber this easily identifies messages related to a single POS
transaction. (Proposed: An element of the POSData this would be an optional field in the schema)
c. STAN (System Trace Audit Number) is used to recognize a single successful payment or loyalty aspect
for a transaction.
III. Linking fields:
a. The TransactionNumber field of the POSData structure, which can be present in all message pairs of a
POS transaction, and is an implicit way to link these message pairs belonging to the same transaction.
This linking becomes explicit with the adding of the Split flag for split tenders.
b. The TerminalID, TerminalBatch, STAN, and optionally TimeStamp fields in the OriginalTransaction
structure, which identify a previous successful payment or loyalty transaction.
c. The RequestID field in the OriginalTransaction structure, which identifies a previous message pair.
d. The TransactionNumber field in the OriginalTransaction structure, which identifies a complete previous
POS transaction.

8.2 Transaction Identification by the POS

The POS workstation has the following data to reference a message pair, or a transaction:
o The RequestID field in the header of every message, which identifies a pair of messages for the POS
workstation.
o The TransactionNumber field of the POSData structure, which identifies a POS transaction, useful when
the POS transaction includes several payment transactions (split tenders), or several message pairs.

8.3 Transaction Identification by the EPS

The EPS uses the STAN field, sent in the Terminal data structure of a response to a successful payment or
loyalty transaction, as an identifier of the transaction for the POP terminal. The value is assigned by the EPS for each
POP terminal independently.

8.4 Use case

8.4.1 Single Payment or Loyalty Transaction, Single Message

The payment and loyalty transactions below contain a single message pair, CardPayment or LoyaltyAward, with no
reference to a previous message pair or a previous transaction:
 The TransactionNumber field can be present or not in the request.
 If the payment or the loyalty is successful, the EPS assign a STAN identifier to the transaction for the requested
POP, and put it in the response to the POS.
POS System EPS

CardPayment req

RequestID 338 338 RequestID

Terminal
723 STAN

rep

Single Payment Transaction, Single Message

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 86 of 144

POS System EPS

LoyaltyAward req

RequestID 339 339 RequestID

Terminal
724 STAN

rep

Single Loyalty Transaction, Single Message

8.4.2 Single Payment, PreAuthoryzation

The payment transaction contains the CardPreauthorization followed by the FinancialAdvice at the end of good
delivery. The linking of the CardFinancialAdvice with the CardPreauthorization uses the linking field III.b described in
Proposition, and the EPS can optionally uses the linking field III.a if the TransactionNumber field is present:
 The TransactionNumber field can be present or not in the Preauthorization request.
 If the pre-authorization succeeds, the EPS assign a STAN identifier to the transaction for the requested POP, and
put it in the response to the POS.
 In case of failure, there is no good delivery and no CardFinancialAdvice request.
 The CardFinancialAdvice request contains the STAN field in the OriginalTransaction structure.
 The TransactionNumber field can be present or not in the CardFinancialAdvice request.
POS System EPS
CardPreauthorization req

RequestID 340 340 RequestID

Terminal
725 STAN

rep
CardFinancialAdvice req

RequestID 341 341 RequestID

OriginalTransaction Terminal
STAN 725 726 STAN

rep

8.4.3 Multiple Payments, Split Tenders

The POS transaction includes several payment transactions with split tender.
In this case, the linking is realized with the linking field III.a:
 All the payment requests contain the TransactionNumber field and the Split flag, may be except the first one.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 87 of 144

POS System EPS

CardPayment req

RequestID 344 344 RequestID

Terminal
Split true 728 STAN

TransactionNumber 78

rep

CardPayment req

RequestID 346 346 RequestID

Terminal
Split true 729 STAN

TransactionNumber 78

rep

8.4.4 Reversal Resulting from an Exception

This is the case of a payment or loyalty reversal automatically requested by the POS after doubts concerning
the result of the transaction, the only known information is the RequestID of the message transaction to reverse.
In this case, the linking is realized with the method-linking field III.c:
 The Reversal request contains the structure OriginalTransaction containing the RequestID field with the same value
than the RequestID of the transaction message to reverse.
POS System EPS
LoyaltyRedemption req

RequestID 347 347 RequestID

rep

LoyaltyRedemptionReversal req

RequestID 348 348 RequestID

OriginalTransaction
RequestID 347
rep

8.4.5 Reference to a Previous Split Tenders

The reference to a previous sequence of successful payment transactions is the case of the TicketReprint of
split tenders. In this case, the linking is realized with the linking field III.d:
 The TicketReprint request contains the structure OriginalTransaction containing the TransactionNumber field with
the same value than the TransactionNumber of all the payment and loyalty message of the transaction.
The link of TicketReprint with OriginalTransaction.TransactionNumber is required only if the transaction to reprint can
contain split tenders.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 88 of 144

POS System EPS

CardPayment req

RequestID 349 349 RequestID

Terminal
Split true 730 STAN

TransactionNumber 79

rep

CardPayment req

RequestID 350 350 RequestID

Terminal
Split true 731 STAN

TransactionNumber 79

rep

TicketReprint req

RequestID 351 351 RequestID

OriginalTransaction
TransactionNumber 79

rep

8.4.6 Reference to a Previous Unique Transaction

This is the case where there is only one successful transaction, payment or loyalty. Examples are a
TicketReprint of a non-split tender, a Reversal resulting from a customer change of mind, or a Refund to link to a
previous transaction. In this case, the linking is realized with the linking field III.b or III.d.
POS System EPS
CardPayment req

RequestID 352 352 RequestID

Terminal
TransactionNumber 80 732 STAN

rep

TicketReprint req

RequestID 353 353 RequestID

OriginalTransaction
TransactionNumber 80
OriginalTransaction
STAN 732

rep

8.4.7 Refund Transaction Reference

The case of the Refund transaction is the same than the previous one, linking with linking field III.b or III.d,
except that the linking is optional and present to limit fraud on returns.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 89 of 144

POS System EPS

CardPayment req

RequestID 354 354 RequestID

Terminal
733 STAN

rep

PaymentRefund req

RequestID 355 355 RequestID

OriginalTransaction Terminal
STAN 733 734 STAN

rep

9. POS-EPS CODING-DECODING RULES

This section gives general rules and practices to observe for the coding/decoding of messages.

9.1 XML Message Decoding Model

The decoding model of XML Schema messages consist of two processing modules:
o A XML Schema library module, which processes the syntax validation of the message conforming to the
Schema definition files (.xsd).
o An applicative module, which processes the syntax validation of the message defined in these specification that
unfortunately cannot be realized by the XML Schema library.

Application
POS-EPS XML message
XML Schema Decoded and Validated
Decoding
Library message
Module

POS-EPS
xsd
Specifications

XML Message Decoding Model

9.2 XML Message Coding Decoding

During the decoding of XML messages, the POS or the EPS must conform to the following rules:
o If a field declared mandatory is absent, the message is considered invalid.
o If a field declared optional is absent and has a default value declared in the Data Dicionary, the field is
considered present with this default value.
o If a field declared unused is present, the field is ignored without further verifications on its value.
o When the Schema definition of an element or an attribute does not contains neither length constraints nor
default value, the application has to verify the length range and apply the default value described in the
following section "Message Syntax". This rule also applies to the Lite type validation (e.g. CardPAN is a string
in the XML format, and a BCD string in the Lite format, XML decoding has to verify than the characters of this
string are decimal digits).
During the coding of XML messages, the POS or the EPS must conform to the following rule:

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 90 of 144

o If a field is declared mandatory, it cannot be absent of the message (at the exception of error cases, e.g;
CardPAN cannot be present in the response if no card has been read).

9.3 Lite Message Coding Decoding

During the decoding of Lite messages, the POS or the EPS must conform to the following rules:
o If a field declared mandatory is absent, the message is considered invalid.
o If a field declared optional is absent and has a default value declared in the Data Dicionary, the field is
considered present with this default value.
o If a field declared unused is present, the field is ignored without further verifications on its value.
o If a field contains a tag not defined in this specifications, the message is considered invalid.
o The application has to verify the length range and apply the default value described in the following section
"Message Format".
During the coding of Lite messages, the POS or the EPS must conform to the following rule:
o If a field is declared mandatory, it cannot be absent of the message (at the exception of error cases).

10. LOYALTY REBATES

This section contains a description of the rebates implementation within POS-EPS protocol specifications.

10.1 Standard Rebates Processing

Definition A rebate occurs during a loyalty transaction with the two following forms:
1) The loyalty transaction reduces the amount of one or several sale items
sent by the POS, or
2) The loyalty transaction decreases the total amount of the transaction.
A rebate appears in the POS-EPS interface only when the EPS has in charge the
acceptance and the processing of loyalty transaction, with the possible control of a
loyalty host.

Impacted Rebate data are located in the response of a CardService messages and can
Transactions happen:
 In the LoyaltyAward message, when the payment is
accomplisheded by the POS.
 In standard payment message, when loyalty and payment
are both achieved by the EPS

Rebate on Rebate on a sale item is declared by the EPS in the response message by:
Item  Adding the corresponding SaleItem in the message.
 Changing the SaleItem.Amount value to reflect the new
amount of the item, after rebate, if known by EPS, otherwise set
SaleItem.Amount to 0.0.
 Changing the total amount value Tender.TotalAmount in the
response to indicate the new amount of the sale, after rebate on this item.
 Setting the SaleItem.AdditionalProductInfo field to the value
sent in BIT 63 of the POS-FEP response, i.e.
n7 Balance
n2 Balance Measurement
n7 Discount
n2 Discount Measurement
 Adding the SaleItem.RebateLabel text field, to be printed by
the POS on the sale ticket.

Rebate on the Rebate on the whole purchase is declared by the EPS in the response message by:
Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 91 of 144

Whole  Changing the total amount value Tender.TotalAmount in the

Purchase response to indicate the new amount of the sale, after rebate on the whole
purchase.
 Adding a new SaleItem element, with an ItemID defined as
the next free ItemID in the sequence sent from POS, a dedicated
ProductCode (e.g. value 904), the Amount equivalent to the rebate amount
on the whole purchase, the field TypeMovement value 3 to denote a
decreased amount, and the RebateLabel text field.
 Setting the SaleItem.AdditionalProductInfo for this new item
to the value sent in BIT 63 of the POS-FEP response, i.e.
n1 BalanceCode
n12 Overall Balance
n2 Overall Balance Measurement
n8 Overall Discount Fuels
n2 Overall Discount Fuels Measurement
n8 Overall Discount Non-Fuels
n2 Overall Discount Non-Fuels Measurement
n8 Overall Discount
LLL Length of Tax Info (000 if absent)
ans …257 Tax code

General Rules The processing of the rebate must be conform to the following rules:
1) Rebate can occurs on several items of the same payment transaction, but
one rebate can occurs on the same item at the most.
2) In the response message, the sale items of the request, which are not
modified by a rebate, are not included by the EPS.
3) A loyalty account can generate simultaneously rebate and other award in
Loyalty.LoyaltyAmount.
4) Within one transaction, only one loyalty account identifier
(Loyalty.LoyaltyCard) can be allowed for rebates and other awards.
5) In order for the EPS to be able to report the rebates in the reconciliation
towards POS, BIT 4 in the response from the FEP has to be set to the
amount after (item specific and ticket specific) rebates.
6) The information to be sent to POS in SaleItem.Rebate is transported in BIT
62 of the response from the FEP. A new value “9” is used for the device type
in BIT62-2, this means that the format of BIT62-3 is implementation specific.

Rules for POS The POS processing of the rebate must be conform to the following rules:
1) POS can identify rebates by a difference between Tender.TotalAmount and
the TotalAmount requested and on the existence of SaleItem elements in
the response from EPS
2) SaleItem elements have to be checked for the Amount sent back, if this is
different from the amount in the request, then a rebate has been applied, if
the amount is <> zero, then this is the rebated value of the item. If the
amount is equal to zero then type of rebate is described in more detail in
AdditonalProductInfo which have to be evaluated.
3)

10.2 Other Rebate Processing

Rebate When the POS sends a reversal request, the EPS has to retrieve the information
Reversal concerning the rebate on the original transaction if applicable, and to reverse the
amount payment after rebates (i.e. the paid amount).

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 92 of 144

Loyalty Rebates are a subset of the loyalty reconciliation, which is defined below. The POS-
Reconcilia- EPS reconciliation response contains both payment records and loyalty records. As
tion the data exchanged during a loyalty transaction: award, rebates or redemption, are
slightly different from those exchanged during a payment transaction, the loyalty
reconciliation records differ from the payment transaction record. On the other hand,
the loyalty scheme is simpler than the payment one, since the acquirer and the
issuer are the same.
The loyalty records reconciliation complies to the following assumptions:
 In case of several loyalty programs (i.e. loyalty hosts), the
CardCircuit field identifies the loyalty program, which has to be included in
the Loyalty data element of message responses.
 In case of several loyalty FEP or schemes, the Acquirer
attribute contains the LoyaltyAcquirerID, which identifies the FEP or the
scheme.
 The NumberPayments field contains the number of loyalty
transactions counted in this record.
 Like for the payment, the PaymentType attribute
differentiates the normal case ("Debit") from the refund ("Credit").
 The LoyaltyType field, which is present if and only if this a
loyalty transaction record, identifies the type of loyalty transaction: award,
offline award, redemption, or rebate.
 The TotalAmount field value is the sum of the
LoyaltyAmount values sent in the message responses of the loyalty
transactions. An exception to this rule is the case of offline loyalty award
transactions, where the LoyaltyAmount is unknown in the time of the
reconciliation, and where the TotalAmount field value contains the sum of
the Tender.TotalAmount values.
 The AcquirerBatch attribute is not used for the loyalty
records.

Rebate When a loyalty refund is resquested by the POS alone or with a payment refund:
Refund  If the payment refund is partial (e.g. return of an item), a
rebate on the whole purchase is not refunded.
 In case of rebate on the whole purchase, the POS has to
send in the refund request, the dedicated sale item (e.g. value 904)
generated by the EPS.
 In case of rebate on the item level, the POS has to add a
new SaleItem element, with a dedicated ProductCode (e.g. value 903), the
Amount equal to the sum of rebate applied on the sale items returned on the
refund request.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 93 of 144

10.3 Examples
CardPayment The following example presents a CardPayment request:
Request  Two items of 5.00 € each.
 Total amount of 10.00 €.

<CardServiceRequest ApplicationSender="AP4900" POPID="01" RequestID="00002949"

RequestType="CardPaymentLoyaltyAward" WorkstationID="POS99" xmlns="http://www.nrf-arts.org/IXRetail/namespace"
xmlns:IFSF="http://www.ifsf.org/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace ./IFSF/XSD/CardRequest.xsd">
<POSData>
<POSTimeStamp>2005-12-09T15:14:44</POSTimeStamp>
</POSData>
<Loyalty LoyaltyFlag=”True”/>
<TotalAmount Currency="EUR">10.00</TotalAmount>
<SaleItem ItemID="a001">
<ProductCode>19</ProductCode>
<Amount>5.00</Amount>
<UnitMeasure>LTR</UnitMeasure>
<UnitPrice>5.000</UnitPrice>
<Quantity>1.00</Quantity>
<TaxCode>1</TaxCode>
<AdditionalProductCode>4003116415030</AdditionalProductCode>
<AdditionalProductInfo>36320403330399</AdditionalProductInfo>
</SaleItem>
<SaleItem ItemID="a002">
<ProductCode>19</ProductCode>
<Amount>5.00</Amount>
<UnitMeasure>LTR</UnitMeasure>
<UnitPrice>5.000</UnitPrice>
<Quantity>1.00</Quantity>
<TaxCode>1</TaxCode>
<AdditionalProductCode>4003116415030</AdditionalProductCode>
<AdditionalProductInfo>36320403330399</AdditionalProductInfo>
</SaleItem>
</CardServiceRequest>

CardPayment The CardPayment response has:

Response  A rebate of 0.25 € on the second sales item.
 A rebate of 1.00 € on the whole purchase.
 Total amount of 8.75 €.

<CardServiceResponse ApplicationSender="AP4900" OverallResult="Success" POPID="01" RequestID="00002949"

RequestType="CardPaymentLoyaltyAward" WorkstationID="POS99" xmlns="http://www.nrf-arts.org/IXRetail/namespace"
xmlns:IFSF="http://www.ifsf.org/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace ./IFSF/XSD/CardResponse.xsd">
<Terminal STAN="99010098" TerminalBatch="0031" TerminalID="71000044"/>
<Tender>
<TotalAmount Currency="EUR">8.75</TotalAmount>
<Authorisation AcquirerID="0000" CardCircuit="BP-Routex" CardPAN="700674999999000014" TimeStamp="2005-12-
09T15:14:44"/>
</Tender>
<Loyalty LoyaltyFlag=”true” CardCircuit="Loyalty Bonus" CardEntryMode="Swipe" LoyaltyTimeStamp="2005-12-
09T15:15:05">
<LoyaltyCard>3B333038333432353030383935363934313D3130313030303030303030303030
343437383437</LoyaltyCard>
</Loyalty>
<SaleItem ItemID="a002">
<ProductCode>19</ProductCode>
<Amount>4.75</Amount>
<AdditionalProductInfo>000000000000002501</AdditionalProductInfo>
<RebateLabel>Item Rebate</RebateLabel>
</SaleItem>
</CardServiceResponse>
<SaleItem ItemID="a003">
<ProductCode>904</ProductCode>
<Amount>1.00</Amount>
<AdditionalProductInfo>00000000000000000000000000000000000000000100000 </AdditionalProductInfo>
<TypeMovement>3</TypeMovement>
<RebateLabel>Ticket Rebate</RebateLabel>

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 94 of 144

</SaleItem>

RebateLabel The texts to be printed for rebates on the POS and the CardCircuit for rebates are
sent back in BIT62 of the response from the FEP. This is the text to be sent for the
example above:
 Rebate CardCircuit: Loyalty Bonus
 Ticket Rebate: Ticket Rebate
 Item Rebate: Item Rebate

046 LLL length of BIT 62

00 LL length for BIT 62-1 (i.e., no “Allowed product sets”)
9 BIT 62-2, indicating rebate labels
040 LLL for BIT 62-3
Loyalty Bonus \ CardCircuit for the Rebate Program
Ticket Rebate\ RebateLabel to be printed for the ticket rebate
\ No item rebate for the first item
Item Rebate RebateLabel to be printed for the rebate for the second item

Reconciliatio The reconciliation containing only the previous payment and loyalty transaction
n Response shows the result below:
 A record of 1.25 € concerning the rebates.
 A record of 8.75 € for the payments.

<ServiceResponse ApplicationSender="AP4900" OverallResult="Success" RequestID="00002950"

RequestType="ReconciliationWithClosure" WorkstationID="POS99" xmlns="http://www.nrf-
arts.org/IXRetail/namespace" xmlns:IFSF="http://www.ifsf.org/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-
instance" xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace ./IFSF/XSD/ServiceResponse.xsd">
<Reconciliation>
<TotalAmount Acquirer="0000" CardCircuit="Loyalty Bonus" Currency="EUR" LoyaltyType="Rebate"
NumberPayments="1" PaymentType="Debit">1.25</TotalAmount>
<TotalAmount Acquirer="0000" CardCircuit="BP-Routex" Currency="EUR" NumberPayments="1"
PaymentType="Debit">8.75</TotalAmount>
</Reconciliation>
</ServiceResponse>

Payment The complete refund of the previous payment and loyalty transaction:
Loyalty  The two items of 5.00 € each.
Refund  The item level rebate of 0.25 € (product code 903).
Request  The whole purchase rebate of 1.00 € (product code 904).
 Total amount of 8.75 €.

<CardServiceRequest ApplicationSender="AP4900" POPID="01" RequestID="00002951"

RequestType="PaymentLoyaltyRefund" WorkstationID="POS99" xmlns="http://www.nrf-arts.org/IXRetail/namespace"
xmlns:IFSF="http://www.ifsf.org/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.nrf-arts.org/IXRetail/namespace ./IFSF/XSD/CardRequest.xsd">
<POSData>
<POSTimeStamp>2005-12-09T16:14:44</POSTimeStamp>
</POSData>
<Loyalty LoyaltyFlag=”True”/>
<TotalAmount Currency="EUR">8.75</TotalAmount>
<SaleItem ItemID="a001">
<ProductCode>19</ProductCode>
<Amount>5.00</Amount>
<UnitMeasure>LTR</UnitMeasure>
<UnitPrice>5.000</UnitPrice>
<Quantity>1.00</Quantity>
<TaxCode>1</TaxCode>
<AdditionalProductCode>4003116415030</AdditionalProductCode>
<AdditionalProductInfo>36320403330399</AdditionalProductInfo>
</SaleItem>
<SaleItem ItemID="a002">
<ProductCode>19</ProductCode>
<Amount>5.00</Amount>
<UnitMeasure>LTR</UnitMeasure>
<UnitPrice>5.000</UnitPrice>

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 95 of 144

<Quantity>1.00</Quantity>
<TaxCode>1</TaxCode>
<AdditionalProductCode>4003116415030</AdditionalProductCode>
<AdditionalProductInfo>36320403330399</AdditionalProductInfo>
</SaleItem>
<SaleItem ItemID="a003"
<ProductCode>904</ProductCode>
<Amount>1.00</Amount>
<TypeMovement>3</TypeMovement>
</SaleItem>
</CardServiceRequest>
<SaleItem ItemID="a004">
<ProductCode>903</ProductCode>
<Amount>0.25</Amount>
<TypeMovement>3</TypeMovement>
</SaleItem>

11. POS-EPS VERSION IDENTIFICATION

To identify POS-EPS application provider, application type, application version, protocol type and version EPS
and POS use following attributes:

- <xs:attribute name="Manufacturer_Id" type="Manufacturer_IdType" use="optional"/>

- <xs:attribute name="Model" type="ModelType" use="optional"/>
- <xs:attribute name="DeviceType" type="DeviceType_Type" use="optional"/>
- <xs:attribute name="ProtocolVersion" type="ProtocolVersionType" use="optional"/>
- <xs:attribute name="CommunicationProtocol" type="CommunicationProtocolVersionType" use="optional"/>
- <xs:attribute name="ApplicatioSoftwareVersion" type="ApplicatioSoftwareVersionType" use="optional"/>
- <xs:attribute name="SWChecksum" type="SWChecksumType" use="optional"/>

Those attributes are part of “Login” service request and response. Despite the fact that use of those attributes is
declare as optional, for backward compatibility, they are mandatory for EPS and POS that what to comply with
certification process.

12. SOFT KEY SOLUTION

The requesting device provide the prompting device with the number of choices to be made available to the
customer/operator, the text to display, and the value to return for each choice.

In DeviceRequest messages, optional repeating element called “SoftKey” is used. It defined similarly to the existing
TextLine element, but include additional attributes that are specific to soft key prompting. The presence of the “SoftKey”
element acts as an instruction to associate text with a soft key. The value of the mandatory “SoftKeyReturn” attribute
will be the value to return, should that soft key be pressed.

The “GetAnyKey” value of the Command element is used to specify that the desired prompt input is a single key press.

12.1 Attributes of the SoftKey Element

The SoftKey element contains all of the attributes of the existing TextLine element except for ReceiptZone and
PaperCut. In addition, it also contains:
o SoftKeyReturn (mandatory) – Value to be returned in the InString field in the DeviceResponse should this
soft key choice be picked.

The following attributes will also have additional values:

o Alignment – Addition of values “Top” and “Bottom” to align a SoftKey element to a soft key above or below
the display.

Attributes such as row and column will retain their existing functionality, allowing specific rows or columns to be
assigned to SoftKey or TextLine elements.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 96 of 144

12.2 Transaction Flow for Soft Key Prompting

Note: For the purposes of the example transaction flow, this assumes EPS is the requesting device and POS/OPP is
displaying the prompt.

1. EPS sends a DeviceRequest to the POS with at least one SoftKey element.
2. POS recognizes that a SoftKey element indicates that the text value of the element should be associated with a
specific button that the customer can choose. For every SoftKey element, a choice (i.e. button) will be made
available for the customer. The POS is responsible for making the options available, based upon the hardware
present.
3. Customer makes a choice of an available option.
4. The POS returns the chosen option, using the string of the SoftKeyReturn attribute assigned to that choice, in the
InString field in the DeviceResponse.

Example Soft Key Prompt

The following soft key example is a Credit/Debit prompt with two options for the customer.

This example contains one TextLine element and two SoftKey elements. Note that attributes on a SoftKey element
(such as alignment in the example below) can affect more than the displayed text. In the example below, the device
has soft keys on both sides of the display. The alignment attribute has been used to specify the use of the right side
keys. In the absence of the specific instruction, it would be up to the displaying device to choose a soft key.

XML Request
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<DeviceRequest RequestID="00000003" WorkstationID="POS002" POPID="101" RequestType="Input" xmlns="http://www.nrf-
arts.org/IXRetail/namespace">
<Output OutDeviceTarget="PinPad" MinTime="0">
<TextLine>Select Credit or Debit</TextLine>
<SoftKey SoftkeyReturn="Credit" Alignment="Right">
Press Here for Credit
</SoftKey>
<SoftKey SoftkeyReturn="Debit" Alignment="Right">
Press Here for Debit
</SoftKey>
</Output>
<Input InDeviceTarget="PinPad">
<Command TimeOut="255">GetAnyKey</Command>
</Input>
</DeviceRequest>

Displayed on the PinPad

Note: the arrow is generated by the device managing the soft key

 Select Credit or Debit 

 Press Here for Credit  
 Press Here for Debit  
 

( is a button)

Soft Key Example XML Response:

Note: Customer pressed “Credit” soft key
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 97 of 144

<DeviceResponse RequestID="00000003" WorkstationID="POS002" POPID="101" RequestType="Input" OverallResult="Success"

xmlns="http://www.nrf-arts.org/IXRetail/namespace">
<Output OutDeviceTarget="PinPad" OutResult="Success"/>
<Input InDeviceTarget="PinPad" InResult="Success">
<InputValue>
<InString>Credit</InString>
</InputValue>
</Input>
</DeviceResponse>

12.3 Additional Notes For Requesting a Choice Among Defined Keys

This functionality can be extended to allow choices without soft key buttons. The following functionality assumes that
the EPS and POS have agreed to a definition for available keys. The EPS and POS devices must be configured with
agreed to values.

Each available button on the input device will be assigned a value

Note: Values in brackets [] are examples only.

1 2 3 CREDIT PAY
QZ ABC DEF HERE INSIDE
[1] [2] [3] [Credit] [Key5]

4 5 6 DEBIT
GHI JKL MNO HERE
[4] [5] [6] [Debit] [Key10]

7 8 9 CANCEL HELP
PRS TUV WXY
[7] [8] [9] [Cancel] [Key15]

CLEAR 0 ENTER NO YES

[Clear] [0] [Enter] [No] [Yes]

The EPS can be configured to prompt using only soft key values representing keys existing on the hardware.

Using the previous example, the POS recognizes that the two soft key choices requested (“Credit” and “Debit”) map to
specific keys on the keypad. The POS makes these two keys (“Credit Here” and “Debit Here”) available for the
customer to press.

Example Soft Key Style Request for Device Not Using Soft Keys:
The following example is a Credit/Debit prompt with a single line of text, instructing the device getting user input that
there are two valid key press options for the customer, “Credit” and “Debit”.

Note that this example is almost identical to the previous example for a device with soft keys. This example shows how
it possible to use the SoftKey element (with or without including text for each soft key) for both devices with or without
soft keys. If this example XML document did contain text within the SoftKey element, a device using predefined keys
could still display the prompt and get valid input.

XML Request
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 98 of 144

<DeviceRequest RequestID="00000003" WorkstationID="POS002" POPID="101" RequestType="Input" xmlns="http://www.nrf-

arts.org/IXRetail/namespace">
<Output OutDeviceTarget="PinPad" MinTime="0">
<TextLine>
Select Credit or Debit
</TextLine>
<SoftKey SoftKeyReturn="Credit"/>
<SoftKey SoftKeyReturn="Debit"/>
</Output>
<Input InDeviceTarget="PinPad">
<Command TimeOut="255"> GetAnyKey </Command>
</Input>
</DeviceRequest>

Displayed on the PinPad

Note: Buttons shaded in green are known to the device to be valid responses

Select Credit or Debit

1 2 3 CREDIT PAY
QZ ABC DEF HERE INSIDE

4 5 6 DEBIT
GHI JKL MNO HERE

7 8 9 CANCEL HELP
PRS TUV WXY

CLEAR 0 ENTER NO YES

Example XML Response

Note: Customer pressed key with value “Debit”
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<DeviceResponse RequestID="00000003" WorkstationID="POS002" POPID="101" RequestType="Input" OverallResult="Success"
xmlns="http://www.nrf-arts.org/IXRetail/namespace">
<Output OutDeviceTarget="PinPad" OutResult="Success"/>
<Input InDeviceTarget="PinPad" InResult="Success">
<InputValue>
<InString>Debit</InString>
</InputValue>
</Input>
</DeviceResponse>

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 99 of 144

12.4 Exception Processing FAQ

1. What does the DeviceResponse look like if the user cancels the prompt?
a. The OverallResult should be “Aborted”. It is the responsibility of the device displaying the prompt to enable
a “cancel” key. This is a standard requirement and not specific to Soft Key prompting.
2. What if a device is not capable of displaying the prompt or getting the requested input?
a. The device should return a DeviceResponse with an OverallResult of “Failure”. Just like requesting track
data from a device without a card reader or PIN data from a device not able to encrypt, it is the
responsibility of those configuring the device requesting the input to ensure the receiving device is capable
of carrying out the prompt commands.
3. What should a device do if it does not have enough soft keys to handle the prompt?
a. One option is for the displaying device to implement a scrolling mechanism, so that all options can be
displayed, if not at the same time. Ultimately, if the device is not capable of displaying the prompt or
getting input in the requested format, it should return a DeviceResponse with an OverallResult of “Failure”.
It is the responsibility of those configuring the device requesting the prompt to ensure the receiving device
is capable of carrying out the prompt.

13. FORCE DRAFT CAPTURE

This chapter describe implementation of functionality to distinguish between offline (P2H and H2H filed P25
Message Reason Code = 1003) and force draft capture (P2H and H2H filed P25 Message Reason Code = 1378)
transaction types within POS-EPS interface.

13.1 FDC Use cases

Base on use case describe below flowing assumption can be made:
- while force draft capture is done neither card and card holder are present
- PAN of card will always be inserted manually
- Manual transaction (voucher) has been accepted priori by the acquire (with voice referral or within allow floor
limit for transactions amount / products) and therefore FDC process can’t be refuse neither by EPS nor by
HOST as long as message is correctly formatted. Therefore steps i.e. 14, 16, 21 are not correct - such
transaction can’t be refuse
Most appropriate POS-EPS I/f message for this case is CardFinancialAdvice of CardRequest. CardFinancialAdvice has
all require data elements including indicator of card holder presents (<xs:element name="CardHolderPresent"
type="xs:boolean" minOccurs="0"/>).
With this element CardFinancialAdvice message deliver all necessary information for EPS to process FDC transaction.

Additionally following mapping between POS-EPS and P2H/H2H messages is done for field P-22:

P22 Position 5 indicates if cardholder present or not present – is map to “CardHolderPresent”

P22 Position 6 indicates if card present or not present. – is map to “CardHolderPresent”. As cardholder not present
imply that the card was also not present.
P22 Position 7 indicates manual entry. – is map to “ManualPAN”

FDC use case with CardFinancialAdvice message.

Actors: Customer, Offline Service (POS system down), Online Service (POS system up), Offline acceptance Service,
EPS Server

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 100 of 144

1 2
$ 3

$
$

5 4

Offline Service Offline Acceptance

Customer
Service

6
7
8
Online Service EPS System

1 Customer request to pay by card while POS system is not available

2 Offline Service (POS system down) round up sale and apply appropriate acceptance rules. At this point card PAN is
collect as well as any other details (i.e. CVV, ID number) and paper voucher is produce.
3 Offline Acceptance Service give approval for transaction (optionally may give offline authorization code that need to
be use in steps 7)
4 Offline Service (POS system down) finalizes sales and delivers goods or service to customer
5 Customer leave.
6 Online Service (POS system up) is restore.
7 Online Service (POS system up) rings up the customer’s sale items, selects the ‘CardFinancialAdvice ’ method of
payment and send message to EPS Server
8 EPS Server process message and send back response to Online Service (POS system up) with overall result
‘Success’. This concludes process.

FDC use case - deny of offline transaction.

Actors: Customer, Offline Service (POS system down), Online Service (POS system up), Offline acceptance Service,
EPS Server

1 2
$
3
$

Offline Acceptance
Customer Offline Service
Service
1 Customer request to pay by card while POS system is not available
2 Offline Service (POS system down) round up sale and apply appropriate acceptance rules. At this point card PAN is
collect as well as any other details (i.e. CVV, ID number) and paper voucher is produce.
3 Offline Acceptance Service deny approval for transaction
4 Offline Service (POS system down) denies sales and Customer leave. This concludes process.

FDC use case – deny of CardFinancialAdvice message due to exceptions (i.e. out of paper , comms down, not
all require data provided).
Actors: Customer, Offline Service (POS system down), Online Service (POS system up), Offline acceptance Service,
EPS Server

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 101 of 144

1 2
$
3

$
$

5 4

Offline Acceptance
Customer Offline Service
Service

6
7
8
Online Service EPS System

1 Customer request to pay by card while POS system is not available

2 Offline Service (POS system down) round up sale and apply appropriate acceptance rules. At this point card PAN is
collect as well as any other details (i.e. CVV, ID number) and paper voucher is produce.
3 Offline Acceptance Service give approval for transaction (optionally may give offline authorization code that need to
be use in steps 7)
4 Offline Service (POS system down) finalizes sales and delivers goods or service to customer
5 Customer leave the site.
6 Online Service (POS system up) is restore.
7 Online Service (POS system up) rings up the customer’s sale items, selects the ‘CardFinancialAdvice ’ method of
payment and send message to EPS Server
8 EPS Server process message and send back response to Online Service (POS system up) with overall result “Fail”.
9 Online Service (POS system up) analyse response (this may be due to printer not ready at POS, data comm. down,
missing mandatory filed in message or message not correctly format), take correction actions repeat step 7 if feasible or
raise an exception for manual procedure. This concludes process.

14. DEVICE PROXY EXTENSION

14.1 Button Function

The Proxy Device Button contains the functionality for the buttons like shop, credit or printer. You must activate the
button for a define time, if there any button in the timeout time press, the response message have an OverallResult =
Success and the Button No, which was press, stand in the InNumber field.

Request
XML IFSF Initiator Description
Parameter
Request Type M POS „Output“
WorkstationID M POS Identifies the application (associated to the
socket) sending the request. Usually the POS.
RequestID M POS ID of the request
POPID M POS PinPad-No.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 102 of 144

Output M POS
OutDeviceTarget M POS “Button”
TextLine M POS List of the unblock Buttons
e.g.: Button 1,2,3 unblock
< Textline > 1
< Textline > 2
< Textline > 3
Input M POS
InDeviceTarget M POS “Button”
Command M POS “GetDecimals”
TimeOut M POS Timeout in seconds for Button-Input.

Response
XML IFSF Initiator Description
Parameter
Request Type M EPS Reflection from Request
WorkstationID M EPS Reflection from Request
RequestID M EPS Reflection from Request
POPID M EPS Reflection from Request
OverallResult M EPS Result of the request e.g. „Success“

Output M EPS
OutDeviceTarget M EPS “Button”
OutResult M EPS Result of the request e.g. „Success“
Input O EPS
InDeviceTarget M EPS “Button”
InResult M EPS Result of the request e.g. „Success“
InputValue M EPS
InNumber O EPS Button-No.
e.g.: 1

14.2 Example for Button

POS  EPS: Request

<?xml version="1.0" encoding=" ISO-8859-1" standalone="no" ?>

<DeviceRequest RequestType="Output"
WorkstationID="5"
RequestID="1254"
POPID="1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceRequest.xsd">
<Output OutDeviceTarget="Button">
<TextLine>1</TextLine>
<TextLine>2</TextLine>
<TextLine>3</TextLine>
</Output>
<Input InDeviceTarget="Button">
<Command TimeOut="300">GetDecimals</Command>
</Input>
</DeviceRequest>

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 103 of 144

EPS  POS: Response

<?xml version="1.0" encoding="ISO-8859-1"?>

<DeviceResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\\Schema\\DeviceResponse.xsd
RequestType="Output"
WorkstationID="5"
RequestID="1254"
POPID="1"
OverallResult="Success">
<Output OutDeviceTarget="Button"
OutResult="Success"/>
<Input InDeviceTarget="Button"
InResult="Success">
<InputValue>
<InNumber>1</InNumber>
</InputValue></Input>
</DeviceResponse>

14.3 LED Function

The Proxy Device LED contains the functionality for the buttons LED like on, off or flash. In the request message you
must select the LED and the state for each LED.

Request
XML IFSF Initiator Description
Parameter
Request Type M POS „Output“
WorkstationID M POS Identifies the application (associated to the
socket) sending the request. Usually the POS.
RequestID M POS ID of the request
POPID M POS PinPad-No.

Output M POS
OutDeviceTarget M POS “LED”
Textline M POS List of the LED equal Button
M POS CharSet
0: LED off
1: LED on
2: LED flash

Response
XML IFSF Initiator Description
Parameter
Request Type M EPS Reflection from Request
WorkstationID M EPS Reflection from Request
RequestID M EPS Reflection from Request
POPID M EPS Reflection from Request
OverallResult M EPS Result of the request e.g. „Success“

Output M EPS
OutDeviceTarget M EPS “LED”

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 104 of 144

OutResult M EPS Result of the request e.g. „Success“

14.4 Example for LED

POS  EPS: Request

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>

<DeviceRequest RequestType="Output"
WorkstationID="999"
RequestID="1254"
POPID="1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceRequest.xsd">
<Output OutDeviceTarget="LED">
<TextLine CharSet="1">1</TextLine>
<TextLine CharSet="0">2</TextLine>
<TextLine CharSet="2">3</TextLine>
</Output>
</DeviceRequest>

EPS  POS: Response

<?xml version="1.0" encoding="ISO-8859-1"?>

<DeviceResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\\Schema\\DeviceResponse.xsd
RequestType="Output"
WorkstationID="999"
RequestID="1254"
POPID="1"
OverallResult="Success">
<Output OutDeviceTarget="LED"
OutResult="Success"/>
</DeviceResponse>

14.5 Screen Function

The Proxy Device screen contains the functionality for the customer Display. These massage ist equal the O.P.I.
message “Graphics and Speech Support”.
Following elements and attributes are currently defined:
— Image File:
Used to transfer the File name of a pictogram file which is to be shown on the screen.
— Sound File:
Used to transfer the file nameof an audio file which contains a short spoken text.

Request
XML IFSF Initiator Description
Parameter
Request Type M POS “Output“
WorkstationID M POS Identifies the application (associated to the
Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 105 of 144

socket) sending the request. Usually the

POS.
RequestID M POS ID of the request
POPID M POS PinPad-No.

Output M POS
OutDeviceTarget M POS “CustomerDisplay”
Textline O POS List of text lines to be displayed
ImageFile O POS Name of image file, respectively the pictogram to be
displayed, e.g. “CardInsert.gif”
SoundFile O POS Name of a sound file to be played, e.g.
“CardInsert.wav”

Response
XML IFSF Initiator Description
Parameter
Request Type M EPS Reflection from Request
WorkstationID M EPS Reflection from Request
RequestID M EPS Reflection from Request
POPID M EPS Reflection from Request
OverallResult M EPS Result of the request e.g. „Success“

Output M EPS
OutDeviceTarget M EPS “CustomerDisplay”
OutResult M EPS Result of the request e.g. „Success“

14.6 Example for Screen

POS  EPS: Request

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>

<DeviceRequest RequestType="Output"
WorkstationID="999"
RequestID="1254"
POPID="1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceRequest.xsd">
<Output OutDeviceTarget="CustomerDisplay">
<TextLine>Please insert Card</TextLine>
<ImageFile>CardInsert.gif</ImageFile>
<SoundFile>CardInsert.wav</SoundFile>
</Output>
</DeviceRequest>

EPS  POS: Response

<?xml version="1.0" encoding="ISO-8859-1"?>

<DeviceResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\\Schema\\DeviceResponse.xsd
RequestType="Output"
WorkstationID="999"

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 106 of 144

RequestID="1254"
POPID="1"
OverallResult="Success">
<Output OutDeviceTarget="CustomerDisplay"
OutResult="Success"/>
</DeviceResponse>

14.7 Door Control Function

The Proxy Device Door Control contains the functionality for the Outdoor Payment door. If the state of the door change
the EPS send a unsolicited request to the POS. If the POS has no actual state of the door, it can send a request to the
EPS, and get the aktual state about the door over the result message.

Request
XML IFSF Initiator Description
Parameter
Request Type M POS/EPS ”Input“
WorkstationID M POS/EPS Identifies the application (associated to the
socket) sending the request. Usually the
POS.
RequestID M POS/EPS ID of the request
POPID M POS/EPS PinPad-No.

Output M POS/EPS
OutDeviceTarget M POS/EPS “DoorControl”
Input M POS/EPS
InDeviceTarget M POS/EPS “DoorControl”
Command M POS/EPS “GetChar”
InputValue O EPS
InString M EPS Door state
e.g. open

Response
XML IFSF Initiator Description
Parameter
Request Type M POS/EPS Reflection from Request
WorkstationID M POS/EPS Reflection from Request
RequestID M POS/EPS Reflection from Request
POPID M POS/EPS Reflection from Request
OverallResult M POS/EPS Result of the request e.g. „Success“

Output O POS/EPS
OutDeviceTarget M POS/EPS “DoorControl”
OutResult M POS/EPS Result of the request e.g. „Success“
Input O POS/EPS
InDeviceTarget M POS/EPS “DoorControl”
InResult M POS/EPS Result of the request e.g. „Success“
InputValue O EPS
M EPS InString
Door state
e.g. open

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 107 of 144

14.8 Example for Door Control

1. POS Request

POS  EPS: Request

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>

<DeviceRequest RequestType="Output"
WorkstationID="999"
RequestID="1254"
POPID="1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceRequest.xsd">
<Output OutDeviceTarget="DoorControl"/>
<Input InDeviceTarget="DoorControl">
<Command >GetChar</Command>
</Input>
</DeviceRequest>

EPS  POS: Response

<?xml version="1.0" encoding="ISO-8859-1"?>

<DeviceResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\\Schema\\DeviceResponse.xsd
RequestType="Output"
WorkstationID="5"
RequestID="1254"
POPID="1"
OverallResult="Success">
<Output OutDeviceTarget="DoorControl"
OutResult="Success"/>
<Input InDeviceTarget="DoorControl"
InResult="Success">
<InputValue>
<InString>open</InString>
</InputValue></Input>
</DeviceResponse>
2. EPS unsolicited Request

EPS  POS: Request

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>

<DeviceRequest RequestType="Output"
WorkstationID="999"
RequestID="1254"
POPID="1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\Schema\DeviceRequest.xsd">
<Output OutDeviceTarget="DoorControl"/>
<Input InDeviceTarget="DoorControl">

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 108 of 144

<Command >GetChar</Command>
<InputValue>
<InString>open</InString>
</InputValue></Input>
</Input>
</DeviceRequest>

POS  EPS: Response

<?xml version="1.0" encoding="ISO-8859-1"?>

<DeviceResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="C:\\Schema\\DeviceResponse.xsd
RequestType="Output"
WorkstationID="5"
RequestID="1254"
POPID="1"
OverallResult="Success">
<Output OutDeviceTarget="DoorControl"
OutResult="Success"/>
<Input InDeviceTarget="DoorControl"
InResult="Success"/>
</DeviceResponse>

15. CASH IN DRAWER

15.1 Background
This is addition of a field to allow the POS to inform the EPS of the amount of cash in the drawer, or alternatively, the
maximum cash back allowed by the POS for the transaction.

15.2 CashAvailable
An optional CashAvailable element added to the POSData section of the CardRequest.xsd schema, defined as type
MonetaryAmount.

The POS should provide this data to inform the EPS of any POS limits to the amount of cash back available. The EPS
should not approve a cash back amount greater than the amount provided by the POS. If the element is not present,
then there are no POS cash back restrictions (i.e. no change to present functionality). Examples of the gaps this
functionality addressed include:
Preventing the EPS from approving more cash back than there is cash available in drawer.
Preventing the EPS from approving cash back when it is not available, such as at a self-service kiosk
Specifying a site level driven cash back limit.

15.3 POSData Element

The use of CashAvailable element is highlighted in this POSData element definition.

<xs:element name="POSData">
<xs:complexType>
<xs:sequence>
<xs:element name="POSTimeStamp" type="xs:dateTime"/>
<xs:element name="ServiceLevel" type="ServiceLevelType" minOccurs="0"/>

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 109 of 144

<xs:element name="ShiftNumber" minOccurs="0">

<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:totalDigits value="3"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="ClerkID" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:totalDigits value="9"/>
<xs:minInclusive value="0"/>
<xs:maxInclusive value="999999999"/>
<xs:fractionDigits value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="OutdoorPosition" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:totalDigits value="2"/>
<xs:fractionDigits value="0"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="CashAvailable" type="MonetaryAmount" minOccurs="0"/>
<xs:element name="Track1" type="xs:hexBinary" minOccurs="0"/>
<xs:element name="Track2" type="xs:hexBinary" minOccurs="0"/>
<xs:element name="Track3" type="xs:hexBinary" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="LanguageCode" type="LanguageCodeType" use="optional"/>
<xs:attribute name="ClerkLevel" type="xs:integer" use="optional" default="5"/>
<xs:attribute name="CardEntryMode" type="CardEntryModeType" use="optional"/>
<xs:attribute name="ForcePaymentMethod" type="PaymentMethodType" use="optional"/>
<xs:attribute name="Split" type="xs:boolean" use="optional" default="false"/>
<xs:attribute name="Unattended" type="xs:boolean" use="optional" default="false"/>
<xs:attribute name="StoreReq" type="StoreReqType" use="optional"/>
<xs:attribute name="TransactionNumber" type="RequestIDType" use="optional"/>
<xs:attribute name="ReferenceTransaction" type="RequestIDType" use="optional"/>
</xs:complexType>
</xs:element>

16. CASH BACK

Below chapter dociument the flow of cash back functionality in a post-pay and pre-pay transaction.

16.1 Cash Back in post-pay

EPS shall be configured to prompt for cash back by card type, and/or based on purchase device type.
EPS shall have maximum amount of cash back allowed by merchant (which would supersede amount sent by card
processor if the merchant limit is less than card processor limit).
The EPS does not have to be aware of the amount of cash in the drawer. Amount of cash in the drawer shall be a
merchant rule based on cash back service provided.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 110 of 144

1. EPS
CardPayment
3.
Request
1200

CardPayment 1210

8.
Response 7.
Merchant POS/Terminals
FEP/Card Processor
2.
Cash back
4. allowed?

9. POP

6. Yes No 5.

1 POS Initiates a CardPayment Request

2 The EPS shall force the cash back question (prompt).
3 1200 Message -request for auth sent through host to card processor with all product codes including cash product
code.
4 FEP/Card Processor shall determine if the account is allowed cash back and the limit the purchase device or
individual is allowed.
5 Decision=No - card processor has either determined that the cash back product code amount is over limit and
declines the transaction (with reason code/message), or the account/individual does not have a cash back
agreement with the card issuer and the transaction is declined.
6 Decision=Yes - card processor has determined that the account and purchase device is allowed cash back and is
within the limit. Approval of the transaction is given.
7 FEP/Card Processor returns a 1210 message to EPS.
8 EPS Returns CardPayment Response to POS. Cash back amount is in the CashBack field of the IFSF
CardPayment response and TotalAmount adjusted accordingly.
Cashier dispenses cash to customer.

16.2 Cash Back in pre-pay

EPS shall be configured to prompt for cash back by card type, and/or based on purchase device type.
EPS shall have maximum amount of cash back allowed by merchant (which would supersede amount sent by card
processor if the merchant limit is less than card processor limit).
The EPS does not have to be aware of the amount of cash in the drawer. Amount of cash in the drawer shall be a
merchant rule based on cash back service provided.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 111 of 144

2.
CardPreauthorization
EPS
Request 4.
1100
9. CardPreauthorization
1110
Response
CardFinancialAdvice 8.
11. Request 13.1220
1230
CardFinancialAdvice 14.
Merchant POS/Terminals 15. Response
FEP/Card Processor
12.
5. Cash back
allowed?

POP
16. 6.
1., 3., 10. 7. Yes No

1. Driver pulls up to the pump and swipes their card.

2. The POS sends a CardPreauthorization Request and includes the cash back product code in the EvaluateItems
element.
3. The EPS shall force the cash back question (prompt). Optionally, EPS may prompt customer for cash back amount
(depending on host requirements and EPS configuration).
4. 1100 message - request for auth sent through host to card processor with default product codes and cash product
code.
5. Card processor shall determine if the account is allowed cash back and the limit the purchase device or individual
is allowed.
6. Host-EPS Decision=No - card processor has determined that the cash back product code is over limit or the
account/individual does not have a cash back agreement.
7. Host-EPS Decision=Yes - card processor has determined that the account and purchase device is allowed cash
back and is within the limit.
8. Approval of the transaction is given and returned in a 1110 message to EPS.
9. EPS-POS – CardPreauthorization Response. The cash back product code is included in the RestrictionsCodes
element. This signals the POS to complete the transaction inside.
10. The customer finishes fueling and is directed inside.
11. POS initiates CardFinancialAdvice request with sales information.
12. EPS will prompt customer for cash back amount if this was not done during the PreAuthorization phase.
13. The EPS sends 1220 final and completed sales message to the card processor
14. Processor returns 1230 Post Sale message to the EPS.
15. In the IFSF CardFinancialAdvice response, the EPS sends the cash back amount in the CashBack field and
TotalAmount is adjusted accordingly.
Cashier dispenses cash to customer.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 112 of 144

17. CONFIGURABLE RECONCILIATION FORMATS

A new optional child element called ReconciliationGroup is added to the
ServiceRequest.POSData.Format field. It is an optional repeating element (a list), with each
instance being a unique enumerated string representing an attribute from the IFSF Reconciliation’s
TotalAmount element (e.g. CardCircuit, WorkstationID, CardEntryMode, etc.). To instruct the EPS
to use this new field, the current Format field would be populated by a new enumerated value called
“POSReconciliationGroups”.

When a POS requests a Reconciliation using the “POSReconciliationGroups” Format, the EPS will
parse the ReconciliationGroup element list and group transactions based upon the tags provided by
the POS.

Giving the POS a way to provide instruction to the EPS in the form of the ReconciliationGroup list
will enable the EPS to provide data in all possible combinations to the POS, including those
represented today by the existing Long, Short, and None formats.

Flexible reconciliation is backwards compatible. If the Reconciliation Format field is populated with a
legacy enumerated value (i.e. Short, None, Long), the EPS will recognize those values and process
accordingly. The default value will continue to be “Short”.

Flexible reconciliation can be used for Reconciliation and ReconciliationWithClosure.

The ReconciliationGroup element will be added as an optional element to the POSData element in
the ServiceRequest schema:
<xs:element name="ReconciliationGroup" minOccurs="0">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="PaymentType"/>
<xs:enumeration value="Currency"/>
<xs:enumeration value="CardCircuit"/>
<xs:enumeration value="Acquirer"/>
<xs:enumeration value="POPID"/>
<xs:enumeration value="TerminalID"/>
<xs:enumeration value="STAN"/>
<xs:enumeration value="TimeStamp"/>
<xs:enumeration value="ApprovalCode"/>
<xs:enumeration value="WorkstationID"/>
<xs:enumeration value="UsedPaymentMethod"/>
<xs:enumeration value="CardEntryMode"/>
<xs:enumeration value="AcquirerBatch"/>
</xs:restriction>
</xs:simpleType>
</xs:element>

The RecFormatType simpleType in IFSF_BasicTypesCard.xsd (used for the Format attribute) will
have “POSReconciliationGroups” added to its enumerations.
<xs:simpleType name="RecFormatType">
<xs:restriction base="xs:string">
<xs:enumeration value="Long"/>
<xs:enumeration value="Short"/>
<xs:enumeration value="None"/>

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 113 of 144

<xs:enumeration value="POSReconciliationGroups"/>
</xs:restriction>
</xs:simpleType>

The table* below illustrates the Reconciliation element in the ServiceResponse. The only mandatory
fields under TotalAmount are TotalAmountValue and NumberPayments.
Lite POS
Field Short None
Field Name Usage Tag Defined
Type Format Format
(Hex) Format
Reconciliation E B 6D M M M
TerminalBatch A B 7D M M M
LanguageCode A B 4E O O O
TotalAmount E I On On
TotalAmountReconciliation L 9A Mn Mn
TotalAmountValue L 84 M M
NumberPayments A B 56 O M
PaymentType A B 62 M O
Currency A B 3E O O
CardCircuit A B 2C M O
Acquirer A B 20 O O
POPID A B 65 O
TerminalID A B 7E O
STAN A B 78 O
CardPAN A B 2F O
TimeStamp A B 82 O
ApprovalCode A B 2A O
Workstation ID A B 8E O O
UsedPaymentMethod A B 8B O
CardEntryMode A B 2D O
AcquirerBatch A B 21 On O
*Modified from the IFSF 2.0 specification

17.1 Use Case

Step # Description
1. POS sends a ReconciliationWithClosure (ServiceRequest type) message to the EPS.
The Format field is “POSReconciliationGroups”
The ReconciliationGroups element is present 3 times (Example Only)
1. UsedPaymentMethod
2. CardEntryMode
3. Acquirer
2. EPS prompts the cashier as necessary.

Note: POS must support, as possible, DeviceRequest messages from the EPS at all
times between the start and end of the ServiceRequest message pair.
3. EPS does internal processing and closes all open acquirer batches.
4. EPS completes network processing by sending a ServiceResponse that corresponds
to the original ServiceRequest.

Reconciliation TotalAmount Elements contain the following attributes

TotalAmount value (required)

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 114 of 144

NumberPayments (required)
PaymentType (required)
Acquirer (by POS request)
UsedPaymentMethod (by POS request)
CardEntryMode (by POS request)
5. POS processes the response, evaluating the OverallResult and other pertinent fields.
In this example, transactions have been broken down by uniquely by acquirer, entry
mode, and method of payment.
ReconciliationWithClosure (POSReconciliationGroups) Use Case

APPENDIX A TCP/IP BASICS

A.1 TCP/IP Basics

TCP/IP stands for Transmission Control Protocol / Internet Protocol. It becomes most popular with the Internet.
TCP/IP actually refers to a group of protocols that are used for data transmission, it is the communications protocol in
most Unix networks, the Internet, and as a safe neutral protocol in many mixed-platform networks.

TCP/IP was developed in 1973 but was not published as a standard until 1983, when it was chosen as the standard
protocol for communications over the new ARPAnet wide area network (an early forerunner of the Internet). One of the
reasons for TCP/IP popularity in academic networks and within Unix stems from its origins in the University of
California, Berkeley, which developed the BSD series of Unix products, each incorporating the new TCP/IP protocol
and Berkeley sockets.

The TCP/IP protocol has five layers and can be closely modelled to the ISO/OSI seven-layer network model.

OSI Layer Level Description

7 Application Defines the program interface (Socket) to the network for user
applications
6 Presentation Is responsible for encoding data from the application layer ready for
transmission over the network and vice versa
5 Session Creates a virtual connection between applications
4 Transport Allows reliable communication of data
3 Network Makes it possible to access nodes in a LAN using logical addressing
2 Data Link Accesses the physical network with physical addresses
1 Physical Includes the connectors, cables and so on

As a data packet passes from the application layer down through the layers, each layer adds its own header and footer
information before passing the new packet down to the next layer. Once at the physical layer, the complete packet is
transmitted to the next node, where it is passed up the layers with the information headers stripped off one by one. At
the end, the data packet arrives at the application layer of the destination.

These packets of information that are passed over the network are called datagrams; each datagram contains a header
that include all relevant information needed to deliver the data correctly. The main parts of the datagram header include
the source and destination port numbers that are used to send the data to be transferred between the correct
processes running on each or one computer. There is also a sequence number that allows the destination computer to
rebuild the sequence of datagrams into the correct order and, lastly, there is an error-detection checksum.

The Internet Protocol (IP) part of the complete TCP/IP family is responsible for moving the data from one computer to
another using the network layer of the model. The IP is limited in that it does not contain any error detection or
correction information, nor does it establish or manage the link. Instead, it relies on TCP to carry out all of these

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 115 of 144

functions – the IP simply sends the datagram. As with the other layers, IP adds its own header to the datagram it
receives. This header contains basic information such as the length of the data, protocol, and version of IP being used.

Working on top of the TCP/IP suite of protocols are all sorts of applications that will be familiar to most experts: SNMP
for network management, FTP for file transfer, SMTP for email transfer, HTTP the Hypertext Transfer Protocol, DNS for
Domain Name Services, etc.

OSI 7 LAYER TCP/IP Protocol Stack

(7) Application H S S
T F M N D
(6) Presentation T T T M N
P P P P S
(5) Session

(4) Transport TCP UDP

(3) Network ICMP IP IGMP

(2) Data Link Ethernet, ATM,

Frame
(1) Physical Relay, etc.

The graphic above shows, that the TCP/IP protocol has a much simpler layered structure than the seven layers of the
OSI model. The Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) protocols are transport
protocols corresponding to OSI layer 4. Both protocols make use of the Internet Protocol (IP), an OSI layer 3 protocol
(the network layer). As well as these three protocols, there are two more basic protocols in the TCP/IP suite that extend
the IP protocol: ICMP and IGMP. The functionality of these protocols must be implemented in the layer housing the IP
protocol.
ICMP and IGMP stands for Internet Control Message Protocol and Internet Group Management Protocol.

A.2 TCP/IP Transmission Control Protocol

Connection-oriented communication can use reliable communication where the layer 4 protocol sends
acknowledgements of data receipts and requests retransmissions if data is not received or is corrupted. The TCP
protocol uses such reliable communication.
TCP requires that a connection must be opened before data can be send. The server application must perform a so -
called passive open to create a connection with a known port number, where rather than making a call to the network,
the server listens and waits for incoming requests.
The client application must perform an active open by sending a synchronize sequence number (SYN) to the server
application to identify the connection. The client application uses the server port number to send the SYN to the server.
The server must send an acknowledgement (ACK) to the client together with the sequence number (SYN) of the server.
The client in turn answers with an ACK and the connection is established. Now sending and receiving can start. After
receiving a message, an ACK messages is always returned.
The TCP protocol is complex and time consuming because of the handshaking mechanism, but this protocol takes care
of guaranteeing delivery of packets, obviating the need to include that functionality in the application protocol.

Contrary to TCP, UDP (User Datagram Protocol) is a very fast protocol as it specifies just the minimum mechanism
required for data transfer. This has some disadvantages. Messages can be received in any order and a message send
first could be received last. The delivery of UDP messages is not guaranteed at all and messages can be lost or even
two copies of the same message might be received.
UDP does not require a connection to be opened and data can be sent as soon as it is ready. UDP does not send
acknowledgement messages, so the data can be received or it can be lost. If reliable data transfer is needed over UDP,
it must be implemented in a higher-level protocol.
UDP can be used with unicast communications if fast transfer is required, such as multimedia delivery, but the major
advantage of UDP apply to broadcasts and multicasts.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 116 of 144

A.3 IP Addressing
The IP (Internet Protocol) actually moves a datagram between two computers, from the source port to the destination
port (both identified in the datagram header). In addition to this way of identifying the application that is sending or
receiving the datagram, IP must also be able to identify the correct computers in the transfer. Every node on a TCP/IP
network can be identified by a 32 bit IP address.

In order to identify each computer on the network, each different computer (or host) is allocated a unique IP address.
These 32-bit numbers are normally written as four eight-bit byte values (called octets), each separated by a full-stop
(for example 123.334.2.28).

An IP address consists of two parts: the network part and the host part. Depending on the network class, the network
part consists of the fort on, two or three bytes:

Class Byte 1 Byte 2 Byte 3 Byte 4

A Network (1-126) Host (0-255) Host (0-255) Host (0-255)
B Network(128-191) Network (0-255) Host (0-255) Host (0-255)
C Network(192-223) Network (0-255) Network(0-255) Host (0-255)
D Network(224-239) For multicasting

The first bit of a Class A network address must be ‘0’, so the first byte of a Class A network is in the binary range
00000001 (decimal 1) to 01111110 (decimal 126). The remaining three bytes serve to identify nodes on the network,
allowing us to connect more than 16 million devices on a Class A network. Note that the address 127.0.0.1 is always
the address of the local host, and 127.0.0.0 is a local loop-back. Loop-backs are used to test the network protocol
stack on a machine without going through the network interface card.

Class B networks always have the first two bits of the first byte of the IP address set to ‘10’, giving a range of 10000000
(decimal 128) to 10111111 (decimal 191). The second byte further identifies the network with a value of 0 to 255,
leaving the remaining two bytes to identify nodes on the network; a total of 65.534 devices.

Class C networks are denoted by an IP address where the first three bits are set to ‘110’, allowing a range of the first
byte from 11000000 (decimal 192) to 11011111(decimal 223). With this network type, only one byte is set aside for
node identification, so only 254 devices can be connected.

Class A, B and C network addresses leave addresses that have a first byte of 224 to 255. Class D networks (224 – 239)
are used for multicasting, and Class E (240 – 255) is reserved for testing purposes.

The Internet Protocol (IP) supports three kinds of IP addresses:

Unicast – unicast network packets are send to a single destination

Broadcast – broadcast datagrams are send to all nodes in a subnet
Multicast – multicast datagrams are send to all nodes, possible on different subnets, that belong to a group.

The TCP/IP protocol provides a connection-oriented communication where two systems communicate with each
other; with this protocol, we can only send unicast messages. If multiple clients connected to a single server, all clients
maintain a separate connection on the server. The server needs resources for each of these simultaneous connections,
and must communicate individually with every client.

Broadcast addresses are identified by IP addresses where all bits of the host are set to 1. For instance to send
messages to all hosts in a subnet with a mask of 255.255.255.0 in a network with the address 192.168.0, the broadcast
address would be 192.168.0.255. Any host with an IP address beginning with 192.168.0 will then receive the broadcast
messages.
Broadcasts are always performed with connectionless communication using the UDP protocol. The server sends the
data regardless of whether any client is listening.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 117 of 144

Multicast addresses are identified by IP addresses in the range 224.0.0.0 to 239.255.255.255. Multicast packets can
pass across different networks through routers, so it is possible to use multicats in an Internet scenario as long as the
network provider supports multicasting.

One of the disadvantages of an IP address is that, even when written in the four-part, dotted-decimal format, it is still
difficult to remember. Instead, the Internet uses host names that are associated with an IP address. Normally, these are
written as the domain name followed by the host name within that domain. For example, www.mycompay.com has a
domain name of “www” and a hostname of “mycompany.com”. The entire tree-word name is also called a fully qualified
host name or URL (Uniform Resource Locator) or URI (Uniform Resource Identifier) and refers to a host with a
particular, unique IP address.
The advantage of using host name instead of a dotted-decimal format IP address is that it is easy for a user to
remember. The disadvantage is that somewhere on the Internet there needs to be a table that will translate any host
name into its IP address. This is called a DNS (Domain Name Service) server, which can hold every IP address on the
Internet and its corresponding name.

A.4 TCP/IP Working Principles

Within a network that is using the TCP/IP suite of protocols there are two terms often confuse new users : ports and
sockets.

Whenever data is transferred from one application to another, it technically is being transferred from one port to
another port one the destination computer. The port number is used to identify the application that is running on a
computer. When the TCP/IP protocol receives data, it tries to identify the correct port number based on the type of data
using a look-up table. A port number is a numeric identifier that a process uses to identify itself at a given network (IP)
address.
No two processes can have the same port number at a given IP address.

The port number is a 16-bit number in the range 0 - 65535 and can be divided into three categories:

System (well known ) port numbers

User (registered ) port numbers
Dynamic or private ports

The system port numbers are in the range of 0 to 1023. System port numbers should only be used by system privileged
processes. Well-known protocols have default port numbers in this range. For example a web server applications is
almost always on port 80, an a FTP server application almost always on port 20.

User port numbers fall in the range 1024 to 49151. Your server applications usually will take one of these ports, an you
can also register the port number with the Internet Assigned Numbers Authority (IANA) if you wish to make it known to
the internet community.

Dynamic ports are used in the range 49152 to 65535. When it is not necessary to know the port number before starting
an application, a port in this range would be suitable. Client applications connecting to servers might use such a port.

The term socket does not define a protocol. It has two meanings, but neither of them relates to a protocol. One meaning
is the socket programming API (Application Program Interface) that was created initially by the University of Berkeley
for BSD Unix. BSD sockets were adapted as a programming interface for the Windows environment (under the name
WinSock). Windows sockets is a protocol independent programming interface for writing network applications.
The second usage of the term socket denotes an endpoint for communication between processes. In TCP/IP, an
endpoint is bound to an IP address and a port number. We have to differentiate between stream and datagram socket
types. A stream socket uses connection-oriented communication using the TCP/IP protocol. On the other hand the
datagram socket uses connection-less communication using UDP/IP.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 118 of 144

A socket identifies a particular networking session by combining the IP address and the port address. For any network
session there are always two sockets defined – one for the source and one for the destination. Together they form a
complete networking unit.

A socket can also be thought of as a two-way pipe; it contents two end points and allows data to flow across the pipe
from one end point to the other. As a technology, it was first implemented as a method for exposing the TCP/IP suite to
calling applications. Today, most socket API’s are generic enough to be used for almost any inter-process
communication request. From an application developer’s point of view, a socket is something that can be “plugged into”
to allow data to be send from one endpoint to another.
Sockets are a core technology for programming applications that communicate across IP networks.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 119 of 144

APPENDIX B IFSF LITE

B.1 IFSF Lite Data Coding

B.1.1 Introduction
XML and Lite IFSF Lite data conforms as far as possible to the IFSF XML data format.
Relationship Simple data (i.e. data that does not contain other data) have a one to one relation to
their counterpart in XML.
Data structure (i.e. data that contains attributes or other data elements in XML), are
defined as the sequence of the attributes first, then the elements of the corresponding
XML Schema structure.
Tables of the chapter III bring for each message, the order of the fields in the data
structures you can use in messages.

Schema Definition XML Structure Lite Structure

Element 1 Attribute 1 Attribute 1

Element n Attribute m Attribute m

Attribute 1 Element 1 Element 1

Attribute m Element n Element n

Figure B.1: Lite and XML Relationship

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 120 of 144

XML and Lite Let take as example the Login request message that is a ServiceRequest data
Example structure.
The Schema definition file ServiceRequest.xsd contains the definition of the data,
where the elements appear before the attributes in a data structure:
<xs:element name="ServiceRequest">
…
<xs:element name="POSData">
…
<xs:element name="POSTimeStamp" type="xs:dateTime"/>
…
<xs:element name="TotalAmount" minOccurs="0"> <xs:complexType>
…
<xs:attribute name="RequestType" type="ServiceRequestType" use="required"/>
…
<xs:attribute name="WorkstationID" type="WorkstationIDType" use="required"/>
<xs:attribute name="POPID" type="POPIDType" use="optional"/>
<xs:attribute name="RequestID" type="RequestIDType" use="required"/>
…
The XML Login message is encoded in the following manner:
<ServiceRequest RequestType="Login" IFSFVersion="1.7.1" WorkstationID="POS01"
POPID="012" RequestID="98254" … >
<POSdata ClerkLevel="6">
<POSTimeStamp>2004-02-17T18:39:09-08:00</POSTimeStamp>
</POSdata>
</ServiceRequest>
The order of the elements of the IFSF Lite Login message is shown below (we will see
the encoded message later in this section):
ServiceRequest
RequestType
IFSFVersion
WorkstationID
POPID
RequestID
POSData
POSTimeStamp

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 121 of 144

XML Values In XML, you enclose each data element by the start-tag containing the element name
and the attribute, and the end-tag containing the element name. Between these tags
you include the content of the data element, which could be the data element if this is
a data structure, a content value, or nothing.
For instance the data TotalAmount contains an optional attribute Currency, and the
value corresponding to the amount as shown in the example below:
<TotalAmount Currency="EUR">48.51</TotalAmount>
In this case, IFSF has to define three different data elements:
 The data structure TotalAmount,
 The data field Currency,
 The data field corresponding to the total amount, which has no
name in XML Schema, used only by IFSF Lite, and named TotalAmountValue.
This value is the first element of the data structure:
TotalAmount
TotalAmountValue
Currency
The usage of a content value, and the adding of a new data name in IFSF Lite with the
1
"Value" suffix , occurs in a very limited number of cases that are:
 CommandValue, for the DeviceRequest.Input.Command
structure,
 CurrentTimeValue, for the ServiceRequest.CurrentTime
structure,
 TextLineValue, for the DeviceRequest.Output.TextLine
structure,
 CommandValue, for the DeviceRequest.Input.Command
structure,
 LoyaltyAmountValue, for the
CardServiceRequest.LoyaltyReq.LoyaltyAmount and
CardServiceResponse.LoyaltyRep.LoyaltyAmount structures,
 LoyaltyApprovalCodeValue, for the
CardServiceRequest.LoyaltyReq. LoyaltyApprovalCode and
CardServiceResponse.LoyaltyRep. LoyaltyApprovalCode structures,
 LoyaltyCardContent, for the
CardServiceRequest.LoyaltyReq.LoyaltyCard and
CardServiceResponse.LoyaltyRep.LoyaltyCard structures,
 BuzzerValue, for the DeviceRequest.Output.Buzzer structure,
Obviously, these data, which are present in the Data Dictionary, are not used at all in
the XML message.

1
InputValue is an IFSF XML data structure, that does not belong to this case.
Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 122 of 144

XML Conflict In the IFSF Lite application protocol, each data is unique, and is identified by its name.
Names In the ISFS XML application protocol, each data is identified by its name in the
enclosing data structure. So the same name can be used in two different structures,
which globally the same high level semantic meaning but with a different syntax.
For instance, the data named Input is both element of the data structure
DeviceRequest, to contain the operation requested to the input device, and element of
the DeviceResponse data structure to contain the result of the input operation in the
message response.
To resolve the name conflict, the IFSF Lite protocol has introduced the new names
InputReq and InputResp, to identify the related data structures.
The data name conflicts occurs also in a very limited number of times, the Data
Dictionary provide for such entries the double name <XML Name>/<Lite Name>:
 InputReq and InputResp, for the DeviceRequest.Input and
DeviceResponse.Input structures,
 OutputReq and OutputResp, for the DeviceRequest.Output
and DeviceResponse.Output structures,
 CardRequestType, ServiceRequestType and
DeviceRequestType, for the CardServiceRequest.RequestType and
CardServiceResponse.RequestType, ServiceRequest.RequestType and
ServiceResponse.RequestType, and DeviceRequest.RequestType and
DeviceResponse.RequestType structures respectively,
 TotalAmountReq, TotalAmountResp, and
TotalAmountReconciliation for the CardServiceRequest.TotalAmount,
CardServiceResponse.TotalAmount and ServiceResponse.TotalAmount
structures respectively,
 LoyaltyReq and LoyaltyRep, for the
CardServiceRequest.Loyalty and CardServiceResponse.Loyalty structures,
The TotalAmount data structure we have used as example in the previous item has the
following definition:
TotalAmountReq
TotalAmountValue
Currency

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 123 of 144

B.1.2 Data Encoding

Coding Each data used in the messages of the IFSF Lite interface is coded using three fields:
Structure  The Tag which identifies the data and its type,
 The Length which specifies the data length, and is included
only when the length of the field is not fixed. When the field length is fixed, the
length is said to be “implied”
 The Value, which gives the content of the data.

Data Tag Length Value

Figure B.21: IFSF Lite Data Encoding

B.1.3 Tag Encoding

Tags Each and every element has been assigned a unique one-byte tag. This byte is an
Allocation unsigned integer.
Data tag values may be found in a following section (e. g. WorkStationID data has the
decimal tag 142 and the hexadecimal tag 8E).

Reserved Values less that 32 (decimal) have not been used to avoid conflict with values that can
Tags be used by the serial protocol as data communications control characters.
The tag 255 (decimal) is reserved to allow future expansion beyond 223 tags using
multiple byte tags.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 124 of 144

B.1.4 Length Encoding

Length Length encoding is based on ASN.1 BER. (Basic Encoding Rules) , and contains the
Encoding number of bytes of the value Field.
There are three forms of Length encoding:
 The Implied form, if the data width is fixed, then the Length
field is absent,
 The Short form, if the data width is variable and less than 128
bytes, then the Length field is coded using one byte,
 The Long form, if the data width is variable and more than 127
bytes, then the Length field is coded using more than one byte.
For most cases either the Short or the Implied Forms are used for the coding of data.

Data Tag Length Value

Number of bytes of Value field

Implied Fixed number of bytes of Value field

Short Definite 0 Number of bytes of Value field

Long Definite 1
Number of bytes of Value field

Number of bytes following

Figure 2: IFSF Lite Length Encoding

Implied Form Over half of the fields in this specification have a fixed length, thus a length byte is not
necessary in these cases, and data begins immediately following the tag byte.
The data dictionary defines which fields have an implied length for example, Currency
data have an implied length of 2, and US Dollar currency is encoded as the
hexadecimal sequence: 3E 08 40.

Short Form The Short Form encoding is used for lengths from zero to 127. A single byte is used
as an 8-bit integer to hold the length.
A 31-byte length would be encoded as the hexadecimal byte 1F.

Long Form For values greater than 127, the Long Form is used. The most significant bit of the
first byte is set to indicate long form, and the remaining 7 bits indicate the number of
bytes following that should be interpreted together as an unsigned integer.
A length of 155 bytes would be encoded the hexadecimal sequence: 81 9B.
A length of 256 bytes would be encoded the hexadecimal sequence: 82 01 00.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 125 of 144

B.1.5 Value Encoding

Value Encoding of Value field depends on data type which can be:
Encoding  Complex, data containing a sequence of other data,
 Enum, finite set of possible values,
 Boolean, comprising two possible values true or false,
 Text String, string of alphanumeric characters,
 Character, composed of one character,
 Binary, string of hexadecimal bytes,
 BCD Integer, right justified decimal digit string,
 BCD String, left justified decimal digit string,
 Signed Integer, binary signed integer,
 BCD NvM, decimal number with a fixed number of fractional
digits,
 Compressed Track String, for track 2 and 3 of magnetic cards.
Most of the data types used within this IFSF Lite specification compress the data. This
is to support the anticipated higher bandwidth requirements of the IFSF interface. The
data types of each element are listed in the Data Dictionary above.

Complex This is an element containing only other elements.

The length byte for this element includes all the bytes of the contained fields, including
their tag and length bytes.
The Value is composed of the sequence of all its elements.

Enum This is a single byte Value where discrete values are given specific meanings.

Boolean This is a single byte Value, where false is encoded with the decimal value 32, and true
the decimal value 33.

Text String The Value is a string of ASCII and international characters with values greater than or
equal to 32. Values less than 32 are commonly used as special control characters,
and their use is avoided.

Character The Value is a single character, usually a significant ASCII value. It is similar to an
Enum type, except that the character is meaningful. One example is ‘S’ for Self
Service Level and ‘F’ for Full Service.

Binary The Value has straight hexadecimal representation, also known as “binary”.

BCD A quick note regarding BCD. BCD stands for Binary Coded Decimal. BCD encoded
values store two decimal digits in each byte.
Values with a scalar meaning (integers, currency amounts, etc.) are right justified zero
filled, while numeric strings (PAN’s, SSN’s, UserIDs, etc.) are left justified and “ F”
filled, when leading zero may be significant. See below for more information.

BCD Integer The Value is a simple integer encoding where each byte represents two BCD digits.
For example, the number 192 would be encoded as the hexadecimal sequence: 01
92.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 126 of 144

BCD String The Value is a representation of a string value that just happens to be limited to
numeric characters. Examples include PAN’s , SSN’s, etc.
These strings are always left justified and space padded to an even number of bytes.
For example, a ClerkID of 269 would be encoded as the hexadecimal sequence: 26
9F.

Signed The Value is a signed binary integer, coded as 2's complement.

Integer For example, value of +15 would be encoded as the hexadecimal byte: 0F, and a value
of -2 would be encoded as the hexadecimal byte: FE.

BCD NvM The Value is a fractional decimal number with a fixed number of fractional digits. As
such, it is more like an integer than a float. The maximum value and precision are
expressed as NvM, where N is the maximum number of digits, both whole and
fractional, and M is the number of fractional digits.
For example, USD values up to $999.99 could be stored in a field defined as a BCD
5v2 type. These values are BCD encoded for compression, with each byte holding
two integers. Values are always right justified and zero filled.
For example, a TotalAmountValue (type BCD 12v3) of $120.83 will be encoded as the
hexadecimal sequence: 12 08 30 for the Value field.
If the length is variable, all the leading zero (i.e. at the left) are discarded. Example of
BCD 7v4 coding with variable length are:
0.001 coded as 10,
0.1 coded as 10 00,
1.0 coded as 01 00 00,
3,508.1 coded as 35 08 10 00,

Compressed Tracks 2 and 3 of payment and loyalty cards are encoded with a 4-bit character
Track String encoding (i.e. an hexadecimal digit), thus two characters can be stored per byte.
Tracks 2 and 3 does not contain the Start and End Sentinels, and the LRC.
Each character is:
 A decimal digit, with the hexadecimal value from 0 to 9
 The separator, with the hexadecimal value D
 The padding character, with the hexadecimal value F, as last
character of the string if the number of digits is odd, in order to have a whole
number of bytes.
Below is an example of track2 value:
0000 70 79 32 21 34 07 10 03 00 3D 93 05 00 00 00 00 |py2!4....=......|
0010 00 00 0F |... |

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 127 of 144

B.2 IFSF Lite Message Coding

Message An IFSF POS-EPS message is XML document where the root element has one of the
Encoding following tag:
 CardServiceRequest, for a CardService message request sent
by a POS workstation (CardPayment request, CardPreAuthorisation request,…),
 CardServiceResponse, for a CardService message response
sent by EPS (CardPayment response, CardPreAuthorisation response,…),
 ServiceRequest, for a Service message request sent by a
POS workstation (Login request, ReconciliationWithClosure request,…),
 ServiceResponse, for a Service message response sent by
EPS (Login response, ReconciliationWithClosure response,…),
 DeviceRequest, for a Device message request sent by a POS
workstation or the EPS (CashierTerminal request, PINVerify request,…),
 DeviceResponse, for a Device message response sent by a
POS workstation or EPS (CashierTerminal response, PINVerify response,…),
IFSF Lite defines six related complex data, allowing encoding of the whole message.

Message As example, we consider a Login message request containing the following data and
Example values:
Data Name Value
ServiceRequest
RequestType “Login”
WorkstationID “POS01”
POPID “012”
RequestID “98254”
POSData
POSTimeStamp “2004-02-17T18:39:09-08:00"

XML IFSF The encoding of the previous message provides the following text string:
<?xml version="1.0" encoding="UTF-8"?>
Message
<ServiceRequest RequestType="Login" WorkstationID="POS01" POPID="012"
Encoding RequestID="98254" xmlns="http://www.nrf-arts.org/IXRetail/namespace"
xmlns:IFSF="http://www.ifsf.org/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=“.\ServiceRequest.xsd">
<POSdata >
<POSTimeStamp>2004-02-17T18:39:09-08:00</POSTimeStamp>
</POSdata>
</ServiceRequest>

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 128 of 144

XML IFSF The binary dump of this message is presented below:

0000 3C 3F 78 6D 6C 20 76 65 72 73 69 6F 6E 3D 22 31 |<?xml version="1|
Binary 0010 2E 30 22 20 65 6E 63 6F 64 69 6E 67 3D 22 55 54 |.0" encoding="UT|
Message 0020 46 2D 38 22 3F 3E 3C 53 65 72 76 69 63 65 52 65 |F-8"?><ServiceRe|
0030 71 75 65 73 74 20 52 65 71 75 65 73 74 54 79 70 |quest RequestTyp|
0040 65 3D 22 4C 6F 67 69 6E 22 20 57 6F 72 6B 73 74 |e="Login" Workst|
0050 61 74 69 6F 6E 49 44 3D 22 50 4F 53 30 31 22 20 |ationID="POS01" |
0060 50 4F 50 49 44 3D 22 30 31 32 22 20 52 65 71 75 |POPID="012" Requ|
0070 65 73 74 49 44 3D 22 39 38 32 35 34 22 20 78 6D |estID="98254" xm|
0080 6C 6E 73 3D 22 68 74 74 70 3A 2F 2F 77 77 77 2E |lns="http://www.|
0090 6E 72 66 2D 61 72 74 73 2E 6F 72 67 2F 49 58 52 |nrf-arts.org/IXR|
00A0 65 74 61 69 6C 2F 6E 61 6D 65 73 70 61 63 65 22 |etail/namespace"|
00B0 20 78 6D 6C 6E 73 3A 49 46 53 46 3D 22 68 74 74 | xmlns:IFSF="htt|
00C0 70 3A 2F 2F 77 77 77 2E 69 66 73 66 2E 6F 72 67 |p://www.ifsf.org|
00D0 2F 22 20 78 6D 6C 6E 73 3A 78 73 69 3D 22 68 74 |/" xmlns:xsi="ht|
00E0 74 70 3A 2F 2F 77 77 77 2E 77 33 2E 6F 72 67 2F |tp://www.w3.org/|
00F0 32 30 30 31 2F 58 4D 4C 53 63 68 65 6D 61 2D 69 |2001/XMLSchema-i|
0100 6E 73 74 61 6E 63 65 22 20 78 73 69 3A 73 63 68 |nstance" xsi:sch|
0110 65 6D 61 4C 6F 63 61 74 69 6F 6E 3D 93 2E 5C 53 |emaLocation=..\S|
0120 65 72 76 69 63 65 52 65 71 75 65 73 74 2E 78 73 |erviceRequest.xs|
0130 64 22 3E 09 3C 50 4F 53 64 61 74 61 20 3E 09 09 |d">.<POSdata >..|
0140 3C 50 4F 53 54 69 6D 65 53 74 61 6D 70 3E 32 30 |<POSTimeStamp>20|
0150 30 34 2D 30 32 2D 31 37 54 31 38 3A 33 39 3A 30 |04-02-17T18:39:0|
0160 39 2D 30 38 3A 30 30 3C 2F 50 4F 53 54 69 6D 65 |9-08:00</POSTime|
0170 53 74 61 6D 70 3E 09 3C 2F 50 4F 53 64 61 74 61 |Stamp>.</POSdata|
0180 3E 3C 2F 53 65 72 76 69 63 65 52 65 71 75 65 73 |></ServiceReques|
0190 74 3E |t> |

IFSF Lite The encoding of the previous message is showed below with the Data name, the Tag
Message Length and Value encoding in hexadecimal byte:
Data Name Tag Length Value Comment
Encoding ServiceRequest 97 2D
RequestType 95 24 Login
WorkstationID 8E 01 POS #1
POPID 65 0C POP #12
RequestID 6F 03 09 82 54 req #98254
POSData 66 08
POSTimeStamp 68 20 04 02 17 10 39 09

IFSF Lite The binary dump of this message is presented below, tags are in bold face and length
Binary in italic:
0000 97 15 95 24 8E 01 65 0C 6F 03 09 82 54 66 08 68 |...$..e.o...Tf.h|
Message 0010 20 04 02 17 10 39 09 | ....9. |

XML Value Taking again the case of the XML content value, below are the encoding of an
Example example of data structure TotalAmount in XML and in Lite.

The XML encoding is provided below with the data dump, supposing of course a UTF8
encoding:
<TotalAmount Currency="EUR">48.51</TotalAmount>
0000 3C 54 6F 74 61 6C 41 6D 6F 75 6E 74 20 43 75 72 |<TotalAmount Cur|
0010 72 65 6E 63 79 3D 22 45 55 52 22 3E 34 38 2E 35 |rency="EUR">48.5|
0020 31 3C 2F 54 6F 74 61 6C 41 6D 6F 75 6E 74 3E |1</TotalAmount> |

The Lite encoding of the same data is presented below:

Data Name Tag Length Value Comment
TotalAmountReq 83 07
TotalAmountValue 84 03 48 51 00 48.51
Currency 44 86 EUR
0000 83 07 84 03 48 51 00 44 86 |....HQ.D. |

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 129 of 144

Long XML A ticket print, for an indoor payment, in IFSF mode would have the following format :
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
Message - <DeviceRequest RequestID="00001692" RequestType="Output" WorkstationID="POS001" POPID="001"
Example RequestID="00001692" RequestType="Output" xmlns="http://www.nrf-
arts.org/IXRetail/namespace">
- <Output OutDeviceTarget="Printer" Complete="false" >
<TextLine />
<TextLine >OIL BUSINESS RECEIPT</TextLine>
<TextLine >Acct/Card # : XXXXXXXXXXXXXX4448</TextLine>
<TextLine >Auth # : 102030</TextLine>
<TextLine >ODOMETER 1234</TextLine>
<TextLine >RESP CODE 000 REF 559</TextLine>
<TextLine />
<TextLine >CUSTOMER COPY</TextLine>
<TextLine />
<TextLine >THANKS, COME AGAIN</TextLine>
</Output>
- <Output OutDeviceTarget="Printer" Complete="false" >
<TextLine />
<TextLine >OIL BUSINESS RECEIPT</TextLine>
<TextLine >Acct/Card # : XXXXXXXXXXXXXX4448</TextLine>
<TextLine >Auth # : 102030</TextLine>
<TextLine >ODOMETER 1234</TextLine>
<TextLine >RESP CODE 000 REF 559</TextLine>
<TextLine />
<TextLine >MERCHANT COPY</TextLine>
<TextLine />
<TextLine >________________________________________</TextLine>
<TextLine >SIGNATURE</TextLine>
<TextLine >I agree to pay the amount stated</TextLine>
<TextLine >on this receipt.</TextLine>
<TextLine />
<TextLine >THANKS, COME AGAIN</TextLine>
</Output>
</DeviceRequest>

Long Lite For Lite format, this would result in the following data
Message
Example

Name Tag Length Data Comment

DeviceRequest 93 82 Overall length of this message

01 E7
DeviceRequestType 96 21 Output
Workstation ID 8E 01 POS001
POPID 65 01 001
RequestID 6F 04 00 00 16 92 00001692
OutputReq 5C 81 B0
OutDeviceTarget 5A 22 Printer
Complete 3C 20 false
TextLine 7F 02
TextLineValue 80 00 ""
TextLine 7F 16
TextLineValue 80 14 4F 49 4C 20 42 "OIL BUSINESS RECEIPT"
55 53 49 4E 45
53 53 20 52 45
43 45 49 50 54
TextLine 7F 22
TextLineValue 80 20 41 63 63 74 2F "Acct/Card # : XXXXXXXXXXXXXX4448"
43 61 72 64 20
23 20 3A 20 58
58 58 58 58 58

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 130 of 144

Name Tag Length Data Comment

58 58 58 58 58
58 58 58 34 34
34 38
TextLine 7F 11
TextLineValue 80 0F 41 75 74 68 20 "Auth # : 102030"
23 20 3A 20 31
30 32 30 33 30
TextLine 7F 0F
TextLineValue 80 0D 4F 44 4F 4D 45 "ODOMETER 1234"
54 45 52 20 31
32 33 34
TextLine 7F 17
TextLineValue 80 15 52 45 53 50 20 "RESP CODE 000 REF 559"
43 4F 44 45 20
30 30 30 20 52
45 46 20 35 35
39
TextLine 7F 02
TextLineValue 80 00 ""
TextLine 7F 0F
TextLineValue 80 0D 43 55 53 54 4F "CUSTOMER COPY"
4D 45 52 20 43
4F 50 59
TextLine 7F 02
TextLineValue 80 00 ""
TextLine 7F 14
TextLineValue 80 12 54 48 41 4E 4B "THANKS, COME AGAIN"
53 2C 20 43 4F
4D 45 20 41 47
41 49 4E
OutputReq 5C 82
01 24
OutDeviceTarget 5A 22 Printer
Complete 3C 20 false
TextLine 7F 02
TextLineValue 80 00 ""
TextLine 7F 16
TextLineValue 80 14 4F 49 4C 20 42 "OIL BUSINESS RECEIPT"
55 53 49 4E 45
53 53 20 52 45
43 45 49 50 54
TextLine 7F 22
TextLineValue 80 20 41 63 63 74 2F "Acct/Card # : XXXXXXXXXXXXXX4448"
43 61 72 64 20
23 20 3A 20 58
58 58 58 58 58
58 58 58 58 58
58 58 58 34 34
34 38
TextLine 7F 11
TextLineValue 80 0F 41 75 74 68 20 "Auth # : 102030"
23 20 3A 20 31
30 32 30 33 30
TextLine 7F 0F
TextLineValue 80 0D 4F 44 4F 4D 45 "ODOMETER 1234"
54 45 52 20 31
32 33 34
TextLine 7F 17
TextLineValue 80 15 52 45 53 50 20 "RESP CODE 000 REF 559"
43 4F 44 45 20
30 30 30 20 52
45 46 20 35 35

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 131 of 144

Name Tag Length Data Comment

39

TextLine 7F 02
TextLineValue 80 00 ""
TextLine 7F 0F
TextLineValue 80 0D 4D 45 52 43 48 "MERCHANT COPY"
41 4E 54 20 43
4F 50 59
TextLine 7F 02
TextLineValue 80 00 ""
TextLine 7F 2A
TextLineValue 80 28 5F 5F 5F 5F 5F "________________________________________
5F 5F 5F 5F 5F "
5F 5F 5F 5F 5F
5F 5F 5F 5F 5F
5F 5F 5F 5F 5F
5F 5F 5F 5F 5F
5F 5F 5F 5F 5F
5F 5F 5F 5F 5F
TextLine 7F 0B
TextLineValue 80 09 53 49 47 4E 41 "SIGNATURE"
54 55 52 45
TextLine 7F 22
TextLineValue 80 20 49 20 61 67 72 "I agree to pay the amount stated"
65 65 20 74 6F
20 70 61 79 20
74 68 65 20 61
6D 6F 75 6E 74
20 73 74 61 74
65 64
TextLine 7F 11
TextLineValue 80 0F 6F 6E 20 74 68 "on this receipt"
69 73 20 72 65
63 65 69 70 74
TextLine 7F 02
TextLineValue 80 00 ""
TextLine 7F 14
TextLineValue 80 12 54 48 41 4E 4B "THANKS, COME AGAIN"
53 2C 20 43 4F
4D 45 20 41 47
41 49 4E

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 132 of 144

Message If this were to be viewed as a binary dump it would appear as follows:

0000 93 82 01 E7 96 21 8E 01 65 01 6F 04 00 00 16 92 |.....!..e.o.....|
Dump 0010 5C 81 B0 5A 22 3C 20 7F 02 80 00 7F 16 80 14 4F |\..Z"< ........O|
0020 49 4C 20 42 55 53 49 4E 45 53 53 20 52 45 43 45 |IL BUSINESS RECE|
0030 49 50 54 7F 22 80 20 41 63 63 74 2F 43 61 72 64 |IPT.". Acct/Card|
0040 20 23 20 3A 20 58 58 58 58 58 58 58 58 58 58 58 | # : XXXXXXXXXXX|
0050 58 58 58 34 34 34 38 7F 11 80 0F 41 75 74 68 20 |XXX4448....Auth |
0060 23 20 3A 20 31 30 32 30 33 30 7F 0F 80 0D 4F 44 |# : 102030....OD|
0070 4F 4D 45 54 45 52 20 31 32 33 34 7F 17 80 15 52 |OMETER 1234....R|
0080 45 53 50 20 43 4F 44 45 20 30 30 30 20 52 45 46 |ESP CODE 000 REF|
0090 20 35 35 39 7F 02 80 00 7F 0F 80 0D 43 55 53 54 | 559........CUST|
00A0 4F 4D 45 52 20 43 4F 50 59 7F 02 80 00 7F 14 80 |OMER COPY.......|
00B0 12 54 48 41 4E 4B 53 2C 20 43 4F 4D 45 20 41 47 |.THANKS, COME AG|
00C0 41 49 4E 5C 82 01 24 5A 22 3C 20 7F 02 80 00 7F |AIN\..$Z"< .....|
00D0 16 80 14 4F 49 4C 20 42 55 53 49 4E 45 53 53 20 |...OIL BUSINESS |
00E0 52 45 43 45 49 50 54 7F 22 80 20 41 63 63 74 2F |RECEIPT.". Acct/|
00F0 43 61 72 64 20 23 20 3A 20 58 58 58 58 58 58 58 |Card # : XXXXXXX|
0100 58 58 58 58 58 58 58 34 34 34 38 7F 11 80 0F 41 |XXXXXXX4448....A|
0110 75 74 68 20 23 20 3A 20 31 30 32 30 33 30 7F 0F |uth # : 102030..|
0120 80 0D 4F 44 4F 4D 45 54 45 52 20 31 32 33 34 7F |..ODOMETER 1234.|
0130 17 80 15 52 45 53 50 20 43 4F 44 45 20 30 30 30 |...RESP CODE 000|
0140 20 52 45 46 20 35 35 39 7F 02 80 00 7F 0F 80 0D | REF 559........|
0150 4D 45 52 43 48 41 4E 54 20 43 4F 50 59 7F 02 80 |MERCHANT COPY...|
0160 00 7F 2A 80 28 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F |..*.(___________|
0170 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F |________________|
0180 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 5F 7F 0B 80 |_____________...|
0190 09 53 49 47 4E 41 54 55 52 45 7F 22 80 20 49 20 |.SIGNATURE.". I |
01A0 61 67 72 65 65 20 74 6F 20 70 61 79 20 74 68 65 |agree to pay the|
01B0 20 61 6D 6F 75 6E 74 20 73 74 61 74 65 64 7F 11 | amount stated..|
01C0 80 0F 6F 6E 20 74 68 69 73 20 72 65 63 65 69 70 |..on this receip|
01D0 74 7F 02 80 00 7F 14 80 12 54 48 41 4E 4B 53 2C |t........THANKS,|
01E0 20 43 4F 4D 45 20 41 47 41 49 4E | COME AGAIN |

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 133 of 144

B.3 IFSF Lite Data Dictionnary

Introduction This section presents the detailed syntaxic and semantic informations of each data
fields of the application messages, ordered in alphabetical order. Every data
contains the following information:
 The Lite Tag.
 The Data Name of the field which is the same as in XML
with variations explained above.
 The Lite Type.
 The Length.

Tag Data Name Type Length

20 Acquirer Text String 1-20
21 AcquirerBatch BCD Int. 1-10
22 AcquirerID Text String 1-20
23 AdditionalProductCode BCD Int. 1-8
24 AdditionalProductInfo Text String 1-99
B7 Agent Agent Impl. 1 32 = MobilePhonePrepaid
Enum
27 Alignment Alignment Impl. 1 32 = Left
Enum 33 = Right
34 = Center
35 = Justified
28 Amount BCD 12v4 1-6
29 ApplicationSender Text String 1-8
2A ApprovalCode Text String 1-20
2B Authorization Complex
2C AutoConfirm Boolean Impl. 1
CF Barcode Text String 8-14
C2 Buzzer Complex
C3 BuzzerValue Boolean Impl. 1
2C CardCircuit Text String 1-20
2F CardPAN BCD String 5-10
31 CardReadElement CardRead Impl. 1 32 = Magstripe
Enum 33 = ICC
34 = EMV
35 = MagstripeRFID
70 CardRequestType CardRequest Impl. 1 32 = CardPayment
Enum 33 = CardPreAuthorisation
34 = CardFinancialAdvice
35 = PaymentReversal
36 = PaymentRefund
37 = TicketReprint
38 = StoreValueInCard
39 = CardBalanceQuery
40 = RepeatLastMessage
41 = CardRead
42 = LoyaltyAward
43 = LoyaltyRedemption
44 = LoyaltyAwardReversal
45 = LoyaltyRedemptionReversal
46 = LoyaltyBalanceQuery
47 = LoyaltyLinkCard
48 = LoyaltyAwardRefund
49 = LoyaltyRedemptionRefund
91 CardServiceRequest Complex

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 134 of 144

Tag Data Name Type Length

92 CardServiceResponse Complex
32 CashBackAmount BCD 12v4 1-6
BF CharSet Binary Impl. 2
33 CharStyle1 CharStyle Impl. 1 32 = Normal
Enum 33 = Bold
34 = Italic
35 = Underline
34 CharStyle2 CharStyle Impl. 1
Enum
35 CharStyle3 CharStyle Impl. 1
Enum
36 ClerkID BCD Int. 1-5
38 Color ColorEnum Impl. 1 32 = White
33 = Black
34 = Red
35 = Green
36 = Yellow
37 = Blue
38 = Grey
39 = Brown
39 Column BCD Int. Impl. 1
3A Command Complex
3B CommandValue CommandEnum Impl. 1 32 = GetDecimals
33 = GetChar
34 = GetAmount
35 = GetAnyKey
36 = GetConfirmation
37 = ReadCard
38 = CheckPIN
39 = ProcessPIN
3C Complete Boolean Impl. 1
C5 CounterBeep Binary Impl. 1
3E Currency Currency Impl. 1 32 = ADP (Andorran Peseta)
Enum 33 = AED (UAE Dirham)
…
227 = ZMK (Kwacha)
228 = ZWD (Zimbabwe Dollar)
C1 Cursor Boolean Impl. 1
3F Decimals BCD Int. 1-10
93 DeviceRequest Complex
96 DeviceRequestType DeviceRequest Impl. 1 32 = Input
Enum 33 = Output

94 DeviceResponse Complex
C4 DurationBeep Binary Impl. 2
C6 DurationPause Binary Impl. 2
40 Echo Boolean Impl. 1
CD EMV Complex
C0 Erase Boolean Impl. 1
BA FiscalReceipt Boolean Impl. 1
43 Height Height Impl. 1 32 = Single
Enum 33 = Double
34 = Half
D2 Hex Binary 1-64
CE ICC Complex
45 InBoolean Boolean Impl. 1
46 InDeviceTarget Device 32 = CashierDisplay
33 = CustomerDisplay

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 135 of 144

Tag Data Name Type Length

Enum 34 = Printer
35 = ICCrw
36 = CardReader
37 = PinEntryDeviceCardReader
38 = PinPad
39 = PEDReaderPrinter
40 = MSR
41 = RFID (not currently used for IFSF Lite, included for
consistency)
42 = BarcodeScanner
43 = CashierKeyboard
44 = CashierTerminal
45 = POS
47 InNumber BCD Int. 1- 32
48 InputReq Complex
90 InputResp Complex
BD InputSynchronize
49 InputValue Complex
4A InResult RequestResultE Impl. 1
num
CA InSecureData Boolean Impl. 1
4B InString Text String 1-64
4D ItemID Text String 1-4
4E LanguageCode Language Impl. 1 32 = aa (Afar)
Enum 33 = ab (Abkhazian)
34 = af (Afrikaans)
…
168 = za (Zhuang)
169 = zh (Chinese)
170 = zu (Zulu)
4F Length BCD Int. Impl. 1
D1 LoyaltyAcquirerBatch Text String 1-10
B4 LoyaltyAcquirerID Text String 1-20
BC LoyaltyAllowed Boolean Impl. 1
AF LoyaltyAmount Complex
B0 LoyaltyAmountValue BCD 12v4 1-6
B2 LoyaltyApprovalCode Complex
B3 LoyaltyApprovalCodeValue Text String 1-20
AC LoyaltyCard Complex
AD LoyaltyCardContent Binary 1-19
AB LoyaltyFlag Boolean Impl. 1
AE LoyaltyPAN BCD String 5-10
AA LoyaltyRep Complex
A9 LoyaltyReq Complex
B6 LoyaltyTimeStamp BCD Int. Impl. 7
C8 MAC Complex
51 MaxLength BCD Int. Impl. 1
52 MaxTime BCD Int. Impl. 2
53 MaxTries BCD Int. Impl. 1
54 MinLength BCD Int. Impl. 1
55 MinTime BCD Int. Impl. 1
B9 MOPRule Complex
56 NumberPayments BCD Int. 1-3

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 136 of 144

Tag Data Name Type Length

A7 OriginalAmount BCD 12v4 1-6
58 OriginalHeader Complex
B1 OriginalLoyaltyAmount BCD 12v4 1-6
59 OriginalTransaction Complex
5A OutDeviceTarget Device Impl. 1
Enum
5B OutdoorPosition BCD Int. Impl. 1
5C OutputReq Complex
5D OutputResp Complex
5E OutResult RequestResult Impl. 1 32 = Success
Enum 33 = PartialFailure
34 = Failure
35 = DeviceUnavailable
36 = Aborted
37 = TimeOut
38 = FormatError
39 = ParsingError
40 = ValidationError
41 = MissingMandatoryData
42 = Logout
43 = Busy
C7 OutSecureData Complex
5F OverallResult RequestResult Impl. 1
Enum
60 PaperCut Boolean Impl. 1
61 PaymentAmount BCD 12v4 1-6
62 PaymentType Transaction Impl. 1 32 = Debit
Enum 33 = Credit

65 POPID Binary Impl. 1

4C POSAddress Binary 1-6
66 POSData Complex
68 POSTimeStamp BCD Int. Impl. 7
6B ProductCode BCD Int. Impl. 2
6C Quantity BCD 7v4 3-5
B5 RebateLabel Text String 1-16
6D Reconciliation Complex
CC ReferenceRequestID BCD Int. 1-4
6F RequestID BCD Int. 1-4
71 RestrictionCodes BCD Int. Impl. 2
BE Row BCD Int. Impl. 1
73 SaleChannel Text String 1-20
74 SaleItem Complex
D0 SecureData Complex
C9 Separator Separator Impl. 1 33 = Dot
Enum 34 = Comma

CB SequenceID Binary Impl. 1

75 ServiceLevel Character Impl. 1
97 ServiceRequest Complex
95 ServiceRequestType ServiceEnum Impl. 1 32 = Diagnosis
33 = SendOffllineTransactions
34 = Reconciliation
35 = ReconciliationWithClosure
36 = Login

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 137 of 144

Tag Data Name Type Length

37 = Logoff
38 = RepeatLastMessage
98 ServiceResponse Complex
76 ShiftNumber BCD Int. Impl. 2
78 STAN BCD Int. 1-4
7A TaxCode BCD Int. Impl. 1
7B Tender Complex
7C Terminal Complex
7D TerminalBatch BCD Int. Impl. 2
7E TerminalID Text String 1-8
7F TextLine Complex
80 TextLineValue Text String 0-80
BB TimeDisplay Boolean Impl. 1
81 TimeOut BCD Int. Impl. 2
82 TimeStamp BCD Int. Impl. 7
9A TotalAmountReconciliation Complex
83 TotalAmountReq Complex
99 TotalAmountResp Complex
84 TotalAmountValue BCD 12v4 1-6
85 Track1 Text String 1-75
86 Track2 Compressed 1-19
Track String
87 Track3 Compressed 1-19
Track String
A0 TransactionNumber BCD Int. 1-4
89 UnitMeasure UnitMeasure 32 = Each
Enum 33 = Foot
34 = Gallon (UK)
35 = Gallon (US)
36 = Gram
37 = Inch
38 = Kilogram
39 = Pound
40 = Meter
41 = Centimetre
42 = Litre
43 = Centilitre
44 = Ounce
45 = Quart
46 = Pint
47 = Mile
48 = Kilometer
49 = Yard
8A UnitPrice BCD 12v4 1-6
8D Width WidthEnum Impl. 1
8E WorkstationID Binary Impl. 1
D3 *** For Private Use ***
D4 *** For Private Use ***
D5 *** For Private Use ***
D6 Manufacturer_Id Text String 3
D7 Model Text String 3
D8 DeviceType Text String 3
D9 ProtocolVersion BCD Int. 12

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 138 of 144

Tag Data Name Type Length

DA CommunicationProtocol BCD Int. 12
DB ApplicatioSoftwareVersion Text String 1-12
DC SWChecksum Text String 4
DD SoftKey Complex
DE SoftKeyReturn Text String 1-10

B.4 IFSF Lite Serial Transport Protocol

B.4.1 Protocol Usage Context

Introduction This protocol is used to carry out transport of IFSF Lite application messages between
POS system and EPS. It uses at the physical level, simple RS232 asynchronous serial
ports.

Application At the application level, the protocol is based on request/response dialogue type.
Protocol As each message pair is identified by an application field, a response can be
Features unambiguously associated with its request by the application protocol, therefore
transport protocol will not offer this service.
At each side, an entity may have the initiative to send a request, so transport protocol
must protect against message collisions, even if probability of this event is low.

Transport Protocol
POS System EPS

Request
POS
Workstation
Response

POP
POS EPS
POP
Workstation Server
POP

Request
POS
Workstation
Response

Figure B.3: Usage of Serial Transport Protocol

Usage Transport protocol connects one or several POS workstations to an EPS with possibly
Context the same physical serial line. Transport must allow interleaving of message from
multiple POS workstations, and permit to reach proper POS workstation with
messages from the EPS.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 139 of 144

B.4.2 Protocol Specification

Serial Port The IFSF Lite interface uses a simple RS232 asynchronous serial protocol.
Data Bits: 8
Parity: None
Stop Bits: 1
Baud Rate: 1200*/2400*/4800*/9600/19200/38400/115200
Flow Control: Hardware

Physical Layer The POS will raise DTR when POS application is initialised. The EPS will raise DSR
when EPS application is initialised.
A constant connection is assumed, there is no usage link setup and teardown control
characters such as ENQ and EOT.

Information Application data or information frames have the following format:

Frame Format an STX character,
a control byte, containing addressing information and frame number,
application data, with escape character addition for transparent transmission,
an ETX or an ETB character,
two bytes of the CRC-16 checksum in network order (most significant byte first)

Control Byte Control byte is encoded as follows:

6 most significant bits contain destination address, allowing proper addressing by the
transport protocol without decoding of the application message to find the
WorkstationID value,
2 least significant bits contain frame sequence number, allowing easy recognition of
frame repetition.
The frame sequence number is used to distinguish an Information frame from the
previous Information frame, and from the following Information frame. It is forbidden to
send 2 subsequent Information frames with the same frame sequence nnumber.

STX Start of Frame

Frame Number
Control Byte
Address
Application Data

ETX/ETB End of Frame

High CRC

Low
Figure B.4: Information Frame Format
Control Transport protocol uses two control frames to accept or refuse reception of Information
Frames frame:
The acknowledgment frame, composed of the ACK (0x06) character only.
The non acknowledgment frame, composed of the NAK (0x15) character only.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 140 of 144

Transparent In order to minimize frame size, 8-bit or binary data may be transmitted within a frame.
Transmission To distinguish between binary data and control characters, a specific set of characters
must be preceded by the “data link escape” character, or DLE. For example, to send a
binary 0x02 (STX), the sender would first send DLE, then the actual data byte. When a
device receives a DLE, it will discard the DLE and treat the next character, whatever it
is, as data and not a control character. To send 0x10, which is the DLE character
itself, DLE is transmitted twice.
The following characters are used as control characters within this protocol and must
be preceded by DLE:
STX (0x02)
ETX (0x03)
ACK (0x06)
DLE (0x10)
NAK (0x15)
ETB (0x17)
Note: CRCs are implicitly “escaped” by the ETX or ETB, thus no escape characters
are required for the two CRC bytes.

Application Some application messages can be very long (e.g. Reconciliation message response).
Message Transport protocol split application message into Information frames of
Fragmenta- MaxFrameLength bytes at the most.
tion All fragment must have length of MaxFrameLength bytes, except the last one. All
fragment must be terminated by ETB, except the last one which is terminated by ETX.
Reassembling of frames at their reception is achieved by the concatenation of the
fragment enclosed by STX and ETB, until and including the first fragment enclosed by
STX and ETX.

Frame Whenever a frame is received, the checksum is validated. If the frame is intact, an
Acknowledge ACK character is transmitted to the sender. If a frame is corrupt, a NAK character is
sent instead to request retransmission. Up to MaxRepetition NAKs may be transmitted
for any one message.
Conversely, whenever a NAK is received, the currently outstanding unacknowledged
frame is retransmitted. If the device does not have an outstanding unacknowledged
frame the NAK is ignored.

Timeout If a device is expecting an ACK and doesn’t receive it after TORequest seconds, the
Handling frame will be retransmitted. If a device receives a frame with the same frame
sequence number as the previous message, it will send an ACK but otherwise ignore
the duplicate frame.

Information Each device must be capable of receiving a frame while transmitting another frame.
Frame Once a frame has been ACK’ed, another frame may be transmitted immediately. Only
Interleaving one unacknowledged frame may be outstanding at a time for each direction of
transmission.
Application message responses may come back out of order.
For example, another application message request may be sent while waiting for a
response, but only after the first request has been ACK’ed.
These interleaving requirements apply symmetrically to both the EPS and POS.

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 141 of 144

POS EPS

Request 1

ACK
1st request is ACK'ed,
OK to send 2nd Request 2

ACK

Response 2

Response 2 received
before response 1! ACK

Response 1

ACK

Figure B.5: Frame Interleaving

Addressing Application messages of different sources and destination are multiplexed on the
and same serial line, multiple POS workstations, EPS and EPS backup if backup used.
Multiplexing Message source is identified at the application level.
The address field in the control byte of Information frame is used to identify the
destination of the frame. The value of this address field follows the same mechanism
than IPAddress of the POS workstation in the Login message which is renamed
POSAddress.

B.4.3 Protocol State Table

State Table States, events, table for the processing of frame emission, are presented below.
Frame
Emission

State Comment
Idle No frame emission pending, all the sending requests are completed.
Sending An information frame sending is started, last byte of the frame is not sent.
Wait Ack An information frame is sent, an ACK or a NAK is waiting.
Table B.1: Frame Emission States
State Comment
Send Message Application requests to send a message to a destination address.
Emission End Last information frame byte is just sent.
Emssion Error An error while sending Information frame has occurred.
Receive Ack ACK is receivedby the reception processing
Receive Nak NAK is receivedby the reception processing
Time out Timer has expired
Send Ack Transport protocol want to acknowledge an Information frame.
Send Nak Transport protocol want to unacknowledge an Information frame.
Table B.2: Frame Emission Events

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 142 of 144

Idle Sending Wait Ack

Send Split message in Information Split message in Information Split message in Information
Message frames, with destination frames, with destination frames, with destination
address and frame number. address and frame number. address and frame number.
Store frames in sending Store frames in sending Store frames in sending
queue. queue. queue.
Start sending of 1st frame Sending Sending
Clear repetition counter
Sending
Emission Start timer TORequest
End Wait Ack
Emssion If repetition counter is more
Error than MaxRepetition
Send Emission Error to
application.
Send next frame
Sending or Idle
Increment repetition
counter.
Resend 1st frame of sending
queue.
Sending
Send Ack Send ACK Store ACK to send Send ACK
Idle Sending Wait Ack
Send Ack Send NAK Store NAK to send Send NAK
Idle Sending Wait Ack
Receive Ack Stop timer
(Send next frame)
If ACK or NAK to send, send
it.
If sending queue empty
Idle
Start sending of 1st frame
Clear repetition counter
Sending
Receive Nak If repetition counter is more
than MaxRepetition
Send Emission
Error to application.
Send next frame
Sending or Idle
Increment repetition
counter.
Resend 1st frame of sending
queue.
Sending
Time out If repetition counter is more
than MaxRepetition
Send Emission
Error to application.
Send next frame
Sending or Idle
Increment repetition
counter.
Resend 1st frame of sending

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 143 of 144

queue.
Sending
Table B.3 Frame Emission State Table

State Table States, events, table for the processing of frame reception, are presented below.
Frame
Reception

State Comment
Idle No frame reception pending, all the receiving request are completed.
Receiving An information frame is currently received, last byte of the frame is not received.
Table B.4: Frame Reception States
State Comment
Receive STX STX control character is just received.
Receive ETX ETX control character is just received with 2 bytes of CRC.
Receive ETB ETB control character is just received with 2 bytes of CRC.
Reception Error An error while receiving an Information frame has occurred.
Receive Ack ACK is received by the reception processing
Receive Nak NAK is received by the reception processing
Time out Timer has expired
Send Ack Transport protocol wants to acknowledge an Information frame.
Send Nak Transport protocol wants to unacknowledge an Information frame.
Table B.5: Frame Reception Events
Idle Receiving
Receive STX Start timer TORequest. Remove receiving bytes.
Receiving Receiving
Receive ETX Request Send NAK to Frame Emission. Stop timer TORequest.
Idle Verify CRC
if CRC correct
Request Send ACK to Frame
Emission.
If unrepeted frame (frame number), pass
Information Frame content to application.
Idle
Request Send NAK to Frame Emission.
Idle
Receive ETB Request Send NAK to Frame Emission. Stop timer TORequest.
Idle Verify CRC
if CRC correct
Request Send ACK to Frame
Emission.
If unrepeted frame (frame number), pass
Information Frame block content to
application.
Idle
Request Send NAK to Frame Emission.
Idle
Reception Request Send NAK to Frame Emission. Receiving
Error Idle
Receive Ack Pass Receive ACK event to Frame
Emission.
Idle
Receive Ack Pass Receive NAK event to Frame

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011
 Confidential December 2011 Page 144 of 144

Emission.
Idle
Time out Request Send NAK to Frame Emission.
Idle
Table B.6: Frame Reception State Table

Part319_POStoEPSImplementationGuidelinesV1.05.doc
Copyright © IFSF Ltd 2011