oscar pos integration specification for sepa compliant terminals

OSCar POS Integration Specification for SEPA Compliant Terminals

Phase 2

10/07/2014 version 3.2 1/154

OSCAR POS INTEGRATION SPECIFICATION FOR

SEPA COMPLIANT TERMINALS


Phase 2

10/07/2014 version 3.2 2/154

Revision History

Version Date Author Object

1.0 22.08.2011 CB/SRC Integration of comments and SEPA-FAST Part 1 Version

1.2

1.1 27.01.2012 CB/SRC Integration of final CAPE MUGs and additional

clarifications

1.2 19.03.2012 CB/SRC Integration of comments received from the TWG of OSCar

Phase 2

version 2.0

16.05.2013 OSCar

Technical Task

Force

OSCar phase 2 – final version

Phase 2

version 3.1

28.01.2014 OSCar

Technical Task

Force

OSCar phase 2 V3.1

Phase 2

version 3.1

14.2.2014 OSCar

Technical Task

Force

Erratum of the version edited on 28.01.2014

Phase 2

version 3.2

09.07.2014

OSCar

Technical Task

Force

Integration of file transfer for Batch capture and for

configuration.

Amendments on presence conditions of POIComponent

data in StatusReport and Authorisation messages.

Amendments on Specific processing based on PAN

(section 10.1)

Amendments on Voice Authorisation processing.

Integration of comments received


Phase 2

10/07/2014 version 3.2 3/154

Table of Contents

OSCAR POS INTEGRATION SPECIFICATION FOR SEPA COMPLIANT

TERMINALS.................................................................................................... 1

1 Introduction.................................................................................................... 6

2 OSCar Technical Scope ................................................................................ 6

3 Cancellation Processing ............................................................................. 10

3.1 Configuration Requirements: ......................................................................... 10

3.2 Implementation Requirements: ...................................................................... 10

4 HAP Functionality ........................................................................................ 12

4.1 HAP Status .................................................................................................... 13

4.2 HAP Online Approval Request ....................................................................... 16

4.3 HAP Transaction Data Storage ...................................................................... 26

4.3.1 SEPA-FAST data elements ........................................................................... 27

4.3.2 EPAS data elements ...................................................................................... 27

4.3.3 HAP data elements ........................................................................................ 27

4.4 HAP Transaction Finalisation ......................................................................... 28

4.5 HAP Search Transactions.............................................................................. 32

4.6 Batch Processing ........................................................................................... 32

4.7 Perform Reconciliation ................................................................................... 35

4.8 Perform Diagnostic ........................................................................................ 35

5 Configuration and maintenance handling.................................................. 37

5.1 TMAP functionality ......................................................................................... 37

5.2 Perform Terminal Management session ........................................................ 37

5.3 Configuration Data Model .............................................................................. 38

5.4 SEPA-FAST Configuration Parameters ......................................................... 39

5.4.1 Logical parameters classification ................................................................... 39

5.4.2 Categories details .......................................................................................... 41

5.4.3 Structure of data elements tables .................................................................. 42

5.4.3.1 Parameters internal structure ......................................................................... 43

5.4.3.2 Data Elements description ............................................................................. 46

5.4.3.3 Data Elements by Tag ................................................................................... 57


Phase 2

10/07/2014 version 3.2 4/154

5.5 Acquirer Protocol Configuration Parameters .................................................. 62

5.5.1 StatusReport.................................................................................................. 64

5.5.2 ManagementPlanReplacement ...................................................................... 68

5.5.3 AcceptorConfigurationUpdate ........................................................................ 70

5.5.4 TerminalManagementRejection ..................................................................... 75

5.5.5 Download of Cryptographic Keys ................................................................... 75

6 HAP Message data elements processing .................................................. 79

6.1 Authorisation Exchange ................................................................................. 80

6.1.1 AcceptorAuthorisationRequest ...................................................................... 80

6.1.3 AcceptorAuthorisationResponse .................................................................... 87

6.2 Completion Exchange .................................................................................... 91

6.2.1 AcceptorCompletionAdvice ............................................................................ 91

6.2.2 AcceptorCompletionAdviceResponse ............................................................ 96

6.3 Cancellation Exchange .................................................................................. 98

6.3.1 AcceptorCancellationAdvice .......................................................................... 98

6.3.2 AcceptorCancellationAdviceResponse ........................................................ 102

6.4 Batch Transfer ............................................................................................. 104

6.4.1 AcceptorBatchTransfer ................................................................................ 104

6.4.3 AcceptorBatchTransferResponse ................................................................ 114

6.5 Diagnostic Exchange ................................................................................... 116

6.5.1 AcceptorDiagnosticRequest ......................................................................... 116

6.5.2 AcceptorDiagnosticResponse ...................................................................... 117

6.6 Reconciliation .............................................................................................. 119

6.6.1 AcceptorReconciliationRequest ................................................................... 119

6.6.2 AcceptorReconciliationResponse ................................................................ 120

6.7 Reject .......................................................................................................... 122

7 Sale System Protocol ................................................................................ 123

7.1 Interface with the Sale System .................................................................... 123

7.2 Usage of SEPA-FAST Data Element in EPAS Messages ............................ 125

8 First initialisation of the POI ..................................................................... 128

9 References ................................................................................................. 129


Phase 2

10/07/2014 version 3.2 5/154

10 Annex ......................................................................................................... 130

10.1 SEPA-FAST Extension: Specific Processing based on PAN ........................ 130

10.2 SEPA-FAST Extension: Process Additional Application Profile

Parameters .................................................................................................. 133

10.3 SEPA-FAST Extension: Process Chip Fallback in case of

Emergency .................................................................................................. 135

10.3.1 Overview ..................................................................................................... 135

10.3.2 Configuration of the Emergency Processing ................................................ 136

10.3.3 Procedure of Chip Fallback .......................................................................... 136

10.3.3.1 Card communication during emergency processing..................................... 139

10.3.3.2 Building Candidate List for Chip Fallback ..................................................... 149

10.3.3.3 Processing of Chip Fallback ........................................................................ 149

10.4 SEPA-FAST Extension for contactless transactions: Specific

processing for Kernel identification for CB Cards ......................................... 151

10.4.1 Data Dictionary ............................................................................................ 151

10.4.2 Flow ............................................................................................................. 152


Phase 2

10/07/2014 version 3.2 6/154

1 Introduction The "Financial Application Specification for SCF Compliant EMV Terminals" (SEPA-FAST) gives a generic

description of the application (HAP) which ensures the link between the SEPA-FAST application and the

Host Acquirer Protocol. It describes also the interface to the attendant and/or to the sale system (SCAP).

The aim of this specification is as follows:

- to define in detail the structure and the functions of the HAP application with detailed descriptions

of the messages and data elements when the SEPA-FAST application has to interact with the

EPAS Protocol within the framework of the OSCar project,

- to define an interface application for the terminal management system with detailed descriptions

of the messages and data elements used for configuration and maintenance purposes.

- The interaction between the sale system and the dedicated interface (SCAP) using the EPAS

Retailer protocol.

SEPA-FAST allows for the proprietary process "Specific Processing based on PAN". This process has to

be implemented within the framework of the OSCar project for terminals that are intended to support

girocard. An Annex (see section 10.1) of this specification describes how this process shall be

implemented. According to SEPA-FAST section 8.2.7 the data elements for the Selected ApplicatIon

Profile Number are set for use during the transaction. For the support of girocard, additional data elements

might be set per Application Profile (see section 10.2).

In addition, SEPA-FAST allows for a proprietary process for contactless technology. This proprietary

process has to be implemented on the POI as described in section 10.4. in order to process some legacy

contactless cards for CB scheme.

2 OSCar Technical Scope This section describes the detailed technical scope according to the functional scope defined in the

document [OSCar Scope]

An OSCar POI terminal supports:

A SEPA FAST application implemented according to [SEPA-FAST] supporting the functionalities

described in [OSCar Scope]

A Host Acquirer Protocol Application HAP responsible for:

- the dialog between the SEPA-FAST application and the Acquirer system using the EPAS Acquirer

Protocol according to [CAPE ACQ MDR] and [CAPE ACQ MUG]

A Terminal Management System Protocol Application TMAP responsible for:


Phase 2

10/07/2014 version 3.2 7/154

- The administrative and maintenance functionalities using the TMS protocol according to [CAPE

TMS MDR] and [CAPE TMS MUG].

Optionally a Sale System, Cardholder and Attendant Protocol (SCAP) application controlling the

retailer protocol according to the EPAS Retailer Protocol [EPAS RTP].

An OSCar Acquirer supports:

the EPAS Acquirer Protocol according to [CAPE ACQ MDR] and [CAPE ACQ MUG],

the TMS protocol according to [CAPE TMS MDR] and [CAPE TMS MUG] if the acquirer is the terminal

manager (with limitations described in the [OSCar Scope]).

The EPAS Acquirer Protocol [CAPE ACQ MDR] is only supported with the following profiles:

Profile 1

- Authorisation without Capture for online transactions using the AcceptorAuthorisationRequest and

AcceptorAuthorisationResponse messages,

- Capture immediately after the finalisation of the online or offline transaction using the messages

AcceptorCompletionAdvice/AcceptorCompletionAdviceResponse,

- AcceptorReconciliationRequest/AcceptorReconciliationResponse for reconciliation with the

Acquirer Host,

Profile 2

- Authorisation without Capture for online transactions using the AcceptorAuthorisationRequest and

AcceptorAuthorisationResponse messages

- Capture of online and offline transactions by batch using the messages

AcceptorBatchTransfer/AcceptorBatchTransferResponse for a group of online and offline

transactions. The Reconciliation is done within the batch.

EPAS Acquirer protocol authorises to perform the Batch transfer by message exchange or by file. In

Oscar the two modes are possible.

Profile 3

- Authorisation with Capture for online transactions using the AcceptorAuthorisationRequest and

AcceptorAuthorisationResponse messages,


Phase 2

10/07/2014 version 3.2 8/154

- Capture immediately after transaction finalisation for offline transactions using the messages

AcceptorCompletionAdvice/AcceptorCompletionAdviceResponse,

- AcceptorReconciliationRequest/AcceptorReconciliationResponse for reconciliation with the

Acquirer Host,

The common functionalities of all the profiles:

- AcceptorDiagnosticRequest/AcceptorDiagnosticResponse for cryptographic key validation, and

- AcceptorRejection for error handling

- AcceptorCancellationAdvice/AcceptorCancellationAdviceResponse to perform the Cancellation.

The cancellation processing is described in section 3

The functionalities of the EPAS TMS Protocol [CAPE TMS MDR] supported are:

- StatusReport message requesting the ManagementPlanReplacement as response message

(message exchange or file transfer) to define the TMS actions to be performed, and

- StatusReport message requesting the AcceptorConfigurationUpdate as response message

(message exchange or file transfer) to update the application and acquirer protocol parameters.

The messages of the Acquirer (except the Rejection message) as well as the TMS protocol are

authenticated using a Message Authentication Code (MAC) with DUKPT as key derivation mechanism as

described in section "Message Security" of the [EPAS Security].

For test environment, the POI will be connected to three different hosts

two Acquirer Host simulators, and

one TMS simulator

In addition, the POI may be connected to the Sale System.

As a consequence three different cryptographic keys (one per communication partner) are to be supported

in the terminal for testing.

The EPAS Retailer Protocol [EPAS RTP] may be supported by the POI. The test laboratory offers a Sale

System simuIator for the initiation of the services and the output of display messages and receipts. The

functionality of the Sale system, Cardholder and Attendant Protocol (SCAP) application controlling the

retailer protocol is described in section 7.

All profiles and functionalities described in [OSCar Scope] and detailed above are in scope for testing.

Kernel Configuration:

- If present, the Kernel C-3 is configured in EMV mode.


Phase 2

10/07/2014 version 3.2 9/154

- If present, the Kernel C-2 shall not activate the data storage feature.


Phase 2

10/07/2014 version 3.2 10/154

3 Cancellation Processing

An OSCar POI implements the cancellation by CancellationAdvice only.

Therefore a transaction can be cancelled if present in the POI storage with Transaction Result =

APPROVED and the related reconciliation period is still opened (respectively the batch it belongs to has

not been sent)..

3.1 Configuration Requirements:

The following POI Configuration applies to an OSCar POI

- Application Profile Settings for Cancellation (APSC):

o APSC[2, 8] = 0b or 1b (Cancellation limited to last transaction)

o APSC[2, 7] = 0b or 1b (Cancellation allowed of transactions logged)

o APSC[2, 6] = 0b (Cancellation allowed with Online Request)

- AcquirerProtocolParameters:

o OnLineTransaction.CancellationExchange = Absent or Advice

o OffLineTransaction.CancellationExchange = Absent or Advice(1)

(1) this value may be used to trigger an optional CancellationAdvice in addition to a record in the

batch when cancelling an offline approved transaction.

3.2 Implementation Requirements:

The HAP component of an OSCar POI shall implement the following processes:

Search log for transaction to be cancelled <Reference Data, Application Profile Settings for Cancellation (APSC), Transaction Result = APPROVED>

This process is used when Service Start Events[1, 3] = 1b (REFERENCE ENTRY)

HAP returns the list {Transaction Sequence Counter, Transaction Date, Transaction Time, Selected Service, Transaction Amount, Reference Data Terminal Identification} of all the transaction records that fullfill the following conditions:

- Reference Data = Reference Data of the current cancellation transaction

- Transaction Result = APPROVED

- Cashback Amount = 0


Phase 2

10/07/2014 version 3.2 11/154

- Application Profile Settings for Cancellation (APSC) is present

- APSC[2, 7] = 1b (Cancellation allowed of transactions logged)

- (Selected Service = PAYMENT and APSC[1, 8] = 1b (Cancellation of Payment allowed)) or (Selected Service = REFUND and APSC[1, 7] = 1b (Cancellation of Refund allowed))

- Cancellation Flag = Not Cancelled (cf. [Table 7])

- Finalization Flag = Finalized (cf. [Table 7])

Restore last transaction <APSC, Transaction Result = APPROVED>

This process is used when Service Start Events[1, 4] = 1b (ACCEPT)

HAP returns the list



- Application Profile Settings for Cancellation (APSC) is present

- APSC[2, 8] = 1b (Cancellation limited to last transaction)

- (Selected Service = PAYMENT and APSC[1, 8] = 1b (Cancellation of Payment allowed)) or (Selected Service = REFUND and APSC[1, 7] = 1b (Cancellation of Refund allowed))



Search log for transaction to be cancelled <PAN, Transaction Amount, Application Profile Settings for Cancellation (APSC), Transaction Result = APPROVED>

This process is used when Service Start Events[1, 4] <> 1b (ACCEPT) AND Service Start

Events[1, 3] <> 1b (REFERENCE ENTRY)

HAP returns the list {Transaction Sequence Counter, Transaction Date, Transaction Time, Selected Service, Transaction Amount, Reference Data Terminal Identification} of all the transaction records that fullfill the following conditions:

- Acquirer Identifier = Acquirer Identifier of the current cancellation transaction



- (Selected Service = PAYMENT if APSC[1, 8] = 1b (Cancellation of Payment allowed)) or (Selected Service = REFUND if APSC[1, 7] = 1b (Cancellation of Refund allowed))

- PAN = PAN of the current cancellation transaction

- Transaction Amount = Transaction Amount of the current cancellation transaction



Note: this search function allows that transaction is cancelled over another technology than the original one. It also allows cancelling a transaction involving the same PAN but another PAN Sequence Number.


Phase 2

10/07/2014 version 3.2 12/154

The Application Profile Settings for Cancellation used in this case is the one selected during the Cancellation transaction.

4 HAP Functionality As decribed in section 22 of [SEPA-FAST], HAP is the application responsible for handling the acquirer

protocol.and has access to all [SEPA-FAST] application data.

The list of HAPI functions defined in [SEPA-FAST] is extended to integrate new functions:

“Reconciliation” and “Diagnostic”. These functions can be called during the Idle State of the SEPA-FAST

application.

Retailer Protocol parameters are not defined in this document.

HAP manages the following:

- conversion of data elements exchanged between SEPA-FAST and EPAS (see section 6),

- The communication between the POI application and the host using the EPAS Acquirer Protocol,

Note: In the following sections, data elements and components from EPAS are printed in italics.

The names of all data elements defined in the SEPA-FAST are printed in bold and italics.


Phase 2

10/07/2014 version 3.2 13/154

4.1 HAP Status According to section 15.1 of [SEPA-FAST] the function is called during the Start-up of the Financial

Application.

HAP Status shall process mandatory tasks as:

Check of the availibilty of mandatory data required for the financial application and the aquirer

protocol.

Transmission respectively retransmission of any outstanding pending transactions.

Transaction recovery because of power failure.

Other actions could be processed if triggered manually or by configuration. These actions are:

Diagnostic exchange if triggered manually by the merchant.

Batch Transfer if required.

Reconciliation if triggered manually by the merchant or configured by TMS.


Phase 2

10/07/2014 version 3.2 14/154

HAP Status

10

Check Mandatory Data

NOK

20

Perform

Diagnostic

OK

30

Check log and if any pending

transaction advices and take

the corresponding action if

any

40

Perform Reconciliation

Done

Batch Transfer

50

Done

Terminal Error Indicator =

TRUE?

Done Done

YesNo

Done

Figure 1: HAP Status


Phase 2

10/07/2014 version 3.2 15/154

1-10 Check Mandatory Data

At financial application start-up, HAP shall ensure that

all mandatory configuration data for the SEPA-FAST application listed in section 5.4,

the host communication parameters for the acquirer protocol, and

the cryptographic keys needed for the protection of the Acquirer as well as TMS protocol

are available.

If a mandatory data element is missing, HAP performs the following:

- Informs the SEPA-FAST application that a Terminal Management session is needed

- sets the element Call TMS to the value "AsSoonAsPossible"

- sets the Terminal Error Indicator to “TRUE”

- sets the Nok Reason to “CONFIGURATION ERROR”

1-20 Perform Diagnostic

This process is described in section 4.8

If Diagnostic exchange couldn’t be performed successfully (e.g. Time-Out, Reject or error in response) for

all Acquirer hosts then Terminal Error Indicator is set to TRUE.

The attendant gets an indication of the Diagnostic result for each host.

1-30 Check log. If any pending transaction advices exist take the corresponding action

This process checks if there are any outstanding pending messages. It searches over logged transactions

for transactions with Finalization flag set to ‘Not finalized’. Every not finalized transaction must be

processed by HAP Transaction Finalisation described in section 4.4.

List of possible pending messages:

AcceptorCompletionAdvice for the capture of a successful payment or refund,

AcceptorCompletionAdvice for the reversal of an unsuccessful transaction,

AcceptorCancellationAdvice for the capture of a successful cancellation.

AcceptorCancellationAdvice for the reversal of an unsuccessful cancellation.

The advice message or several messages may be pending since there was

1. a communication error or time-out during the last message exchange, or


Phase 2

10/07/2014 version 3.2 16/154

2. a power failure during HAP transaction storage of the last transaction.

HAP is operating the following actions to resolve the failure:

ad 1.

If the advice has already been sent HAP sends a retransmission of this advice.

If the advice has not been sent during the finalisation of the corresponding transaction the advice

is generated and transmitted.

ad 2.

If there was power failure during HAP Online Approval Request or HAP transaction storage of the

last transaction and an authorisation request has been sent for this transaction HAP will generate

a completion advice as reversal.

HAP will send the pending messages to the acquirer host directly.

If the processing of pending transactions couldn’t be performed successfully then Terminal Error

Indicator is set to TRUE.

1-40 Perform Reconciliation

Before the reconciliation can be started, all transactions have to be captured. The reconciliation process is described in section 4.7.

If Reconciliation exchange couldn’t be performed successfully then Terminal Error Indicator is set to

TRUE.

1-50 Batch Transfer

HAP checks if

the physical memory limit of the transaction log is reached or

one of the limits BatchTransfer.MaximumNumber or BatchTransfer.MaximumAmount for the

online and offline transactions are configured and reached

In case of one of these events HAP generates the BatchTransfer message and sends it to the acquirer.

If Batch Transfer couldn’t be performed successfully then Terminal Error Indicator is set to TRUE.

For more details, see section 4.6.

4.2 HAP Online Approval Request According to SEPA-FAST this function performs an online approval if required. All data elements that are

required by the protocol but not provided by SEPA-FAST are generated by HAP. The following flow

illustrates the handling of the online approval process.


Phase 2

10/07/2014 version 3.2 17/154

Is Selected Service =

'01' or '02 or ‘08’'?

HAP approval Request

OKNOK

30

Send Request Message

40

Receive Response

Message

50

Parse Response Message

10

Build

AcceptorAuthorisationReq

uest

Message

Ok

Ok

Ok

Set NOK reason = ‘DATA

ERROR’

Nok

TMSTrigger in Response?

No

Yes

Unable to go

online

Nok

Nok

Fill Call TMS with value of

TMSContactLevel

All mandatory data

needed for the protocol

is available?

Yes

No

01 (PAYMENT) 02 (REFUND)08 (DEFERRED PAYMENT)

Out of

scope

No

Figure 2: Approval exchange processing

This function checks at the beginning the Selected Service to build the corresponding EPAS message

after verifying that SEPA-FAST has sent the mandatory data needed. The data elements listed in the table

6 of the section 16.1 and in the table 9 of the section 16.3 of the SEPA-FAST specification shall be made

available for the Host Acquirer Protocol application (HAP) at the Host Acquirer Protocol application

interface (HAPI) except some data elements that need specific handling by HAPI. The definition of these

data elements in section 16 of [SEPA-FAST] contains a row "Auth/Clearing" with the respective

information.


Phase 2

10/07/2014 version 3.2 18/154

HAP shall use the value of the data elements set when HAPI is called. HAP stores the contents of the message elements in the transaction log for the validation of the response.

2-10 Build EPAS Authorisation Request Message

Payment Service:

If Selected Service is Payment, HAP shall build an AcceptorAuthorisationRequest message (see section 6.1.1) as follows:

Build Message Body

o For the service Payment the message element Transaction.TransactionType is set to

"CardPayment".

o For EMV Chip Transactions, the ICCRelatedData message element is filled with the

following data elements of SEPA-FAST. Any data element contained in this table shall

be coded in TLV according to the EMV specifications.

o For PayPass MagStripe transactions, the ICCRelatedData is filled with Terminal Data

and with available Card Data.

If an EMV Chip transaction fails and a fallback or other chip application is processed then,

the ICCRelatedData message element for a Payment is filled at least with the data

elements Processing Status, Nok Reason, Terminal Verification Results (TVR) and

Transaction Status Information (TSI).

Transaction Data Element for AcceptorAuthorisationRequest used for Payment

Tag Presence

M Mandatory – C Conditional

Amount, Authorised (Numeric) 9F02 M

Amount, Other (Numeric) 9F03 C – Present if available

Application Cryptogram (AC) 9F26 M - Value used for ARQC

Application Effective Date 5F25 C – Present if available

Application Interchange Profile (AIP) 82 M

Application Priority Indicator 87 C – Present if available

Application Transaction Counter (ATC) 9F36 M

Application Version Number – Terminal 9F09 M

Cryptogram Information Data (CID) 9F27 M - Value used for ARQC

Cardholder Verification Method (CVM) Results 9F34 M except for kernels C1 & C-3

Customer Exclusive Data (CED) 9F7C C – Present if available for the Kernel C-3

Dedicated File (DF) Name 84 M


Phase 2

10/07/2014 version 3.2 19/154

Transaction Data Element for AcceptorAuthorisationRequest used for Payment

Tag Presence


Form Factor Indicator 9F6E C – Present if available for the Kernel C-3

Interface Device (IFD) Serial Number 9F1E C – Present if available

Issuer Application Data (IAD) 9F10 C – Present if available, value used for ARQC

Merchant Custom Data 9F7C C – Present if available for the Kernel C-2

Terminal Capabilities 9F33 M

Terminal Country Code 9F1A M

Terminal Transaction Qualifiers 9F66 M for kernel C-3

Terminal Type 9F35 M

Terminal Verification Results (TVR) 95 M - Value used for ARQC

Transaction Currency Code 5F2A M

Transaction Date 9A M

Transaction Sequence Counter 9F41 M

Transaction Type 9C M

Unpredictable Number 9F37 C – Present if available

Issuer Script Results D4 C – Present if available

Third Party Data 9F6E C – Present if available

Table 1: Transaction Data Element for AcceptorAuthorisationRequest used for Payment

Build Security Trailer

See section 4.1, Note 1-30

Build Message Header

o InitiatingParty is filled with identification of the acceptor system (e.g. Merchant

Identifier concatenated with Terminal Identification assigned by the acquirer)

o Message Function is set to "AuthorisationRequest"

o Generate next ExchangeIdentification

o Generate CreationDateTime etc.


Phase 2

10/07/2014 version 3.2 20/154

Refund Service:

If Selected Service is Refund, HAP shall build an AcceptorAuthorisationRequest message (see section 6.1.1) as follows:

Build Message Body

o Set Transaction.TransactionType to "Refund"

o For EMV Chip transactions, the ICCRelatedData message element is filled with the

following data elements of SEPA-FAST.

Transaction Data Element for AcceptorAuthorisationRequest used for Refund

Tag Presence

M Mandatory , C Conditional, - Optional

Amount, Authorised (Numeric) 9F02 -

Amount, Other (Numeric) 9F03 -

Application Cryptogram (AC) 9F26 -

Application Effective Date 5F25 -

Application Interchange Profile (AIP) 82 M

Application Priority Indicator 87 C – Present if available

Application Transaction Counter (ATC) 9F36 -

Application Version Number - Terminal 9F09 M

Cryptogram Information Data (CID) 9F27 -

Cardholder Verification Method (CVM) Results 9F34 -

Customer Exclusive Data (CED) 9F7C C – Present if available for the Kernel C3

Dedicated File (DF) Name 84 M

