OSCAR POS INTEGRATION SPECIFICATION FOR SEPA COMPLIANT TERMINALS

Transcription

1 OSCAR POS INTEGRATION SPECIFICATION FOR SEPA COMPLIANT TERMINALS 10/07/2014 version 3.2 1/154

2 Revision History Version Date Author Object CB/SRC Integration of comments and SEPA-FAST Part 1 Version CB/SRC Integration of final CAPE MUGs and additional clarifications CB/SRC Integration of comments received from the TWG of OSCar version 2.0 version 3.1 version 3.1 version OSCar OSCar phase 2 final version Technical Task Force OSCar OSCar phase 2 V3.1 Technical Task Force OSCar Erratum of the version edited on Technical Task Force OSCar Integration of file transfer for Batch capture and for Technical Task configuration. Force 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 10/07/2014 version 3.2 2/154

3 Table of Contents OSCAR POS INTEGRATION SPECIFICATION FOR SEPA COMPLIANT TERMINALS Introduction OSCar Technical Scope Cancellation Processing Configuration Requirements: Implementation Requirements: HAP Functionality HAP Status HAP Online Approval Request HAP Transaction Data Storage SEPA-FAST data elements EPAS data elements HAP data elements HAP Transaction Finalisation HAP Search Transactions Batch Processing Perform Reconciliation Perform Diagnostic Configuration and maintenance handling TMAP functionality Perform Terminal Management session Configuration Data Model SEPA-FAST Configuration Parameters Logical parameters classification Categories details Structure of data elements tables Parameters internal structure Data Elements description Data Elements by Tag /07/2014 version 3.2 3/154

4 5.5 Acquirer Protocol Configuration Parameters StatusReport ManagementPlanReplacement AcceptorConfigurationUpdate TerminalManagementRejection Download of Cryptographic Keys HAP Message data elements processing Authorisation Exchange AcceptorAuthorisationRequest AcceptorAuthorisationResponse Completion Exchange AcceptorCompletionAdvice AcceptorCompletionAdviceResponse Cancellation Exchange AcceptorCancellationAdvice AcceptorCancellationAdviceResponse Batch Transfer AcceptorBatchTransfer AcceptorBatchTransferResponse Diagnostic Exchange AcceptorDiagnosticRequest AcceptorDiagnosticResponse Reconciliation AcceptorReconciliationRequest AcceptorReconciliationResponse Reject Sale System Protocol Interface with the Sale System Usage of SEPA-FAST Data Element in EPAS Messages First initialisation of the POI References /07/2014 version 3.2 4/154

5 10 Annex SEPA-FAST Extension: Specific Processing based on PAN SEPA-FAST Extension: Process Additional Application Profile Parameters SEPA-FAST Extension: Process Chip Fallback in case of Emergency Overview Configuration of the Emergency Processing Procedure of Chip Fallback Card communication during emergency processing Building Candidate List for Chip Fallback Processing of Chip Fallback SEPA-FAST Extension for contactless transactions: Specific processing for Kernel identification for CB Cards Data Dictionary Flow /07/2014 version 3.2 5/154

6 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 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 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: 10/07/2014 version 3.2 6/154

7 - 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, 10/07/2014 version 3.2 7/154

8 - 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. 10/07/2014 version 3.2 8/154

9 - If present, the Kernel C-2 shall not activate the data storage feature. 10/07/2014 version 3.2 9/154

10 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) 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 10/07/2014 version /154

