IFSF POS to EPS
Transcript of IFSF POS to EPS
IFSF Conexxus POS to EPS Alignment
POS/EPS Overview
Device
Device
•Requirement to separate the selling application (Point Of Sale) and the card payment application (Electronic Payment System). •Enabled the POS to be out of scope for many card payment certification requirements.
IFSF P2F
IFSF H2H
IFSF H2H
Forecourt
Control IFSF POS to FDC
Car
Wash
Price
Pole
Disp
Tank
IFSF Car Wash
IFSF Price Pole
IFSF Dispensor
IFSF Tank level g
auge
IFSF POS to FDC
Conex
xus
Loyalty
EPS Payment
Application
POS Selling
Application
IFS
F P
OS
to
EP
S
IFSF P2F
Device
POS
IFSF POS TO EPS
•Performs the sales transaction getting input for card payment - scanning articles, providing information on products and amounts etc.
•Logging each transaction - the print receipt is stored into an electronic journal including the printed Eft receipt (and/or loyalty receipt).
•Releasing the pump •Tank Level Gauges management •Fuel deliveries input/output.
•Getting the card details: through the necessary peripherals, get card information
•Card validation.
•Security: entry of a PIN, signature required, merchant approval required, etc.
•Issuer specific actions: E.g. getting kilometres, driver-id, vehicle-id, etc.
•Loyalty functionality
•Printing Receipts
EPS
•Host identification: switching to the correct acquirer/issuer using correct protocol.
•Adjusting the sale as a result of interaction with the EPS.
•Reconciliation functions
• Reconciliation
2 Types of message encoding available:
• XML used over a TCP/IP connection
•IFSF Lite used over a serial connection but also TCP/IP connection
2 Types of transport protocols available:
• TCP/IP connection
• Serial (RS232)
• Device Messages – allows control of the peripherals
3 Main messages at application level:
• Service Messages – covers services outside the payment/loyalty transaction
• CardService Messages – covers all types of payment/loyalty transactions
IFSF and Conexxus Standards
Jan 2012
Updates - V2.5
June 2008
Connexus Interface Specification V1.0
Describe the Connexus use of IFSF POS-EPS
July 2005
IFSF POS to EPS implementation guide V1.00
Purpose: to aid implementation.
Aug 2002
IFSF POS to EPS Specification V1.0
May 2006
Sep 2006
Nov 2006
Apr 2007
Updates - V1.01
Dec 2011
Updates - V1.02
Updates - V1.03
Dec 2011
Updates - V1.04
IPR added – V1.01
IPR added - V1.05
Mar 2014
Updates - V2.6
Apr 2014
Conexxus added- V2.6.1
Aug 2014
Updates - V2.7
Project To Align Conexxus and IFSF
Initial review of all documents provided overview of differences
Sub group formed to agree on changes to both documents ensuring no functionality is lost from either in a new standard.
Detailed review: every message type, every piece of data, one by one and their associated business and/or technical requirement over 8 months.
Primary aim is to bring the currently diverging IFSF and Conexxus implementations of the POS to EPS standard back together again, whilst simultaneously rectifying any omissions and errors in both.
Participation from Statoil, IFSF, Conexxus, W Capra, Wincor Nixdorf, Tokheim, Total, Wayne, BP, ExxonMobil, Ingenico, Shell, VeriFone, WEX INC, ajb Software Design, Visa Europe…………
Not feasible to retain backward compatibility without creating more problems
Would have different message types for the same function, duplication of data, different schema etc.
•if a new piece of data has been defined, ensure that its purpose cannot be covered by an existing piece of data .
How we Aligned
The following broad criteria were agreed for issue resolution:
•Ensure that the logic of the ‘payment/loyalty functionality on the EPS rather than the POS’ is maintained.
•Ensure that the various POS to EPS architectures are catered for.
•If a piece of data coexists in both documents, but in different parts of the structure, only revert to the original IFSF structure if it is logical to do so.
•If piece of data coexists in both documents, but they have different names, revert to the original IFSF name ensuring consistency of naming convention.
We now have a message type: CardTransaction with a LoyaltyFlag set true or false as appropriate.
Message Types
CardService message types in IFSF and Conexxus differed considerably.
The new Standard adopts the principle (partly in use by Conexxus today) that data within messages can determine the required function instead of having a separate message type for each function.
Example: Currently CardPayment CardPaymentLoyaltyAward
Messages Required •CardTransaction •LoyaltyTransaction •CardPreAuthorisation •CardFinancialAdvice •LoyaltyAdvice •CardBalanceQuery •Reversal •Refund •LoyaltyLinkCard •LoyaltyPointsTransfer •CardFunction •PINChange •TicketReprint •AbortRequest
Removed from Connexus: CardSwipe (CardRead) LoyaltyReversal LoyaltyAwardRefund
Removed from IFSF and Conexxus: LoyaltyAward LoyaltyBalanceQuery
Removed from IFSF: CardPayment CardSwipe (CardRead in Conexxus) LoyaltySwipe CardFinancialAdviceLoyaltyAward CardPaymentLoyaltyAward PaymentRefund PaymentLoyaltyRefund CardPreAuthorizationLoyaltySwipe CardPaymentLoyaltyRedemption PaymentReversal PaymentLoyaltyReversal LoyaltyRedemption LoyaltyAwardReversal LoyaltyRedemptionReversal RepeatLastMessage (TBC) CardActivate CardStop StoreValueInCard RefundValueFromCard
29 message types in IFSF reduced to 14
Every piece of data has been analysed for definition, functionality, errors and duplication.
Data
The result: CardServiceRequest •Attributes reduced from 43 to 28 •Elements reduced from 65 to 34
The result: CardServiceResponse •Attributes reduced from 68 to 35 •Elements reduced from 54 to 30
Aug 2012 • IFSF Project: Examine all existing standards and recommend how to merge
into one standard retaining backward compatibility
Due to the extent of the differences it soon became apparent that we could no longer retain backward compatibility
Apr 2013 • IFSF Project: amalgamate the IFSF and Connexus requirements for POS to
EPS and produce a new standard which supersedes both without the requirement for backward compatibility.
Jun 2014
Weekly POS to EPS subgroup.
First draft ready to go out for comment in Jan 2014 however delayed with internal discussions between Conexxus and IFSF on various issues Posted on website in June
Nov 2013
New V3.0 IFSF POS to EPS Standard
•IFSF now includes more loyalty functionality
•More efficient standard
•IFSF and Conexxus now aligned ready to move forward.
•Errors/Omissions rectified
•Less complex schema
•Greater alignment with IFSF V2 Host to Host and POS to FEP
Next Steps Version 3.0
•Add agreed changes. •Finalise schema and include IFSF Lite
Any new required functionality must be added to the standard asap or we will start going back to square one
New Functionality (Version 3.1) Mobile Payment functionality Additional Loyalty Functionality Additional Reconciliation functions Admin functionality