Interface Device (IFD) Serial Number 9F1E C – Present if available

Issuer Application Data (IAD) 9F10 -

Terminal Capabilities 9F33 M

Terminal Country Code 9F1A M

Terminal Type 9F35 M

Terminal Verification Results (TVR) 95 -

Transaction Currency Code 5F2A M

Transaction Date 9A -

Transaction Sequence Counter 9F41 -

Transaction Type 9C -

Unpredictable Number 9F37 -

Third Party Data 9F6E -


Phase 2

10/07/2014 version 3.2 21/154

Table 2: Transaction Data Element for AcceptorAuthorisationRequest used for Refund

Any data element contained in this table shall be coded according to the BER-TLV description as defined

in ISO/IEC 8825.


o See section 4.1, Note 1-10


o see Payment Service

2-20 Build EPAS Cancellation Request Message

The Cancellation request is not supported.

2-30 Send Message

After building the message, HAP has to send it to the recipient. The recipient (HostIdentification) including

the correct communication parameters are selected according to the Acquirer Number.

If a problem occurs (e.g. the message function is not found in any MessageToSend list in the HAP

configuration, see section 5.5.3) and HAP could not send the message, it returns "Unable to go online" to

SEPA-FAST.

2-40 Receive Response Message

The recipient shall reply to HAP with a response message to accept, decline or acknowledge the

transaction.

- If HAP does not receive a response in time, it returns "Unable to go online" to SEPA-FAST. In this

case HAP shall reverse the transaction during HAP transaction finalisation (see section 4.4) by

sending an AcceptorCompletionAdvice or an AcceptorCancellationAdvice message.

2-50 Parse Response Message

When HAP receives the response message to its request, it shall verify the consistency of the syntax and

the format of each data element as well as their values. It has to check as well the validation of the MAC

as described in the [CAPE ACQ MUG].

HAP shall send an AcceptorCompletionAdvice or an AcceptorCancellationAdvice message during HAP

transaction finalisation (see section 4.4) with message element Reversal set to "True" when it receives

- a reject message,

- a message with in incorrect MAC,


Phase 2

10/07/2014 version 3.2 22/154

- a message with a syntax (e.g. mandatory elements missing, wrong sequence of elements, not

existing enumeration value), format (coding error) and/or length error.

If all checks are successful, HAP updates the appropriate terminal transaction data elements using the present message elements as described in section 6.1.3.

For EMV Chip Transactions, the following data elements are retrieved from the message element

ICCRelatedData in case of an AcceptorAuthorisationResponse message has been received:

Transaction Data Element in AcceptorAuthorisationResponse

Tag Presence


Issuer Authentication Data (IATD) 91 C – Present if online issuer authentication performed

Issuer Script Template 1 71 C – One or several present if commands to chip are sent by issuer

Issuer Script Template 2 72 C – One or several present if commands to chip are sent by issuer

Authorisation Response Code (ARC) 8A M

Table 3: Transaction Data Element in AcceptorAuthorisationResponse

Any data element contained in this table shall be coded according to the BER-TLV description as defined in ISO/IEC 8825.

Once the response received, HAP shall verify data elements described hereafter, to fill the transaction

result accordingly. Data elements to be verified:

o ResponseToAuthorisation.Response

o Action.ActionType

o Action.MessageToPresent.MessageContent

o Action.MessageToPresent.MessageDestination

According to the value of ResponseToAuthorisation.Response the acquirer host fills a list of actions for the acceptor.

For the Action.ActionType equal to "DisplayMessage" the acquirer delivers

Action.MessageToPresent.MessageContent.

The length of the text messages for the POI displays is limited for the acquirer host by the POI capabilities

DisplayCapabilities.LineWidth sent in the request. The terminal will show these text messages on the

display without any additional plausibility check. The information whether the cardholder or the merchant

display has to be used is sent in message element Action.MessageToPresent.MessageDestination.


Phase 2

10/07/2014 version 3.2 23/154

The following action types and text messages are sent by the acquirer host if the

ResponseToAuthorisation.Response is equal to "Declined". Additional response reasons and text

messages may be used by the Acquirer host for declined transactions.

TransactionResponse.Action.ActionType

Action.MessageToPresent.MessageContent

Action.MessageToPresent.MessageDestination

All other values Any text(1) "CardholderDisplay"

Referral Refer to card issuer "CardholderDisplay"

Referral Call Merchant Service "MerchantDisplay"

Table 4: Message presented by the Acquirer Host to the Cardholder or Merchant

HAP checks whether the ActionType corresponds to the contents of ResponseToAuthorisation.Response.

According to the contents of the message element ResponseToAuthorisation.Response and the list of

ActionType, HAP sets the SEPA-FAST data elements Transaction Result for all transactions (chip and

non chip) and Authorisation Response Code (ARC) for non chip transactions.

The different cases for Payment, Refund and Cancellation are described below:

Data in Response Message Data set by HAP

ResponseToAuthorisation.Response

TransactionResponse.Action.ActionType

Transaction Result ARC2 Nok

Reason

Approved Equal to "DisplayMessage",

"PrintMessage" OR no Action

present

APPROVED "00" -

Approved Different than “DisplayMessage",

PrintMessage"

ABORTED - DATA

ERROR

Declined "Busy", "CaptureCard",

"PINLastTry", "PINRetry" or any

defined action not listed in this table.

DECLINED "05" -

Declined Referral - VOICE