11 - 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 - Transaction Result = APPROVED - Cashback Amount = 0 - 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)) - Cancellation Flag = Not Cancelled (cf. [Table 7]) - Finalization Flag = Finalized (cf. [Table 7]) 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 - Transaction Result = APPROVED - Cashback Amount = 0 - (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 - Cancellation Flag = Not Cancelled (cf. [Table 7]) - Finalization Flag = Finalized (cf. [Table 7]) 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. 10/07/2014 version /154

12 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. 10/07/2014 version /154

13 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. 10/07/2014 version /154

14 HAP Status Check Mandatory Data Perform Diagnostic Check log and if any pending transaction advices and take the corresponding action if any Perform Reconciliation Batch Transfer Done Done Done Done Done No Terminal Error Indicator = TRUE? Yes OK NOK Figure 1: HAP Status 10/07/2014 version /154

15 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 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 10/07/2014 version /154

16 2. a power failure during HAP transaction storage of the last transaction. HAP is operating the following actions to resolve the failure: ad 1. ad 2. 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. 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 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 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 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. 10/07/2014 version /154

17 HAP approval Request Out of scope No Is Selected Service = '01' or '02 or 08 '? Yes 01 (PAYMENT) 02 (REFUND) 08 (DEFERRED PAYMENT) No All mandatory data needed for the protocol is available? 10 Build AcceptorAuthorisationReq uest Message 30 Send Request Message Nok Ok 40 Receive Response Message Nok Ok 50 Set NOK reason = DATA ERROR Nok Parse Response Message Ok Fill Call TMS with value of TMSContactLevel Yes TMSTrigger in Response? No NOK OK Unable to go online 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. 10/07/2014 version /154

18 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 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 o o For the service Payment the message element Transaction.TransactionType is set to "CardPayment". 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. 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 Amount, Authorised (Numeric) 9F02 M Presence M Mandatory C Conditional 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 10/07/2014 version /154

19 Transaction Data Element for AcceptorAuthorisationRequest used for Payment Tag Presence M Mandatory C Conditional 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 o o o InitiatingParty is filled with identification of the acceptor system (e.g. Merchant Identifier concatenated with Terminal Identification assigned by the acquirer) Message Function is set to "AuthorisationRequest" Generate next ExchangeIdentification Generate CreationDateTime etc. 10/07/2014 version /154

20 Refund Service: If Selected Service is Refund, HAP shall build an AcceptorAuthorisationRequest message (see section 6.1.1) as follows: Build Message Body o o Set Transaction.TransactionType to "Refund" 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 Amount, Authorised (Numeric) 9F02 - Amount, Other (Numeric) 9F03 - Application Cryptogram (AC) 9F26 - Application Effective Date 5F25 - Application Interchange Profile (AIP) 82 M Presence M Mandatory, C Conditional, - Optional 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 - 10/07/2014 version /154

21 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 Build Security Trailer o See section 4.1, Note 1-10 Build Message Header o see Payment Service 2-20 Build EPAS Cancellation Request Message The Cancellation request is not supported 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 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 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, 10/07/2014 version /154

22 - 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 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 M Mandatory C Conditional 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 Once the response received, HAP shall verify data elements described hereafter, to fill the transaction result accordingly. Data elements to be verified: o o o o ResponseToAuthorisation.Response Action.ActionType Action.MessageToPresent.MessageContent 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. 10/07/2014 version /154

23 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.Ac tion.actiontype Action.MessageToPresent.Messa gecontent Action.MessageToPresent.Messa gedestination 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: ResponseToAuthoris ation.response Data in Response Message TransactionResponse.Action.Acti ontype Data set by HAP Transaction Result ARC 2 Nok Reason Approved Approved Declined Equal to "DisplayMessage", "PrintMessage" OR no Action present Different than DisplayMessage", PrintMessage" "Busy", "CaptureCard", "PINLastTry", "PINRetry" or any defined action not listed in this table. APPROVED "00" - ABORTED - DATA ERROR 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 10/07/2014 version /154

24 Declined Message element absent, "DisplayMessage" and/or "PrintMessage" - DECLINED (otherwise) DECLINED "05" - PartialApproved "DisplayMessage" and/or "PrintMessage" - PAYMENT PART ONLY (if Payment with Cashback) PARTIALLY APPROVED (if Selected Service = DEFERRED PAYMENT) - DECLINED (otherwise) - "05" for declined TechnicalError "DisplayMessage" and/or "PrintMessage" DECLINED "05" - Table 5: Handling for the Authorisation Response for Payment ResponseToAuthorisation. Response Data in Response Message TransactionResponse.Action.ActionType Data set by HAP 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. 10/07/2014 version /154

25 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 10/07/2014 version /154

26 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 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]. 10/07/2014 version /154

