OSCAR POS INTEGRATION SPECIFICATION FOR SEPA COMPLIANT TERMINALS

Transcription

1 OSCAR POS INTEGRATION SPECIFICATION FOR SEPA COMPLIANT TERMINALS 26/03/2012 1/200

2 Revision History Version Date Author Object CB/SRC Integration of TMS Messages, Diagnosis added in Retailer Protocol and section 5 has been reworked CB/SRC Integration of comments and SEPA-FAST Part CB/SRC Integration of final CAPE MUGs and additional clarifications CB/SRC Integration of comments received from the TWG of OSCar 26/03/2012 2/200

3 Table of Contents OSCAR POS INTEGRATION SPECIFICATION FOR SEPA COMPLIANT TERMINALS Introduction OSCar Technical Scope HAP Functionality HAP Status HAP Online Approval Request HAP Transaction Data Storage SEPA-FAST data elements EPAS data elements HAP Transaction Finalisation HAP Search Transactions Batch Processing Perform Reconciliation Perform Diagnostic Perform Terminal Management session HAP Configuration Handling HAP 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 Acquirer Protocol Configuration Parameters StatusReport ManagementPlanReplacement AcceptorConfigurationUpdate /03/2012 3/200

4 5 HAP Message data elements processing Authorisation Exchange AcceptorAuthorisationRequest AcceptorAuthorisationResponse Completion Exchange AcceptorCompletionAdvice AcceptorCompletionAdviceResponse Cancellation Exchange AcceptorCancellationRequest AcceptorCancellationResponse AcceptorCancellationAdvice AcceptorCancellationAdviceResponse Batch Transfer AcceptorBatchTransfer AcceptorBatchTransferResponse Diagnostic Exchange AcceptorDiagnosticRequest AcceptorDiagnosticResponse Reconciliation AcceptorReconciliationRequest AcceptorReconciliationResponse Reject Sale System Protocol application Introduction Login Request, Login Response Logout Request, Logout Response Diagnosis Request, Diagnosis Response Payment Request, Payment Response for Normal Payment or Voice Authorisation Payment Request, Payment Response for Refund Reversal Request, Reversal Response for Cancellation Abort, TransactionStatus /03/2012 4/200

5 6.9 Display Input Print Reconciliation References Annex SEPA-FAST Extension: Specific Processing based on PAN SEPA-FAST Extension: Process Additional Application Profile Parameters /03/2012 5/200

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. The aim of this specification is 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. 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 8.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 8.2). 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] - administrative and maintenance functionalities using the TMS protocol according to [CAPE TMS MDR] and [CAPE TMS MUG]. Optionally a Sale System and Attendant Protocol (SAP) 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], Optionally 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]). 26/03/2012 6/200

7 The EPAS Acquirer Protocol [CAPE ACQ MDR] is only supported with the following profiles: - Authorisation without Capture for online transactions using the AcceptorAuthorisationRequest and AcceptorAuthorisationResponse messages, - AcceptorCompletionAdvice/AcceptorCompletionAdviceResponse with Capture immediately after the finalisation of the online or offline transaction, - AcceptorBatchTransfer/AcceptorBatchTransferResponse for a group of online and offline transactions on a cyclic call and according to the configuration of the maximum amount or number limit (The BatchTransfer request message of the POI may use the CommonData in the dataset for factorisation.), - AcceptorCancellationRequest/AcceptorCancellationResponse and AcceptorCancellationAdvice/AcceptorCancellationAdviceResponse for Cancellation, - AcceptorReconciliationRequest/AcceptorReconciliationResponse for reconciliation with the Acquirer Host, - AcceptorDiagnosticRequest/AcceptorDiagnosticResponse for cryptographic key validation, and - AcceptorRejection for error handling The functionalities of the EPAS TMS Protocol [CAPE TMS MDR] supported are: - StatusReport message requesting the ManagementPlanReplacement as response message (message exchange) to define the TMS actions to be performed, and - StatusReport message requesting the AcceptorConfigurationUpdate as response message (message exchange) 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 [CAPE ACQ MUG]. 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. 26/03/2012 7/200