AUTHORISATION (If

APS[1,3]=1b (Referral

allowed)

- "02"

- "05" for

declined

-

1 display and receipt text messages for the cardholder and merchant sent by the host have to be defined

by the card scheme

2 For non chip transactions


Phase 2

10/07/2014 version 3.2 24/154

- DECLINED (otherwise)

Declined Message element absent,

"DisplayMessage" and/or

"PrintMessage"

DECLINED "05" -

PartialApproved "DisplayMessage" and/or

"PrintMessage"

- PAYMENT PART ONLY

(if Payment with Cashback)

- PARTIALLY APPROVED

(if Selected Service =

DEFERRED PAYMENT)

- DECLINED (otherwise)

“00”

- "05" for

declined

-

TechnicalError "DisplayMessage" and/or

"PrintMessage"

DECLINED "05" -

Table 5: Handling for the Authorisation Response for Payment

Data in Response Message Data set by HAP

ResponseToAuthorisation.Response

TransactionResponse.Action.ActionType Transaction Result

Approved Only "DisplayMessage" and/or "PrintMessage" may be present

APPROVED

Declined any DECLINED

PartialApproved any DECLINED

TechnicalError any DECLINED

Table 6: Handling for the Authorisation Response for Refund and Cancellation Response

The SEPA-FAST data element Decline Display Message is filled then with

Action.MessageToPresent.MessageContent of the response message.

For the Action.ActionType equal to "PrintMessage" the acquirer delivers also the message element

Action.MessageToPresent.MessageContent.

The length of the text messages is limited for the acquirer host by the POI capability PrintLineWidth for the

printer sent in the request. The terminal prints these text messages without any additional plausibility

check. The information whether the cardholder or the merchant receipt has to be used is sent in message

element Action.MessageToPresent.MessageDestination.

The print messages for the cardholder and/or merchant are printed in the Footer of the corresponding

receipt.


Phase 2

10/07/2014 version 3.2 25/154

If no receipt message for the cardholder is issued by the host no additional text will be shown on the

cardholder receipt.

If no receipt message for the merchant is issued by the host no additional text will be shown on the

merchant receipt.

If the data element TransactionResponse.TMSTrigger is present in the response message, HAP shall take

into account the instructions to call the TMS.

The TMSIdentification may be ignored since only one TMS is used. The communication parameters are

taken from the local configuration of the POI.

The HAP data element Call TMS is filled with the value of the message element TMSContactLevel. The

POI will react as follows according to the value of Call TMS (compare section 4.1):

"AsSoonAsPossible" or "Critical":

The TMS will be contacted in the Idle State of the financial application after performing a

Reconciliation if required.

"DateTime":

The TMS has to be contacted in the Idle State at the date and time provided in

TMSContactDateTime if present. The date and time in TMSContactDateTime is stored in HAP. If

TMSContactDateTime is not present the element Call TMS is set to "ASAP".

HAP returns to SEPA-FAST:

Ok, if a valid response was received,

Nok, if the transaction needs to be aborted. In this case Nok Reason is set to DATA ERROR


Phase 2

10/07/2014 version 3.2 26/154

4.3 HAP Transaction Data Storage This function is used at Transaction Completion to request storage of the transaction data.

The storage of the transaction data is necessary for

the capture of the transaction by an AcceptorCompletionAdvice message if configured by TMS,

the capture of the transaction by a BatchTransfer if configured by TMS, or

the cancellation of the transaction.

For Acquirers not using batch capture: HAP will keep the transactions in the data storage, also called transaction

log in section 6.2.3 of [SEPA-FAST], until a ReconciliationResponse message with Response equal to "Approved"

has been received (see section 6.6).

For Acquirers using batch capture: HAP will keep the transactions in the data storage until the

BatchTransferResponse with all “Approved” datasets has been received (see section 6.5).

HAP shall support limitation of financial risk by supporting limits for the number of logged transactions not yet

captured and the number of offline transactions not yet captured. The limits are configured by TMS see [CAPE

TMS MDR]. The usage of the limits is specified in [CAPE TMS MUG].

HAP shall check that all mandatory data it needs for the protocol are available and store the transaction. The error

handling during this processing is described in section 15.1 of [SEPA-FAST].


Phase 2

10/07/2014 version 3.2 27/154

HAP Transaction Data

Storage

OKNOK

All mandatory data

needed for the protocol

is available?

Yes

Log Limit is reached?

Store Transaction

Set Terminal Error Reason = LOG LIMIT EXCEEDED

Set Terminal Error Indicator = TRUE

Ok

Yes

No

No

Nok

Figure 3: HAP transaction data storage

Note: the Log limit controlled in the figure 4 is an internal log limit related to the terminal capacity and is not

configurable.

4.3.1 SEPA-FAST data elements SEPA-FAST specifies in section 15.1 which data elements shall be logged when available.

4.3.2 EPAS data elements All the data elements needed for the generation and validation of the messages described in section 6 are stored by HAP.

4.3.3 HAP data elements

All data elements described in this section must be added to each transaction record in the HAP transaction data storage.


Phase 2

10/07/2014 version 3.2 28/154

Length (in Bytes)

Format Data element Description Presence Value

1 b Cancellation Flag This element is used by HAP Search Transaction function. If a transaction is flagged as ‘Cancelled’ in the transaction log the transaction cannot be presented for the Cancellation Service anymore. More about HAP Search is described in section 4.5

M ‘00’ – Not Cancelled (default value)

‘01’ – Cancelled

1 b Finalization Flag Transaction flagged as ‘Not Finalized’ has not completed finalization phase as described in section 4.4

M ‘00’ – Not Finalized (default value)

‘01’ – Finalized

Table 7: HAP data elements

4.4 HAP Transaction Finalisation This function is used at Transaction Completion to trigger transaction finalisation in HAP.

HAP performs the Transaction Finalisation for the acquirer protocol:

Advice handling for completion and/or reversal,

Capture of the data.

HAP returns:

Ok, if the function was performed successfully

Nok, otherwise.


Phase 2

10/07/2014 version 3.2 29/154

.

HAP Transaction Finalisation

10

Build

AcceptorCompletionAdvice

message

20

Build

AcceptorCancellationAdvice

message

30

Send Advice Message

50

Parse Response Message

OKNOK

Is Selected

Service = ’03' ?’

Completion

required by acquirer or configuration or

necessary as reversal ?

Yes

Yes

No

40

Receive Response Message

Ok

Ok

Nok

Nok

No

Nok

TMSTrigger in Response?Yes

Fill Call TMS with value of

TMSContactLevel

Ok

No

60

Update Finalization Flag

Figure 4: HAP Transaction Finalisation


Phase 2

10/07/2014 version 3.2 30/154

4-10 Build AcceptorCompletionAdvice Message

For the capture of payment and refund transactions by completion the EPAS completion exchange consisting of

the AcceptorCompletionAdvice as described in section 6.2.1 and AcceptorCompletionAdviceResponse as

described in section 6.2.2 is used:

The following steps are carried out:

Build Message Body

o If a reversal has to be sent the following message elements are set:

Transaction.Reversal is set to "True".

Transaction.FailureReason is present and set to one of the values defined in [CAPE ACQ

MDR].

o If the transaction is approved the element Transaction.TransactionSuccess is set to "True".

Otherwise the Transaction.TransactionSuccess is set to "False".

o For EMV Chip transactions, the ICCRelatedData message element for a Payment is filled with

the data elements of SEPA-FAST already listed in Table 1 for Offline transactions and Online

transactions without a second GENERATE AC. If a second GENERATE AC has been

performed, the data elements Application Cryptogram (AC), Cryptogram Information Data

(CID), Issuer Application Data (IAD), Terminal Verification Results (TVR) and

Unpredictable Number are updated with the new values. The Issuer Script Results are

added if any available for this transaction.

o If EMV Chip transactions cannot successfully be completed (a TC has not been received) the

ICCRelatedData message element for a Payment is filled with the data elements Processing

Status, Nok Reason, Terminal Verification Results (TVR) and Transaction Status

Information (TSI).

o For EMV Chip transactions, the ICCRelatedData message element for a Refund is filled with

the data elements of SEPA-FAST as already listed in Table 2.



4-20 Build AcceptorCancellationAdvice Message

For the Cancellation service the EPAS cancellation exchange consisting of the AcceptorCancellationAdvice as

described in section 6.3.1 and AcceptorCancellationAdviceResponse as described in section 6.3.2 messages is

used.

The AcceptorCancellationAdvice is not sent if:

- Transaction Result = ABORTED

or

- The original transaction has OnLineContext = False and no CompletionAdvice has been sent

- and AcquirerProtocolParameters.OffLineTransaction.FinancialCapture = Batch

- and AcquirerProtocolParameters.OffLineTransaction.CancellationExchange is Absent


Phase 2

10/07/2014 version 3.2 31/154


Build Message Body

o For EMV Chip transactions, the ICCRelatedData message element is filled with the data

elements of SEPA-FAST listed in Table 2: Transaction Data Element for

AcceptorAuthorisationRequest used for Refund.



The Cancellation Flag of the cancelled transaction is updated to ‘Cancelled’ if Transaction Result = APPROVED.

Transaction marked as cancelled cannot be presented for the Cancellation Service anymore in HAP Search

Transaction (see section 4.5).

4-30 Send Advice Message

Send the advice message to the host according to the Acquirer Number.

If the FinancialCapture is equal to Completion for the transaction in process the message function

CompletionAdvice has to be found in one MessageToSend list. Otherwise an error occurs and HAP shall return

Nok to SEPA-FAST.

If the HostIdentification has been selected and no connection to this host could be established, HAP shall return

Nok to SEPA-FAST and .shall retry to retransmit the advice as soon as possible or according to TMS configuration.

If the problem persists the advice is still pending and will be handled by HAP Status (see section 4.1).

4-40 Receive Response Message

If the response message is not received HAP has to retransmit the advice message as soon as possible or

according to the TMS configuration and shall return Nok to SEPA-FAST. If the problem persists, the message is

handled by HAP Status (see section 4.1).

4-50 Parse Response Message

If HAP receives the response message HAP checks the consistency of the message syntax and format as well as

the MAC as described in the [CAPE ACQ MUG].

If the checks are successful; HAP updates the appropriate terminal transaction data elements using the present

message elements as described in section 6.2.2 and 6.3.2.

If HAP detects an error in the response message, it has to retransmit the advice message as soon as possible or

according to the TMS configuration.


Phase 2

10/07/2014 version 3.2 32/154

If HAP does not receive a valid response, HAP returns nok to SEPA-FAST.

4-60 Update Finalization Flag

After a successfuly completed finalization, the Finalization Flag of the transaction is set to ‘Finalized’.

Transaction is marked as ‘Finalized’:

When a transaction completion was required and the completion was performed successfully

Or when no completion was required for the transaction.

Transactions having Transaction Result = VOICE AUTHORISATION are marked as ‘Not Finalized’.

If a transaction is marked as ‘Not Finalized’:

Cancellation Service for such transaction is not allowed

For pending transactions (Transaction Result <> VOICE AUTHORISATION), retransmission will be

performed:

o In accordance to TMS configuration

o Or by HAP Status checking of pending transactions during SEPA-FAST initialization.

4.5 HAP Search Transactions The use of this function and the data used by HAP to search for transactions are described in [SEPA-FAST]

section 15.1.

HAP performs additional operations during search transactions function according to HAP specific functionality:

For Cancellation service, transactions marked as ‘Not Finalized’ will be skipped and not stored into the Search Transaction Result list.

For Voice Authorisation processing, transactions returned by the search function shall be marked as ‘Not Finalized’ and having Transaction Result = VOICE AUTHORISATION.

Note:

Outstanding pending transactions have Finalization Flag set to ‘Not Finalized’.

4.6 Batch Processing The acquirer can require by configuration that the acceptor send the transactions in batch. In

AcceptorBatchTransfer or AcceptorBatchTransferResponse (see section 6.4), transactions are organised in

DataSet.In the OSCar project, if the acquirer requires the batch for authorised online transactions, it has to require

it also for authorised offline transactions. The limits used as trigger for the batch transfer of Online and Offline

transations are defined in [CAPE TMS MUG].

For message exchange mode, grouping of transactions in several BatchTransfer messages is possible. HAP may

split the whole log in several requests if needed.


Phase 2

10/07/2014 version 3.2 33/154

Batch processing

10

Build

AcceptorBatchTransfer

Message

20

Send

BatchTransfer

Message

30

Receive and Parse

AcceptorBatchTransferResponse

End Batch

processing

End Batch

processing

Nok

Ok

Nok

No All transactions

captured ?

Yes

Ok

Figure 5: Batch Processing

5-10 Build BatchTransfer Request

The POI generates the BatchTransfer message containing all transactions to be captured according to the TMS configuration.

Depending on the value of the “OnlineContext” attribute of the transactions to be captured, the TMS configuration (see section 5.5.3) is used in the following way:

OnlineTransaction.ExchangePolicy = "NumberLimit":

The batch transfer is started if the number of only successfully completed and not cancelled (Type=Debit+Credit) online transactions has reached the limit BatchTransfer.MaximumNumber.

OnlineTransaction.ExchangePolicy = "TotalLimit":

The batch transfer is started if the TotalAmount sum of only successfully completed and not cancelled (Type=Debit+Credit) online transactions has reached the limit BatchTransfer.MaximumAmount.

OnlineTransaction.ExchangePolicy = "Cyclic": see [CAPE TMS MUG]


Phase 2

10/07/2014 version 3.2 34/154

OfflineTransaction.ExchangePolicy = "NumberLimit":

The batch transfer is started if the number of only successfully completed and not cancelled (Type=Debit+Credit) offline transactions has reached the limit BatchTransfer.MaximumNumber.

OfflineTransaction.ExchangePolicy = "TotalLimit":

The batch transfer is started if the TotalAmount sum of only successfully completed and not cancelled (Type=Debit+Credit) offline transactions has reached the limit BatchTransfer.MaximumAmount.

OfflineTransaction.ExchangePolicy = "Cyclic": see [CAPE TMS MUG]

The BatchTransfer may also be initiated by the merchant using a local administration interface of the POI or using the Retailer Protocol (see section 7).

If the POI uses the message exchange to perform Batch Transfer, it may split the number of transactions in several message exchanges if the maximum length of the message is limited by the POI capabilities.


Fill in Data Set information

o Generate DataSetIdentification:

Generate Name

Set Type to "BatchCapture"

Generate CreationDateTime

Calculate and fill in TransactionTotals of the Data Set

o For EMV Chip transactions, the ICCRelatedData message element is filled with the same data

elements as in the AcceptorCompletionAdvice message.


o See section 4.1, Note 1-30

Build File Header

o Set DownloadTransfer = False

o Select the recipient (HostIdentification) including the correct communication Parameter

according to the Acquirer Number.

o Fill in FormatVersion

o Generate next ExchangeIdentifier

o Generate CreationDateTime etc.

5-20 Send BatchTransfer message

If no connection to the host could be established HAP will retry the BatchTransfer according to the TMS

configuration. If the retry cannot successfully be performed HAP Status will handle the pending messages.

Once a Batch has been sent, any transaction newly finalised has to be stored in a new Batch.

A Batch cannot be reopened (e.g. in case of rejection) to append a new transaction under any circumstances.


Phase 2

10/07/2014 version 3.2 35/154

5-30 Receive and parse BatchTransferResponse

For message exchanges mode, the Acquirer host sends a BatchTransferResponse for each request.

For file transfer mode, the Acquirer generates a BatchTransferResponse and the POI uploads it after a time period

defined by the acquirer.

HAP checks the consistency of the Syntax and Format of the response message. Subsequently HAP validates the

MAC as described in the [CAPE ACQ MUG].

If the validations are successfully performed HAP will perform the following actions:

If "RemoveDataSet" is set to True, HAP can delete the log of the DataSet, otherwise it has to keep it.

If one or more transactions are rejected, HAP shall keep them stored to send them by another means to

the recipient.

If the validation of the response message fails, HAP will keep all transactions.

4.7 Perform Reconciliation This function can be performed during the HAP Status if required. It can also be performed independently during the Idle State of the SEPA-FAST application.

A Reconciliation period can be closed even if any pending Voice Authorisation transactions (transactions having

the result ‘VOICE AUTHORISATION’) exist.

The reconciliation exchange is triggered by

- a limit or a timer configured by a TMS configuration, or

- the merchant using a local administration interface of the POI or using the Retailer Protocol.

The TMS configuration (see section 5.5.3) is used as described in [CAPE ACQ MUG], section 2.6.4.

The following steps are carried out to build the AcceptorReconliationRequest:

Build Message Body

o the totals are calculated as described in [CAPE ACQ MUG]

o see section 6.6.1


o see Note 1-30


o see AcceptorDiagnosticRequest except MessageFunction

o Message Function is set to "ReconciliationRequest"

Checks consistency of the Syntax and Format of the message AcceptorReconciliationResponse described in section 6.6.2. It checks as well the message integrity (MAC) as described in [CAPE ACQ MUG].

4.8 Perform Diagnostic This function can be performed during the HAP Status if required. It can also be performed independently during the Idle State of the SEPA-FAST application.


Phase 2

10/07/2014 version 3.2 36/154

The diagnostic exchange is triggered by the merchant using a local administration interface of the POI or using the Retailer Protocol (see section 7). If the diagnostic is initiated by the Retailer Protocol the message exchange is performed with all Acquirer Hosts. The exchange may be limited to one or group of host(s) if the POI supports the Pre-selection of the Acquirer.

The following steps are carried out to build the AcceptorDiagnosticRequest:

Build Message Body

o see section 6.5.1

Build Security Trailer as described in the section Message Security of [CAPE ACQ MUG]

The Security Trailer contains the generic CMS data structure with the type ContentInformationType1. The

ContentType of the structure has the value "AuthenticatedData", for a MAC (Message Authentication

Code), generated with a cryptographic key. The data elements of the structure are filled with all information

the recipient needs to identify the key and the used cryptographic algorithms.


o InitiatingParty filled with identification of the acceptor system (e.g. Merchant Identifier

concatenated with Terminal Identification assigned by the acquirer)

o Select the recipient including the correct communication parameter according to the Acquirer

Number

o The element MessageFunction is set to "DiagnosticRequest"

o Fill in ProtocolVersion

o Generate next ExchangeIdentification

o Generate CreationDateTime.

Checks consistency of the Syntax and Format of the message AcceptorDiagnosticResponse described in section 6.5.2. It checks as well the message integrity (MAC) as described in [CAPE ACQ MUG].

If TMSTrigger is present in the response then Call TMS is set to the value of TMSContactLevel.


Phase 2

10/07/2014 version 3.2 37/154

5 Configuration and maintenance handling

5.1 TMAP functionality

In the OSCar project, TMAP is the application responsible for handling the protocol used for maintenance and administrative functionality.

TMAP manages the following:

- SEPA-FAST configuration data elements provided by TMS (see section 5.4),

- EPAS configuration data elements provided by TMS (see section 5.5),

- The communication between the POI application and the terminal manager system using the TMS

protocol.

It is recommended that the POI keeps backup values for the parameters needed to successfully contact TMS.

It is not required that TMAP synchronizes the POI sytem time with the TMS host. The method used to synchronize POI date/time is out of scope of this document.

5.2 Perform Terminal Management session This function is performed during the Idle State of the SEPA-FAST application.

The management session is performed upon a request from SEPA-FAST application or if the DateTime configured for a cyclic call is met.

When TMAP receives a request from SEPA-FAST application to begin a management session, it checks the value

of the data elements Call TMS, Terminal Error Indicator and Nok Reason.

If the element Call TMS has the value "ASAP" or "Critical" the TMS session is started immediately as specified in

[CAPE TMS MUG].

If the element Call TMS has the value "DateTime", the TMS session is started when the date and time specified in the Action.TimeCondition data structure of the ManagementPlan or in the TMSContactDateTime of the AuthorisationResponse is met as specified in [CAPE TMS MUG].

If the element Terminal Error Indicator is set to TRUE and Nok Reason is set to “CONFIGURATION ERROR”

then TMAP prepares the element Errors of the TMS message StatusReport with the content "Mandatory data

missing".

If the TMS session has been performed successfully TMAP sets the element Call TMS to "None"

At the end of the TMS session, TMAP shall ensure that all mandatory configuration data is available


Phase 2

10/07/2014 version 3.2 38/154

5.3 Configuration Data Model

SEPA-FAST and EPAS use different formats for data elements coding. These formats are both handled by TMAP.

For the purpose of this document:

SEPA-FAST configuration data elements shall be described as TLV as defined in [SEPA-FAST]

EPAS configuration data elements are structured as described in [CAPE TMS MDR]

Figure 6: Overview of configuration components

Host Communication Parameter

Terminal Card service Configuration Data

Application profile

Terminal Configuration Data

Acquirer Protocol Parameters

TMAP

EPAS Configuration Data SEPA-FAST Configuration Data


Phase 2

10/07/2014 version 3.2 39/154

5.4 SEPA-FAST Configuration Parameters

As SEPA-FAST does not specify how the configurable data elements per Application Profile are received and

locally stored, or how the values are retrieved or referenced for use during a transaction, the purpose of this part is

to provide an implementation guide for SEPA-FAST parameters downloading

5.4.1 Logical parameters classification

Terminal Configuration Data

Application

Profile n

Configuration

Data

Application

Profile n

Configuration

Data

Application

Profile n

Configuration

Data

Application

Profile n

Configuration

Data

Application

Profile n

Configuration

Data

Supported Card Service n’




Supports

Sup

port

s

Supports

Su

ppo

rts

Supp

ort

sSupports

Supp

ort

s

Supports Supp

ort

sTerminal Card service Configuration Data

Figure 7: Overview of SEPA-FAST data classification

SEPA-FAST data elements configuration data elements are classified into three main categories on the logical level:

Terminal configuration data, there is only one occurrence of these data elements which is handled by a

SEPA-FAST application

Terminal Card service configuration data, there must be as many occurrences as there are services

possibly supported by the SEPA-FAST application


Phase 2

10/07/2014 version 3.2 40/154

Application profile configuration data: multiple occurrences of application profile configuration data

elements can be present in the SEPA-FAST depending on acquirer parameters downloading. Al least

one set of application profile configuration data element must be present.

Note: There is no hierarchy between Terminal Card service configuration data elements and Application profile configuration data elements. Different application profiles can be selected for the same service and the same application profile set of parameters may be used by more than one service.


Phase 2

10/07/2014 version 3.2 41/154

5.4.2 Categories details

Application Profile Selection

Table (E2)

Application Profile AID

Application Profile Number

Supported Services

…………………….

Terminal Configuration Data (Terminal Level) Card Service parameters (Terminal Level) Application Profilel level parameters

Terminal List of AID

(E5)

Service Settings Table (E4)

check

check Must match for Apllication Profile Selection

Card data

PAN

AID

Bank Identifier Code (BIC)

Issuer Country Code (a2 )

Issuer Country Code (a3 )

Issuer Identification Number

(IIN)

IBAN

Optional: other private Tag(s)

check

Certification Authority (CA)

Public Key Table (E3)

Application Profile Selection Table

non Chip (E8)

BIN based Card Product Identifier

(BID)


Supported Services

Application Profile Acquirer

Number

………………………………...

Terminal List of BID

(E7)

AID Preference Table

(EE)

Acquirer Parameter

Table (ED)

Iden

tify the

pro

file to b

e selected

check

check

Terminal Exception

File (E9)

Terminal Specific Data (E0

&E1)

Configured Services

Terminal capabilities

Terminal Country Code

Terminal Type

Terminal Identification

………………………….

Ch

eck

Application Profile Parameters (E6)


Application Profile Settings (APS)

Acquirer Identifier

…………………………...

Merchant Category Code

Merchant Identifier

Merchant Name and Location

………………………….

Terminal Action Code (TAC) – Default

Terminal Action Code (TAC) – Denial

Terminal Action Code (TAC) – Online

Terminal Capabilities

Terminal Floor Limit

Terminal Identification

…………………………..

Combinations List &

Parameters (EC)

Service settings

Figure 8: Detailed SEPA-FAST Data Catagories


Phase 2

10/07/2014 version 3.2 42/154

5.4.3 Structure of data elements tables

SEPA-FAST configuration data elements are grouped into a set of envelopes.

These data elements shall be coded according to the BER-TLV description as defined in ISO/IEC 8825.

According to the specification [CAPE TMS MDR] the SEPA-FAST configuration data will be transported in the

message component 'ApplicationParameters' of the message AcceptorConfigurationUpdate (see section 5.5.3).

The message element 'Application Identifier' will be set to "SEPA-FAST Part 1" and the 'Version' to the overall

version of the configuration data for the SEPA-FAST terminal application. The message element 'Parameters'

contains the SEPA-FAST configuration data in binary format as described in the following.

The parameters are grouped by integrating them in separate envelopes (templates). These Templates can be

transmitted in any order:

- one template E0 with the permanent terminal specific data that are specific for the vendor or hardware i.e.

the command key labels etc.,

- one template E1 with the terminal specific data i.e the terminal capabilities, terminal country code etc.,

- one template E2 containing a set of Application Profile Selection Tables,

- one template E3 containing a set of Certification Authority (CA) Public Keys,

- one template E4 with the Service Setting table,

- one template E5 with the list of AID characteristics

- one or more templates E6 (one per Application Profile) containing profile specific configuration data

identified with the Applcation profile Number,

- one template E7 with the list of BID (BIN based Card Product Identifier) characteristics,

- one template E8 containing a set of Application Profile Selection Tables for Non Chip,

- one template E9 containing the terminal exception file listing cards.,

- one template EA containing the Limit Set List,

- one template EC containing the Combinations List & Parameters Table,

- one template ED containing the Acquirer Parameter Table,

- one template EE containing the AID Preference Table, and

- one template EB containing the Default Kernel ID per AID


Phase 2

10/07/2014 version 3.2 43/154

5.4.3.1 Parameters internal structure The templates grouping the application configuration data contain the following parameters:

E0 permanent terminal specific data (vendor specific):

9F1E, DF14, DF15, DF16

DF33 Terminal Supported Language List

E1 Terminal specific data:

9F40 Additional Terminal Capabilities

9F33 Terminal capabilities

……….

9F35 Terminal Type

DF40 Terminal Application Version List (n-times RID concatenated with Application Version)

E2 Application Profile Selection Table:

BF01 Application Profile Selection Table Entry 1



……….

E3 Certification Authority (CA) Public Key Table:

BF01 Public Key 1

BF01 Public Key 2

BF01 Public Key 3

……….

E4 Service Settings Table:

BF01 Service Settings Entry 1



……….

E5 Terminal List of AID characteristics:

BF01 characteristics of AID Entry 1 (containing the AID and the characteristics including the ASI at the minimum)

BF01 characteristics of AID Entry 2

BF01 characteristics of AID Entry 3

……….

E6 Application Profile one per Application profile number

…….

E6 Application Profile one per Application profile number

E7 Terminal List of BID characteristics:

BF01 characteristics of BID Entry 1




Phase 2

10/07/2014 version 3.2 44/154

……….

E8 Application Profile Selection Table Non Chip:

BF01 Application Profile Selection Table Non Chip Entry 1



……….

E9 Terminal Exception file:

BF01 characteristics of card Entry 1



..........

EA Limit Set List:

BF01 Characteristics of Limit Set1



......

EC Combinations List & Parameters Table

BF01 Combinations List & Parameters Table Entry 1



...........

ED Acquirer Parameter Table

BF01 Acquirer Parameter Table Entry 1



..........

EE AID Preference Table

BF01 AID Preference Table Entry 1



..........

EB Default Kernel ID per AID

BF01 Default Kernel ID for AID1 Entry 1



..........

Validation of the Parameters during Installation


Phase 2

10/07/2014 version 3.2 45/154

During the installation of the application parameters TMAP has to validate the following issues respectively to

perform the following processing:

I. TMAP checks the syntax of the configuration data, the TLV coding, format and length of each data element, if

one error occurs, the complete configuration data are discarded.

II. E2 to E5 have to contain at least one table (template) BF01.

III. Templates E0 to E5, E7 to E9, EA, ED, EE, EC, EF and every instance of template E6 are always updated

completely. The update of individual primitive or constructed Tags in one of the templates E1 to E9, EA, ED,

EE and EC is not possible.

IV. E6 containing a new Application Profile Number DF19 adds a new application profile to the terminal

configuration with this number.

V. E6 containing an existing Application Profile Number DF19 replaces the whole contents of the application

profile with this number.

o All data elements already stored under this Application Profile Number are deleted and

subsequently all new data elements of this template stored under this Application Profile

Number.

o If E6 contains only the Application Profile Number DF19 and no other element the existing

application profile with this number is deleted.

VI. The TMS Action.Type "Delete" of the management plan erases all existing Application Profiles of the SEPA-

FAST application if the DataSetIdentification.Name in the action is equal to "Application Profile".

VII. The entries of the Application Profile Selection Table in the template E2 and the Application Profile Table

Non Chip in the template E8 have to be installed by TMAP in the order/sequence of the configuration file.

These entries will be treated by the terminal application in this predefined sequence then.

VIII. E7 and E8 have to contain at least one table (template) BF01 if magnetic stripe and/or Manual Entry

processing is supported by the terminal.

IX. Empty templates are not allowed. To delete a template, the rule defined in the

ManagementPlanReplacement applies (see page69).

During the downloading phase the format and the presence of mandatory data elements shall be checked by

TMAP. A mandatory data element of any of the templates shall be present (or present in its reference profiles for

E6).


Phase 2

10/07/2014 version 3.2 46/154

With the exception of rules defined in this document, other consistency of the downloaded acquirer parameters is

under the responsibility of the TMS application and shall not be checked during downloading and installation

phase.

5.4.3.2 Data Elements description

Permanent terminal specific data for the template E0

The template E0 contains the terminal specific data. For large retailers where several terminals are installed (integrated systems), this template has to be configured on each of them.


Phase 2

10/07/2014 version 3.2 47/154

Tag Length (in Bytes)

Format Data element Presence

'9F1E' 8 an8 Interface Device (IFD) Serial Number O

'DF14' Up to 5 ans…5 Command Key Clear Label M

'DF15' Up to 5 ans…5 Command Key Enter Label M

'DF16' Up to 5 ans…5 Command Key Scroll Label M

‘9F1C’ 8 an8 Terminal Identification M

Terminal specific data for the template E1



'9F40' 5 b Additional Terminal Capabilities M

'DF12' 2 an2 Cardholder Default Language M

'DF13' 2 b2 Configured Services M

'DF17' 1 b Default Card Service M

'DF18' 1 b Max. Number of Chip Tries O

'DF40' var b Terminal Application Version List (contact) M

‘DF49’ Terminal Application Version List (contactless) C

‘9F33’ 3 b Terminal capabilities M

‘9F1A’ 2 n3 Terminal Country Code M

‘DF34’ 2 b Terminal Settings M

'DF33' 4..60 an..60 Terminal Supported Language List M

‘9F35’ 1 n2 Terminal Type M

‘DF35’ 2 n3 Terminal Transaction Currency Code M

DF47 3 a3 Terminal Transaction Currency Code – Alpha3 M

‘DF36’ 1 n1 Terminal Transaction Currency Exponent M

‘DF46’ 1 b Unpredictable Number Range O


Phase 2

10/07/2014 version 3.2 48/154

Application Profile Selection Table for the template E2

The envelope E2 may contain several entries. Each entry is contained in the tag BF01.

The content of each entry is described below:



‘DF01’ 5-16 b Application Profile AID M

‘DF02’ 1 n 2 Application Profile Number M

‘DF03’ 2 b Supported Services M

‘DF04’ 1 n 2 Application Profile Acquirer Number C

‘DF05’ 1 b AID Match Criteria C

‘DF06’ 8 or 11 b Bank Identifier Code C

‘DF07’ 2 a 2 Issuer Country Code(alpha2 format) C

‘DF08’ 3 a 3 Issuer Country Code(alpha3 format) C

‘DF09’ 3 n 6 Issuer Identification Number (IIN) C

‘DF0A’ 3 cn 6 IIN Mask C

‘DF0B’ up to 34 ans…34 IBAN Comparison Value C

‘DF0C’ up to 34 as…34 IBAN Mask C

‘DF0D’ 6 n 12 Application Profile Amount Limit C

‘DF0E’ 1 n 2 Cashback present C

‘DF0F’ 1 b Technology of Profile C

‘DF10’ up to 8 b Application Profile Kernel ID C

Optional: other private Tag(s)


Phase 2

10/07/2014 version 3.2 49/154

Certification Authority (CA) Public Key Table for template E3


The content of each entry:is described below.



‘DF01’ 5 b Registered Application Provider Identifier (RID) – Terminal M

‘9F22’ 1 b Certification Authority (CA) Public Key Index – Terminal M

‘DF02’ 1 b Certification Authority (CA) Hash Algorithm Indicator M

‘DF03’ 1 b Certification Authority (CA) Public Key Algorithm Indicator M

‘DF04’ var. (max

248)

b Certification Authority (CA) Public Key Modulus M

‘DF05’ 1 or 3 b Certification Authority (CA) Public Key Exponent M

‘DF06’ 20 b Certification Authority (CA) Public Key Check Sum O

Service Settings Table for template E4


The content of each entry is described below.



‘DF01’ 1 b1 Service Identifier M

‘DF10’ 2 b2 Service Settings M

‘DF02’ 1 b1 Cardholder Initial Msg # M

‘DF11’ 1 b1 Allowed Service Start Events M

‘DF0F’ 1 b1 Minimum Service Start Conditions M

‘DF0F’ 1 b1 Minimum Service Start Conditions (multiple instances) O

Terminal List of AID for template E5





‘DF01’ 5-16 b Terminal AID M

‘DF02’ 1 n 1 Application Selection Indicator M


Phase 2

10/07/2014 version 3.2 50/154

Application Profile table for template E6

An envelope E6 per Application profile number. The presence of a data element ‘M’ means that the element must be present in this Application Profile or the referenced profile.



‘DF19’ 1 n2 Application Profile Number M

‘9F01’ 6 n 6-11 Acquirer Identifier M

‘EF’ up to 256 b5 Additional Data Elements O

‘DF1B’ 1 n2 Acquirer Number M

‘DF26’ 5 b5 Additional Restrictions of Forced Acceptance O

‘9F40’ 5 b Additional Terminal Capabilities O

‘9F1A’ 2 n3 Terminal Country Code O

‘DF41’ 1-16 ans Application Label Default M

‘DF27’ 5 b5 Application Profile Settings (APS) M

‘DF28’ 2 b2 Application Profile Settings for Cancellation (APSC) C

‘DF29’ 6 n12 Cash Advance Maximum Amount O

‘DF2A’ 6 n12 Cashback Maximum Amount O

‘DF8118’ 1 b CVM Capability – CVM Required C

‘DF8119’ 1 b CVM Capability – No CVM Required C

‘DF42’ 1 b CVM Magnetic Stripe C

‘DF43’ 1 b CVM Manual Entry C

‘DF1A’ var b Default Dynamic Data Authentication Data Object List O

‘DF4B’ 3 n6 Default Hold Time M

‘DF44’ 1 b Fallback Parameter – Chip O

‘DF45’ 1 b Fallback Parameter – Magnetic Stripe O

‘DF8130’ 1 b Hold Time Value C

‘DF811B’ 1 b Kernel 2 Configuration C

‘9F6D’ 1 n2 Kernel 4 Reader Capabilities C

‘DF4A’ 1 b Kernel 4 Settings C

‘DF811E’ 1 b Mag-stripe CVM Capability – CVM Required C

‘DF812C’ 1 b Mag-stripe CVM Capability – No CVM Required C

‘DF1C’ 1 n2 Maximum Target Percentage to be used for Biased Random

Selection

O

‘9F15’ 2 n4 Merchant Category Code M

‘9F7C’ 20 b Merchant Custom Data O


Phase 2

10/07/2014 version 3.2 51/154



‘9F16’ 15 ans 15 Merchant Identifier M

‘9F4E’ var ans Merchant Name and Location M

‘DF812D’ 3 n6 Message Hold Time C

‘DF4C’ Online Capability (Partial or Full) C

‘DF2B’ 1 n2 Overspend Percentage O

‘DF2C’ 7 b7 PAN Mask O

‘DF2D’ 6 n12 Payment Maximum Amount O

‘DF2E’ 6 n12 Payment Minimum Amount O

‘DF8131’ Up to 128 b Phone Message Table C

‘DF2F’ 2 n3 Pre-Authorisation Default Number of Days O

‘DF30’ Up to 64 b Receipt Data Object List (Receipt DOL) O

‘DF8124’ 6 n12 Reader Contactless Transaction Limit (No On-device CVM) C

‘DF8125’ 6 n12 Reader Contactless Transaction Limit (On-device CVM) C

‘DF8126’ 6 n12 Reader CVM Required Limit (Kernel) C

‘DF24’ 1 n2 Reference Application Profile Number O

‘DF31’ 6 n12 Refund Maximum Amount O

‘DF48’ 1 b Removal Timeout O

‘DF32’ var ans Scheme Identifier O

‘DF1D’ 1 n2 Target Percentage to be Used for Random Selection O

‘DF1E’ 5 b5 Terminal Action Code (TAC) – Default C

‘DF1F’ 5 b5 Terminal Action Code (TAC) – Denial C

‘DF20’ 5 b5 Terminal Action Code (TAC) – Online C

‘9F33’ 3 b Terminal Capabilities O

‘9F1B’ 4 b4 Terminal Floor Limit O

‘9F1C’ 8 an8 Terminal Identification O

‘9F1D’ 1-8 b Terminal Risk Management Data O

‘DF21’ 4 b4 Threshold Value for Biased Random Selection O

‘9F53’ 1 b Transaction Category Code O

‘9F7A’ 1 n1 VLP Terminal Support Indicator O

‘DF22’ 6 n12 Deferred Payment Default Amount O

‘DF23’ 6 n12 Deferred Payment Maximum Amount O

‘DF25’ 2 n4 Deferred Payment Transaction Duration O


Phase 2

10/07/2014 version 3.2 52/154

Terminal List of BID for template E7





'DF01' 5-16 b BIN based Card Product Identifier (BID) M

'DF02' Up to 10 cn...20 Prefix M

Application Profile Selection Table Non chip for the template E8


The content of each entry is described below:



'DF01' 5-16 b BIN based Card Product Identifier (BID) M

'DF02' 1 n 2 Application Profile Number M

'DF03' 2 b Supported Services M

'DF04' 1 n 2 Application Profile Acquirer Number C

'DF05' up to 10 cn...20 Prefix C

'DF06' up to 10 b Prefix Mask C

Terminal Exception File for template E9


Phase 2

10/07/2014 version 3.2 53/154

Tag: 'E9'

Length (in bytes): var

Format: var.

Value: For the kernel E1 processing, the terminal exception file allows to define the following:

the black listed cards (lost, stolen,..) or prefixes,

The cards or prefixes to be processed online,

While performing the Terminal Risk Management, if the card is found in the Exception File with processing indicator set to ‘00’, the terminal shall set the ‘Card appears in exception file’ bit in the TVR to 1. The match can be full or partial.

If the processing indicator is set to ‘01’, the terminal shall set the ‘Transaction exceeds floor limit’ bit in the TVR to 1.

Configuration: Yes (Terminal)

Presence: Optional


The Exception File is structured as follows:

Tag

'BF01'

Length

of Entry 1

Entry 1 … Tag

'BF01'

Length

of Entry n

Entry n




‘DF46’ Up to 10 cn…19 Prefix M

‘DF47’ 1 n2 Application Primary Account Number Sequence Number O

‘DF48’ 1 b Processing Indicator :

‘00’: Declined

‘01’: Online

If absent, value ‘00’ is to be considered.

O

Name Description

Prefix Between 1 and up to 19 decimal digits, to be compared with the first

digits of the PAN

Application Primary Account

Sequence Number

Identifies and differentiates cards with the same PAN. Can be used to

refine processing on black listed cards for full match.


Phase 2

10/07/2014 version 3.2 54/154

Processing Indicator Gives an indication if the card has to be processed online or to be

declined.

Limit Set List EA

The Limit Set List EA envelope is a template consisting of one Limit Set or of the concatenation of several Limit Sets.

It may contain several entries. Each entry is contained in the tag BF01 and is structured as follows:

Tag

'BF01'

Length

of Entry 1

Entry 1 … Tag

'BF01'

Length

of Entry n

Entry n

Every Limit Set is the value field of a constructed data object with tag 'BF01' and is coded according to the table below.


Format Value Presence

'DF01' 1-16 b Terminal Application Program ID M

'DF02' 1 b Status Check Support flag O

'DF03' 1 b Zero Amount Allowed flag O

'DF04' 6 n 12 Reader Contactless Transaction Limit O

'DF05' 6 n 12 Reader Contactless Floor Limit O

'DF06' 6 n 12 Reader CVM Required Limit O

Acquirer Parameter Table ED

This template is consisting of the concatenation of Acquirer Parameter Table Entries for all acquirers supported by the terminal. It is used, amongst others, during the Acquirer Pre-selection process.

The Acquirer Parameter Table is structured as shown in following table.

Tag

'BF01'

Length

of Entry 1

Entry 1 … Tag

'BF01'

Length

of Entry n

Entry n

Every Acquirer Parameter Table Entry is the value field of a constructed data object with tag 'BF01' and is coded according to following table. The content of each entry is described below.



'DF01' 1 n2 Acquirer Number M

'DF02' 1-16 ans Acquirer Label M

'DF03' 1 b Used for Pre-Selection M


Phase 2

10/07/2014 version 3.2 55/154

AID Preference Table EE

Template consisting of the concatenation of AID Preference Table Entries for all (partial) Card AIDs of card applications that shall be preferred to other card applications. The envelope EE may contain several entries. Each entry is contained in the tag BF01.

The AID Preference Table EE is structured as follows:

Tag

'BF01'

Length

of Entry 1

Entry 1 … Tag

'BF01'

Length

of Entry n

Entry n




'DF01' 5-16 b (Partial) Card AID of a preferred card application M

'DF02' 1 n1 Application Selection Indicator for the preferred card application M

'BF02' var. b Subordinated Application(s) M

Combinations List & Parameters EC

Template indicating which AID-Kernel is supported per service and containing the combination parameters.The envelope EC may contain several entries. Each entry is contained in the tag BF01. The configuration of this template is mandatory if Contactless is supported.

The Combinations List & Parameters Table is structured as shown in following table.

Tag

'BF01'

Length

of Entry 1

Entry 1 … Tag

'BF01'

Length

of Entry n

Entry n




'DF01' 5-16 b AID M

'DF02' 1 b Kernel ID M

'DF03' 2 b Supporting Services M

DF04 1 b Cashback Present Flag C

‘DF05’ 4 b Terminal transaction Qualifiers O

‘DF06’ 1 b Status Check Support flag O

‘DF07’ 1 b Zero Amount Allowed flag O

‘DF08’ 6 n12 Reader Contactless Transaction Limit O

‘DF09’ 6 n12 Reader Contactless Floor Limit O


Phase 2

10/07/2014 version 3.2 56/154



‘DF0B’ 6 n12 Reader CVM Required Limit O

‘DF0C’ 1 b Extended Selection Support flag O

'DF0D' 1 b Status Check Requested (pre-defined indicator) O

'DF0E' 1 b Zero Amount (pre-defined indicator) O

'DF0F' 1 b Contactless Application Not Allowed (pre-defined indicator) O

'DF10' 1 b Reader Contactless Floor Limit Exceeded (pre-defined

indicator)

O

'DF11' 1 b Reader CVM Required Limit Exceeded (pre-defined indicator) O

Default Kernel ID per AID for template EB

The envelope EB may contain several entries. Each entry is contained in the tag BF01.




‘DF01’ 5-16 b Terminal AID M

‘DF02’ 1 or

3-8 bytes

n1 Kernel ID M


Phase 2

10/07/2014 version 3.2 57/154

5.4.3.3 Data Elements by Tag

Name Template Tag

Acquirer Identifier ‘E6’ ‘9F01’

Application Version Number – Terminal ‘E1’ part of

‘DF40’

Merchant Category Code ‘E6’ ‘9F15’

Merchant Identifier ‘E6’ ‘9F16’

Terminal Country Code ‘E1’ ‘9F1A’

Terminal Floor Limit ‘E6’ ‘9F1B’

Terminal Identification ‘E6’ ‘9F1C’

Terminal Risk Management Data ‘E6’ ‘9F1D’

Certification Authority (CA) Public Key Index – Terminal ‘E3’ ‘9F22’

Terminal Capabilities ‘E1’ or ‘E6’ ‘9F33’

Terminal Type ‘E1’ ‘9F35’

Additional Terminal Capabilities ‘E1’ or ‘E6’ ‘9F40’

Merchant Name and Location ‘E6’ ‘9F4E’

Transaction Category Code ‘E6’ ‘9F53’

Kernel 4 Reader Capabilities ‘E6’ ‘9F6D’

VLP Terminal Support Indicator ‘E6’ ‘9F7A’

Merchant Custom Data ‘E6’ ‘9F7C’

Subordinated Application(s) ‘EE’ ‘BF02’

Issuer Script Results - ‘D4’

Registered Application Provider Identifier (RID) – Terminal ‘E3’ ‘DF01’

BIN based Card Product Identifier (BID) ‘E8’ ‘DF01’

Application Profile AID ‘E2’ ‘DF01’

Service Identifier ‘E4’ ‘DF01’

Terminal AID ‘E5’ ‘DF01’

Terminal Application Program ID ‘EA’ ‘DF01’

Terminal AID ‘EC’ ‘DF01’

Acquirer Number ‘ED’ ‘DF01’

(Partial) Card AID of a preferred card application ‘EE’ ‘DF01’

Status Check Support flag ‘EA’ ‘DF02’


Phase 2

10/07/2014 version 3.2 58/154

Name Template Tag

Acquirer Label ‘ED’ ‘DF02’

Kernel ID ‘EC’ ‘DF02’

Application Selection Indicator for the preferred card application ‘EE’ ‘DF02’

Application Profile Number ‘E2’ or ‘E8’ ‘DF02

Certification Authority (CA) Hash Algorithm Indicator ‘E3’ ‘DF02’

Cardholder Initial Msg # ‘E4’ ‘DF02’

Application Selection Indicator ‘E5’ ‘DF02’

Certification Authority (CA) Public Key Algorithm Indicator ‘E3’ ‘DF03’

Supported Services ‘E2’ or ‘E8’ ‘DF03’

Zero Amount Allowed flag ‘EA’ ‘DF03’

Supporting Services ‘EC’ ‘DF03’

Used for Pre-Selection ‘ED’ ‘DF03’

Certification Authority (CA) Public Key Modulus ‘E3’ ‘DF04’

Application Profile Acquirer Number ‘E2’ or ‘E8’ ‘DF04’

Reader Contactless Transaction Limit ‘EA’ ‘DF04’

Application Selection Indicator ‘EC’ ‘DF04’

Certification Authority (CA) Public Key Exponent ‘E3’ ‘DF05’

AID Match Criteria ‘E2’ ‘DF05’

Prefix ‘E7’ or ‘E8’ ‘DF05’

Reader Contactless Floor Limit ‘EA’ ‘DF05’

Terminal Transactions Qualifiers ‘EC’ ‘DF05’

Bank Identifier Code ‘E2’ ‘DF06’

Certification Authority (CA) Public Key Check Sum ‘E3’ ‘DF06’


Phase 2

10/07/2014 version 3.2 59/154

Name Template Tag

Prefix Mask ‘E8’ ‘DF06’

Reader CVM Required Limit ‘EA’ ‘DF06’

Status Check Support flag ‘EC’ ‘DF06’

Issuer Country Code(alpha2 format) ‘E2’ ‘DF07’

Zero Amount Allowed flag ‘EC’ ‘DF07’

Issuer Country Code(alpha3 format) ‘E2’ ‘DF08’

Reader Contactless Transaction Limit ‘EC’ ‘DF08’

Issuer Identification Number (IIN) ‘E2’ ‘DF09’

Reader Contactless Floor Limit ‘EC’ ‘DF09’

IIN Mask ‘E2’ ‘DF0A’

Terminal Floor Limit ‘EC’ ‘DF0A’

IBAN Comparison Value ‘E2’ ‘DF0B’

Reader CVM Required Limit ‘EC’ ‘DF0B’

IBAN Mask ‘E2’ ‘DF0C’

Extended Selection Support flag ‘EC’ ‘DF0C’

Application Profile Amount Limit ‘E2’ ‘DF0D’

Cashback present ‘E2’ ‘DF0E’

Technology of Profile ‘E2’ ‘DF0F’

Minimum Service Start Conditions ‘E4’ ‘DF0F’

Application Profile Kernel ID ‘E2’ ‘DF10’

Service Settings ‘E4’ ‘DF10’

Allowed Service Start Event ‘E4’ ‘DF11’

Cardholder Default Language ‘E1’ ‘DF12’

Configured Services ‘E1’ ‘DF13’

BIN based Card Product Identifier (BID) ‘E7’ ‘DF13’

Default Card Service ‘E1’ ‘DF17’

Max. Number of Chip Tries ‘E1’ ‘DF18’

Application Profile Number ‘E6’ ‘DF19’

Default Dynamic Data Authentication Data Object List ‘E6’ ‘DF1A’

Acquirer Number ‘E6’ ‘DF1B’

Maximum Target Percentage to be used for Biased Random Selection ‘E6’ ‘DF1C’

Target Percentage to be Used for Random Selection ‘E6’ ‘DF1D’


Phase 2

10/07/2014 version 3.2 60/154

Name Template Tag

Terminal Action Code (TAC) – Default ‘E6’ ‘DF1E’

Terminal Action Code (TAC) – Denial ‘E6’ ‘DF1F’

Terminal Action Code (TAC) – Online ‘E6’ ‘DF20’

Threshold Value for Biased Random Selection ‘E6’ ‘DF21’

Transaction Reference Currency Conversion ‘E6’ ‘DF23’

Reference Application Profile Number ‘E6’ ‘DF24’

Additional Restrictions of Forced Acceptance ‘E6’ ‘DF26’

Application Profile Settings (APS) ‘E6’ ‘DF27’

Application Profile Settings for Cancellation (APSC) ‘E6’ ‘DF28’

Cash Advance Maximum Amount ‘E6’ ‘DF29’

Cashback Maximum Amount ‘E6’ ‘DF2A’

Overspend Percentage ‘E6’ ‘DF2B’

PAN Mask ‘E6’ ‘DF2C’

Payment Maximum Amount ‘E6’ ‘DF2D’

Payment Minimum Amount ‘E6’ ‘DF2E’

Pre-Authorisation Default Number of Days ‘E6’ ‘DF2F’

Receipt Data Object List (Receipt DOL) ‘E6’ ‘DF30’

Refund Maximum Amount ‘E6’ ‘DF31’

Scheme Identifier ‘E6’ ‘DF32’

Terminal Settings ‘E1’ ‘DF34’

Terminal Transaction Currency Code ‘E1’ ‘DF35’

Terminal Transaction Currency Exponent ‘E1’ ‘DF36’

Terminal Application Version List (contact) ‘E1’ ‘DF40’

Application Label Default ‘E6’ ‘DF41’

CVM Magnetic Stripe ‘E6’ ‘DF42’

CVM Manual Entry ‘E6’ ‘DF43’

Fallback Parameter – Chip ‘E6’ ‘DF44’

Fallback Parameter – Magnetic Stripe ‘E6’ ‘DF45’

Unpredictable Number Range ‘E1’ ‘DF46’

Application Primary Account Number (PAN) ‘E9’ ‘DF46’

Terminal Transaction Currency Code – Alpha3 ‘E1’ ‘DF47’

Application Primary Account Number Sequence Number ‘E9’ ‘DF47’


Phase 2

10/07/2014 version 3.2 61/154

Name Template Tag

Removal Timeout ‘E6’ ‘DF48’

Terminal Application Version List (contactless) ‘E1’ ‘DF49’

Kernel 4 Settings ‘E6’ ‘DF4A’

Default Hold Time ‘E6’ ‘DF4B’

Online Capability (Partial or Full) ‘E6’ ‘DF4C’

CVM Capability – CVM Required ‘E6’ ‘DF8118’

CVM Capability – No CVM Required ‘E6’ ‘DF8119’

Kernel 2 Configuration ‘E6’ ‘DF811B’

Mag-stripe CVM Capability – CVM Required ‘E6’ ‘DF811E’

Reader Contactless Transaction Limit (No On-device CVM) ‘E6’ ‘DF8124’

Reader Contactless Transaction Limit (On-device CVM) ‘E6’ ‘DF8125’

Reader CVM Required Limit (Kernel) ‘E6’ ‘DF8126’

Mag-stripe CVM Capability – No CVM Required ‘E6’ ‘DF812C’

Message Hold Time ‘E6’ ‘DF812D’

Hold Time Value ‘E6’ ‘DF8130’

Phone Message Table ‘E6’ ‘DF8131’

Additional Data Elements ‘E6’ ‘EF’

Deferred Payment Default Amount ‘E6’ ‘DF22’

Deferred Payment Maximum Amount ‘E6’ ‘DF23’

Deferred Payment Transaction Duration ‘E6’ ‘DF25’

Terminal AID ‘EB’ ‘DF01’

Kernel ID ‘EB’ DF02


Phase 2

10/07/2014 version 3.2 62/154

5.5 Acquirer Protocol Configuration Parameters The OSCar terrminal is configured using the EPAS Terminal Management System (TMS) Protocol defined in

[CAPE TMS MDR]. The usage of these messages is specified in [CAPE TMS MUG].

The TMS messages StatusReport, ManagementPlanReplacement and AcceptorConfigurationUpdate are

exchanged as messages or by file..

If the exchange is done by messages, the rules defined in section 8.1 of [CAPE TMS MUG] will apply for the

OSCar terminal.

If the transfer is done by file, the rules defined in section 8.2 of [CAPE TMS MUG] will apply for the OSCar terminal.

The exchange by messages and file (mix of the two possibilities) is not supported in OSCar.

The parameters intended to configure the EPAS Protocol message exchange behaviour included in the OSCar

scope are downloaded via the message AcceptorConfigurationUpdate (see section 5.5.3) in the following

components:

AcquirerProtocolParameters

HostCommunicationParameters.

The message component AcquirerProtocolParameters may contain for each Acquirer identified by

AcquirerIdentification parameters that describe

how to complete and capture online transactions (OnlineTransaction)

how to complete and capture offline transactions (OfflineTransaction)

the reconciliation process (ReconciliationExchange)

the host to be used per message function (Host)

the cancellation processing

The content of the component MessageItem defines which message elements shall be present in the Acquirer

protocol messages and its value. This functionality is only used for the definition of the POI Identifier

InitiatingParty.Identification in the message header.

The structure AcquirerProtocolParameters is used to configure the behaviour of the POI for the completion

exchange subsequent to an online or offline transaction. It is used also to configure the POI for the capture of

online and offline transactions as well as the content of a batch Transfer.

The message component HostCommunicationParameters is used to define the network parameters and the

cryptographic keys for each host which could be an acquirer host system or an intermediary agent assigned by the

acquirer or the acceptor.

The following sections describe additional rules about the presence of the optional data elements and their usage.


Phase 2

10/07/2014 version 3.2 63/154

The multiplicity column of the tables below is used to indicate if the data element is mandatory or not for the OSCar

project.

All data elements defined as mandatory in [CAPE TMS MUG] are mandatory for OSCar.

If a data element is conditional, the condition is defined in the column ‘TMAP Processing’.

Some data elements defined as conditional or optional in [CAPE TMS MUG] are mandatory for OSCar.

The column ‘SEPA-FAST data element’ is used to describe which EPAS data element corresponds to SEPA-FAST

data element.

Data elements not required for an OSCar implementation are in grey.

[1..1]: the data element is mandatory, one occurrence is permitted

[1..*]: the data element is mandatory (at least one occurrence shall be present), many occurrences are permitted

[0..1]: the data element is optional or conditional. The presence condition is defined in the column ‘TMAP

Processing’: if the condition is verified it shall be present.

.


Phase 2

10/07/2014 version 3.2 64/154

5.5.1 StatusReport

StatusReport Component Mult. SEPA-FAST Data Element (DE)

TMAP processing

Header [1..1] see [CAPE TMS MUG]

DownloadTransfer [1..1]

FormatVersion [1..1]

ExchangeIdentification [1..1]

CreationDateTime [1..1]

InitiatingParty [1..1]

Identification [1..1]

Type [0..1]

Issuer [0..1]

ShortName [0..1]

RecipientParty [0..1]


Type [0..1]

Issuer [0..1]

ShortName [0..1]

StatusReport

POIIdentification [1..1]

Identification [1..1] Unique identification of the POI.

Type [0..1]

Issuer [0..1]

ShortName [0..1]

TerminalManagerIdentification [1..1]

Identification [1..1] Identifier of the TMS host

Type [0..1]

Issuer [0..1]

ShortName [0..1]

DataSet [1..1] Only one DataSet is allowed.

Identification [1..1] see [CAPE TMS MUG]

Name [0..1]

Type [1..1] see [CAPE TMS MUG]

Version [0..1]

CreationDateTime [1..1] see [CAPE TMS MUG]

SequenceCounter [0..1]

Content [1..1]

POICapabilities [0..1] Shall be present if DataSetRequired equal to “ManagementPlan”

CardReadingCapabilities [0..*]

CardholderVerificationCapabilities [0..*]

OnlineCapabilities [0..1]

DisplayCapabilities [0..2]

DisplayType [1..1]

NumberOfLines [1..1]

LineWidth [1..1]


Phase 2

10/07/2014 version 3.2 65/154


TMAP processing

PrintLineWidth [0..1]

POIComponent [1..1]

Type [1..1] Terminal (“TERM”) for the POI information


ItemNumber [1..1] -

ProviderIdentification [1..1] Terminal: name of the manufacturer

Identification [1..1] Name of the product assigned by the provider

SerialNumber [1..1] Terminal: serial number of the terminal.

If not configured (9F1E absent), set with the hard coded value of the terminal serial number.

Status [0..1]

VersionNumber [0..1]

Status [0..1]

StandardCompliance [0..1]


Version [1..1]

Issuer [1..1]

Characteristics [1..1]

Memory [1..*]


TotalSize [1..1]

FreeSize [1..1]

Unit [1..1]

Communication [1..*]

Communication-Type [1..1]

RemoteParty [1..1]

Active [1..1]

SecurityAccess-Modules [0..1]

Subscriber-Identification-Modules

[0..1]

POIComponent [0..1] The component containing informations about the server is mandatory for an integrated solution

Type [1..1] Server (“SERV”) : mandatory for an integrated solution


ItemNumber [1..1] -

ProviderIdentification [1..1]


SerialNumber [0..1]

Status [0..1]


Status [0..1]



Version [1..1]

Issuer [1..1]



Phase 2

10/07/2014 version 3.2 66/154


TMAP processing

Memory [0..*]


TotalSize [1..1]

FreeSize [1..1]

Unit [1..1]



RemoteParty [1..1]

Active [1..1]



[0..1]

POIComponent [0..*] The component containing informations about the device shall be sent if the POI architecture is composed of devices (e.g. PinPad) connected to a server or to a countertop terminal

Type [1..1] Device (“DVCE”)


ItemNumber [1..1] -



SerialNumber [0..1]

Status [0..1]


Status [0..1]



Version [1..1]

Issuer [1..1]


Memory [0..*]


TotalSize [1..1]

FreeSize [1..1]

Unit [1..1]



RemoteParty [1..1]

Active [1..1]



[0..1]

POIComponent [1..1]

Type [1..1] "APLI": information about the SEPA-FAST payment application.



Phase 2

10/07/2014 version 3.2 67/154


TMAP processing

ItemNumber [0..1] -

ProviderIdentification [1..1] Name of the SEPA-FAST payment application provider


SerialNumber [0..1]

Status [1..1]


Status [0..1]


Identification [1..1] "SEPA-FAST"

Version [1..1] "3.1"

Issuer [1..1] "OSCAR"

Assessment [1..*] At least one occurrence containing the registration number of the OSCar certification shall be set

Type [1..1] "CERT"

Assigner [1..*] "OSCAR"

DeliveryDate [0..1]

ExpirationDate [0..1]

Number [1..1] The registration number of the OSCAR certification could be used here for the functional test.

POIComponent [1..1]

Type [1..1] "APPR": for the current version of the payment application parameters used by the POI.


ItemNumber [0..1] -

ProviderIdentification [1..1] Name of the SEPA-FAST parameters provider, i.e. AcceptorConfiguration.TerminalManagerIdentification.Identification


SerialNumber [0..1]

Status [1..1]

VersionNumber [1..1] Version Number of the parameters

Status [0..1]

POIComponent [1..*] One instance per EMVCo Kernel.

At least one instance of EMVKernel shall be set

Type [1..1] ‘EMVKernel’

Identification [1..1] “L2”, “C-1”, “C-2”, “C-3” or “C-4”

ItemNumber [0..1] -

ProviderIdentification [0..1] Name of the company who implements the Kernel

Identification [1..1] Name of the EMV Application Kernel

SerialNumber [0..1]

Status [1..1]

VersionNumber [1..1] Version of the kernel

Status [0..1]


Identification [1..1] “EMV ICC Specifications”, “EMV Book C-1”, “EMV Book C-2”, “EMV Book C-3”or “EMV Book C-4”

Version [1..1] e.g. “4.3”, “2.3”…


Phase 2

10/07/2014 version 3.2 68/154


TMAP processing

Issuer [1..1]

Assessment [1..*]

Type [1..1] "APPL "

Assigner [1..*] "EMVCo", …

DeliveryDate [0..1]


Number [1..1] Approval number of the kernel

POIComponent [0..*] Additional POIComponent occurrences are allowed

AttendanceContext [1..1] see [CAPE TMS MUG]

POIDateTime [1..1] see [CAPE TMS MUG]

DataSetRequired [0..1] see [CAPE TMS MUG]

For messages exchange it shall be present


Name [0..1]

Type [1..1] “MerchantParameters” and “TerminalParameters” are out of scope of OSCar

Version [0..1]


POIChallenge [0..1] Shall be present for Key download

TMChallenge [0..1] Shall be present for Key download

EncryptedKey [0..1] Shall be present for Key download

ContentType [1..1]

EnvelopedData [1..1]

Event [0..*] see [CAPE TMS MUG]

TimeStamp [1..1]

Result [1..1]

ActionIdentification [1..1]

ActionType [1..1]

DataSetIdentification [0..1]

Name [0..1]

Type [1..1]

Version [0..1] Version of the ManagementPlan or DataSet


AdditionalErrorInformation [0..1]

Errors [0..1]

SecurityTrailer [1..1]

5.5.2 ManagementPlanReplacement

ManagementPlanReplacement Component Mult. SEPA-FAST Data Element (DE)

TMAP processing

Header [1..1] Unknown from SEPA-FAST

see [CAPE TMS MUG]



Phase 2

10/07/2014 version 3.2 69/154


TMAP processing






Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [0..1]

Issuer [0..1]

ShortName [0..1]

ManagementPlan [1..1]

POIIdentification [0..1] Copy from StatusReport


Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [0..1]

Issuer [0..1]

ShortName [0..1]

DataSet [1..*] see [CAPE TMS MUG]


Name [0..1]

Type [1..1]

Version [1..1]



Content [0..1]

Action [1..*] see [CAPE TMS MUG]

Type [1..1]

Address [0..1]

PrimaryAddress [1..1]

PrimaryPortNumber [1..1]

SecondaryAddress [0..1]

SecondaryPortNumber [0..1]

UserName [0..1]

AccessCode [0..1]

ClientCertificate [0..1]


Name [0..1] Has to be set with the name of the template (E0, E1, E2,..,EE) if one template has to be deleted when Type =


Phase 2

10/07/2014 version 3.2 70/154


TMAP processing

"ApplicationParameters".

For templates with multiple entries, all entries are deleted.

if Name = “E6”, all Application Profiles defined in the SEPA-FAST application are deleted.

Type [1..1] see [CAPE TMS MUG], except if Name = "ApplicationProfile"

Version [0..1]


Trigger [1..1] see [CAPE TMS MUG]

AdditionalProcess [0..1] Shall be present if any process has to be performed before or after TMS action.

TimeCondition [1..1] see [CAPE TMS MUG]

WaitingTime [0..1]

StartTime [0..1]

EndTime [0..1]

Period [0..1]

MaximumNumber [0..1]

ReTry [0..1]

Delay [1..1]


TMChallenge [0..1] Absent if key download is not performed by TMS

KeyEncipherment-Certificate [0..*] Absent if key download is not performed by TMS

ErrorAction [0..n]

ActionResult [1..n]

ActionToProcess [1..1]


5.5.3 AcceptorConfigurationUpdate

AcceptorConfigurationUpdate Component Mult. SEPA-FAST Data Element (DE)

TMAP processing

Header [1..1] Unknown from SEPA-FAST

see [CAPE TMS MUG]







Type [0..1]

Issuer [0..1]

ShortName [0..1]


Phase 2

10/07/2014 version 3.2 71/154


TMAP processing



Type [0..1]

Issuer [0..1]

ShortName [0..1]

AcceptorConfiguration [1..1]

POIIdentification [0..1] Copy from StatusReport


Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [0..1]

Issuer [0..1]

ShortName [0..1]

DataSet [1..n] see [CAPE TMS MUG]


Name [0..1]

Type [1..1]

Version [1..1]



Content [1..1] see [CAPE TMS MUG]

AcquirerProtocolParameters [0..*] One instance per AcquirerIdentification

AcquirerIdentification [1..*]

Identification [1..1] Acquirer Number

Parameters may be defined per Acquirer Number

Type [0..1]

Issuer [0..1]

ShortName [0..1]

ApplicationIdentification [1..1] “SEPA-FAST Part 1” sent by TMS only

Host [1..*] One or two host systems are used.

HostIdentification [1..1] Host to be used by HAP for finally selected Acquirer Number

MessageToSend [1..*]

OnlineTransaction [0..1]

FinancialCapture [1..1] Allowed Values : “Batch” or “Completion”or “Authorisation”

BatchTransfer [0..1] see [CAPE TMS MUG]

ExchangePolicy [1..*]


MaximumAmount [0..1]

TimeCondition [0..1]

WaitingTime [0..1]

StartTime [0..1]


Phase 2

10/07/2014 version 3.2 72/154


TMAP processing

EndTime [0..1]

Period [0..1]


ReTry [0..1]

Delay [1..1]


CompletionExchange [0..1] see [CAPE TMS MUG]

ExchangePolicy [1..*] Allowed Values: “IMMD”, “ONDM” or “NONE”




WaitingTime [0..1]

StartTime [0..1]

EndTime [0..1]

Period [0..1]


ReTry [0..1]

Delay3 [1..1]


ExchangeFailed [0..1] Allowed Value: "True"

ExchangeDeclined [0..1] Allowed Value: "True"

CancellationExchange [0..1] Allowed Value: "ADVC"; See section 3

OfflineTransaction [0..1]

FinancialCapture [1..1] Allowed Values : “Batch” or “Completion”

BatchTransfer [0..1] see [CAPE TMS MUG]

ExchangePolicy [1..n]




WaitingTime [0..1]

StartTime [0..1]

EndTime [0..1]

Period [0..1]


ReTry [0..1]

Delay [1..1]


CompletionExchange [0..1] see [CAPE TMS MUG]

ExchangePolicy [1..*] Allowed Values: “IMMD”or “NONE”




WaitingTime [0..1]

StartTime [0..1]


Phase 2

10/07/2014 version 3.2 73/154


TMAP processing

EndTime [0..1]

Period [0..1]


ReTry [0..1]

Delay [1..1]


ExchangeFailed [0..1]

ExchangeDeclined [0..1]

CancellationExchange [0..1] Allowed Value: "ADVC"; See section 3

ReconciliationExchange [1..1] see [CAPE TMS MUG]

ExchangePolicy [1..*]




WaitingTime [0..1]

StartTime [0..1]

EndTime [0..1]

Period [0..1]


ReTry [0..1]

Delay [1..1]


ReconciliationByAcquirer [0..1] HAP supports only the value “False”

TotalsPerCurrency [0..1]

SplitTotals [0..1]

CardDataVerification [0..1]

BatchTransferContent [0..*] see [CAPE TMS MUG]

MessageItem [0..*] see [CAPE TMS MUG]

ItemIdentification [1..1] The element InitiatingParty.Identification is mandatory

Condition [1..1]

Value [1..1]

ProtectCardData [1..1] see [CAPE TMS MUG]

MerchantParameters [0..n]

TerminalParameters [0..n]

ApplicationParameters [0..*] Only one occurrence is allowed

ApplicationIdentification [1..1] “SEPA-FAST Part 1”

Version [1..1]

Parameters [0..*] Only one instance of Parameters will be downloaded. The content of Parameters is described in section 5.4.3.

EncryptedParameters [0..1]

ContentType [1..1]


HostCommunicationParameters [0..*] see [CAPE TMS MUG]

HostIdentification [1..1]

Address [1..1]


Phase 2

10/07/2014 version 3.2 74/154


TMAP processing

PrimaryAddress [1..1]

PrimaryPortNumber [1..1]

SecondaryAddress [0..1]

SecondaryPortNumber [0..1]

UserName [0..1]

AccessCode [0..1]

ClientCertificate [0..1]

Key [0..*]


AdditionalIdentification [0..1]

Version [1..1]

SecurityParameters [0..*]

POIChallenge [0..1]

TMChallenge [0..1]

SymmetricKey [0..*]


AdditionalIdentification [0..1]

Version [1..1]

Type [0..1] Allowed value: "DUKP9"

Function [1..*] "KeyDerivation"

ActivationDate [0..1]

DeactivationDate [0..1]

KeyValue [1..1]

ContentType [1..1]




Phase 2

10/07/2014 version 3.2 75/154

5.5.4 TerminalManagementRejection

TerminalManagementRejection Mult. SEPA-FAST Data Element (DE)

TMAP processing

Header [1..1] see [CAPE TMS MUG]







Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [0..1]

Issuer [0..1]

ShortName [0..1]

Reject [1..1] see [CAPE TMS MUG]

RejectReason [1..1]

AdditionalInformation [0..1]

MessageInError [1..1]

5.5.5 Download of Cryptographic Keys

The section presents the download of the DUKPT Terminal Initial Keys (TIK). These cryptographic keys

are used for:

MAC (Message Authentication Code) of the EPAS Acquirer or the TMS Protocol,

The protection of the cardholder PIN performed by the payment application SEPA-FAST and used

by the Acquirer protocol,

The protection of sensitive data by the payment application SEPA-FAST, the EPAS Acquirer or

the TMS Protocol.

The download of cryptographic keys is specified in the section 6 of the document [CAPE TMS MUG] , with

the specifications of the security mechanism and data structure in the document [EPAS Security].

As specified in the section 6.3 of [CAPE TMS MUG], the download of one or several keys requires the

exchange of 5 messages:

The StatusReport message to send the state of the keys loaded in the POI.


Phase 2

10/07/2014 version 3.2 76/154

The ManagementPlan message to provide the action of downloading the keys and the related

parameters,

The StatusReport message to request and initiate the key exchange,

The ConfigurationUpdate message to send the keys to load by the POI,

The StatusReport message to send the status of the keys loading operation.

Key Status

The first StatusReport message contains an occurrence of the data structure Component with the Type

“SecurityParameters” for each of the DUKPT key of the POI.

The message is protected in the SecurityTrailer:

By a MAC, if the POI already own a symmetric MAC key,

Otherwise by a digital signature.


Phase 2

10/07/2014 version 3.2 77/154

Management Plan with Key Dowload Action

If DUKPT keys have to be loaded, the management plan contains an Action with the Type

“SecurityParameters” and the data elements:

TMChallenge, a Terminal Manager chanllenge, and

KeyEnciphermentCertificate, an encrypting public key of the Terminal Manager.

The message is protected in the SecurityTrailer by the same mechanism as the StatusReport message.

Status Report to Request Key Downloading

To perform the Action with the Type “SecurityParameters”, the POI sends a StatusReport message

containing in addition to the identification of the required data set:

POIChallenge, a POI challenge

TMChallenge, the challenge sent in the related Action,

EncryptedKey, the session keys generated by the POI, and protected by the encrypting public key

of the Terminal Manager sent in the management plan in KeyEnciphermentCertificate.




Configuration Update to Inject Keys

The Terminal Manager sends a ConfigurationUpdate message with the DUKPT to load as specified in the

section 6.3.5 of [CAPE TMS MUG]. For each key to load:

The Type has the value “DUKP9”,

The Function is:

o "MessageAuthenticationCodeGeneration" and "MessageAuthenticationCodeVerification"

for a MAC key,

o “PINEncryption” for a PIN key,

o "DataEncryption" and "DataDecryption" for the protection of sensitive data.


Phase 2

10/07/2014 version 3.2 78/154

The ConfigurationUpdate message contains:

POIChallenge, the challenge sent by the POI in the StatusReport message,

TMChallenge, , a new Terminal Manager chanllenge.

The message is protected in the SecurityTrailer by the same mechanism as the StatusReport

message.

Key Download Result

To report the outcome of the key loading, the POI sends a StatusReport message containing an

occurrence of the data structure Component with the Type “SecurityParameters” for each of the DUKPT

key of the POI with in addtion:

KeyCheckValue, if the key was successfully loaded,

TMChallenge, the challenge sent in the ConfigurationUpdate message,





Phase 2

10/07/2014 version 3.2 79/154

6 HAP Message data elements processing

The EPAS messages needed to cover OSCar's scope are listed below:

AcceptorAuthorisationRequest

AcceptorAuthorisation Response

AcceptorCompletionAdvice

AcceptorCompletionAdviceResponse

AcceptorCancellationAdvice

AcceptorCancellationAdviceResponse

AcceptorReconciliationRequest

AcceptorReconciliationResponse

AcceptorBatchTransfer

AcceptorBatchTransferResponse

AcceptorDiagnosticRequest

AcceptorDiagnosticResponse

AcceptorRejection

The multiplicity column of the tables below is used to indicate if the data element is mandatory or not for

the OSCar project.

All data elements defined as mandatory in [CAPE ACQ MUG] are mandatory for OSCar.

If a data element is conditional, the condition is defined in the column ‘HAP Processing’.

Some data elements defined as conditional or optional in [CAPE ACQ MUG] are mandatory for OSCar.

The column ‘SEPA-FAST data element’ is used to describe which EPAS data element corresponds to

SEPA-FAST data element.

Data elements not required for an OSCar implementation are in grey.

[1..1]: the data element is mandatory, one occurrence is permitted

[1..*]: the data element is mandatory (at least one occurrence shall be present), many occurrences are

permitted

[0..1]: the data element is optional or conditional. The presence condition is defined in the column ‘HAP

Processing’: if the condition is verified it shall be present.


Phase 2

10/07/2014 version 3.2 80/154

6.1 Authorisation Exchange

6.1.1 AcceptorAuthorisationRequest

AcceptorAuthorisationRequest Component Mult. SEPA-FAST Data Element (DE)

HAP processing

MessageFunction [1..1] Unknown from SEPA-FAST

These data elements are handled by HAP.

InitiatingParty.Identification defined by TMS using AcquirerProtocolParameters.MessageItem of the AcceptorConfigurationUpdate message

ProtocolVersion [1..1]

[1..1]





Type [0..1] See [CAPE ACQ MUG]

Issuer [0..1]

ShortName [0..1]

RecipientParty [0..1] See [CAPE ACQ MUG]


Type [0..1]

Issuer [0..1]

ShortName [0..1]

Traceability [0..*]

RelayIdentification [1..1]


Type [1..1]

Issuer [0..1]

ShortName [0..1]

TraceDateTimeIn [1..1]

TraceDateTimeOut [1..1]

AuthorisationRequest [1..1]

Environment [1..1]

Acquirer [1..1]


Identification [1..1] Acquirer Identifier

Type [0..1]

Issuer [0..1]

ShortName [0..1]

ParametersVersion [1..1] Downloaded by TMS handled by HAP

Filled with DataSet.Identification.Version of the TMS message AcceptorConfigurationUpdate

Merchant [1..1]


Identification [1..1] Merchant Identifier

Type [0..1]

Issuer [0..1]

ShortName [0..1]


Phase 2

10/07/2014 version 3.2 81/154


HAP processing

CommonName [1..1] Merchant Name and Location

LocationCategory [0..1] s

Address [0..1]

CountryCode [1..1] Terminal Country Code

SchemeData [0..1] Presence configured by TMS by using AcceptorConfigurationUpdate.AcquirerProtocolParameters.MessageItem

POI [1..1]


Identification [1..1] Terminal Identification

Type [0..1]

Issuer [0..1]

ShortName [0..1] Presence and value configured by TMS by using AcceptorConfigurationUpdate.AcquirerProtocolParameters.MessageItem

SystemName [0..1]

GroupIdentification [0..1]

Capabilities [1..1] Locally configured can be restricted by configuration

CardReadingCapabilities [1..*] Terminal Capabilities

Service Settings[1, 3]

If Terminal Capabilities Byte 1 bit 8 set "Physical"

If Terminal Capabilities Byte 1 bit 7 set "MagneticStripe"

If Terminal Capabilities Byte 1 bit 6 set "ICC"

If Service Settings[1, 3]= 1b set “EMVProximityReader”

CardholderVerificationCapabilities

[0..*] Terminal Capabilities If Terminal Capabilities Byte 2 bit 8 set "OfflinePINClear"

If Terminal Capabilities Byte 2 bit 7 set "OnLinePIN"

If Terminal Capabilities Byte 2 bit 6 set "ManualSignature"

If Terminal Capabilities Byte 2 bit 5 set "OfflinePINEncrypted"

OnlineCapabilities [1..1] Can be obtained from Terminal Type

If Terminal Type in (21,24,34) set "OnLine"

If Terminal Type in (22,25,35) set "SemiOffLine"

If Terminal Type in (23,26,36) set "OffLine"

DisplayCapabilities [0..*] HAP delivers the display capabilities as follows:

DisplayType [1..1] Additional Terminal Capabilities

If Additional Terminal Capabilities Byte 4 bit 6 set "MerchantDisplay"

or

If Additional Terminal Capabilities Byte 4 bit 5 set "CardholderDisplay"

NumberOfLines [1..1] Mandatory if Capabilities is not empty. Local POI configuration

LineWidth [1..1] Mandatory if Capabilities is not empty. Local POI configuration

PrintLineWidth [0..1] Conditional : If POI is able to print receipts

Local POI configuration

Component [1..1]

Type [1..1] Terminal (“TERM”) for the POI information


Phase 2

10/07/2014 version 3.2 82/154


HAP processing


ItemNumber [0..1]

ProviderIdentification [1..1] Terminal: name of the manufacturer


SerialNumber [1..1] Interface Device (IFD) Serial Number if present

Terminal: serial number of the terminal.

If not configured (9F1E absent), set with the hard coded value of the terminal serial number.

Component [1..1]

Type [1..1] PaymentApplication ("APLI") for SEPA-FAST

Identification [1..1] At least one data element (ProviderIdentification or Identification )shall be present to identify the component

ItemNumber [0..1]

ProviderIdentification [0..1] PaymentApplication: name of the SEPA-FAST payment application provider


SerialNumber [0..1]

Status [1..1]

VersionNumber [1..1] PaymentApplication: release number of the payment application. Should be updated in HAP when the payment application is updated.

Status [0..1]

StandardCompliance [1..1] PaymentApplication: should be updated in HAP when SEPA-FAST is updated.

Identification [1..1] "SEPA-FAST"

Version [1..1] "3.1"

Issuer [1..1] "CIR"


Memory [0..*]


TotalSize [1..1]

FreeSize [1..1]

Unit [1..1]


Communication-Type

[1..1]

RemoteParty [1..1]

Active [1..1]

SecurityAccessModules [0..1]

SubscriberIdentification-Modules

[0..1]

Assessment [1..*]

Type [1..1] "CERT"

Assigner [1..*] "OSCAR"

DeliveryDate [0..1]



Phase 2

10/07/2014 version 3.2 83/154


HAP processing

Number [1..1] The registration number of the OSCAR certification could be used here for the functional test.

Component [0..*] Other components could be present

Card [1..1] Configured by TMS per AcquirerID whether card data encrypted or in plain with PlainCardData present.

ProtectedCardData [0..1] Mandatory if ‘PlainCardData’ absent, otherwise absent

ContentType [1..1]


PlainCardData [0..1] Mandatory if ‘ProtectedCardData’ absent, otherwise absent.

PAN [1..1] PAN

CardSequenceNumber [0..1] Application Primary Account Number (PAN) Sequence Number

If available

EffectiveDate [0..1] Application Effective Date

If available

ExpiryDate [1..1] Expiration Date

ServiceCode [0..1] Service Code If available

TrackData [0..1]

TrackNumber [0..1] Element not sent since the default value is used

TrackValue [1..1] Track 2 Equivalent Data or Track 2 Data

Set EPAS DE with SEPA-FAST DE according to CardDataEntryMode

CardSecurityCode [0..1] Application Profile Settings (APS)

Technology Selected

Conditional : if Manual Entry transaction and the CVD Presence is required for Manual Entry processing (Application profile Settings)

CSCManagement [1..1] CVD Presence If CVD Presence = “00” set “CSCByPass”

If CVD Presence = “01” set “CSCPresent”

If CVD Presence = “02” set “CSCUnread”

If CVD Presence = “09” set “NoCSC”

CSCValue [0..1] Present if CSCManagement is set to “CSCPresent”

CardCountryCode [0..1] Issuer Country Code (alpha3 format)

Issuer Country Code (alpha2 format)

Issuer Country Code

Set EPAS DE with SEPA-FAST DE Issuer Country Code (alpha3 format) If available or convert Issuer Country Code (alpha2 format) or

Issuer Country Code to EPAS DE if available

CardProductProfile [1..1] Application Profile Number is selected during transaction processing

Set EPAS DE with SEPA-FAST DE Rightmost digits of CardProductProfile filled with Application Profile Number and padded with 0 on the left (4 digit for EPAS, 2 for SEPA FAST)

CardBrand [0..1] Scheme Identifier Set EPAS DE with SEPA-FAST DE

If available

AdditionalCardData [0..1]

Cardholder [1..1]

Identification [0..*]

CardholderIdentificationValue

[1..1]

CardholderIdentificationType

[1..1]


Phase 2

10/07/2014 version 3.2 84/154


HAP processing

Name [0..1] Cardholder Name / Cardholder Name Extended

Language [1..1] Selected Language

Authentication [0..*] See [CAPE ACQ MUG]

Absent if no Cardholder Verification applies or for EMV noCVM method

AuthenticationMethod [1..1] Part of Cardholder Verification Method (CVM) Results

CVM (on Outcome)

CVM Magnetic Stripe

CVM Manual Entry

See [CAPE ACQ MUG],

Allowed values: “OfflinePIN”, “OnLinePIN”,

“PaperSignature”, “Password:” (if CardDataEntryMode = EMVProximityReader and CVM (on Outcome) = CONFIRMATION

CODE VERIFIED)

AuthenticationEntity [1..1] Obtained from transaction context:

See [CAPE ACQ MUG],

Set “ICC” if AuthenticationMethod = " Password”

AuthenticationValue [0..1]

CardholderOnlinePIN [0..1] Shall be present if authenticationMethod is “OnlinePIN”, otherwise absent

EncryptedPINBlock [1..1] Enciphered PIN DATA Build ISO0 formatted PIN block

ContentType [1..1]


PINFormat [1..1] Set value ISO0

AdditionalInput [0..1]

AuthenticationCollectionIndicator

[0..1]

AddressVerification [0..1]

AddressDigits [0..1]

PostalCodeDigits [0..1]

PersonalData [0..1]

Context [1..1]

PaymentContext [1..1]

CardPresent [0..1] Technology Selected Element not sent if the default value is used. For Manual Entry transactions, it has to be set to false

CardholderPresent [0..1] Element not sent since the default value is used

OnLineContext [0..1]

AttendanceContext [1..1] Can be obtained from Terminal Type

If TT in (21,22, 23) set "Attended"

If TT in (24,25,26,34,35,36) set "Unattended"

TransactionEnvironment [0..1]

TransactionChannel [0..1]

AttendantMessageCapable [0..1] Local POI configuration

AttendantLanguage [0..1]

CardDataEntryMode [1..1] Technology Selected Set EPAS DE to "ICC" if SEPA-FAST DE Technology Selected = "EMV CHIP"

Set EPAS DE to " MagneticStripe " if SEPA-FAST DE Technology Selected = "MAGNETIC STRIPE " or "FALLBACK"

Set EPAS DE to " Physical " if SEPA-FAST DE Technology Selected = "MANUAL ENTRY "


Phase 2

10/07/2014 version 3.2 85/154


HAP processing

Set EPAS DE to " EMVProximityReader " if SEPA-FAST DE Technology Selected = "CONTACTLESS "

Set EPAS DE to "ICC" if Chip Fallback is performed according to section 10.3

FallbackIndicator [0..1] Technology Selected Set EPAS DE to "True" if SEPA-FAST DE Technology Selected = "FALLBACK" or if Chip Fallback is performed according to section 10.3

SaleContext [0..1] See [CAPE ACQ MUG]

SaleIdentification [0..1]

SaleReferenceNumber [0..1]

SaleReconciliationIdentification [0..1]

CashierIdentification [0..1]

ShiftNumber [0..1]

AdditionalSaleData [0..1]

Transaction [1..1]

TransactionCapture [1..1] Set value according to TMS message AcceptorConfigurationUpdate element OnlineTransaction.FinancialCapture

TransactionType [1..1] Selected Service

Cashback Amount

Transaction Type

If Selected Service = '01' (PAYMENT) and Cashback Amount = "0" set "CardPayment"

If Selected Service = '01' (PAYMENT) and Cashback Amount <> 0 set "CashBack""

If Selected Service = '02' (REFUND) set "Refund"

If SelectedService = ‘08’ (DEFERRED

PAYMENT) set “DeferredPayment”

AdditionalService [0..*] Selected Service

Supplementary Amount

Conditional.

Set to "Gratuity" if Selected service = ‘01’ (PAYMENT) and Supplementary Amount <> 0

ServiceAttribute [0..1]

MerchantCategoryCode [1..1] Merchant Category Code

TransactionIdentification [1..1]

TransactionDateTime [1..1] Transaction Date

Transaction Time

The local time format is used. Fractions of second in time format not significant if present.

TransactionReference [1..1] Transaction Sequence Counter

OriginalTransaction [0..1] Mandatory for update pre-authorisation

TransactionIdentification [1..1] Data elements are obtained from the previous stored transaction

TransactionDateTime [1..1]

TransactionReference [1..1]



Type [0..1]

Issuer [0..1]


Phase 2

10/07/2014 version 3.2 86/154


HAP processing

ShortName 6.1.2 [0..1]

InitiatorTransactionIdentification [0..1]

RecipientTransactionIdentification [0..1]

TransactionType [1..1]

AdditionalService [0..*]


TransactionResult [0..1] Obtained from the original authorisation response message

AuthorisationEntity [0..1]


Type [1..1]

Issuer [0..1]

ShortName [0..1]

ResponseToAuthorisation [1..1]

Response [1..1]

ResponseReason [0..1]

AuthorisationCode [0..1]


ReconciliationIdentification [0..1] Reconciliation Period Identification assigned by the POI, absent if the capture is performed by batch

TransactionDetails [1..1]

Currency [1..1] Terminal Transaction Currency Code - Alpha3

TotalAmount [1..1] Transaction Amount

AmountQualifier [0..1] Selected Service If Selected Service = ‘Deferred Payment’ set to ‘Maximum’

Otherwise set to ‘Actual’ or absent

DetailedAmount [0..*] Present if Cashback (Transaction Type = '09' )or Increased Amount (Transaction Type = '00' and Supplementary Amount <>0)

Type [1..1] Selected Service

Transaction TypeSupplementary Amount

If Selected Service = '01' (PAYMENT) and Transaction Type <> '09' (Cashback) and Supplementary Amount <>0:

Set Type = GRTY

Set Value = Supplementary Amount

If Selected Service = '01' (PAYMENT) and Transaction Type = '09' (Cashback)

Set Type = CSHB

Set Value = Cashback Amount

Value [1..1] Cashback Amount Supplementary Amount

ValidityDate [0..1] Pre-Authorisation Number of Days

(pre-authorisation only)

ValidityDate = Transaction Date + Pre-Authorisation Number of Days

Change request to EPAS

OnLineReason [0..1] Conditional.

The following values are used:

"MerchantForced" if TVR Byte 4 bit 4 is set for chip and "FloorLimit" for magnetic stripe or manual entry transactions


Phase 2

10/07/2014 version 3.2 87/154


HAP processing

otherwise not present

UnattendedLevelCategory [0..1]

AccountType [0..1] Element not sent since the default value is used

RecurringTransaction [0..1]

SequenceNumber [1..1]

PeriodUnit [1..1]

InstalmentPeriod [1..1]

TotalNumberOfPayments [1..1]

InterestCharges [0..1]

Product [0..*]

ProductCode [1..1]

UnitOfMeasure [0..1]

ProductQuantity [0..1]

UnitPrice [0..1]

ProductAmount [1..1]

TaxType [0..1]

AdditionalProductInformation [0..1]

ICCRelatedData [0..1] Absent for MagStripe and Manual Entry transactions, otherwise present.

AdditionalTransactionData [0..1]

SecurityTrailer [1..1] Calculate by HAP

6.1.3 AcceptorAuthorisationResponse

AcceptorAuthorisationResponse Component Mult. SEPA-FAST Data Element (DE)

HAP processing

Header [1..1] These data elements are handled by HAP

MessageFunction [1..1]






Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [1..1]

Issuer [0..1]

ShortName [0..1]

Traceability [0..*]



Phase 2

10/07/2014 version 3.2 88/154


HAP processing


Type [1..1]

Issuer [0..1]

ShortName [0..1]



AuthorisationResponse [1..1]

Environment [1..1]

AcquirerIdentification [0..1] Optional

When present HAP shall verify that this component remains unchanged between the request message and the response message


Type [0..1]

Issuer [0..1]

ShortName [0..1]

MerchantIdentification [0..1]

Identification [1..1] When present HAP shall verify that this component remains unchanged between the request message and the response message

Type [0..1]

Issuer [0..1]

ShortName [0..1]


Identification [1..1] HAP shall verify that this component remains unchanged between the request message and the response message

Type [0..1]

Issuer [0..1]

ShortName [0..1]

ProtectedCardData [0..1] Optional regardless the value of CardDataVerification

ContentType [1..1]


PlainCardData [0..1] Optional regardless the value of CardDataVerification

PAN [1..1] When present HAP shall verify that these components remain unchanged between the request message and the response message

CardSequenceNumber [0..1]

EffectiveDate [0..1]

ExpiryDate [1..1]

Transaction [1..1]


TransactionDateTime [1..1] HAP shall verify that these components remain unchanged between the request message and the response message


RecipientTransactionIdentification [0..1] Optional

If present this data element shall be stored by HAP and shall be returned in the message for capture


Phase 2

10/07/2014 version 3.2 89/154


HAP processing

ReconciliationIdentification [0..1] Optional

HAP shall verify that this component remains unchanged between the request message and the response message

InterchangeData [0..1] Optional

If present this data element shall be stored by HAP and shall be returned in the message for capture


Currency [1..1] HAP shall verify that this component remains unchanged between the request message and the response message

TotalAmount [1..1] Transaction Amount

DetailedAmount [0..*]

Type [1..1] Cashback Amount Supplementary Amount

When present HAP shall verify that these components remain unchanged between the request message and the response message


If TransactionType = ‘CashBack’ and Response = ‘PartialApproved’ set Value to 0



When present HAP shall verify that this component remains unchanged between the request message and the response message


ICCRelatedData [0..1] Issuer Authentication Data (IATD)

Issuer Script Template 1

Issuer Script Template 2

Authorisation Response Code (ARC)

Mandatory for EMV contact Chip transactions.

Present if available for contactless transactions.

HAP fills SEPA-FAST data elements with the TLV data elements contained in ICCRelatedData

TransactionResponse [1..1]

AuthorisationResult [1..1]

AuthorisationEntity [0..1] Theses data elements shall be stored by HAP and shall be returned in the Completion and in OriginalTransaction data element when required by EPAS.


Type [1..1]

Issuer [0..1]

ShortName [0..1]


Response [1..1] Transaction Result Set SEPA-FAST DE with EPAS DE This data element shall be stored by HAP and shall be returned in the Completion and in OriginalTransaction data element when required by EPAS.


AuthorisationCode [0..1] Authorisation Code This data element shall be stored by HAP and shall be returned in OriginalTransaction data element when required by EPAS. The length of the Authorisation Code has to be equal to Authorisation Code otherwise an error occurs.


Phase 2

10/07/2014 version 3.2 90/154


HAP processing

This DE is absent if AuthorisationToAuthorisation.Response<>”Approved” and <> “PartialApproved”

Set SEPA-FAST DE with EPAS DE

CompletionRequired [0..1] This data element shall be stored and handled by HAP

TMSTrigger [0..1] These data elements are handled by EPAS

TMSContactLevel [1..1]

TMSIdentification [0..1]

TMSContactDateTime [0..1]

TransactionVerificationResult [0..1] Out of part 1scope

ElectronicCommerceAuthenticationResult

[0..1]

CSCResult [0..1]

CardholderAddressVerificationResult

[0..1]

DeclinedProductCode [0..*]

Balance [0..1]

Currency [0..1]

Action [0..*] Transaction Result Set SEPA-FAST DE with EPAS DE

ActionType [1..1] See section 4.2

MessageToPresent [0..1]

MessageDestination [1..1]

MessageContent [1..1] Decline Display Message HAP influences display messages and receipt footer

MessageContentSignature [0..1]

SecurityTrailer [1..1] These data elements are handled by HAP


Phase 2

10/07/2014 version 3.2 91/154

6.2 Completion Exchange

6.2.1 AcceptorCompletionAdvice

AcceptorCompletionAdvice Component Mult. SEPA-FAST Data Element (DE)

HAP processing

Header [1..1] see AcceptorAuthorisationRequest




RetransmissionCounter [0..1] Shall be present with a value different than ‘0’ if the message is retransmitted




Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [1..1]

Issuer [0..1]

ShortName [0..1]

Traceability [0..*]



Type [1..1]

Issuer [0..1]

ShortName [0..1]



CompletionAdvice [1..1]

Environment [1..1]

Acquirer [1..1]


Identification [1..1] Acquirer Identifier

Type [0..1]

Issuer [0..1]

ShortName [0..1]

ParametersVersion [1..1] see AcceptorAuthorisationRequest

Merchant [1..1] see AcceptorAuthorisationRequest to set data elements



Type [0..1]

Issuer [0..1]

ShortName [0..1]

CommonName [1..1]


Phase 2

10/07/2014 version 3.2 92/154


HAP processing

LocationCategory [0..1]

Address [0..1]

CountryCode [1..1]

SchemeData [0..1]

POI [1..1]


Identification [1..1] Terminal Identification

Type [0..1]

Issuer [0..1]

ShortName [0..1]

SystemName [0..1]


Capabilities [1..1] see AcceptorAuthorisationRequest




DisplayCapabilities [0..*]

DisplayType [1..1]


LineWidth [1..1]


Component [2..*] see AcceptorAuthorisationRequest

Card [1..1]

ProtectedCardData [0..1] See [CAPE ACQ MUG]

ContentType [1..1]


PlainCardData [0..1] See [CAPE ACQ MUG]

PAN [1..1] PAN

CardSequenceNumber

[0..1] Application Primary Account Number (PAN) Sequence Number


ExpiryDate [1..1] Expiration Date

ServiceCode [0..1] Service Code

TrackData [0..0] Absent in completions


TrackValue [1..1] Track 2 Equivalent Data Set EPAS DE with SEPA-FAST DE

CardCountryCode [0..1] Issuer Country Code see AcceptorAuthorisationRequest

CardProductProfile [1..1] Application Profile Number is selected during transaction processing

see AcceptorAuthorisationRequest

CardBrand [0..1] see AcceptorAuthorisationRequest


Cardholder [0..1]


CardholderIdentificationValue [1..1]

CardholderIdentificationType [1..1]


Phase 2

10/07/2014 version 3.2 93/154


HAP processing

Name [0..1]

Authentication [0..*] see AcceptorAuthorisationRequest

AuthenticationMethod [1..1] see AcceptorAuthorisationRequest

AuthenticationEntity [1..1] see AcceptorAuthorisationRequest




PersonalData [0..1]

Context [1..1]


CardPresent [0..1] see AcceptorAuthorisationRequest

CardholderPresent [0..1] see AcceptorAuthorisationRequest

OnLineContext [0..1] See [CAPE ACQ MUG]

AttendanceContext [1..1] see AcceptorAuthorisationRequest



CardDataEntryMode [1..1] see AcceptorAuthorisationRequest

FallbackIndicator [0..1] see AcceptorAuthorisationRequest

SaleContext [0..1] see AcceptorAuthorisationRequest





ShiftNumber [0..1]


Transaction [1..1]

TransactionCapture [0..1] See [CAPE ACQ MUG]

TransactionType [1..1] see AcceptorAuthorisationRequest

AdditionalService [0..*] See [CAPE ACQ MUG]


MerchantCategoryCode [1..1] see AcceptorAuthorisationRequest


TransactionDateTime [1..1] see AcceptorAuthorisationRequest

TransactionReference [1..1] see AcceptorAuthorisationRequest

OriginalTransaction [0..1]






TransactionResult [0..1]



Type [1..1]

Issuer [0..1]

ShortName [0..1]



Phase 2

10/07/2014 version 3.2 94/154


HAP processing

Response [1..1]



TransactionSuccess [1..1] If Transaction Result APPROVED ('00') set TransactionSuccess= True

If Transaction Result in DECLINED

('01') or ABORTED ('02') set TransactionSuccess= False

Reversal [0..1] See [CAPE ACQ MUG]

HAP defines the contents of this element:

See section 4.4

MerchantOverride [0..1] See [CAPE ACQ MUG]

HAP sets this indicator if Merchant authentication has been performed according to the functionality "Forcing Transaction Acceptance" of [SEPA-FAST]

FailureReason [0..*] Presence according to [CAPE ACQ MUG]

If NOK Reason in (CANCELLED, CARD MISSING, NO CARD INSERTED , NOT ACCEPTED, TIME OUT) Then FailureReason = "Customer Cancel"

According to the result of message exchanges HAP may set the following values :

"TooLateResponse", "UnableToSend", "TimeOut", "OnlineDeclined"

If no previous FailureReason was set then set FailureReason = "UnableToComplete"


RecipientTransactionIdentification [0..1] Copy from Authorisation Response

ReconciliationIdentification [0..1] See Authorisation Request

InterchangeData [0..1] Copy from Authorisation Response



HAP fills message element using transaction log (Currency of the AuthorisationResponse respectively Transaction Currency Code retrieved from the Transaction Data Storage for the Offline transaction)

TotalAmount [1..1] HAP fills message element using transaction log (TotalAmount of AuthorisationResponse respectively Transaction Amount retrieved from the Transaction Data Storage for the Offline transaction)

AmountQualifier [0..1]

DetailedAmount [0..*] See Authorisation Request

Type [1..1] Selected Service

Transaction Type

Supplementary Amount


Phase 2

10/07/2014 version 3.2 95/154


HAP processing


Label [0..1]








PeriodUnit [1..1]




Product [0..*]

ProductCode [1..1]



UnitPrice [0..1]


TaxType [0..1]


ICCRelatedData [0..1] For EMV Chip transactions, HAP fills ICCRelatedData (see section 4.4)

AuthorisationResult [0..1] Conditional.

Present and Obtained from the previous authorisation response message if any. For VOICE AUTHORISATION the Authorisation Code is obtained from a Call Center.



Type [1..1]

Issuer [0..1]

ShortName [0..1]


Response [1..1] Transaction Result


AuthorisationCode [0..1] Authorisation Code

TransactionVerificationResult [0..1]

ElectronicCommerceAuthenticationResult

[0..1]

CSCResult [0..1]

CardholderAddressVerificationResult

[0..1]


SecurityTrailer [1..1] This data element is handled by HAP


Phase 2

10/07/2014 version 3.2 96/154

6.2.2 AcceptorCompletionAdviceResponse

AcceptorCompletionAdviceResponse Component

Mult. SEPA-FAST Data Element (DE)

HAP processing

Header [1..1] see AcceptorAuthorisationResponse




RetransmissionCounter [0..1] (See [CAPE ACQ MUG])




Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [1..1]

Issuer [0..1]

ShortName [0..1]

Traceability [0..*]



Type [1..1]

Issuer [0..1]

ShortName [0..1]



CompletionAdviceResponse [1..1]

Environment [1..1] See [CAPE ACQ MUG]

AcquirerIdentification [0..1] Optional


Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [0..1]

Issuer [0..1]

ShortName [0..1]

ProtectedCardData [0..1] Optional regardless the value of CardDataVerification


Phase 2

10/07/2014 version 3.2 97/154

AcceptorCompletionAdviceResponse Component


HAP processing

ContentType [1..1]


PlainCardData [0..1] Optional regardless the value of CardDataVerification

PAN [1..1]



ExpiryDate [1..1]

Transaction [1..1]


TransactionDateTime [1..1] HAP shall verify that these components remain unchanged between the request message and the response message


ReconciliationIdentification [0..1] see AcceptorAuthorisationResponse

Response [1..1]

TMSTrigger [0..1]






Phase 2

10/07/2014 version 3.2 98/154

6.3 Cancellation Exchange

6.3.1 AcceptorCancellationAdvice

AcceptorCancellationAdvice Component Mult. SEPA-FAST Data Element (DE)

HAP processing

Header [1..1] see AcceptorCompletionAdvice




RetransmissionCounter [0..1] Shall be present with a value different than ‘0’ if the message is retransmitted




Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [1..1]

Issuer [0..1]

ShortName [0..1]

Traceability [0..*]



Type [1..1]

Issuer [0..1]

ShortName [0..1]



CancellationAdvice [1..1]

Environment [1..1]

Acquirer [1..1] Copy from Original transaction if Technology Selected = NONE


Identification [1..1] see AcceptorAuthorisationRequest

Type [0..1]

Issuer [0..1]

ShortName [0..1]

ParametersVersion [1..1] see AcceptorAuthorisationRequest

Merchant [1..1] Copy from Original transaction if Technology Selected = NONE



Type [0..1]

Issuer [0..1]

ShortName [0..1]

CommonName [1..1] see AcceptorAuthorisationRequest


Phase 2

10/07/2014 version 3.2 99/154


HAP processing


Address [0..1]

CountryCode [1..1] see AcceptorAuthorisationRequest

SchemeData [0..1]

POI [1..1] Copy from Original transaction if Technology Selected = NONE



Type [0..1]

Issuer [0..1]

ShortName [0..1]

SystemName [0..1]


Capabilities [0..1]

Component [0..1]

Card [1..1] Copy from Original transaction if Technology Selected = NONE

ProtectedCardData [0..1] see AcceptorAuthorisationRequest

ContentType [1..1]


PlainCardData [0..1]

PAN [1..1] see AcceptorAuthorisationRequest

CardSequenceNumber [0..1] see AcceptorAuthorisationRequest

EffectiveDate [0..1] see AcceptorAuthorisationRequest

ExpiryDate [1..1] see AcceptorAuthorisationRequest

ServiceCode [0..1] see AcceptorAuthorisationRequest

TrackData [0..*]


TrackValue [1..1] Track 2 Equivalent Data

CardCountryCode [0..1] see AcceptorAuthorisationRequest

CardProductProfile [1..1] see AcceptorAuthorisationRequest

CardBrand [0..1] see AcceptorAuthorisationRequest


Cardholder [0..1]

Context [1..1] see AcceptorAuthorisationRequest


CardPresent [0..1] See [CAPE ACQ MUG]

CardholderPresent [0..1]

OnLineContext [1..1] Set to ‘False’

AttendanceContext [1..1] see AcceptorAuthorisationRequest



CardDataEntryMode [1..1] see AcceptorAuthorisationRequest

AccountData if Technology Selected = NONE

FallbackIndicator [0..1] see AcceptorAuthorisationRequest


Phase 2

10/07/2014 version 3.2 100/154


HAP processing

SaleContext [0..1] SaleIdentification [0..1] SaleReferenceNumber [0..1] SaleReconciliation- Identification

[0..1]

CashierIdentification [0..1] ShiftNumberer [0..1] AdditionalSaleData [0..1] Transaction [1..1]

TransactionCapture [1..1]

MerchantCategoryCode [1..1] see AcceptorAuthorisationRequest

Copy from Original transaction if Technology Selected = NONE

TransactionIdentification [1..1] Identification of the cancellation transaction assigned by the POI. This identification shall be different from the original transaction to cancel.


Transaction Time


OriginalTransaction [1..1] Identification of the original payment or refund transaction. This identification is obtained from the transaction log or entered by the merchant.






Type [0..1]

Issuer [0..1]

ShortName [0..1]

InitiatorTransaction- Identification

[0..1]

RecipientTransaction- Identification

[0..1]

TransactionType [1..1] See [CAPE ACQ MUG]

AdditionalSevice [0..*] see AcceptorAuthorisationRequest



AuthorisationEntity [0..1] AuthorisationEntity which has approved the transaction to cancel.

see AcceptorAuthorisationResponse


Type [1..1]

Issuer [0..1]

ShortName [0..1]

ResponseTo-Authorisation

[1..1] ResponseToAuthorisation of the transaction to cancel.



Phase 2

10/07/2014 version 3.2 101/154


HAP processing

Response [1..1]


AuthorisationCode [0..1] AuthorisationCode of the transaction to cancel.


TransactionSuccess [1..1]

Reversal [0..1] Absent

Default value (False)is used

FailureReason [0..*] Absent


ReconciliationIdentification [0..1] see AcceptorAuthorisationRequest

InterchangeData [0..1]


Currency [1..1] HAP fills message element using transaction log (Currency of the AuthorisationResponse)

TotalAmount [1..1] HAP fills message element using transaction log (TotalAmount of AuthorisationResponse)




ICCRelatedData [0..1] For EMV Chip transactions, HAP fills ICCRelatedData (see action 20 in chapter 4.4)

AuthorisationResult [0..1] Absent

AuthorisationEntity [0..1] see AcceptorCancellationResponse


Type [1..1]

Issuer [0..1]

ShortName [0..1]


Response [1..1]



AdditionalTransactionData [0..1] Handled by HAP



Phase 2

10/07/2014 version 3.2 102/154

6.3.2 AcceptorCancellationAdviceResponse

AcceptorCancellationAdviceResponse Component


HAP processing

Header [1..1] see AcceptorAuthorisationResponse







Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [1..1]

Issuer [0..1]

ShortName [0..1]

Traceability [0..*]



Type [1..1]

Issuer [0..1]

ShortName [0..1]



AcceptorCancellationAdviceResponse [1..1] Message Component name to be changed.

Environment [1..1]

AcquirerIdentification [0..1] When present HAP shall verify that this component remains unchanged between the request message and the response message


Type [0..1] Element not sent since the default value is used

Issuer [0..1]

ShortName [0..1]

MerchantIdentification [0..1] When present HAP shall verify that this component remains unchanged between the request message and the response message



Issuer [0..1]

ShortName [0..1]

POIIdentification [1..1] HAP shall verify that this component remains unchanged between the request message and the response message


Phase 2

10/07/2014 version 3.2 103/154

AcceptorCancellationAdviceResponse Component


HAP processing


Type [0..1]

Issuer [0..1]

ShortName [0..1]

ProtectedCardData [0..1] Not present in responses

PlainCardData [0..1] Not present in responses

PAN [1..1] PAN When present HAP shall verify that these components remain unchanged between the request message and the response message

CardSequenceNumber [0..1] Application Primary Account Number (PAN) Sequence Number

EffectiveDate [0..1] Application Effective Date

ExpiryDate [1..1] Expiration

Transaction [1..1]

TransactionIdentification [1..1] HAP shall verify that these components remain unchanged between the request message and the response message


Transaction Time


ReconciliationIdentification [0..1]

Response [1..1]

TMSTrigger [0..1]




SecurityTrailer [1..1] Handled by HAP


Phase 2

10/07/2014 version 3.2 104/154

6.4 Batch Transfer

6.4.1 AcceptorBatchTransfer

AcceptorBatchTransfer Component Mult. SEPA-FAST Data Element (DE)

HAP processing


See [CAPE ACQ MUG]







Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [1..1]

Issuer [0..1]

ShortName [0..1]

BatchTransfer [1..1]

TransactionTotals [0..*] See [CAPE ACQ MUG]

POIGroupIdentification [0..1] Present if configured by TMS (SplitTotals is set to “True” ) and if GroupIdentification is present in the Authorisation Request and/or the Completion Advice

CardProductProfile [0..1] Present if configured by TMS (SplitTotals is set to “True” )

Currency [0..1] Present if configured by TMS (TotalsPerCurrency is set to “True” )

Type [1..1]

TotalNumber [1..1]

CumulativeAmount [1..1]

DataSet [1..*] See [CAPE ACQ MUG]


Name [1..1]

Type [1..1]

Version [0..1]


Traceability [0..*]



Type [1..1]

Issuer [0..1]


Phase 2

10/07/2014 version 3.2 105/154


HAP processing

ShortName [0..1]



DataSetInitiator [0..1] See [CAPE ACQ MUG]


Type [0..1]

Issuer [0..1]

ShortName [0..1]

TransactionTotals [1..*] See [CAPE ACQ MUG]

POIGroupIdentification [0..1] Present if configured by TMS (SplitTotals is set to “True” )



Present if configured by TMS (TotalsPerCurrency is set to “True” )

Type [1..1]

TotalNumber [1..1]


CommonData [0..1] See AcceptorAuthorisationRequest to set EPAS data elements with SEPA-FAST data elements.

The structure of CommonData is described in [CAPE ACQ MUG]

Its usage is optional

Transaction [1..*]

{Or Completion [0..1]

TransactionSequenceCounter [1..1] This data element is handled by HAP according to [CAPE ACQ MUG]

Traceability [0..*]



Type [1..1]

Issuer [0..1]

ShortName [0..1]



Environment [1..1]

Acquirer [0..1] Mandatory if absent from Common Data

See AcceptorAuthorisationRequest



Type [0..1]

Issuer [0..1]

ShortName [0..1]

ParametersVersion [1..1]

Merchant [0..1] Mandatory if absent from Common Data



Phase 2

10/07/2014 version 3.2 106/154


HAP processing




Issuer [0..1]

ShortName [0..1]

CommonName [1..1]


Address [0..1]

CountryCode [1..1]

SchemeData [0..1]

POI [0..1] Mandatory if absent from Common Data

See AcceptorAuthorisationRequest



Type [0..1]

Issuer [0..1]

ShortName [0..1]

SystemName [0..1]


Capabilities [1..1]


CardholderVerification Capabilities [1..*]



DisplayType [1..1]


LineWidth [1..1]


Component [2..*] see AcceptorAuthorisationRequest

Card [1..1] See AcceptorAuthorisationRequest

ProtectedCardData [0..1]

ContentType [1..1]



PAN [1..1]



ExpiryDate [1..1]

ServiceCode [0..1]

TrackData [0..0] TrackData not sent for capture to meet data security standards.


TrackValue [1..1] Track 2 Equivalent Data

Chip card only

Set EPAS DE with SEPA-FAST DE

CardCountryCode [0..1]


Phase 2

10/07/2014 version 3.2 107/154


HAP processing

CardProductProfile [1..1]

CardBrand [0..1]


Cardholder [0..1]




Name [0..1] Cardholder Name / Cardholder Name Extended

Authentication [0..*] See AcceptorAuthorisationRequest

AuthenticationMethod [1..1]

AuthenticationEntity [1..1]




PersonalData [0..1]

Context [0..1] Mandatory if absent from Common Data

PaymentContext [1..1] See AcceptorAuthorisationRequest

CardPresent [0..1]


6.4.2

OnLineContext [0..1]

AttendanceContext [1..1]



CardDataEntryMode [1..1]

FallbackIndicator [0..1]

SaleContext [0..1] see AcceptorAuthorisationRequest





ShiftNumberer [0..1]


Transaction [1..1] see AcceptorAuthorisationRequest

TransactionType [0..1] Mandatory if absent from Common Data


AdditionalService [0..*] See AcceptorCompletionAdvice


MerchantCategoryCode [0..1] Mandatory if absent from Common Data


TransactionIdentification [1..1] see AcceptorAuthorisationRequest




Phase 2

10/07/2014 version 3.2 108/154


HAP processing

OriginalTransaction [0..1]









Type [1..1]

Issuer [0..1]

ShortName [0..1]


Response [1..1]



TransactionSuccess [1..1] If Transaction Result APPROVED ('00') set TransactionSuccess= True

If Transaction Result in DECLINED

('01') or ABORTED ('02') set TransactionSuccess= False

See section 5.5.3: AcquirerProtocolParameters.BatchTransferContent

Reversal [0..1] See AcceptorCompletionAdvice

MerchantOverride [0..1] See AcceptorCompletionAdvice

FailureReason [0..*] See AcceptorCompletionAdvice


RecipientTransactionIdentification [0..1] See AcceptorCompletionAdvice

ReconciliationIdentification [0..1] See Authorisation Request

InterchangeData [0..1] See AcceptorCompletionAdvice


Currency [0..1] See AcceptorCompletionAdvice

TotalAmount [1..1] See AcceptorCompletionAdvice

AmountQualifier [0..1] Element not sent since the default value is used

DetailedAmount [0..*] See AcceptorCompletionAdvice

Type [1..1]

Value [1..1]




Change request to EPAS





PeriodUnit [1..1]



Phase 2

10/07/2014 version 3.2 109/154


HAP processing



Product [0..*]

ProductCode [1..1]



UnitPrice [0..1]


TaxType [0..1]


ICCRelatedData [0..1] See AcceptorCompletionAdvice

AuthorisationResult [0..1] See AcceptorCompletionAdvice



Type [1..1]

Issuer [0..1]

ShortName [0..1]


Response [1..1]



TransactionVerificationResult [0..1]

ElectronicCommerceAuthentication-Result

[0..1]

CSCResult [0..1]

CardholderAddressVerificationResult [0..1]


Or Cancellation [0..1] see AcceptorCancellationAdvice

TransactionSequenceCounter [1..1]

Traceability [0..*]



Type [1..1]

Issuer [0..1]

ShortName [0..1]



Environment [1..1]

Acquirer [0..1] Mandatory if absent from Common Data



Type [0..1]

Issuer [0..1]

ShortName [0..1]

ParametersVersion [1..1]

Merchant [0..1] Mandatory if absent from Common Data


Phase 2

10/07/2014 version 3.2 110/154


HAP processing



Type [0..1]

Issuer [0..1]

ShortName [0..1]

CommonName [1..1]

LocationCategory [0..1] Scheme identifier

Address [0..1]

CountryCode [1..1]

SchemeData [0..1]

POI [0..1] Mandatory if absent from Common Data



Type [0..1]

Issuer [0..1]

ShortName [0..1]

SystemName [0..1]

GroupIdentifier [0..1]

Capabilities [0..1]



OnLineCapabilities [0..1]


DisplayType [1..1]


LineWidth [1..1]


Component [0..*]

Type [1..1]


ItemNumber [0..1]



SerialNumber [0..1]

Status [0..1]


Status [0..1]

StandardCompliance [0..*]


Version [1..1]


Memory [0..*]


TotalSize [1..1]

FreeSize [1..1]

Unit [1..1]


Phase 2

10/07/2014 version 3.2 111/154


HAP processing


CommunicationType [1..1]

RemoteParty [1..1]

Active [1..1]

SecurityAccessModules [0..1]

SubscriberIdentityModules [0..1]

KeyCheckValue [0..1]

Assessment [0..*]

Type [1..1]

Assigner [1..*]

DeliveryDate [0..1]


Number [1..1]

Card [1..1]


ContentType [1..1]



PAN [1..1]



ExpiryDate [1..1]

ServiceCode [0..1]

TrackData [0..*]

TrackNumber [0..1]

TrackValue [1..1]

CardCountryCode [0..1]


CardBrand [0..1]


Cardholder [0..1]




Name [0..1]

Authentication [0..*]

AuthenticationMethod [1..1]

AuthenticationEntity [1..1]




PersonalData [0..1]

Context [0..1] Mandatory if absent from Common Data


CardPresent [0..1]



Phase 2

10/07/2014 version 3.2 112/154


HAP processing

OnlineContext [1..1] Set to ‘False’

AttendanceContext [1..1]



AttendantMessageCapable [0..1]

AttendantLanguage [0..1]

CardDataEntryMode [1..1]

FallbackIndicator [0..1]

SaleContext [0..1]





ShiftNumber [0..1]


Transaction [1..1]

MerchantCategoryCode [0..1] Mandatory if absent from Common Data




OriginalTransaction [0..1] Absent if TransactionSuccess = False






Type [0..1]

Issuer [0..1]

ShortName [0..1]



TransactionType [1..1]

AdditionalService [0..*]





Type [1..1]

Issuer [0..1]

ShortName [0..1]


Response [1..1]



TransactionSuccess [1..1] Transaction Result


Phase 2

10/07/2014 version 3.2 113/154


HAP processing

Reversal [0..1] Absent

FailureReason [0..*] Absent



InterchangeData [0..1]


Currency [0..1] Mandatory if absent from Common Data

TotalAmount [1..1]

ValidityDate [0..1]

ICCRelatedData [0..1]

AuthorisationResult [0..1] Absent



Type [1..1]

Issuer [0..1]

ShortName [0..1]


Response [1..1]



TMSTrigger [0..1]




AdditionalTransactionData [0..*]

Or AuthorisationRequest [0..1] Out of scope



Phase 2

10/07/2014 version 3.2 114/154

6.4.3 AcceptorBatchTransferResponse

AcceptorBatchTransferResponse Component

Mult. SEPA-FAST Data Element (DE) HAP processing








Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [1..1]

Issuer [0..1]

ShortName [0..1]

BatchTransferResponse [1..1]

TransactionTotals [1..*]

POIGroupIdentification [0..1]


Currency [0..1]

Type [1..1]

TotalNumber [1..1]


DataSet [0..*] These data elements are handled by HAP according to [CAPE ACQ MUG]


Name [1..1]

Type [1..1]

Version [0..1]


DataSetResult [1..1] These data elements are handled by HAP according to [CAPE ACQ MUG]

Response [1..1]


RemoveDataSet [1..1]

DataSetInitiator [0..1] These data elements are handled by HAP


Type [0..1]

Issuer [0..1]

ShortName [0..1]




Phase 2

10/07/2014 version 3.2 115/154

AcceptorBatchTransferResponse Component

Mult. SEPA-FAST Data Element (DE) HAP processing


Currency [0..1] HAP shall verify that these components remain unchanged between the request message and the response message

Type [1..1]

TotalNumber [1..1]


RejectedTransaction [0..*] Must match transaction present in the batch captured

TransactionSequenceCounter [1..1]


Response [1..1]


Environment [1..1]

AcquirerIdentification [0..1]


Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [0..1]

Issuer [0..1]

ShortName [0..1]



PAN [1..1]

CardSequence-Number

[0..1]


ExpiryDate [1..1]

Transaction [1..1]




Response [1..1]



Phase 2

10/07/2014 version 3.2 116/154

6.5 Diagnostic Exchange

6.5.1 AcceptorDiagnosticRequest

AcceptorDiagnosticRequest Component Mult. SEPA-FAST Data Element (DE)

HAP processing

Header [1..1] Unknown from SEPA-FAST These data elements are handled by HAP according to [CAPE ACQ MUG]







Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [1..1]

Issuer [0..1]

ShortName [0..1]

Traceability [0..*]



Type [1..1]

Issuer [0..1]

ShortName [0..1]



DiagnosticRequest [1..1]

Environment [1..1]

AcquirerParametersVersion [1..1] same as AcceptorAuthorisationRequest


Identification [1..1] Merchant Identifier Set EPAS DE with SEPA-FAST DE of one Application Profile where the Acquirer Number is matching

Type [0..1] Use default value

Issuer [0..1]

ShortName [0..1] Presence and value configured by TMS


Identification [1..1] Terminal Identification Set EPAS DE with SEPA-FAST DE of one Application Profile where the Acquirer Number is matching

Type [0..1]

Issuer [0..1]

ShortName [0..1]


Phase 2

10/07/2014 version 3.2 117/154

AcceptorDiagnosticRequest Component Mult. SEPA-FAST Data Element (DE)

HAP processing


6.5.2 AcceptorDiagnosticResponse

AcceptorDiagnosticResponse Component Mult. SEPA-FAST Data Element (DE)

HAP processing

Header [1..1] Unknown from SEPA-FAST These data elements are handled by HAP







Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [1..1]

Issuer [0..1]

ShortName [0..1]

Traceability [0..*]



Type [1..1]

Issuer [0..1]

ShortName [0..1]



DiagnosticResponse [1..1]

Environment [1..1]

AcquirerParametersVersion [1..1] see AcceptorAuthorisationResponse


Identification [1..1] Merchant Identifier HAP shall verify that these component remain unchanged between the request message and the response message

Type [0..1] Use default value

Issuer [0..1]

ShortName [0..1] Presence and value configured by TMS


Identification [1..1] Terminal Identification HAP shall verify that these component remain unchanged between the request message and the response message

Type [0..1]


Phase 2

10/07/2014 version 3.2 118/154

AcceptorDiagnosticResponse Component Mult. SEPA-FAST Data Element (DE)

HAP processing

Issuer [0..1]

ShortName [0..1]

TMSTrigger [0..1]






Phase 2

10/07/2014 version 3.2 119/154

6.6 Reconciliation

6.6.1 AcceptorReconciliationRequest

AcceptorReconciliationRequest Component


HAP processing








Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [1..1]

Issuer [0..1]

ShortName [0..1]

Traceability [0..*]



Type [1..1]

Issuer [0..1]

ShortName [0..1]



ReconciliationRequest [1..1]

Environment [1..1]

Acquirer [1..1]


Identification [1..1] Acquirer Identifier Set EPAS DE with SEPA-FAST DE of one Application Profile where the Acquirer Number is matching

Type [0..1]

Issuer [0..1]

ShortName [0..1]

ParametersVersion [1..1] same as AcceptorAuthorisationRequest


Identification [1..1] Merchant Identifier Set EPAS DE with SEPA-FAST DE of one Application Profile where the Acquirer Number is matching

Type [1..1]

Issuer [0..1]

ShortName [0..1]



Phase 2

10/07/2014 version 3.2 120/154

AcceptorReconciliationRequest Component


HAP processing

Identification [1..1] Terminal Identification Set EPAS DE with SEPA-FAST DE of one Application Profile where the Acquirer Number is matching

Type [1..1]

Issuer [0..1]

ShortName [0..1]

Transaction [1..1]

ClosePeriod [0..1] Always True

ReconciliationTransactionIdentification

[1..1]



ReconciliationIdentification [1..1] Copy from Authorisation Request


POIGroupIdentification [0..1] Present if configured by TMS (SplitTotals is set to “True” )


Currency [0..1] Present if configured by TMS (TotalsPerCurrency is set to “True” )

Type [1..1]

TotalNumber [1..1]




6.6.2 AcceptorReconciliationResponse

AcceptorReconciliationResponse Component


HAP processing








Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [1..1]

Issuer [0..1]

ShortName [0..1]

Traceability [0..*]


Phase 2

10/07/2014 version 3.2 121/154

AcceptorReconciliationResponse Component


HAP processing



Type [1..1]

Issuer [0..1]

ShortName [0..1]



ReconciliationResponse [1..1]

Environment [1..1]

AcquirerIdentification [1..1]


Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [1..1]

Issuer [0..1]

ShortName [0..1]



Type [1..1]

Issuer [0..1]

ShortName [0..1]


Response [1..1]


Transaction [1..1]

ClosePeriod [0..1] Reconciliation period always closed.

Copy of the request value!

ReconciliationTransactionIdentification [1..1]







Currency [0..1]

Type [1..1]

TotalNumber [1..1]





Phase 2

10/07/2014 version 3.2 122/154

6.7 Reject

AcceptorRejection Component Mult. SEPA-FAST Data Element (DE) HAP processing








Type [0..1]

Issuer [0..1]

ShortName [0..1]



Type [1..1]

Issuer [0..1]

ShortName [0..1]

Traceability [0..*]



Type [1..1]

Issuer [0..1]

ShortName [0..1]



Reject [1..1]

Reject Resaon [1..1]

Additional Information [0..1]

MessageInError [1..1] Message which is rejected


Phase 2

10/07/2014 version 3.2 123/154

7 Sale System Protocol

7.1 Interface with the Sale System The interface with the sale system is specified using the EPAS Retailer Protocol [EPAS RTP] as Sale System Protocol.

For the functional scope of the OSCar payment system, the following services of [EPAS RTP] have to be supported:

- Login and Logout for the session management of the Sale System. A session could represent

a shift of the cashier, a business day or any other period at the convenience of the merchant

(Chapter 4.2.3-4 of [EPAS RTP]),

- Diagnosis to verify the status of the Acquirer host connectivity (Chapter 4.7.4 of [EPAS RTP]),

- Payment for the processing of a various Payment services (Chapter 4.3.1-2 of [EPAS RTP]),

- Reversal for payment manual reversal or payment cancellation (Chapter 4.3.6 of [EPAS

RTP]),

- TransactionStatus, Abort and Event for error handling (Chapter 4.7.1-3 of [EPAS RTP]),

- Display for the output of cardholder and merchant display messages when these interface are

on the displays of the Sale System (Chapter 4.5.1-2 of [EPAS RTP]),

- Input for the merchant input entered on the keyboard of the Sale System (Chapter 4.5.3 of

[EPAS RTP]),

- Print for the print-out of cardholder and merchant receipts at the printer of the Sale System

(Chapter 4.5.2 of [EPAS RTP]),

- Reconciliation to exchange totals with the Sale system, and to initiate reconciliation with

acquirer hosts (Chapter 4.4.1 of [EPAS RTP]).

Complementary services of [EPAS RTP] may be needed to provide the functions required by the Sale system:

- CardAcquisition to allow the Sale system performing process dedicated to the selected card,

before the beginning of thepayment transaction (Chapter 4.3.3 of [EPAS RTP]),

- Balance Inquiry to provide the balance or other information of an account associated to the

selected card (Chapter 4.4.3 of [EPAS RTP]),

- GetTotals to deliver the totals since the beginning of the current reconciliation period without

closing the period (Chapter 4.4.2 of [EPAS RTP]),

- EnableService to provide the so-called swipe-ahead transaction, and for a premature

termination of a transaction after a CardAcquisition (Chapter 4.2.5 of [EPAS RTP]),

- Admin to provide customised administrative services to the Sale system (Chapter 4.2.6 of

[EPAS RTP]).

Other services of [EPAS RTP] may be needed by the merchant:


Phase 2

10/07/2014 version 3.2 124/154

- Loyalty to manage loyalty transactions synchronised with payment transactions (Chapter 4.3.4

of [EPAS RTP]),

- Stored Value to perform administration and payment services of stored value cards (Chapter

4.3.5 of [EPAS RTP]).

- Card Reader device service to manage cards (Chapter 4.5.5-6 of [EPAS RTP]).

The interface between SEPA-FAST and SCAP is called SCAPI (Sale System, Cardholder and Attendant Protocol application Interface).

The following types of interactions (requests and responses) are used in the SCAPI:

Service Request from SCAP to the SEPA-FAST application and Service Request Response

from the SEPA-FAST application to SCAP,

Reinitialisation Request from SCAP to the SEPA-FAST application and Reinitialisation

Request from the SEPA-FAST application to SCAP,

Device Request and Device Request Response from the SEPA-FAST application to SCAP or

from SCAP to the SEPA-FAST application.

The Service Request is used to initialise a Service and can contain additional information for the service to be initialised. When SEPA-FAST performs a Service Request no other messages are allowed from the Sale System.

SCAP should not forward the request of the Sale System Application to the SEPA-FAST application as long as the last service has not been terminated and the SEPA-FAST application is back to the idle state.


Phase 2

10/07/2014 version 3.2 125/154

7.2 Usage of SEPA-FAST Data Element in EPAS Messages This chapter provide the usage of the SEPA-FAST data elements for the messages of the EPAS Retailer.

Diagnosis Request/Response:

Diagnosis Request/Response SEPA-FAST Data Element Processing

AcquirerID Acquirer Number

Payment Request:

Payment Request SEPA-FAST Data Element Processing

PaymentRequest

PaymentTransaction

AmountsReq

Currency Transaction Currency Code and Transaction Currency Exponent

RequestedAmount Working Amount

CashBackAmount Cashback Amount

TipAmount Supplementary Amount

TransactionConditions

AcquirerID Selected Acquirer Number

Acquirer Pre-Selected

CustomerLanguage Selected Language

MerchantCategoryCode Merchant Category Code


Phase 2

10/07/2014 version 3.2 126/154

Payment Response:

PaymentResponse SEPA-FAST Data Element Processing

PaymentResponse

Response

ErrorCondition Terminal Error Reason if Result = Failure

PaymentResult

AmountsResp

AuthorizedAmount Transaction Amount

Send authorised value to Sale System Application

CashBackAmount Cashback Amount Cashback Amount Entered

Cashback Amount if Cashback Amount Entered is TRUE

TipAmount supplementary Amount Supplementary Amount Entered

set to supplementary Amount if Supplementary Amount Entered is TRUE

PaymentAcquirerData

AcquirerID Acquirer Identifier

AcquirerPOIID Terminal Identification

AcquirerTxnID

TransactionID Transaction Sequence Counter

TimeStamp Transaction Date

Transaction Time

ApprovalCode Authorisation Code If available

Reversal Request:

ReversalRequest SEPA-FAST Data Element Processing

ReversalRequest

OriginalPOITransaction

POITransactionID

TransactionID Transaction Sequence Counter

TimeStamp Transaction Date

Transaction Time

Reversal Response:

ReversalResponse SEPA-FAST Data Element Processing

ReversalResponse

Response

ErrorCondition Terminal Error Reason if Result = Failure


Phase 2

10/07/2014 version 3.2 127/154

Display Request:

Cardholder messages might have to be duplicated to the CustomerDisplay of the Sale System except the cardholder display messages necessary during the PIN entry function. During the PIN entry the text message "CARDHOLDER INPUT, PLEASE WAIT" is sent to the cashier display only.

DisplayRequest SEPA-FAST Data Element Processing

DisplayRequest

DisplayOutput

OutputContent

OutputText Message to display

Print Request:

PrintRequest SEPA-FAST Data Element Processing

PrintRequest

PrintOutput

DocumentQualifier According to Fig 92 of SEPA-FAST

RequiredSignatureFlag Signature Line

Reconciliation Request:

ReconciliationRequest SEPA-FAST Data Element Processing

ReconciliationRequest

AcquirerID Acquirer Number


Phase 2

10/07/2014 version 3.2 128/154

8 First initialisation of the POI Once the POI is installed, it needs to make a first call to its terminal management system in order to get a Management Plan and to download configuration parameters.

For this purpose a StatusReport message is sent to the terminal management system with the strict minimum of data.

This data is entered on the POI manually or by other means (USB stick, a card,...) and is listed below:

Terminal Identification assigned by the Terminal Manager

Terminal Manager or Acquirer Identifier

TMS address (IP address and Port).

Once entered, the StatusReport message can be generated as follows and sent to the TMS.

Message Item Value

Header

DownloadTransfer False

FormatVersion EPAS version

ExchangeIdentification 1

CreationDateTime Current date time

InitiatingParty

Identification Terminal Identification

StatusReport

POIIdentification

Identification Terminal Identification

TerminalManagerdentification

Identification Terminal Manager or Acquirer Identifier

DataSet

Identification

Type StatusReport

CreationDateTime Current date time

Content

POICapabilities Present if available and if DataSetRequired = ‘ManagementPlan’

POIComponent POI shall set available components

AttendanceContext Attended or Unattended

POIDateTime Date and time of the POI

DataSetRequired

Identification

Type - Management Plan for first StatusReport message

- AcquirerParameters

SecurityTrailer


Phase 2

10/07/2014 version 3.2 129/154

9 References

[SEPA-FAST] SEPA-FAST Financial Application Specification for SCS Volume Compliant

Terminals, Part 1: POS Environment Technical Specification, Version 3.0

[CAPE ACQ MDR] ISO 20022, Card Payment Exchanges - Acceptor to Acquirer - Message

Definition Report – Part1/Part2, 31 May 2013

[CAPE ACQ MUG] CAPE, Card Payments, Message Usage Guide, version 2.0 Edition January

2014

[CAPE TMS MDR] ISO 20022, Card Payment - Terminal Management - Message Definition

Report – Part1/Part2, 31 May 2013

[CAPE TMS MUG] Card Payments – Terminal Management Message Usage Guide, Version 2.0,

Edition January 2014

[EPAS RTP] Sale to POI Protocol Specifications, Retailer Protocols Working Group,

EPASOrg, Version 2.0,

[OSCar Scope] OSCar Functional Scope Version 3.1

[EPAS Security] EPAS Card Payments Protocol Security, Version 2.0, Edition January 2014


Phase 2

10/07/2014 version 3.2 130/154

10 Annex

10.1 SEPA-FAST Extension: Specific Processing based on PAN

Figure 58 in Section 9.1.2.1 of [SEPA-FAST] shows the proprietary process "Specific Processing

based on PAN" that shall be performed if bit b1 in byte 5 of the SEPA-FAST data element Application

Profile Settings (APS) has the value 1b.

The following function flow and explanatory notes show how this process shall be implemented within

the framework of the OSCar project for terminals that are intended to support girocard.

The following parameters are referenced in the Specific Processing based on PAN function, and are

described in the Data Dictionary (Section 23) of [SEPA-FAST]:

Name Set/modified

Application Label Default

Application Label - Displayed Yes

Application Profile Number Yes

Acquirer Identifier Yes

Acquirer Number Yes

Nok Reason

PAN

Processing Status

Reference Application Profile Number

Scheme Identifier Yes

Selected Application Profile Number Yes

Selected BID Yes

The following parameter is used locally in the Specific Processing based on PAN function and is not

described in the Data Dictionary of [SEPA-FAST]:

Name Description

Profile Num Holds the Selected Application Profile Number or a Reference


There is no unsuccessful exit from this process.

On successful exit from this process,

Either all Application Profile Parameters are unchanged,

Or the Application Profile Number (tag 'DF19'), the Application Label - Displayed (tag 'C0'),

Acquirer Identifier (tag '9F01'), Acquirer Number (tag 'DF1B') and Scheme Identifier (tag

'DF32') will have been updated, while all other Application Profile Parameters shall remain

unchanged.

Note: If present, the Scheme Identifier must be configured in the same Application Profile

Parameters as the Application Label Default.


Phase 2

10/07/2014 version 3.2 131/154

Specific Processing

based on PAN

Ok

30

Application Profile Selection

for Non Chip

{Selected BID}

Done

Nok

10

Card Product Selection

{PAN}

Ok

Nok

Set Nok Reason = NONE

50

Set Processing Status[3, 3] = 0b

20


40


20


40

Set Application Profile Number =

Selected Application Profile

Number

Set Profile Num to Selected


Do the

Application Profile

Parameters for Profile

Num include Reference

Application Profile

Number?

Set Profile Num to

Reference Application

Profile Number

Yes

No

Do the

Application Profile


Num include Application

Label Default?

Yes

No

Set Application Label - Displayed

= Application Label Default

Set Acquirer Identifier and Acquirer Number to

values of Application Profile Parameters for

Profile Num

Set CardBrand to Scheme Identifier

of Application Profile Parameters

for Profile Num

Do the

Application Profile


Num include Scheme

Identifier?

Yes

No

Delete CardBrand from message if

already present

Figure 9: Specific Processing based on PAN

Notes:

9-10 Card Product Selection {PAN}

The Card Product Selection process as described in Section 8.2.5 of [SEPA-FAST] shall be

performed using the PAN that has been read from the chip.

If this process is performed successfully, it returns a BIN based Card product Identifier (BID) in

Selected BID.


Phase 2

10/07/2014 version 3.2 132/154

9-20 Set Processing Status[3, 3] = 0b

The Specific Processing based on PAN process shall not change the Processing Status. Since

Processing Status[3, 3] has been set to 1b during Card Product Selection according to Section

8.2.5 of [SEPA-FAST], Processing Status[3, 3] shall be reset to 0b after successful or

unsuccessful exit from Card Product Selection.

Note:

The same result may be achieved in different ways, e.g. by implementing Card Product

Selection without setting the Processing Status for the Specific Processing based on PAN

process and adding this step for Card Product Selection if performed during magnetic stripe or

Manual Entry processing.

9-30 Application Profile Selection for Non Chip {Selected BID}

The Application Profile Selection for Non Chip process as described in Section 8.2.6 of [SEPA-

FAST] shall be performed using Selected BID.

If this process is performed successfully, it returns an Application Profile Number in Selected

Application Profile Number.

9-40 Set Processing Status[3, 2] = 0b

The Specific Processing based on PAN process shall not change the Processing Status. Since

Processing Status[3, 2] has been set to 1b during Application Profile Selection for Non Chip

according to Section 8.2.6 of [SEPA-FAST], Processing Status[3, 2] shall be reset to 0b after

successful or unsuccessful exit from Application Profile Selection for Non Chip.

Note:

The same result may be achieved in different ways, e.g. by implementing Application Profile

Selection for Non Chip without setting the Processing Status for the Specific Processing

based on PAN process and adding this step for Application Profile Selection for Non Chip if

performed during magnetic stripe or Manual Entry processing.

9-50 Set Nok Reason = NONE

The Specific Processing based on PAN process shall not change the Nok Reason. If Nok

Reason has been set on unsuccessful exit from Card Product Selection or Application Profile

Selection for Non Chip according to Section 8.2.5 or 8.2.6 of [SEPA-FAST], Nok Reason shall

be reset to NONE after unsuccessful exit from these processes.

Note:

The same result may be achieved in different ways, e.g. by implementing Card Product

Selection and Application Profile Selection for Non Chip without setting the Nok Reason for

the Specific Processing based on PAN process and adding this step for Card Product

Selection and Application Profile Selection for Non Chip if performed during magnetic stripe or

Manual Entry processing.


Phase 2

10/07/2014 version 3.2 133/154

10.2 SEPA-FAST Extension: Process Additional Application Profile Parameters

According to ISO 3166, two Country Codes (280 and 276) are defined to represent Germany.

Normally the value 280 shall be used for financial transaction processing at terminals located in

Germany. But in some cases, depending on the payment scheme or on the AID of the payment

application, the value 276 needs to be used.

Therefore, within the framework of the OSCar project, terminals that are intended to be deployed in

Germany shall support Application Profile specific configuration of the Terminal Country Code in

addition to the configuration of the Terminal Country Code on terminal level defined in [SEPA-

FAST] according to the following requirements:

The Terminal Country Code shall be an optional configuration parameter on Application

Profile level.

If the selected Application Profile contains the Terminal Country Code the value of the

Terminal Country Code defined as Application Profile parameter shall take precedence over

and replace the value of the Terminal Country Code defined on terminal level.

According to these requirements, the description of the data element Terminal Country Code in

Section 23.1 (Table 5) and Section 23.1.107 of [SEPA-FAST] has to be adapted as follows:

Data Element Name Tag Terminal Configuration Presence

Terminal Country Code '9F1A' Yes (Terminal)

Yes (Application Profile)

M

O

23.1.107 Terminal Country Code

Template: -

Tag: '9F1A'

Length (in bytes): 2

Format: n 3

Value: Indicates the country of the terminal, represented according to ISO 3166

Source: Terminal Configuration (Terminal and Application Profile)

Presence: Mandatory (Terminal)

Optional (Application Profile)

In addition, Terminal Country Code has to be added in the table listing the EMV data elements that

may be configured per Application Profile contained in Section 8.2.7 of [SEPA-FAST]:

EMV Data Element Name Tag Presence Default

Acquirer Identifier '9F01' O [EMV B3]

Default Dynamic Data Authentication Data

Object List (DDOL)

'DF1A' O '9F37 04'

Maximum Target Percentage to be used for

Biased Random Selection

'DF1C' O 0


Phase 2

10/07/2014 version 3.2 134/154

EMV Data Element Name Tag Presence Default

Merchant Category Code '9F15' O [EMV B3]

Merchant Identifier '9F16' O [EMV B3]

Merchant Name and Location '9F4E' O [EMV B3]

Target Percentage to be Used for Random

Selection

'DF1D' O 0

Terminal Action Code (TAC) - Default 'DF1E' C -

Terminal Action Code (TAC) - Denial 'DF1F' C -

Terminal Action Code (TAC) - Online 'DF20' C -

Terminal Capabilities '9F33' O -

Terminal Country Code '9F1A' O -

Terminal Floor Limit '9F1B' O 0

Terminal Identification '9F1C' O -

Terminal Risk Management Data '9F1D' O [EMV B3]

Threshold Value for Biased Random

Selection

'DF21' O 0


Phase 2

10/07/2014 version 3.2 135/154

10.3 SEPA-FAST Extension: Process Chip Fallback in case of Emergency

10.3.1 Overview To ensure that chip-based transactions are still possible even if the EMV functionality of a large amount of cards is malfunctioning, OIS supports the Chip Fallback in case of Emergency Processing instead of Fallbacks on track 2-processing.

The use of Chip Fallback as countermeasure in case of a failure is subject to the condition that the card issuer has ordered the emergency processing and that the Chip Fallback is explicitly activated for the terminals. The terminal may only apply Chip Fallback if this was activated for this card product in the corresponding Application Profile and if there is a card error.

The process of a Chip Fallback transaction, that is a transaction performed in the context of emergency processing, is similar to the process of a transaction based on track 2. However, the card data used for a Chip Fallback transaction is received from the chip and not from the magnetic stripe as this is the case for transactions based on track 2. These card data is referred to as emergency data. The emergency data consists of the Track 2 Equivalent Data as defined in [SEPA FAST] and optionally additional data.

To read the emergency data from the chip of the card, in particular the Track 2 Equivalent Data, the terminal has to support two so-called read procedures for emergency processing:

Read Procedure 1: Reading of the Track 2 Equivalent Data only with the commands

SELECT and READ RECORD,

Read Procedure 2: Reading of emergency data including the track-2 equivalent data by

using the GET DATA command.

Read Procedure 1 only works with girocard cards. Read Procedure 1 is supported by all girocard cards, in particular those that are already in the field.

Read Procedure 2 will only be supported by future girocard cards, since the procedure requires a specific software addition and additional data on girocard cards. It is intended to standardise the Read Procedure 2 so that also other cards can support this procedure in the future. Future girocard cards and perhaps also other cards will support an online authentication of the card towards the card issuer as addition to the Read Procedure 2. The terminal therefore has to support the following procedure for the retrieval of authentication data from the card:

Authentication procedure: Retrieval of authentication data for the online authentication of the

card with the command INTERNAL AUTHENTICATE.

An online authentication with Online-PIN is performed using the Track 2 Equivalent Data read from the card of the chip and possibly the card authentication data.

The online messages to be used for online authorisations at the interface to the acquirer host are largely identical with online messages for authorisations of EMV and magnetic stripe transactions with girocard cards (see section 6.1). Currently, the Chip Fallback is restricted to the acceptance of girocard cards in the electronic cash system. However, from a technical perspective it is also possible to conduct Chip Fallback transactions for brands other than girocard and for products other than electronic cash, provided that the payment scheme and the product support the necessary card functionality and the authorisation and settlement of these transactions. The configuration data for Chip Fallback transactions is described in the following section 10.3.2, in particular the activation of terminals and the procedure of Chip Fallback transactions as described in section 10.3.3.


Phase 2

10/07/2014 version 3.2 136/154

10.3.2 Configuration of the Emergency Processing

During a transaction in case of emergency the usage of the card is very limited to a data storage and Authentication Processing only. The card does not play any active role during the Risk Analysis and Cardholder Verification. Whether the card is allowed to be used for Chip Fallback transactions has to be checked for the selected Application Profile. The selection is performed as described in section "Application Profile Selection for Non Chip". After reading the Track 2 Equivalent Data of the chip using Read Procedure 1 or 2 the correct Application Profile is searched in the Application Profile Selection Table Non Chip by comparing the PAN with the Prefix or Prefix Mask listed in the Entry as described in Figure "Application Profile Selection for Non Chip" of [SEPA-FAST].

Whether the selected Application Profile allows the Chip Fallback transactions is defined in the Fallback Parameter – Magnetic Stripe. The Fallback Parameter – Magnetic Stripe may contain the additional values.

Value Description

'20' Emergency processing is permitted based on Read Procedure 1 and 2.

'30' Emergency-Processing is permitted based on Read Procedure 2 only

The new values of the Fallback Parameter – Magnetic Stripe are used to activate the Chip Fallback instead of the Fallback to Magnetic Stripe and to define which Read Procedure(s) of the chip have to be used.

10.3.3 Procedure of Chip Fallback

According to section 10.3.2 a terminal that supports Chip Fallback must try to execute a transaction as Chip Fallback if an error occurs during an EMV transaction and provided that this error does not require a complete termination of the transaction.

At the beginning of emergency processing the following conditions are thus fulfilled:

It was first tried to execute the transaction chip-based (according to [SEPA-FAST]) and the

Reset of the card (RESET and ATR) was performed successfully, but an error occurred in the

process afterwards including the processing of the first GENERATE AC command.

The card is still inserted in the card reader.

The cardholder is not yet informed about the error that has occurred.

An emergency transaction is then always conducted as an independent transaction. All cardholder interactions required for the transaction in the framework of a Chip Fallback transaction have to be executed. If at least one cardholder interaction took place during the EMV-based processing of the transaction, the EMV-processing has to be terminated with an error message to the cardholder before the independent emergency transaction can be started.

If no cardholder interaction took place during the EMV-based processing of the transaction the independent emergency transaction can be started without terminating the chip-processing with an error message.


Phase 2

10/07/2014 version 3.2 137/154

The following flow chart in Figure 10 shows the steps of the Chip Fallback.

3

1

Chip Fallback

Terminal supports

at least one

Application Profile

with Chip Fallback?

Yes

No

Transaction in case of

emergency not possible

Card communication in

case of emergency

OK

CHIP ERROR

Card supports

at least one Read

Procedure in case of

emergency?

2

No

Yes

4

5

Selection successful

Transaction completed

Store data for Chip Fallback

6

ErrorSelection of one Read

Procedure in case of Chip

Fallback

Perform Chip Falback

transaction

Figure 10: Steps of a Chip Fallback

Depending on the result of the Chip Fallback the following steps shall apply:

If a Chip Fallback transaction is not possible, the emergency processing ends directly with the

corresponding Processing Status and Nok Reason in the section "Transaction Completion"

of [SEPA-FAST].

If emergency transactions are possible with the card, the transaction is continued in the

framework of emergency processing und terminated (successfully or unsuccessfully). In this

case, the transaction processing is continued until the section "Transaction Completion" of

[SEPA-FAST].

The steps of Chip Fallback are described in more detail in the following sections.


Phase 2

10/07/2014 version 3.2 138/154

10-1 Does the terminal support at least one Application Profile with Chip Fallback?

The check whether the terminal supports at least one Application Profile with Chip Fallback only

has the result “yes“ if the terminal supports at least one Application Profile which fulfills the

following conditions:

The data element Fallback Parameter – Magnetic Stripe contains the value '20' or '30',

And according to the corresponding configuration parameters, the Selected Service is in the

list of the Supported Services.

10-2 Emergency card communication

Section 10.3.3.1 describes how the card communication for the reading of emergency data and, if

applicable, the reading of authentication data of the card shall be conducted.

10-3 Does the card support at least one emergency application of the terminal?

Based on the Track 2 Equivalent Data that is read from the card it is verified if the card supports

at least one of the Application Profiles that are also supported by the terminal. For this purpose,

the candidate list for the Chip Fallback shall be structured as described in section 10.3.3.2.

The check whether the card supports at least one Read Procedures of the terminal only has the

result “yes“ if, at the end of the building of the candidate list for emergency processing, the list is

not empty.

10-4 Storing of data for emergency processing

For a chip processing that was terminated due to an error, the terminal fills the Processing

Status, Nok Reason, Terminal Verification Results (TVR) and Transaction Status

Information (TSI) accordingly.

Furthermore, the terminal stores the data of the previous chip processing that was terminated due

to an error as listed below, if the following conditions apply:

Transaction Amount and if applicable Cashback Amount or Supplementary Amount, if the

Transaction Amount was already determined when the error occurred,

Dedicated File (DF) Name (tag '84') of the last selected application profile, if the error

occurred during or after the final selection of the application,

Cardholder Verification Method (CVM) Results (tag '9F34') of the last selected application,

if the error occurred after the cardholder authentication was started.

10-5 Selection of an emergency application

The terminal selects the first emergency application in the candidate list that is also supported by

the card.


Phase 2

10/07/2014 version 3.2 139/154

10-6 Execution of a Chip Fallback transaction

The execution of a Chip Fallback transaction is performed based on the Track 2 Equivalent Data

read from the card and in the same way as a track 2-based transaction according to the

description in section 10.3.3.3.

10.3.3.1 Card communication during emergency processing

An emergency processing with a card is only possible if the emergency data or the Track 2 Equivalent Data respectively can be read from the chip of the card. Two read procedure are available: Read Procedure 1 and Read Procedure 2. Read Procedure 1 is a proprietary procedure that is supported by all girocard cards, in particular by those that are already in the field. Read Procedure 2 is based on the internationally standardised GET DATA command and - generally speaking - can be supported by all cards. However, Read Procedure 2 will only be supported by girocards, and possibly other cards, issued in the future.

The terminal has to support Read Procedure 1 and Read Procedure 2.

To read the Track 2 Equivalent Data from the chip of the card with Read Procedure 1, two command have to be executed::

The EMV application of the girocard is selected with a SELECT-command.

The Track 2 Equivalent Data of the EMV application are read with a READ RECORD-

command.

With Read Procedure 2, only one command has to be executed to read the emergency data with the Track 2 Equivalent Data from the card:

The constructed data object with Tag '6E' (Application Related Data, see section 10.3.3.1.1) is

read with a GET DATA-command.

The value field Application Related Data must contain at least the Track 2 Equivalent Data

(tag '57').

The value field Application Related Data should also contain a Dynamic Data Authentication

Data Object List (DDOL) (tag '9F49').

Future girocard cards and perhaps also other cards will support not only the Read Procedure 2 but also an Online-Authentication of the cards towards the card issuer. For this purpose, the terminals have to support the following procedure for the request of authentication data from the card:

Authentication procedure: Request of authentication data through command INTERNAL

AUTHENTICATE.

From terminal perspective, the process of the authentication procedure has the following steps:

Structure and content of the command data of the INTERNAL AUTHENTICATE are not

predefined, but are described by a Dynamic Data Authentication Data Object List (DDOL),

which is usually returned by the card. The terminal builds the command data of the

INTERNAL AUTHENTICATE-command.


Phase 2

10/07/2014 version 3.2 140/154

If the card does not issue a DDOL, the terminal uses a default-DDOL.

For online authorisations, the terminal has to send the command data of the INTERNAL

AUTHENTICATE-command and the DDOL used for building the INTERNAL AUTHENTICATE

to the acquirer host.

During online authorisation, the terminal sends the response data of the INTERNAL

AUTHENTICATE (authentication data) without verification of format and length transparently

to the acquirer host.

The following Figure 11 shows the steps of card communication when execution a Chip Fallback transaction. It is shown in particular in which sequence and under what conditions the read procedures and the authentication procedure have to be conducted in case of emergency payment transactions.

In case of a Cancellation transaction, the card communication is conducted in the same way as for payment transaction, but without the step "Authentication Procedure".

5

Card communication in

case of Chip Fallback

Error

Reading successful

DoneNok

1

3

4

ATR already

performed?

Yes

No

Reading successful

6

Read

Procedure 1

supported

Yes

No

Perform Read Procedure 2

(GET DATA '6E')

Authentication Procedure

(INTERNAL AUTHENTICATE)

Perform Read Procedure 1

(SELECT und READ RECORD)

Nok

2Selected

Service =

Payment?

Yes

No

Set Nok Reason =

CHIP ERROR

Figure 11: Steps of card communication during emergency processing

The steps of card communication are explained in more detail in the following sections.

11-1 Read Procedure 2

To ensure that the error that occurred during the attempted regular EMV-procedure does not

affect the Read Procedure 2, the card is deactivated, activated and reset before initiating the Read

Procedure 2. If this is not successful, an error has occurred.

If the reset of the card is successful, it is attempted to read the data object with tag '6E' by means

of the GET DATA-command.


Phase 2

10/07/2014 version 3.2 141/154

The reading is successful, if the GET DATA-command is executed successfully and if the card

responds to the GET DATA command with correctly TLV-coded response data containing a data

object with correctly coded Track 2 Equivalent Data.

In all other cases, an error has occurred, in particular if the card responds with return code '6A 88'

meaning that there is no data object with tag '6E'.

If the reading is successful, the terminal stores the response data of the GET DATA command.

The execution of the Read Procedure 2 is described in detail in section 10.3.3.1.1.

11-2 Payment?

If the Selected Service is PAYMENT, the authentication procedure follows next.

For Selected Service is equal to CANCELLATION, the authentication procedure is not

conducted.

11-3 Authentication Procedure

The terminal builds an INTERNAL AUTHENTICATE-command based on the DDOL responded by

the card or based on its default DDOL; the command data is stored and send to the card.

The INTERNAL AUTHENTICATE-command is successfully executed if the card returns response

data together with the return code '90 00'. In this case, the terminal stores the response data

(authentication data) of the card in order to send it to the card issuer during the online

authorisation.

It the INTERNAL AUTHENTICATE-command has not been successfully executed, the terminal

continues the emergency processing. In this case, the online authorization is conducted without

authentication data of the card.

The execution of the authentication procedure is described in detail in section 10.3.3.1.2.

11-4 Did ATR take place?

If at the beginning of Read Procedure 2 the card could not be successfully reset, i.e. there was no

correct ATR response or a PPS procedure failed, the card communication is terminated without

trying to conduct Read Procedure 1.

11-5 Read Procedure 1?

If the Fallback Parameter – Magnetic Stripe with the value '20' is defined for at least one of the

application profiles supported by the terminal, the terminal will try to use the Read Procedure 1.

Otherwise the card communication is terminated without intending to conduct the Read Procedure

1.


Phase 2

10/07/2014 version 3.2 142/154

11-6 Read Procedure 1

Read Procedure 1 is only applied if Read Procedure 2 could not be completed successfully. To

ensure that the errors that occurred during the attempted Read Procedure 2 do not affect Read

Procedure 1, the card is deactivated, activated and reset at the beginning of Read Procedure 1. If

this is not successful, an error has occurred.

The reading is successful if the girocard EMV-application is successfully selected, the READ

RECORD command is successfully executed, and the card returns response data containing a

correctly TLV-coded record, whose valued field contains a data object with correctly coded Track

2 Equivalent Data. In all other cases, an error has occurred.

If the reading is successful, the terminal stores the Track 2 Equivalent Data contained in the

response data.

The process of the Read Procedure 1 is described in detail in section 10.3.3.1.3.


Phase 2

10/07/2014 version 3.2 143/154

The following flow chart shows the commands used during a successful card communication process for the processing of an Chip Fallback transaction in detail. The individual steps of the process are described in the subsections below. The number of the subsections of this section correspond to the numbers of the commands or actions in the flow chart. Section 10.3.3.1.1.1 thus refers to Action A10.3.3.1.1.1.

The steps that only apply under specific conditions are highlighted in grey.

In case of Cancellation transactions the card communication is the same as for emergency payment transactions, only without the steps C10.3.3.1.2, R10.3.3.1.2 and A10.3.3.1.2.

Flow chart

Chip Card Terminal

<---

C10.3.3.1.1.1 Deactivate and activate chip card,

RESET Chip Card

R10.3.3.1.1.1 ATR chip card --->

<---

C10.3.3.1.1.2 GET DATA Tag '6E' (Application Related Data)

R10.3.3.1.1.2 Track 2 Equivalent Data,

optionally DDOL, optionally other data, e.g. key and algorithm -ID of the authentication key

--->

A10.3.3.1.1.2 Evaluate Track 2 Equivalent Data, store response data

<---

C10.3.3.1.2 INTERNAL AUTHENTICATE with command data according to DDOL

A10.3.3.1.2 Store DDOL and command data

R10.3.3.1.2 Authentication data --->

A10.3.3.1.2 Store response data

<---

C10.3.3.1.3.1 Deactivate and activate chip card,

RESET Chip Card

R10.3.3.1.3.1 ATR Chip Card --->

<--- C10.3.3.1.3.2 SELECT electronic cash EMV 5-AID

R10.3.3.1.3.2 Ok --->

<--- C10.3.3.1.3.3 READ RECORD '03' im EF_EXT

R10.3.3.1.3.3 third Record of EF_EXT --->

A10.3.3.1.3.3 Store Track 2 Equivalent Data

10.3.3.1.1 Execution of Read Procedure 2

10.3.3.1.1.1 Deactivation, activation and reset of the card

The terminal deactivates and actives the card. After that it conducts a reset of the chip according to section "Technology Selection" of [SEPA-FAST].

If the card does not respond with a correct ATR or if a PPS-Procedure that may have to be conducted fails, Read Procedure 2 is terminated with the result Nok Reason = CHIP ERROR.


Phase 2

10/07/2014 version 3.2 144/154

If the card responds with a correct ATR and the PPS procedure that may have to be conducted is successful, the process is continued with the reading of the Application Related Data according to section 10.3.3.1.1.2.

10.3.3.1.1.2 Reading of Application Related Data

With the command GET DATA, the terminal requests the Application Related Data of the card (tag '6E'). The command message of the GET DATA shall be coded as follows:

Length

(in Byte)

Value Description

LA 1 '00' Class-Byte without Secure Messaging

NS 1 'CA' Instruction Code

P1 1 '00' Parameter P1

P2 1 '6E' Parameter P2

Le 1 '00' Response data expected

P2 contains the Tag '6E' of the data object to be returned.

If an error on the transport layer occurs or if the card returns a negative return code, in particular '6A 88' (Data object not found) or if the card does not return response data together with the return code '90 00' Read Procedure 2 is terminated with the result Nok Reason = CHIP ERROR.

If the return code '90 00' is returned, the GET DATA command shall be coded as follows:

Length

(in Byte)

Value Description

Data var. 'XX..XX' TLV-coded value field of the data object with Tag '6E'

SW1 1 '90' Status Byte 1


The response data have to be correctly TLV-coded. If response data is not correctly TLV-coded, Read Procedure 2 is terminated with the result Nok Reason = DATA ERROR.

The response data have to contain the following primitive data object:

Tag Length

(in Byte)

Format Value

‘57' var. b Track 2 Equivalent Data


Phase 2

10/07/2014 version 3.2 145/154

If the response data do not contain the data object with tag '57', Read Procedure 2 is terminated with the result Nok Reason = MISSING DATA.

The response data may contain additional TLV-coded data objects. In particular, the following primitive data object may be contained:

Tag Length

(in Byte)

Format Value

‘9F49' var. b Dynamic Data Authentication Data Object List (DDOL)

The terminal only evaluates the Track 2 Equivalent Data in the value field of the data object with tag '57' and – if present - the DDOL. All other data objects that may be returned are not evaluated. All response data is stored in the ICCRelatedData of the authorisation request.

Structure and content of the Track 2 Equivalent Data are checked by the terminal.

If the check of the fields of the Track 2 Equivalent Data has a negative result, Read Procedure 2 is terminated with the Nok Reason = DATA ERROR.

If the check of the fields of the Track 2 Equivalent Data has a positive result, the terminal stores the Track 2 Equivalent Data for further processing.

If the data object with the DDOL is returned by the card, it is checked whether it is a correctly coded Data Object List (DOL). If the result is positive, the terminal stores the DDOL for authentication processing according to section 10.3.3.1.2. The terminal ignores a DDOL which is not correctly coded..

Read Procedure 2 ends with the result "Reading successful"

10.3.3.1.2 Authentication Procedure

The terminal initiates the authentication of the card with the command INTERNAL AUTHENTICATE..

The command message of the command INTERNAL AUTHENTICATE shall be coded as follows:

Length

(in Byte)

Value Description

CLA 1 '00' Class-Byte without Secure Messaging

INS 1 '88' Instruction Code

P1 1 '00' Fixed value

P2 1 '00' Fixed value

Lc 1 'hh' Length L of the command data field

Data L 'hh..hh' Command Data


The command data have to be build according to a DDOL as described in section "Dynamic Signature Generation" of [SEPA-FAST]. The DDOL to be used is determined as follows:

If a correctly coded DDOL is returned by the card (tag '9F49') then this DDOL is used.


Phase 2

10/07/2014 version 3.2 146/154

If no DDOL is returned by the card or the returned DDOL is not correctly coded, the Default-

DDOL of the terminal is used.

The Default-DDOL is '9F37 04 9A 03 9F35 01'.

'9F37' denotes the tag of an Unpredictable Number with a length of 4 bytes generated by the

terminal.

'9A' denotes the tag of the transaction date with a length of 3 bytes in the format YYMMDD

(see [EMV B3]).

'9F35' denotes the tag of the terminal type with a length of 1 byte (see [EMV B3]).

If the used DDOL contains the tag of an unpredictable number (tag '9F37') the terminal has to generate a 4 byte long Unpredictable Number. This Unpredictable Number may only be used for this dynamic data authentication. If the used DDOL contains the tag of the transaction date (tag '9A') the coding of MMDD of the transaction date within the command message of the command INTERNAL AUTHENTICATE has to comply with the Transaction Date filled in the authorization request message.

The terminal stores the command data and the used DDOL in the chip data for the forwarding in the authorisation request.

If an error on the transport layer occurs or the card returns a negative return code or the card does not return response data together with the return code '90 00', then authentication processing ends without storage of any authentication data of the card.

If the return code '90 00' is returned, the response message of the command INTERNAL AUTHENTICATE shall be coded as follows:

Length

(in Byte)

Value Description

Data var. 'hh..hh' Authentication Data



The terminal stores the authentication data for forwarding in the chip data of the authorisation request.

The Authentication Procedure ends.

10.3.3.1.3 Read Procedure 1

10.3.3.1.3.1 Deactivation, activation and reset of the card

The terminal deactivates and actives the card. After that it conducts a reset of the chip according to section 7.3 of [SEPA-FAST].

If the card does not respond with a correct ATR or if a PPS-Procedure that may have to be conducted fails, Read Procedure 1 is terminated with the result Nok Reason = CHIP ERROR.

If the card responds with a correct ATR and the PPS procedure that may have to be conducted is successful, the process is continued with the selection of the girocard EMV-application according to chapter 10.3.3.1.3.2 .


Phase 2

10/07/2014 version 3.2 147/154

10.3.3.1.3.2 Selection of the der girocard EMV-application

The terminal selects the EMV Application of the girocard with the SELECT-command. The command message of the SELECT command shall be coded as follows:

Length

(in Byte)

Value Description


INS 1 'A4' Instruction Code

P1 1 '04' Selection Control Byte: Selection based on DF-Name

P2 1 '0C' Selection Option Byte: Selection of the first or the only DF with electronic cash EMV 5-AID, no response data

Lc 1 '09' Length of electronic cash EMV 5-AID

Data 9 'D2 76 00 00 25 47 41 01 00'

electronic cash EMV 5-AID

Le 0 - No response data expected

If a transmission error occurs during the execution of the command or if the card rejects the command with the negative return code or if no response data is returned with return code '90 00' Read Procedure 1 is terminated with the result Nok Reason = CHIP ERROR.

If the return code '90 00' is returned, the process is continued with the reading of the Records with the Track 2 Equivalent Data according to 10.3.3.1.3.3 .

10.3.3.1.3.3 Reading of Records with the Track 2 Equivalent Data

The terminal reads the Track 2 Equivalent Data in Record '03' with the command READ RECORD from the EF_EXT in ADF of the selected EMV-application of the chip card. The command message of the command READ RECORD shall be coded as follows:

Length

(in Byte)

Value Description


INS 1 'B2' Instruction Code

P1 1 '03' Record number '03'

P2 1 '0C' Reference Control Byte: Die SFI des EF_EXT ist '01'


If a transmission error occurs during the execution of the command or if the card rejects the command with the negative return code or if no response data is returned with return code '90 00' Read Procedure 1 is terminated with the result Nok Reason = CHIP ERROR. If the return code '90 00' is returned, the command READ RECORD shall be coded as follows:


Phase 2

10/07/2014 version 3.2 148/154

Length

(in Byte)

Value Description

Data var. 'XX..XX' Record data

SW1 1 '90' Statusbyte 1

SW2 1 '00' Statusbyte 2

The terminal checks the response data of the READ RECORD as follows:

The terminal checks if the response data consists of a data objects with Tag '70' correct length

(i.e. consistent with the length of the response data).

If the response data do no consist of a data object with Tag '70' correct length, Read

Procedure 1 is terminated with the result Nok Reason = MISSING DATA.

The terminal analyses the data object template as described in section 14.3 of [SEPA-FAST].

In this process the terminal searches the template for a data object with Tag '57' (Track 2

Equivalent Data).

If a coding error according to section 14.3 of [SEPA-FAST] is detected during the template

analysis, Read Procedure 1 is terminated with the result "error".

It the data object with Tag '57' is not found, Read Procedure 1 is terminated with the result

Nok Reason = MISSING DATA. The terminal analyses the Track 2 Equivalent Data in the

value field of data objects with Tag '57'. All other data objects that may be read are ignored.

If the check of the fields of the Track 2 Equivalent Data has a negative result, Read Procedure 1 is terminated with the result Nok Reason = DATA ERROR.

If the check of the fields of the Track 2 Equivalent Data has a positive result, the terminal stores the Track 2 Equivalent Data for further processing.

Read Procedure 1 is completed with the result “reading successful“.


Phase 2

10/07/2014 version 3.2 149/154

10.3.3.2 Building Candidate List for Chip Fallback

The Application Profile of the terminal foreseen in case of emergency corresponds to the card application if both of the following conditions are met:

The PAN extracted from the Track 2 Equivalent Data of the chip matches with the Prefix or

Prefix Mask of the entry in the Application Profile Selection Table Non Chip (see section

10.3.2).

And the emergency data of the card has been read according to the allowed Read

Procedures as configured in the Fallback Parameter – Magnetic Stripe in the selected

Application Profile:

The emergency data have been retrieved with Read Procedure 2,

Or the emergency data have been retrieved with Read Procedure 1 and the Fallback

Parameter – Magnetic Stripe has the value '20'.

All Application Profiles, supported by the terminal and the card, build the candidate list for the Chip Fallback.

10.3.3.3 Processing of Chip Fallback

A Chip Fallback transaction (PAYMENT or CANCELLATION) is conducted based on the Track 2 Equivalent Data read from the chip of the card according to the description in section 10.3.3.1.1 or 10.3.3.1.3 and, if applicable, also based on the authentication data of the card generated as described in section 10.3.3.1.2 in the same way as an magnetic stripe-transaction, using the configuration of the application profile that was selected for emergency processing according to section 10.3.2.

The Chip Fallback transaction conducted (see section 10.3.3) as independent transaction has to follow the steps below:

Confirmation of the transaction amount or the amounts,

Entering and confirmation of the PIN by the cardholder,

HAP Online-Approval Request,

Transaction Completion including display of the result and if applicable print of a receipt for the

cardholder.

Nevertheless single steps may be influenced in the flow of the Chip Fallback transaction according to the steps already performed in the aborted EMV-based transaction before. This has to be done in a manner plausible for the cardholder. In particular, the following requirements have to be met in case of a continuation of an EMV-based transaction:

If the cardholder has already entered the PIN during the EMV-based processing of the transaction with

the last selected EMV-application before the error occurred as described in section "PIN Entry" of

[SEPA-FAST], the cardholder has to be informed about the error that occurred before the terminal

asks again to enter the PIN. The following information should be displayed (wording suggestion):

CARD ERROR, ENTER PIN AGAIN


Phase 2

10/07/2014 version 3.2 150/154

After the confirmation of the transaction by the cardholder – through confirmation of the amount and/or confirmation of the PIN– the processing of Chip Fallback transactions, including checks of the PIN if applicable, must be conducted online.

For this purpose, the terminal builds an authorisation request and sends it to the corresponding acquirer host and waits for an authorisation response message.

The terminal must include the Chip Fallback data into the authorisation request to the acquirer host according to section 4.2.

The terminal shall add the Chip Fallback data listed in Table 8 to the ICCRelatedData of an authorisation request. The last column indicates whether a data object is mandatory (M) or conditionally (C). If a data object has to be included into the chip data only if it is returned by the card, this is indicated by condition C1. If a data object has to be included into the chip data only if it is stored in the terminal or generated by the terminal during transaction processing, this is indicated by condition C2.

Data Object Tag Length Format Presence

(in Byte)

CVM-Results '9F34' '03' b C2

Terminal capabilities '9F33' '03' b M

Terminal type '9F35' '01' BCD M

IFD Serial Number '9F1E' '08' an (ASCII) C2

DF-Name '84' Up to '10' b C1

Processing Status 'CA' '04' b M

Nok Reason 'C5' '01' b M

Terminal Verification Results (TVR) '95' '05' b M

Transaction Status Information (TSI) '9B' '02' b M

Application Related Data '6E' var. b M

(Default-)DDOL '9F49' var. b C1/C2

Command data INTERNAL AUTHENTICATE 'DF03' var. b C2

Response data INTERNAL AUTHENTICATE 'DF04' var. b C1

Table 8: Chip Fallback Data for the Authorisation Request

If the terminal receives no authorisation response or no correct authorisation response after sending the authorisation request, a reversal must be sent according to section 4.3. Independent of the result of the reversal, the transaction has to end according to section "Transaction Completion" of [SEPA-FAST] for an aborted transaction.

If the terminal receives a correct authorisation response after sending the authorisation request, the transaction shall be completed with the output for an approved transaction for the cardholder according to the section "Transaction Completion" of [SEPA-FAST].


Phase 2

10/07/2014 version 3.2 151/154

10.4 SEPA-FAST Extension for contactless transactions: Specific processing for Kernel identification for CB Cards

Figure 90 [Building the Candidate List Using PPSE - Part 2] of [SEPA-FAST] shows the proprietary

process [Specific Processing based on FCI].

The following function flow and explanatory notes show how this process shall be implemented within

the framework of the OSCar project for terminals that are intended to support already-issued

contacless cards that rely on a proprietary data element to determine the contactless kernel to be

activated. This proprietary tag was introduced before the Kernel Identifier EMV Data Element was

defined. It is provided by the answer to the SELECT ADF command, within the File Control

Information (FCI) Issuer Discretionary Data and it is identified by the ‘DF61’ tag.

This implementation is temporarily necessary for migration purposes.

10.4.1 Data Dictionary

Private Kernel Identifier

Template: 'BF0C'

Tag: 'DF61'

Length (in bytes): 1

Format: b

Value: Indicates the Default Requested Kernel ID

The following values are valid:

'03': Requested kernel is kernel C-3

'04': Requested kernel is kernel C-2

Source: Chip card

Presence: Optional, Contactless interface only

Private Kernel ID per AID - Working table

Tag: -

Length (in bytes): Not applicable

Format: List

Value: The Private Kernel ID per AID - Working Table is an internal table used during Specific Processing based on FCI.

This working Table is initialised to "empty" when entering the [Building the Candidate List Using PPSE] flow. The table will be filled with the couple (ADF Name, Kernel ID) when a valid Private Kernel Identifier is associated with the ADF Name being processed.

Confuguration: No


Phase 2

10/07/2014 version 3.2 152/154

10.4.2 Flow

This pocess is invoked when processing the entries of the Combinations List – Working

Table if no Kernel Identifier data element is available and if no entry of the Default Kernel ID

per AID table applies.

This process exits with Nok if the requested kernel cannot be identified from the Private Kernel Identifier.

The process may be reentered when processing the entries of the Combinations List – Working Table. So the result of the process is stored along with the Application Identifier (AID) - Card (ADF Name), thus avoiding to repeat the processing uselessly. This internal Private Kernel ID per AID - Working Table is cleared each time the Application enters the

Figure 90 [Building the Candidate List Using PPSE - Part 2] of [SEPA-FAST].


Phase 2

10/07/2014 version 3.2 153/154

10

Specific Processing based

on FCI

ADF Name

starts with

‘A000000042’?

Ok

Yes

SW1 SW2 =

'9000'?

Parse Response Data

{SELECT ADF,

Response Data}

Valid

Private Kernel

Identifier present

in FCI Issuer

Discretionary

Data?

Set Kernel ID based on Private

Kernel identifier

Nok

20

No

Nok

No

Nok

Yes

Yes

Ok

Ok

30

SELECT

{ADF Name}

Store (ADF Name, Kernel ID) in

Private Kernel ID per AID -

Working Table

40

YesStore (ADF Name, NONE) in

Private Kernel ID per AID -

Working Table

40

ADF Name

Present in Private

Kernel ID per AID -

Working Table?

No

A

Yes

A

Kernel ID =

NONE?

No

Yes

Yes

No

Figure 12 : Specific Processing based on FCI

12-10 ADF Name Present in Private Kernel ID per AID - Working Table?

If the ADF Name has already been processed, the previous result has been stored in the Private Kernel ID per AID - Working Table.

Select the Entry of Private Kernel ID per AID - Working Table based on the ADF Name which exactly matches the Application Identifier (AID) - Card (ADF Name). If found then set Kernel ID and exit with Yes, else (if not in List) exit with No.


Phase 2

10/07/2014 version 3.2 154/154

12-20 Parse Response Data {SELECT ADF, Response Data}

See Section 14.3 in [SEPA-FAST] for the detailed description of the Parse Response Data process.

12-30 Set Kernel ID based on Private Kernel identifier

Set Kernel ID = 00000011b if Private Kernel identifier = '03'.

Set Kernel ID = 00000010b if Private Kernel identifier = '04'.

12-40 Store (ADF Name, Kernel ID) in Private Kernel ID per AID - Working Table

The result of the process is stored so as to be reused in case the function is reentered with the same ADF Name. Create a new Entry in Private Kernel ID per AID - Working Table and store: ADF Name, Kernel ID.

If no Kernel ID has been identified, the value Kernel ID = NONE is stored.

oscar pos integration specification for sepa compliant terminals

Documents