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

Ian Black

Payment systems Consultant

ianblack001@btinternet.com