8 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 and Attendant Protocol (SAP) application controlling the retailer protocol is described in section 6. All profiles and functionalities described in [OSCar Scope] and detailed above are in scope for testing. 3 HAP Functionality As decribed in section 22 of [SEPA-FAST], HAP is the application responsible for handling the acquirer protocol. In the OSCAR project, HAP is also responsible for handling the protocol used for maintenance and administrative functionality. Thus the functions related to this functionality like reconciliation and parameters configuration are handled by HAP. The list of HAPI functions defined in [SEPA-FAST] is extended to integrate new functions: Reconciliation, Diagnostic and Perform Terminal Management session. 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: - SEPA-FAST configuration data elements provided by TMS (see section 4.2), - EPAS configuration data elements provided by TMS (see section 4.3), - conversion of data elements exchanged between SEPA-FAST and EPAS (see section 5), - The communication between the POI application and the host using the EPAS Acquirer Protocol, - The communication between the POI application and the terminal manager system using the TMS protocol. 26/03/2012 8/200

9 SEPA FAST Application HAP EPAS Protocol HAP Message Processing - Data Conversion - EPAS data elements management - Message consistency Handling SEPA FAST Configuration Data EPAS Configuration Data Terminal Management System Figure 1: Organisation of HAP data elements 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. 26/03/2012 9/200

10 3.1 HAP Status According to section 22 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. Contact the TMS if required. 26/03/ /200

11 HAP Status Call TMS <> None or Time Event 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 60 Done Perform Terminal management session No Terminal Error Indicator = TRUE? Yes OK NOK Figure 2: HAP Status 26/03/ /200

12 2-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 4.2, 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 - informs the merchant with a display message "Mandatory data missing", - prepares the element Errors of the TMS message StatusReport with the content "Mandatory data missing", - sets the element Call TMS to the value "AsSoonAsPossible" - sets the Terminal Error Indicator to TRUE - Tries to call its Terminal Manager System to solve the error Perform Diagnostic This process is described in section 3.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 for the host not responded correctly Check log. If any pending transaction advices exist take the corresponding action This process checks if there are any outstanding 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 2. a power failure during HAP transaction storage of the last transaction. 26/03/ /200

13 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 Perform Reconciliation Before the reconciliation can be started, all transactions have to be captured. The reconciliation process is described in section 3.7. If Reconciliation exchange couldn t 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 Perform Terminal Management session Before a terminal management session can be started, the reconciliation by Reconciliation message or within the Batch Transfer has to be performed. The terminal management process is described in section /03/ /200

14 If the Terminal Management session couldn t performed successfully then Terminal Error Indicator is set to TRUE. 3.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. 26/03/ /200

15 HAP approval Request No All mandatory data needed for the protocol is available? Yes Is Selected Service = '01' or '02'? Yes No No Is Selected Service = '03'? Yes All mandatory data needed for the protocol is available? Yes 10 Build AcceptorAuthorisationRequest Message 20 Build AcceptorCancellation Request Message 30 Send Request Message Nok Ok 40 Receive Response Message Nok Ok 50 Set NOK reason = DATA ERROR Nok Parse Response Message Ok Set Transaction Result = 01 No Response Approved? Yes Set Transaction Result = 00 Fill Call TMS with value of TMSContactLevel Yes TMSTrigger in Response? No NOK OK Unable to go online Figure 3: Approval exchange processing 26/03/ /200

16 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. If the Selected Service is Cancellation the Service Triggers REFERENCE ENTRY, ACCEPT and MANUAL Entry are out of scope of this specification. The data elements listed in the table 5 of the section 23.1 and in the table 6 of the section 23.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 23 of [SEPA-FAST] contains a row "Auth/Clearing" with the respective information. 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 5.1.1) as follows: Build Message Body 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 according to the BER-TLV description as defined in ISO/IEC 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 26/03/ /200

17 Transaction Data Element for AcceptorAuthorisationRequest used for Payment Tag Dedicated File (DF) Name 84 M Presence M Mandatory C Conditional Interface Device (IFD) Serial Number 9F1E C Present if available Issuer Application Data (IAD) 9F10 C Present if available, value used for ARQC Terminal Capabilities 9F33 M Terminal Country Code 9F1A M 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 Table 1: Transaction Data Element for AcceptorAuthorisationRequest used for Payment Build Security Trailer See section 3.1, Note 2-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. 26/03/ /200