27 HAP Transaction Data Storage No All mandatory data needed for the protocol is available? Yes Nok Store Transaction Ok Log Limit is reached? No Yes Set Terminal Error Reason = LOG LIMIT EXCEEDED Set Terminal Error Indicator = TRUE NOK OK 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 SEPA-FAST data elements SEPA-FAST specifies in section 15.1 which data elements shall be logged when available EPAS data elements All the data elements needed for the generation and validation of the messages described in section 6 are stored by HAP HAP data elements All data elements described in this section must be added to each transaction record in the HAP transaction data storage. 10/07/2014 version /154

28 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 b Finalization Flag Transaction flagged as Not Finalized has not completed finalization phase as described in section 4.4 Table 7: HAP data elements M M 00 Not Cancelled (default value) 01 Cancelled 00 Not Finalized (default value) 01 Finalized 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: HAP returns: Advice handling for completion and/or reversal, Capture of the data. Ok, if the function was performed successfully Nok, otherwise. 10/07/2014 version /154

29 HAP Transaction Finalisation Completion required by acquirer or configuration or necessary as reversal? No Yes Yes Is Selected Service = 03'? No Build AcceptorCancellationAdvice message Build AcceptorCompletionAdvice message 30 Nok Send Advice Message Ok 40 Nok Receive Response Message Ok 50 Nok Parse Response Message Ok Fill Call TMS with value of TMSContactLevel Yes TMSTrigger in Response? No 60 Update Finalization Flag. NOK Figure 4: HAP Transaction Finalisation OK 10/07/2014 version /154

30 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 and AcceptorCompletionAdviceResponse as described in section 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 o o If the transaction is approved the element Transaction.TransactionSuccess is set to "True". Otherwise the Transaction.TransactionSuccess is set to "False". 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. 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 Build Message Header Build Security Trailer 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 Build AcceptorCancellationAdvice Message For the Cancellation service the EPAS cancellation exchange consisting of the AcceptorCancellationAdvice as described in section and AcceptorCancellationAdviceResponse as described in section 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 10/07/2014 version /154

31 The following steps are carried out: 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. Build Security Trailer Build Message Header 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) 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) 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) 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 and 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. 10/07/2014 version /154

32 If HAP does not receive a valid response, HAP returns nok to SEPA-FAST 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 o In accordance to TMS configuration 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 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. 10/07/2014 version /154

33 Batch processing 10 Build AcceptorBatchTransfer Message 20 Send BatchTransfer Message Nok Ok 30 Receive and Parse AcceptorBatchTransferResponse Nok Ok No All transactions captured? Yes End Batch processing End Batch processing 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] 10/07/2014 version /154

34 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. The following steps are carried out: 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 Build Security Trailer Build File Header 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 o o o o o Set DownloadTransfer = False Select the recipient (HostIdentification) including the correct communication Parameter according to the Acquirer Number. Fill in FormatVersion Generate next ExchangeIdentifier Generate CreationDateTime etc 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. 10/07/2014 version /154

35 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 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 Build Security Trailer o see Note 1-30 Build Message Header o o see AcceptorDiagnosticRequest except MessageFunction Message Function is set to "ReconciliationRequest" Checks consistency of the Syntax and Format of the message AcceptorReconciliationResponse described in section 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. 10/07/2014 version /154

36 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 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. Build Message Header o InitiatingParty filled with identification of the acceptor system (e.g. Merchant Identifier concatenated with Terminal Identification assigned by the acquirer) o o o o Select the recipient including the correct communication parameter according to the Acquirer Number The element MessageFunction is set to "DiagnosticRequest" Fill in ProtocolVersion Generate next ExchangeIdentification o Generate CreationDateTime. Checks consistency of the Syntax and Format of the message AcceptorDiagnosticResponse described in section 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. 10/07/2014 version /154