18 Refund Service : If Selected Service is Refund, HAP shall build an AcceptorAuthorisationRequest message (see section 5.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 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 - 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 - Table 2: Transaction Data Element for AcceptorAuthorisationRequest used for Refund 26/03/ /200

19 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 3.1, Note 2-10 Build Message Header o see Payment Service 3-20 Build EPAS Cancellation Request Message If Selected Service is Cancellation and the Application Profile Settings for Cancellation (APSC) is configured as follows 1 APSC[2, 7] = 0b (Cancellation allowed of Tx. logged) APSC[2, 6] = 1b (Cancellation allowed with Online Request) the AcceptorCancellationRequest message has to be sent. The AcceptorCancellationRequest message is built (see section 5.3.1) as following: Build Message Body o For EMV Chip transactions, the ICCRelatedData message element is filled with the following data elements of SEPA-FAST. Transaction Data Element for CancellationRequest Tag 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 - Application Transaction Counter (ATC) 9F36 - Application Version Number - Terminal 9F09 M Cryptogram Information Data (CID) 9F27 - Cardholder Verification Method (CVM) Results 9F34 - Presence M Mandatory C Conditional 1 The following configuration APSC[2,7]=1 and APSC[2,6]=1 is not supported in this version of [OIS] 26/03/ /200

20 Transaction Data Element for CancellationRequest Tag Dedicated File (DF) Name 84 M Presence M Mandatory C Conditional 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 Build Security Trailer 9F37 Table 3: Transaction Data Element for CancellationRequest o See section 3.1, Note 2-30 Build Message Header o o see AcceptorAuthorisationRequest except MessageFunction Message Function is set to "CancellationRequest" 3-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. The POI does not support the Acquirer pre-selection process as described in section of [SEPA- FAST]. If a problem occurs (e.g. the message function is not found in any MessageToSend list in the HAP configuration, see section 4.3.3) and HAP could not send the message, it returns "Unable to go online" to SEPA-FAST. 26/03/ /200

21 3-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 3.4) by sending an AcceptorCompletionAdvice respectively 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 respectively an AcceptorCancellationAdvice message during HAP transaction finalisation (see section 3.4) with message element Reversal set to "True" when it receives - a partial authorisation, - a reject message, - a message with in incorrect MAC, - 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 and 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 Table 4: Transaction Data Element in AcceptorAuthorisationResponse 26/03/ /200

22 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. 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.Acti on.actiontype Action.MessageToPresent.Messag econtent Action.MessageToPresent.Messag edestination All other values Any text( 2 ) "CardholderDisplay" Referral Refer to card issuer "CardholderDisplay" Referral Call Merchant Service "MerchantDisplay" Table 5: 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 and Authorisation Response Code (ARC). 2 display and receipt text messages for the cardholder and merchant sent by the host have to be defined by the card scheme 26/03/ /200

23 The different cases for Payment, Refund and Cancellation are described below: Data in Response Message ResponseToAuthorisation. Response TransactionResponse.Action.A ctiontype Data set by HAP Transaction Result ARC Nok Reason Approved All Action Types equal to "DisplayMessage", "PrintMessage", "RequestData" may be present Approved One equal to "Busy", "CaptureCard", "PINLastTry", "PINRetry" Declined "Busy", "CaptureCard", "PINLastTry", "PINRetry" APPROVED "00" - ABORTED - "DATA ERROR" DECLINED "05" - Declined Referral VOICE AUTHORISATION "02" - Declined Message element absent, "DisplayMessage" and/or "PrintMessage" PartialApproved "DisplayMessage" and/or "PrintMessage" TechnicalError "DisplayMessage" and/or "PrintMessage" DECLINED "05" - DECLINED "05" - DECLINED "05" - Table 6: Handling for the Authorisation Response for Payment Data in Response Message Data set by HAP ResponseToAuthorisation.R esponse 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 7: Handling for the Authorisation Response for Refund and Cancellation Response The cardholder text message (MessageDestination = "CardholderDisplay") should be sent in the response for declined transactions. 26/03/ /200

24 The SEPA-FAST data element Decline Display Message is filled then with Action.MessageToPresent.MessageContent of the response message. If the merchant text is not sent the cardholder text message is also shown on the merchant display if available. 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. 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 3.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 "AsSoonAsPossible". 26/03/ /200

25 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 Unable to go online, otherwise. 26/03/ /200

26 3.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. 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 5.6) if the Reconciliation Exchange is necessary. HAP will also keep the transactions in the data storage at least until the BatchTransferResponse has been received and no additional Reconciliation Exchange is necessary. 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 of [SEPA-FAST]. 26/03/ /200

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 4: HAP transaction data storage SEPA-FAST data elements SEPA-FAST specifies in section 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 7 are stored by HAP. 3.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. 26/03/ /200

28 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. NOK Figure 5: HAP Transaction Finalisation OK 26/03/ /200

29 5-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 If the transactions 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. 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 use. 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 3. Build Security Trailer Build Message Header The transaction is flagged as "Cancelled" in the log of the terminal so that the transaction cannot be present for Cancellation anymore in HAP Search Transaction (see section 3.5). 26/03/ /200

30 5-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 transaction has not been captured before and a CancellationAdvice message has been generated but the message function is not found in any MessageToSend list in the HAP configuration, see section 4.3.3, this message is not sent. If the HostIdentification has been selected and no connection to this host could be established the advice message is still pending and will be handled by HAP Status (see section 3.1). In this case HAP shall return Nok to SEPA- FAST Receive Response Message If the response message is not received HAP has to retransmit the advice message in HAP Status (see section 3.1). In this case HAP shall return Nok to SEPA-FAST 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 HAP detects an error in the response message HAP has to retransmit the advice message in HAP Status (see section 3.1). If the checks are successful; HAP updates the appropriate terminal transaction data elements using the present message elements as described in section and HAP returns to SEPA-FAST: Ok, if a valid response was received, Nok, otherwise. 3.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 /03/ /200

31 3.6 Batch Processing The acquirer can require by configuration that the acceptor send the transactions in batch. In AcceptorBatchTransfer or AcceptorBatchTransferResponse (see section 5.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 Cancellation of a transaction is not allowed anymore if the BatchTransfer containing this transaction has been sent. The limits used as trigger for the batch transfer of Online and Offline transations are defined in [CAPE TMS MUG]. The grouping of transactions in several BatchTransfer messages is possible. HAP may split the whole log in several requests if needed. 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 OK End Batch processing NOK Figure 6: Batch Processing 26/03/ /200

32 6-10 Build BatchTransfer Request The POI generates the BatchTransfer message containing all transactions to be captured according to the TMS configuration. The TMS configuration (see section 4.3.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] 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 RetailerProtocol (see section 6.12). The POI 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 3.1, Note 2-30 o o Set DownloadTransfer = False Select the recipient (HostIdentification) including the correct communication Parameter according to the Acquirer Number. 26/03/ /200

33 o o o 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 Receive and parse BatchTransferResponse The Acquirer host sends a BatchTransferResponse for each request. 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 validations of the response message fail HAP will keep all transactions. 3.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 The Cancellation of a transaction is not allowed anymore if the Reconciliation containing this transaction has already been performed successfully. 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 4.3.3) is used in the following way: ReconciliationExchange.ExchangePolicy = "NumberLimit": The reconciliation exchange is started if the number of only successfully completed, captured and not cancelled (Type=Debit+Credit) transactions has reached the limit ReconciliationExchange.MaximumNumber. ReconciliationExchange.ExchangePolicy = "TotalLimit": The reconciliation exchange is started if the TotalAmount sum of only successfully completed, captured and not cancelled (Type=Debit+Credit) transactions has reached the limit ReconciliationExchange.MaximumAmount. ReconciliationExchange.ExchangePolicy = "Cyclic": see [CAPE TMS MUG] The following steps are carried out to build the AcceptorReconliationRequest: Build Message Body 26/03/ /200

34 o the totals are calculated as described in [CAPE ACQ MUG] o see section Build Security Trailer o see Note 2-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]. 3.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. The diagnostic exchange is triggered by the merchant using a local administration interface of the POI or using the Retailer Protocol (see section 6.4). If the diagnostic is initiated by the Retailer Protocol the message exchange is performed with all connected 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 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 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 TMSContactLevel. 26/03/ /200

35 3.9 Perform Terminal Management session 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. If the element Call TMS has the value "AsSoonAsPossible" or "Critical" the TMS session is started immediately as specified in [CAPE TMS MUG]. If the element Call TMS has the value "DateTime" and the date and time delivered in TMSContactDateTime is expired the TMS session is started immediately as specified in [CAPE TMS MUG]. Otherwise no TMS session is started. If the TMS session has been performed successfully the element Call TMS is set to "None". 26/03/ /200

36 4 HAP Configuration Handling 4.1 HAP Configuration Data Model SEPA-FAST and EPAS use different formats for data elements coding. These formats are both handled by HAP. 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] HAP SEPA-FAST Configuration Data EPAS Configuration Data Terminal Card service Configuration Data Acquirer Protocol Parameters Application profile Host Communication Parameter Terminal Configuration Data Figure 7: Overview of configuration components 26/03/ /200

37 Supports Supports Supports Supports Supports OSCar POS Integration Specification for SEPA Compliant Terminals 4.2 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 Logical parameters classification Terminal Card service Configuration Data Supports Supports Supports Supported Card Service n Supported Card Service n Supported Card Service n Supported Card Service n Supports 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 Terminal Configuration Data Figure 8: 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 26/03/ /200

38 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. 26/03/ /200

39 4.2.2 Categories details Terminal List of AID Acquirer Parameter Table AID Preference Table check check Application Profile Selection Table Application Profile AID Application Profile Number Supported Services Application Profile Acquirer Number AID Match Criteria Bank Identifier Code (BIC) Issuer Country Code (a2 ) Issuer Country Code (a3 ) Issuer Identification Number (IIN) IIN Mask IBAN Comparison Value IBAN Mask Optional: other private Tag(s) Application Profile Selection Table non Chip BIN based Card Product Identifier (BID) Application Profile Number Supported Services Application Profile Acquirer Number Prefix Prefix Mask check Terminal List of BID Service Settings Table Terminal Exception File Certification Authority (CA) Public Key Table Cardholder Default Language Command Key Clear Label Command Key Enter Label Command Key Scroll Label Configured Services Default Card Service Max. Number of Chip Tries Terminal Application Version List Terminal Supported Language List Terminal Transaction Currency Code Terminal Transaction Currency Exponent Data defined by EMV Check Additional Terminal Capabilities Interface Device (IFD) Serial Number Terminal capabilities Terminal Country Code Terminal Type Terminal Identification Application Profile Number Additional Data Elements Identify the profile to be selected Application Label Default Application Profile Settings (APS) check Additional Restrictions of Forced Acceptance Application Profile Settings for Cancellation Cash Advance Maximum Amount Cashback Maximum Amount Overspend Percentage PAN Mask Payment Maximum Amount Payment Minimum Amount Pre-Authorisation Default Number of Days Receipt Data Object List (Receipt DOL) Reference Application Profile Number Refund Maximum Amount Scheme Identifier Data defined by EMV PAN Card data AID Bank Identifier Code (BIC) Issuer Country Code (a2 ) Issuer Country Code (a3 ) Issuer Identification Number (IIN) IBAN Optional: other private Tag(s) Allowed service triggers Service settings Acquirer Identifier Additional Terminal Capabilities Default Dynamic Data Authentication Data Object List Default Transaction Certificate Data Object List Maximum Target Percentage to be used for Biased Random Selection Merchant Category Code Merchant Identifier Merchant Name and Location Target Percentage to be Used for Random Selection Terminal Action Code (TAC) Default Terminal Action Code (TAC) Denial Terminal Action Code (TAC) Online Terminal Capabilities Terminal Floor Limit Terminal Identification Terminal Risk Management Data Threshold Value for Biased Random Selection check Must match for Apllication Profile Selection Terminal level parameters Service level parameters Application Profilel level parameters Figure 9: Detailed SEPA-FAST Data Catagories 26/03/ /200