Host2Host Integration – POI-Switch Protocol

Version: 1.22

The estimate to complete an integration with the Commerce 2.0 solution is 21 days. Our support team is fully available to assist you during this development process and ensure a successful implementation.

Introduction

This document describes the protocol between the POI and the EP (part of SWITCH, from now on “EP”), detailing the structure of the messages, fields, data exchange and fail recovery mechanisms.

The information provided here is intended to be used by POI and EP developers to implement the communication procedures from both sides’ point of view.

In scope of this document:

Initially the transactions covered are financial or related to financial activity, but it would be perfectly possible to add non-financial functionality as requested, considering the flexibility of ISO8583 that allows to create custom made generic purpose requests and responses.

Out of scope of this document:

POI settings parameters will not be part of any ISO8583 message of this document.
Neither Cardholder signatures uploading.
Repetition of the request message is not supported.

Glossary and normative references

Below are some of the terms that we will see in this guide:

STR: System Transaction Reference. Unique identifier of the transaction at POI level.
EP:Entry Point.
POI/POS:Point Of Interaction. Combination of hardware and software that together processes a financial card transaction. It corresponds to the client part of the protocol described in this document.
SWITCH: Multi-Vendor Gateway that authorizes credit card or direct payments processing for e-businesses, online retailers, etc… It corresponds to the server part of the protocol described in this document.
PAN: Primary Account Number. The number that is embossed and/or encoded on a plastic card that identifies the issuer and the particular Cardholder account.
BIN: Bank Identification Number. Initial four to six numbers that appear on a credit card. The bank identification number uniquely identifies the institution issuing the card.
Acquirer: Financial institution (or its agent) which acquires from the card acceptor the data relating to a transaction and initiates that data into an interchange system.
Card Acceptor: Party accepting the card and presenting transaction data to an acquirer.
Card Issuer: Financial institution (or its agent) which issues the financial transaction card to the Cardholder.
Data capture: Act of collecting the details of a financial transaction.,
Transaction: One or more related messages within the same message class designed to complete (in so far as this is possible) the intention of the sender of the original message.
Receipt: Paper document on which transaction details are printed for either the Cardholder or the card acceptor.
Fallback: Alternative (lower security) technology used to collect data from a card, e.g. from a contact IC transaction to a magnetic stripe transaction.
TF: Transaction Flow.
NTF: Normal Transaction Flow.
CTF: Cancellation Transaction Flow.
UTF: Unrecognized Transaction Flow.
TTF:Timeout Transaction Flow.
TIN:Transaction Identification Number.

Below is the glossary of ISO regulations:

ISO 3166: Codes for the representation of countries and their subdivisions.
ISO 8583-1:Financial transaction card originated messages – Interchange message specifications.
EMV: Integrated Circuit Card Specification for Payments Systems, also known as EMV.
ISO 4217:Codes for the representation of currencies and funds.
ISO 7813:Financial transaction cards.
ISO 639:Standards to identify languages.

Transport Protocol Architecture

This section describes the procedure that clients (POI) must follow to communicate with the server (Eps). It will be client – server message-oriented synchronous communication using TCP sockets.

Connection establishment

The POI will always initiate the connection; it will be TCP normal connection establishment procedure using the parameters present in its configuration (IP address/host name and port). Normally the POI will have different sets of access data to reach Eps, at least main and alternative. If the connection through the main access data is not possible, the POI will use the alternative parameters, going back to main if secondary also fails; this process will be repeated a fixed number of times, also configured as part of the POI parameters, as well as the delay between attempts.

Data transfer

At network level the length of the message will be included as a 32 bytes header:

HEAD
MESSAGE

The HEAD have a fixed length of 32 bytes with the following format:

Message length: 4 bytes in little endian format.
Protocol version: 4 bytes in ASCII format.
RFU: 24 bytes for future use.

The format of MESSAGE is according to ISO 8583-1:

MGID
BITMAP1/BITMAP2
DATA ELEMENTS

This is an example of Data transfer:

Message: 01 20 80 00 00 00 00 00 00 01 01 01 02 03 04 05 06 07 08
Length of the message: 19 bytes
Version of protocol: 0001

Connection Termination

As a general rule, the element sending the last message will wait for the other closing the communications link (usually the POI will close the communications).

In the case of an Invalid Message Notification, the final sending element could be both client and server, since it does not require a response.

Message format

The structure of the messages to be exchanged is based on the ISO 8583 standard, but with the necessary modifications to match the expected functionality. There is no type or size limitation on the data that can be processed. The approach is to use the structure according to the standard, but with the necessary adaptation in the definition of messages and field contents.

The maximum message size corresponds to the sum of the size of all the bits in the protocol frame.

The message has three parts:

MGID
BITMAP1/BITMAP2
DATA ELEMENTS

For more information, see the Glossary and normative references section of this document.

Message ID (MGID)

Built with 4 bytes (ASCII numeric).

Position	Name	Description
1st	Version Number	1: ISO 8583:1993
2nd	Message Type	– 1: Authorization – 2: Financial – 3: File Actions – 4: Reversals – 5: Reconciliation – 6: Administrative
3rd	Message Function	– 0: Request – 1: Response – 2: Advice – 3: Advice Response – 4: Notification
4th	Transaction Indicator	– 0: Acquirer – 1: Repeat – 4: Others

These are the different messages included in the POI-EP interface.

MGID	Message Description
1100/1101	Authorization Request
1110	Authorization Response
1200/1201	Financial Request
1210	Financial Response
1220/1221	Financial Advice Request
1230	Financial Advice Response
1304	File Actions Request
1314	File Actions Response
1420	Cancellation Advice Request
1430	Cancellation Advice Response
1520	Reconciliation Advice Request
1530	Reconciliation Advice Response
1600	Administrative Request 2
1610	Administrative Response 2
1644	Administrative Notification

BITMAPs

The transport protocol requires one or two BITMAPs, each consisting of 8 binary bytes. The presence of the second is indicated by the most significant bit in BITMAP 1 (P1).

Data elements

These are the different data fields found in the message as configured in the BITMAPs.

The formats allowed in the data fields are:

AN: Numeric and alphabetic characters.
ANP: Numeric, alphabetic and blank characters.
ANS: Numeric, alphabetic and special characters.
ANSB: Numeric, alphabetic, special and binary characters.
N: Numeric characters.
B: Binary data.

These are the types of fields you will find:

Type	Coding	Description
Fixed	Type + Length	Fixed length fields are indicated by a length and a type: N16, AN12, ANS15
Variable 2 bytes length LLVAR	Type + minimum length +.. + maximum length (both lengths are optional)	Variable length fields up to 99 bytes: B..16, N..11, ANS10..17
Variable 3 bytes length LLLVAR	Type + minimum length +… + maximum length	Variable length fields up to 999 bytes: ANSB…300, B…, B…255
Variable 4 bytes length LLLLVAR	Type + minimum length +…. + maximum length	Variable length fields up to 9999 bytes: ANSB…2350, B…, B…1255

Communication flows

In the following sub-sections you will find the different communication flows depending on the case.

Normal Transaction Flow (NTF)

The Normal Transaction Flow (NTF) applies to the following transactions: 1100/1101-1110, 1200/1201-1210, 1220/1221-1230, 1304-1314, 1420-1430, 1600-1610.

Here is an example of a single transaction flow (request and response):

The Normal Transaction Flow (NTF) follows these steps:

The POI establishes the connection to the Switch.
The POI sends the message data to the Switch.
The Switch sends the received message data to the POI.
The POI closes the connection.

In general for all transaction types, upon receipt and successful validation of the response, the communication procedure is terminated and the transaction can continue locally at the POI.

If an additional action is required that needs connection to the EP, such as a cancellation, another complete and independent communication process will be initiated as a separate transaction.

Unrecognized Transaction Flow (UTF)

The Unrecognized Transaction Flow (UTF) applies to the following transactions: 1100/1101-1110, 1200/1201-1210, 1220/1221-1230, 1304-1314, 1420-1430, 1600-1610.

This flow (UTF) is constructed in two parts. The first part corresponds to the request/response message transaction; and the second part corresponds to the Administrative Notification request (1644).

The flow of the Unrecognized Transaction (UTF) follows these steps:

First part: request / response message.

The POI establishes the connection to the Switch.
The POI sends the message data to the Switch.
The Switch sends the received message data to the POI.
The POI closes the connection. At this point the message is not recognised by the POI.

Second part: Administrative Notification request (1644)

The POI establishes the connection to the Switch.
The POI sends MGID = 1644 to the Switch.
The POI closes the connection.

If the element receiving the message determines that the message is invalid, it will notify the sending element of the situation by means of a 1644 message including information explaining why the notification was triggered.

This data could be used by the notified element to keep a record of communication failures, following the following flow:

The POI establishes the connection to the Switch.
The POI sends the message data to the Switch. At this point the message is not recognized by the Switch.
The Switch sends the MGID = 1644 to the POI.
The POI closes the connection.

This notification mechanism applies to both sides of the information exchange flow in the same way. If the EP does not understand a request, the response will be a 1644 message including the original information from the request.

A message shall be considered unrecognizable if:

It does not follow the ISO 8583 specification protocol.
The message ID is not covered by the ISO 8583 specification.
The BITMAPs are not or have not been constructed correctly.
The fields present in the message do not correspond to the content of the BITMAPs.
One of the mandatory fields is not present in the message.

Cancellation Transaction Flow (CTF)

The Cancellation Transaction Flow (CTF) applies only to these financial transactions: 1100/1101-1110, 1200/1201-1210, 1220/1221-1230.

This flow is composed of two normal transaction flows (NTF). The first flow for the financial transaction request/response message; and the second flow for the cancellation request/response message.

The Cancellation Transaction Flow (CTF) follows these steps:

First part: financial transaction request.

The POI establishes the connection with the Switch.
The POI sends the financial message to the Switch.
The Switch sends the received financial message data to the POI.
The POI closes the connection. At this point, the financial response has been accepted by the Switch.

Second part: cancellation request / reply message

The POI establishes the connection to the Switch.
The POI sends MGID = 1420 to the Switch.
The Switch sends the received MGID = 1430 to the POI.
The POI closes the connection.

The cancellation message must be constructed and sent to delete the transaction registered in the Switch in these cases:

Communication Timeout: The Switch does not respond to the request message.
Communication MAC Error: Response from the Switch with the wrong MAC.
Communication Format Error: Switch response with some format error.
Transaction declined in GAC2: The Switch authorizes the EMV Transaction* but the POI rejects it in the second step when generating AC (wrong ARPC or other case).
Transaction declined Remove Card: The Switch authorizes the EMV* Transaction but the cardholder removes the card before the second Generate AC is performed.
Transaction declined Others: The Switch authorizes the EMV Transaction* but the POI declines it for some reason.

* The EMV Transaction is considered authorized from the SWITCH when the following two conditions are met:

BIT 39 is present in the response message and its value is equal to ‘000’.
Tag 8A is present in the response message (BIT55) and the value is a valid code authorized according to “EMV Integrated Circuit Card Specification for POI Payment System” (e.g., ’00’).

Waiting Time Transaction Flow (TTF)

The Waiting Time Transaction Flow (TTF) only applies to these financial transactions: 1200/1201-1210, 1220/1221-1230.

This flow consists of two parts. The first part for the financial transaction request; and the second part for the cancellation request/response message.

*n=0 for phase 1

The Waiting Time Transaction Flow (TTF) follows these steps:

First part: financial transaction request

The POI establishes the connection to the Switch.
The POI sends the financial message to the Switch.
The POI waits for the response, which never arrives, and times out.
The POI closes the connection and proceeds to repeat the request the number of times specified in the terminal configuration.

Second part: cancel request/response message

The POI establishes the connection to the Switch.
The POI sends MGID = 1420 to the Switch.
The Switch sends the received MGID = 1430 to the POI.
The POI closes the connection.

When the response has not been received within the set timeout or the connection is lost, a repeat message is determined for all such transactions that is sent and waits for the response.

This process is repeated the number of times specified in the terminal configuration parameters. When the cycle ends, the transaction will be considered as failed.

At that time the cancel message will be constructed and sent to delete the transaction registered in the Switch. The transaction may or may not be processed by the Switch (the POI is unable to tell), but in either case the cancel message will be sent.

POI-EP Transactions

These are the transactions included in the POI-EP interface:

Transaction Name	MGIDs
Pre-Authorization	1100/1101 (Authorization Request) 1110 (Authorization Response)
Pre-Authorization DCC	Two-transaction flow combined: – First pre-authorization (obtains DCC info) – Second pre-authorization
Sale	1200/1221 (Financial Request) 1210 (Financial Response)
Sale DCC	Two-transaction flow combined: – First sale (obtains DCC info) – Second sale
Return	1220/1221 (Financial Advice Request) 1230 (Financial Advice Response)
Pre-Authorization Completion	1220/1221 (Financial Advice Request) 1230 (Financial Advice Response)
Cancellations	1420 (Cancellation Advice Request) 1430 (Cancellation Advice Response)
Invalid Notification Message	1644 (Administrative Notification)
Key Identification	1600 (Administrative Request 2) 1610 (Administrative Response 2)
Key Load	Two-transaction flow combined: – Key Identification – 1600 (Administrative Request 2) 1610 (Administrative Response 2)
Key Renewal	Two-transaction flow combined: – Key Identification – 1600 (Administrative Request 2) 1610 (Administrative Response 2)
Offline Transaction Upload	1220/1221 (Financial Advice Request) 1230 (Financial Advice Response)
Upload EMV data of Previous Failed Transactions	1304 (File Actions Request) 1314 (File Actions Response)
Get Token	1600 (Administrative Request 2) 1610 (Administrative Response 2)
DCC Verification	1220/1221 (Financial Advice Request) 1230 (Financial Advice Response)
Cash Withdrawal	1220/1221 (Financial Advice Request) 1230 (Financial Advice Response)
Settlement	1520/1521 (Reconciliation Advice Request) 1530 (Reconciliation Advice Response)
IPP Merchant Charge	Phase 2
IPP Card Charge	Phase 2
Tax Free	Phase 2
Tax Free Diva	Phase 2
Premia	Phase 2
Other IPP	Phase 2
Consumer credit	Phase 2
Mobile Top-up	Phase 2
Prepaid card top-up	Phase 2
Operations by reference	Phase 2

Pre-Authorization transaction

This is an Authorization Transaction with request MSGID = 1100 (1101 if it is a repeated message).

Request Message Format (MSGID = 1100/1101)

BIT	Field Name	Type	Required/Optional	Description
2	BIN	N8	R	Card BIN
3	Processing Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be debited
11	Transaction ID Number	N6	R	Identifies TF as a sequence N
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS)
19	Country Code	N3	R	Country code of the merchant/terminal
22	Point of Service Entry Mode (POS/POI)	AN12	R	Details of the transaction and the terminal (card data capture capability, card data capture method, cardholder authentication method,…). Specific format in ANNEX I.
23	Card Number Sequence	N3	O	Contactless EMV cards only: PAN sequence number. If in EMV, the contactless card tag 5F34 will be included here.
24	Function Code	N3	O	Determines the purpose of the message. Fixed value: 100. See Annex 1 for values
35	Card Data	B..99	O	Encrypted track 2 data for EMV, magnetic stripe and contactless cards. Important: Mandatory when a token is not sent.
41	Terminal ID	ANS8	R	Logical ID of the terminal
42	Merchant ID	AN15	R	Logical ID of the merchant
46	Original Reference Number	ANP12	O	Original number of the pre-authorization transaction. It is generated by the SWITCH. It is only included in the pre-authorization update to refer to the original pre-authorization being updated.
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data – Status and configuration – Transaction indicators – Manual entry of transaction data (only if card data is captured manually) – Additional POI data
49	Transaction Currency Code	N3	R	Currency code used in the transaction
52	PinBlock	B8	O	Required only if there is online PIN verification
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information data.
55	EMV ICC Data	B..255	O	EMV only, EMV contactless card. Specific format in Annex 1. Data is included in TLV format: – EMV ICC/Cless Data Not required if the token is sent
56	Additional Data	B..99	O	Additional transaction data
61	Additional Business Data	B..999	O	Additional data included for business reasons
64	MAC	B8	O	Message Authentication Code

Response Message Format (MSGID = 1110)

BIT	Field Name	Type	Required/Optional	Description
3	Processing Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be debited. Same value as in the request if the transaction is approved. If not, it will be set to 0.
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS). The SWITCH generates this value, it is on the ticket.
37	Reference Number	ANP12	O	Required if the response code is approved. The SWITCH generates the transaction identification, it will be on the ticket. See Annex 3 for more information.
38	Authorization Number	ANP6	O	Required if the response code is approved. Authorization code, this data will be on the ticket.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code – Authorization response code – DCC response code (see DCC pre-authorization).
41	Terminal ID	ANS8	R	Logical ID of the terminal
42	Merchant ID	AN15	R	Logical ID of the merchant
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Transaction response data
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information data.
55	EMV ICC Data	B..255	O	EMV card only. Required if CHIP data related by the issuer is approved. Specific format in Annex 1. Data is included in TLV format: – EMV Response Data
56	Additional Data	B..99	O	Additional transaction data. Specific format in Annex 1. Data in TLV format: – Special features data
60	Transaction Data	ANS..99999	O	Transaction data
61	Additional Business Data	B..999	O	Additional data included for business reasons
64	MAC	B8	O	Message Authentication Code

The valid flows for these transactions are:

NTF
CTF: If the sale is accepted by the Switch but something incorrect happens at the POI (e.g., the printer cannot process the ticket).
UTF: If the sale response message is incorrectly formatted.
TTF: If the response never arrives at the POI.

In any case, the BIT11 (Transaction Identification Number) has the same value during the flow. Once the flow completes successfully, the POI increments its sequence, never before the flow is complete.

This is especially important in CTF and TTF flows because if the cancel request/response message fails, the POI will not increment the sequence number and will send in the next transaction the same sequence number. The Switch must delete the previous transaction in this case. See Annex 2 of this guide for more information.

For more information on why the reference number is generated by the Switch, see Annex 3 of this guide.

Pre-authorization transaction with DCC

The DCC Pre-Authorization transaction is a two-step financial transaction:

DCC Transaction Verification: the terminal sends the card data to verify if the card can be processed by DCC. If yes, the Switch responds with the information and the cardholder will choose the desired transaction currency (local or card).
DCC Pre-Authorization Transaction: When the cardholder selects the currency (local or cardholder), the POI sends the DCC Pre-Authorization Transaction with the selected currency.

Second step. Format of the request message (MSGID = 1100/1101)

BIT	Field Name	Type	Required/Optional	Description
2	BIN	N8	R	Card BIN
3	Processing Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be debited
11	Transaction ID Number	N6	R	Identifies TF as a sequence N
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS)
19	Country Code	N3	R	Country code of the merchant/terminal
22	Point of Service (POS/POI) Entry Mode	AN12	R	Details of the transaction and the terminal (card data capture capability, card data capture method, cardholder authentication method, etc.). Specific format in ANNEX I.
23	Card Number Sequence	N3	O	Contactless EMV cards only: PAN sequence number. If in EMV, the contactless card tag 5F34 will be included here.
24	Function Code	N3	R	Determines the purpose of the message. Valid values: – 185: DCC in the cardholder’s currency. – 187: DCC in the local currency See Annex 1 for values
35	Card Data	B..99	O	Encrypted track 2 data for EMV, magnetic stripe and contactless cards. Important: Required when a token is not sent.
41	Terminal ID	ANS8	R	Logical ID of the terminal
42	Merchant ID	AN15	R	Logical ID of the merchant
46	Original Reference Number	ANP12	O	Original number of the pre-authorization transaction. It is generated by the SWITCH. It is only included in the pre-authorization update to refer to the original pre-authorization being updated.
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data – Status and configuration – Transaction indicators – Manual entry of transaction data (only if card data is captured manually) – Additional POI data
49	Transaction Currency Code	N3	R	Code of the currency used in the transaction
52	PinBlock	B8	O	Required only if there is online PIN verification
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
55	EMV ICC Data	B..255	O	EMV only, contactless EMV card. Specific format in Annex 1. Data is included in TLV format: – EMV ICC/Cless Data Not required if the token is sent
56	Additional Data	B..99	R	First step in DCC verification of the transaction identifier. Specific format in Annex 1. Data is included in TLV format: – Original transaction data.
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
64	MAC	B8	O	Message authentication code

Second step. Format of the response message (MSGID = 1110)

BIT	Field Name	Type	Required/Optional	Description
3	Processing Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be debited. Same value as in the request if the transaction is approved. If not, it will be set to 0.
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS). The SWITCH generates this value, it is on the ticket.
37	Reference Number	ANP12	O	Required if the response code is approved. The SWITCH generates the identification of the transaction, it will be on the ticket. See Annex 3 for more information.
38	Authorization Number	ANP6	O	Required if the response code is approved. Authorization code, this data will be on the ticket.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code – Authorization response code
41	Terminal ID	ANS8	R	Logical ID of the terminal
42	Merchant ID	AN15	R	Logical ID of the merchant
48	Additional Information	AN…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Transaction response data
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
55	EMV ICC Data	B..255	O	EMV card only. Required if CHIP related data is approved by the issuer. Specific format in Annex 1. Data is included in TLV format: – EMV response data
56	Additional Data	B..99	O	Additional transaction data. Specific format in Annex 1.
60	Transaction Data	ANS..99999	O	Transaction data
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
64	MAC	B8	O	Message authentication code

Valid flows for the first sale transaction are:

NTF
UTF: If the sale response message is incorrectly formatted.

Valid flows for the second sale transaction are:

NTF
CTF: If the sale is accepted by the Switch but something incorrect happens at the POI (e.g., the printer cannot process the ticket).
UTF: If the sale response message is incorrectly formatted.
TTF: If the sales response never arrives.

This is especially important in CTF and TTF flows because if the cancel request/response message fails, the POI will not increment the sequence number and will send in the next transaction the same sequence number. The Switch must delete the previous transaction in this case. See Annex 2 of this guide for more information.

For more information on why the reference number is generated by the Switch, see Annex 3 of this guide.

Sale transaction

This is a financial Transaction with request MSGID = 1200 (1201 if repeated Message).

Request Message Format (MSGID = 1200/1201)

BIT	Field Name	Type	Required/Optional	Description
2	BIN	N8	R	Card BIN
3	Processing Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be debited
5	Donation Amount	N12	O	Amount to be donated
11	Transaction ID Number	N6	R	Identifies TF as a sequence N
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS)
19	Country Code	N3	R	Country code of the merchant/terminal
22	Point of Service (POS/POI) Entry Mode	AN12	R	Details of the transaction and the terminal (card data capture capability, card data capture method, cardholder authentication method, etc.). Specific format in ANNEX I.
23	Card Number Sequence	N3	O	Contactless EMV cards only: PAN sequence number. If in EMV, the contactless card tag 5F34 will be included here.
24	Function Code	N3	O	Determines the purpose of the message. Fixed value: 200. See Annex 1 for values
35	Card Data	B..99	O	Encrypted track 2 data for EMV, magnetic stripe and contactless cards. Important: Required when a token is not sent.
41	Terminal ID	ANS8	R	Logical ID of the terminal
42	Merchant ID	AN15	R	Logical ID of the merchant
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data – Status and configuration – Transaction indicators – Manual entry of transaction data (only if card data is captured manually) – Additional POI data
49	Transaction Currency Code	N3	R	Code of the currency used in the transaction
52	PinBlock	B8	O	Required only if there is online PIN verification
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
55	EMV ICC Data	B..255	O	EMV only, contactless EMV card. Specific format in Annex 1. Data is included in TLV format: – EMV ICC/Cless Data Not required if the token is sent
56	Additional Data	B..99	O	Additional transaction data
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
111	Raw Data	B..99999	O	QR-Barcode raw data. It is mandatory if the card data capture method is “QR” or “Barcode” (See BIT 22). QR-Barcode entry data will be reported in “QR entry transaction data” (See BIT 48)
128	MAC	B8	O	Message authentication code

Response Message Format (MSGID = 1210)

BIT	Field Name	Type	Required/Optional	Description
3	Processing Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be debited. Same value as in the request if the transaction is approved. If not, it will be set to 0.
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS). The SWITCH generates this value, it is on the ticket.
37	Reference Number	ANP12	O	Required if the response code is approved. The SWITCH generates the identification of the transaction, it will be on the ticket. See Annex 3 for more information.
38	Authorization Number	ANP6	O	Required if the response code is approved. Authorization code, this data will be on the ticket.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code – Authorization response code – DCC response code (see DCC pre-authorization).
41	Terminal ID	ANS8	R	Logical ID of the terminal
42	Merchant ID	AN15	R	Logical ID of the merchant
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Transaction response data
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
54	Additional Amount	AN..120	O	Partial payments: – Original transaction amount
55	EMV ICC Data	B..255	O	EMV card only. Required if CHIP related data is approved by the issuer. Specific format in Annex 1. Data is included in TLV format: – EMV response data
56	Additional Data	B..99	O	Additional transaction data. Specific format in Annex 1. Data in TLV format: – Special features data
60	Transaction Data	ANS..99999	O	Transaction data
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
64	MAC	B8	O	Message authentication code

The valid flows for this transaction are:

NTF
CTF: If the sale is accepted by the Switch but something incorrect happens at the POI (e.g. the printer cannot process the ticket).
UTF: If the sale response message is incorrectly formatted.
TTF: If the sales response never arrives.

This is especially important in CTF and TTF flows because if the cancel request/response message fails, the POI will not increment the sequence number and will send in the next transaction the same sequence number. The Switch must delete the previous transaction in this case. See Annex 2 of this guide for more information.

For more information on why the reference number is generated by the Switch, see Annex 3 of this guide.

Sale transaction with DCC

The DCC Sales Transaction is a financial transaction built in two steps:

DCC Transaction Verification: the terminal sends the card data to verify if the card can be processed by DCC. If yes, the Switch responds with the information and the cardholder will choose the desired transaction currency (local or card).
DCC Sale Transaction: When the cardholder selects the currency (local or cardholder), the POI sends the DCC Sale Transaction with the selected currency.

Second step. Format of the request message (MSGID = 1200/1201)

BIT	Field Name	Type	Required/Optional	Description
2	BIN	N8	R	Card BIN
3	Processing Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be debited
11	Transaction ID Number	N6	R	Identifies TF as a sequence N
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS)
19	Country Code	N3	R	Country code of the merchant/terminal
22	Point of Service (POS/POI) Entry Mode	AN12	R	Details of the transaction and the terminal (card data capture capability, card data capture method, cardholder authentication method, etc.). Specific format in ANNEX I.
23	Card Number Sequence	N3	O	Contactless EMV cards only: PAN sequence number. If in EMV, the contactless card tag 5F34 will be included here.
24	Function Code	N3	O	Determines the purpose of the message: – 285: DCC in the cardholder’s currency – 287: DCC in the local currency See Annex 1 for values
35	Card Data	B..99	O	Encrypted track 2 data for EMV, magnetic stripe and contactless cards. Important: Required when a token is not sent.
41	Terminal ID	ANS8	R	Logical ID of the terminal
42	Merchant ID	AN15	R	Logical ID of the merchant
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data – Status and configuration – Transaction indicators – Manual entry of transaction data (only if card data is captured manually) – Additional POI data
49	Transaction Currency Code	N3	R	Code of the currency used in the transaction
52	PinBlock	B8	O	Required only if there is online PIN verification
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
55	EMV ICC Data	B..255	O	EMV only, contactless EMV card. Specific format in Annex 1. Data is included in TLV format: – EMV ICC/Cless Data Not required if the token is sent
56	Additional Data	B..99	O	First step in DCC verification of the transaction identifier. The format is specified in Annex 1. Data is included in TLV format: – Original transaction data
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
64	MAC	B8	O	Message authentication code

Second step. Response message format (MSGID = 1210)

BIT	Field Name	Type	Required/Optional	Description
3	Processing Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be debited. Same value as in the request if the transaction is approved. If not, it will be set to 0.
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS). The SWITCH generates this value, it is on the ticket.
37	Reference Number	ANP12	O	Required if the response code is approved. The SWITCH generates the identification of the transaction, it will be on the ticket. See Annex 3 for more information.
38	Authorization Number	ANP6	O	Required if the response code is approved. Authorization code, this data will be on the ticket.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code – Authorization response code
41	Terminal ID	ANS8	R	Logical ID of the terminal
42	Merchant ID	AN15	R	Logical ID of the merchant
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Transaction response data
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
55	EMV ICC Data	B..255	O	EMV card only. Required if CHIP related data is approved by the issuer. Specific format in Annex 1. Data is included in TLV format: – EMV response data
56	Additional Data	B..99	O	Additional transaction data. Specific format in Annex 1.
60	Transaction Data	ANS..99999	O	Transaction data
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
64	MAC	B8	O	Message authentication code

Valid flows for the first sale transaction are:

NTF
UTF: If the sale response message is incorrectly formatted.

Valid flows for the second sale transaction are:

NTF
CTF: If the sale is accepted by the Switch but something incorrect happens at the POI (e.g., the printer cannot process the ticket).
UTF: If the sale response message is incorrectly formatted.
TTF: If the sales response never arrives.

For more information on why the reference number is generated by the Switch, see Annex 3 of this guide.

Refund transaction

This is a financial Advice Transaction with request MSGID = 1220 (1221 if repeated Message).

Request Message Format (MSGID = 1220/1221)

BIT	Field Name	Type	Required/Optional	Description
2	BIN	N8	R	Card BIN
3	Processing Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be debited
11	Transaction ID Number	N6	R	Identifies TF as a sequence N
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS)
19	Country Code	N3	R	Country code of the merchant/terminal
22	Point of Service (POS/POI) Entry Mode	AN12	R	Details of the transaction and the terminal (card data capture capability, card data capture method, cardholder authentication method, etc.). Specific format in ANNEX I.
23	Card Number Sequence	N3	O	Contactless EMV cards only: PAN sequence number. If in EMV, the contactless card tag 5F34 will be included here.
24	Function Code	N3	R	Determines the purpose of the message: – 200: Normal refund – 202: Refund with reference and last 4 digits of the PAN See Annex 1 for values
35	Card Data	B..99	O	Encrypted track 2 data for EMV, magnetic stripe and contactless cards. Important: Required when a token is not sent.
37	Reference Number	ANP12	O	Switch original transaction identifier for online operations, and POI Reference Number in the case of offline operations. Required for refunds with reference.
41	Terminal ID	ANS8	R	Logical ID of the terminal
42	Merchant ID	AN15	R	Logical ID of the merchant
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data – Status and configuration – Transaction indicators – Manual entry of transaction data (only if card data is captured manually) – Additional POI data
49	Transaction Currency Code	N3	R	Code of the currency used in the transaction
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
55	EMV ICC Data	B..255	O	EMV only, contactless EMV card. Specific format in Annex 1. Data is included in TLV format: – EMV ICC/Cless Data Not required if the token is sent. A refund can be made using reference + token
56	Additional Data	B..99	O	Additional transaction data
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
111	Raw Data	B..99999	O	QR-Barcode raw data. It is mandatory if the card data capture method is “QR” or “Barcode” (See BIT 22). QR-Barcode entry data will be reported in “QR entry transaction data” (See BIT 48)
128	MAC	B8	O	Message authentication code

Response Message Format (MSGID = 1230)

BIT	Field Name	Type	Required/Optional	Description
3	Processing Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be debited. Same value as in the request if the transaction is approved. If not, it will be set to 0.
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS). The SWITCH generates this value, it is on the ticket.
37	Reference Number	ANP12	O	Required if the response code is approved. The SWITCH generates the identification of the transaction, it will be on the ticket. See Annex 3 for more information.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code – Financial advice response code
41	Terminal ID	ANS8	R	Logical ID of the terminal
42	Merchant ID	AN15	R	Logical ID of the merchant
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Transaction response data
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
56	Additional Data	B..99	O	Additional transaction data. Specific format in Annex 1.
60	Transaction Data	ANS..99999	O	Transaction data
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
64	MAC	B8	O	Message authentication code

The valid flows for this transaction are:

NTF
CTF: If the transaction is accepted by the Switch but something incorrect happens in the POI (e.g. the printer cannot process the ticket).
UTF: If the transaction response is incorrectly formatted.
TTF: If the transaction response never arrives.

For more information on why the reference number is generated by the Switch, see Annex 3 of this guide.

Pre-Authorization Completion Transaction

This is a financial Advice Transaction with request MSGID = 1220 (1221 if repeated Message).

Request Message Format (MSGID = 1220/1221)

BIT	Field Name	Type	Required/Optional	Description
2	BIN	N8	R	Card BIN
3	Processing Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be debited
11	Transaction ID Number	N6	R	Identifies TF as a sequence N
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS)
19	Country Code	N3	R	Country code of the merchant/terminal
22	Point of Service (POS/POI) Entry Mode	AN12	R	Details of the transaction and the terminal (card data capture capability, card data capture method, cardholder authentication method, etc.). Specific format in ANNEX I.
23	Card Number Sequence	N3	O	Contactless EMV cards only: PAN sequence number. If in EMV, the contactless card tag 5F34 will be included here.
24	Function Code	N3	O	Determines the purpose of the message. Fixed value: 201. See Annex 1 for values
35	Card Data	B..99	O	Encrypted track 2 data for EMV, magnetic stripe and contactless cards. Important: Required when a token is not sent.
37	Reference Number	ANP12	R	Identification of the original transaction generated by the SWITCH
41	Terminal ID	ANS8	R	Logical ID of the terminal
42	Merchant ID	AN15	R	Logical ID of the merchant
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data – Status and configuration – Transaction indicators – Manual entry of transaction data (only if card data is captured manually) – Additional POI data
49	Transaction Currency Code	N3	R	Code of the currency used in the transaction
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data. Not required if the token is sent
55	EMV ICC Data	B..255	O	EMV only, contactless EMV card. Specific format in Annex 1. Data is included in TLV format: – EMV ICC/Cless Data Not required if the token is sent
56	Additional Data	B..99	O	Additional transaction data. See Annex 1 for specific formats.
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
64	MAC	B8	O	Message authentication code

Response Message Format (MSGID = 1230)

BIT	Field Name	Type	Required/Optional	Description
3	Processing Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be debited. Same value as in the request if the transaction is approved. If not, it will be set to 0.
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS). The SWITCH generates this value, it is on the ticket.
37	Reference Number	ANP12	O	Required if the response code is approved. The SWITCH generates the identification of the transaction, it will be on the ticket. See Annex 3 for more information.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code – Financial advice response code
41	Terminal ID	ANS8	R	Logical ID of the terminal
42	Merchant ID	AN15	R	Logical ID of the merchant
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Transaction response data
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
56	Additional Data	B..99	O	Additional transaction data.
60	Transaction Data	ANS..99999	O	Transaction data
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
64	MAC	B8	O	Message authentication code

The valid flows for this transaction are:

NTF
CTF: If the transaction is accepted by the Switch but something incorrect happens at the POI (e.g., the printer cannot process the ticket).
UTF: If the transaction message is incorrectly formatted.
TTF: If the transaction response never arrives.

For more information on why the reference number is generated by the Switch, see Annex 3 of this guide.

Key Identification Transaction

This is an Administrative Transaction with request MSGID = 1600.

Request Message Format (MSGID = 1600)

BIT	Field Name	Type	Required/Optional	Description
11	Transaction ID Number	N6	R	Identifies TF as a sequence N
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS)
24	Function Code	N3	R	Determines the purpose of the message. Fixed value: – 690 See Annex 1 for values
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data – Status and configuration
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
72	Data Record	B…999	R	Data to identify keys present in the POI. Specific format in Annex 1. Data included in TLV format – Key identification data
128	MAC	B8	O	Message authentication code

Response Message Format (MSGID = 1610)

BIT	Field Name	Type	Required/Optional	Description
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS). The SWITCH generates this value, it is on the ticket.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code – Key response code
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
72	Data Record	B…999	R	Data containing information of the challenge from the server. Specific format in Annex 1. Data is included in TLV format: – Response to key identification data
128	MAC	B8	O	Message authentication code

The valid flows for this transaction are:

NTF
UTF: if response is a bad formatted message.

Key Load Transaction

The Key Upload Transaction is an administrative transaction that follows two steps:

Key Identification Transaction: The terminal sends the key data and receives a fragment of the information (a challenge).
Key Upload Transaction: The terminal sends a MAC calculated with the challenge received in the Key Identification Transaction (for the authentication process) and receives the new Upload Keys if the challenge is calculated correctly.

The second step is an Administrative Transaction with request MSGID = 1600.

Second step. Request Message Format (MSGID = 1600)

BIT	Field Name	Type	Required/Optional	Description
11	Transaction ID Number	N6	R	Identifies TF as a sequence N
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS)
24	Function Code	N3	R	Determines the purpose of the message. Fixed value: – 691 See Annex 1 for values
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data – Status and configuration
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
72	Data Record	B…999	R	Data to identify keys present in the POI. Specific format in Annex 1. Data included in TLV format – Key identification data
128	MAC	B8	O	Message authentication code

Second step. Response Message Format (MSGID = 1610)

BIT	Field Name	Type	Required/Optional	Description
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS). The SWITCH generates this value, it is on the ticket.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code – Key response code
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
72	Data Record	B…999	R	Data containing information of the challenge from the server. Specific format in Annex 1. Data is included in TLV format: – Response to key identification data
111	Raw Data	B..999999	O	Token value
128	MAC	B8	O	Message authentication code

The valid flows for the Second Step transaction are:

NTF
UTF: if response is a bad formatted message.

Key Renovation Transaction

The Key Renewal Transaction is an administrative transaction that follows two steps:

Key Identification Transaction: The terminal sends the data and receives a fragment of the information (challenge).
Administrative Transaction: The terminal sends a MAC calculated with the challenge received from the Key Identification Transaction (by the authentication process) and receives the new renewal keys.

The second step is an Administrative Transaction with request MSGID = 1600.

Second step. Request Message Format (MSGID = 1600)

BIT	Field Name	Type	Required/Optional	Description
11	Transaction ID Number	N6	R	Identifies TF as a sequence N
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS)
24	Function Code	N3	R	Determines the purpose of the message. Fixed value: – 692 See Annex 1 for values
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data – Status and configuration
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
72	Data Record	B…999	R	Data to identify keys present in the POI. Specific format in Annex 1. Data included in TLV format – Key update data
128	MAC	B8	O	Message authentication code

Second step. Response Message Format (MSGID = 1610)

BIT	Field Name	Type	Required/Optional	Description
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS). The SWITCH generates this value, it is on the ticket.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code – Key response code
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
72	Data Record	B…999	R	Data containing information of the challenge from the server. Specific format in Annex 1. Data is included in TLV format: – Response to key update data
128	MAC	B8	O	Message authentication code

The valid flows for the Second Step transaction are:

NTF
UTF: if response is a bad formatted message.

Key Removing Transaction

The Key Removal Transaction is an administrative transaction that follows two steps:

Key Identification Transaction: The terminal sends the key data and receives a fragment of the information (challenge).
Administrative Transaction: The terminal sends a MAC calculated with the challenge received in the Key Identification Transaction (by the authentication process) and receives the references of the keys to be deleted.

The second step is an Administrative Transaction with request MSGID = 1600.

Second step. Request Message Format (MSGID = 1600)

BIT	Field Name	Type	Required/Optional	Description
11	Transaction ID Number	N6	R	Identifies TF as a sequence N
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS)
24	Function Code	N3	R	Determines the purpose of the message. Fixed value: – 693 See Annex 1 for values
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data – Status and configuration
53	Security Control Information	B..99	R	Details of the security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security information data.
61	Additional Business Data	B..999	O	Additional data included for commercial reasons
72	Data Record	B…999	R	Data containing the authentication data and the terminal challenge data. Specific format in Annex 1. Data is included in TLV format: – Key data update. For the generation of this data, it is necessary to use the Key Identification Data Response received in the First Step.
128	MAC	B8	O	Message authentication code

Second step. Response Message Format (MSGID = 1610)

BIT	Field Name	Type	Required/Optional	Description
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request.
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS). The SWITCH generates this value, it is on the ticket.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code – Key response code
53	Security Control Information	B..99	R	Details of security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information Data
61	Additional Business Data	B..999	O	Additional data included for business purposes.
72	Data Record	B…999	R	Data containing information about the server challenge. Specific format in Annex 1. Data is included in TLV format: – Response to key update data
128	MAC	B8	O	Message authentication code.

The valid flows for the Second Step transaction are:

NTF
UTF: If response is a bad formatted message.

Cancellations Transactions

This is a Cancellation Advice Transaction with request MSGID = 1420.

Request Message Format (MSGID = 1420)

BIT	Field Name	Type	Required/Optional	Description
3	Process Code	N6	R	Additional transaction qualifiers.
4	Transaction Amount	N12	R	Amount to be debited.
11	Transaction ID Number	N6	R	Identifies TF as a sequence N.
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS).
19	Country Code	N3	R	Country code of the merchant/terminal.
24	Function Code	N3	O	Determines the purpose of the message. Same value as the transaction being canceled. See Annex 1 for values.
25	Reason Code	N4	O	Reason for the cancellation(s). Valid values: – 4001: Pre-authorization cancellation. – 4006: Communication time expired. – 4007: Communication MAC error. – 4008: Communication format error. – 4009: Declined transaction: ARPC. – 4010: Declined transaction: AAC. – 4011: Declined transaction: GAC2. – 4012: Declined transaction: Remove Card. – 4013: Declined transaction: Others. – 4020: Transaction declined by the Customer. IMPORTANT: Required field for pre-authorization transactions.
37	Reference Number	ANP12	O	Required for pre-authorization transactions.
41	Terminal Identifier	ANS8	R	Logical ID of the terminal.
42	Merchant Identifier	AN15	R	Logical ID of the merchant.
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data. – Status and configuration. – Transaction indicators.
53	Security Control Information	B..99	R	Details of security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information Data.
55	EMV ICC Data	B..255	O	Mandatory in EMV cancellations. Specific format in Annex 1. Data is included in TLV format: – EMV ICC/Cless Data (2nd GenAC data). Not required if the token is sent.
56	Additional Data	B..99	R	Original transaction ID. Included in TLV format. See Annex 1 for specific formats.
61	Additional Business Data	B..999	O	Additional data included for business purposes.
64	MAC	B8	O	Message authentication code.

Response Message Format (MSGID = 1430)

BIT	Field Name	Type	Required/Optional	Description
3	Process Code	N6	R	Additional transaction qualifiers.
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request.
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS).
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code (The switch will always process the cancellation (==000) except in cases where it cannot find the original transaction data). – Cancellation response code.
41	Terminal Identifier	ANS8	R	Logical ID of the terminal.
42	Merchant Identifier	AN15	R	Logical ID of the merchant.
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Transaction response data.
53	Security Control Information	B..99	R	Details of security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information Data.
60	Transaction Data	ANS..99999	O	This field is present in the pre-authorization cancellation.
61	Additional Business Data	B..999	O	Additional data included for business purposes.
64	MAC	B8	O	Message authentication code.

The Cancellation Transaction is part of the CTF or TTF flows to cancel a previous original transaction.

This cancellation is automatic and transparent to the cardholder.

The equivalent manual procedure would be to launch the process of a Return Transaction.

Invalid Message Notification

This is an Administrative Notification Transaction with request MSGID = 1644.

Request Message Format (MSGID = 1644)

BIT	Field Name	Type	Required/Optional	Description
11	Transaction ID Number	N6	R	Identifies TF as a sequence N.
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS).
24	Function Code	N3	O	Determines the purpose of the message. Same value as the original transaction. See Annex 1 for values.
25	Reason Code	N4	O	Reason for the cancellation(s). Valid values: – 4600: Format error. – 4601: Unrecognized message.
41	Terminal Identifier	ANS8	O	Logical ID of the terminal.
42	Merchant Identifier	AN15	O	Logical ID of the merchant.
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Status and configuration (Key version).
53	Security Control Information	B..99	R	Details of security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information Data.
56	Additional Data	B..99	R	Original transaction ID. Included in TLV format. See Annex 1 for specific formats.
61	Additional Business Data	B..999	O	Additional data included for business purposes.
64	MAC	B8	O	Message authentication code.

The Invalid Message Notification is a transaction that is part of the UTF flow to notify of an incorrect formatting / unknown message that the POI has previously received.

This notification is automatic and transparent to the cardholder.

Offline Transaction Upload

This is a financial Advice Transaction with request MSGID = 1220 (1221 if repeated Message).

Request Message Format (MSGID = 1220)

BIT	Field Name	Type	Required/Optional	Description
2	BIN	N8	R	Card BIN.
3	Process Code	N6	R	Additional transaction qualifiers.
4	Transaction Amount	N12	R	Amount to be debited.
11	Transaction ID Number	N6	R	Identifies TF as a sequence N.
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS).
19	Country Code	N3	R	Country code of the merchant/terminal.
22	Point of Service Entry Mode (POS/POI)	AN12	R	Details of the transaction and the terminal (card data capture capability, card data capture method, cardholder authentication method, etc.).
23	Card Number Sequence	N3	O	Contactless EMV cards only: PAN sequence number. If in EMV, the contactless card tag 5F34 will be included here.
24	Function Code	N3	O	Determines the purpose of the message. Fixed value: 800. See Annex 1 for values.
35	Card Data	B..99	O	Encrypted track 2 data for EMV, magnetic stripe and contactless cards. Important: Mandatory when a token is not sent.
37	Reference Number	ANP12	R	Original transaction identification generated by the SWITCH.
38	Authorization Number	ANP6	R	Offline authorization number generated by the POI.
41	Terminal Identifier	ANS8	R	Logical ID of the terminal.
42	Merchant Identifier	AN15	R	Logical ID of the merchant.
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data. – Status and configuration.
49	Transaction Currency Code	N3	R	Currency code used in the transaction.
52	PinBlock	B8	O	Mandatory if there is online PIN verification.
53	Security Control Information	B..99	R	Details of security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information Data. Not required if the token is sent.
55	EMV ICC Data	B..255	O	EMV only, EMV contactless card. Specific format in Annex 1. Data is included in TLV format: – EMV ICC/Cless Data.
61	Additional Business Data	B..999	O	Additional data included for business purposes.
64	MAC	B8	O	Message authentication code.

Response Message Format (MSGID = 1230)

BIT	Field Name	Type	Required/Optional	Description
3	Process Code	N6	R	Additional transaction qualifiers.
4	Transaction Amount	N12	R	Amount to be debited. Same value as in the request if the transaction is approved. Otherwise, it will be set to 0.
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request.
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS). Same value as in the request.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code.
41	Terminal Identifier	ANS8	R	Logical ID of the terminal.
42	Merchant Identifier	AN15	R	Logical ID of the merchant.
53	Security Control Information	B..99	R	Details of security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information Data.
61	Additional Business Data	B..999	O	Additional data included for business purposes.
64	MAC	B8	O	Message authentication code.

The valid flows for this transaction are:

NTF
UTF: If the transaction message is incorrectly formatted.
TTF: If the transaction response never arrives.

In either case, the BIT11 (Transaction Identification Number) has the same value during the flow. Once the flow completes successfully, the POI increments its sequence, never before the flow is complete.

This is especially important in the TTF flow because if the cancel request/response message fails, the POI will not increment the sequence number and will send in the next transaction the same sequence number. The Switch must delete the previous transaction in this case. See Annex 2 of this guide for more information.

For more information on why the reference number is generated by the Switch, see Annex 3 of this guide.

Previous Failed Transactions EMV Data Upload

This is an File Action Transaction with request MSGID = 1304.

Request Message Format (MSGID = 1304)

BIT	Field Name	Type	Required/Optional	Description
11	Transaction ID Number	N6	R	Identifies TF as a sequence N.
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS).
24	Function Code	N3	O	Determines the purpose of the message. Fixed value: 802. See Annex 1 for values.
41	Terminal Identifier	ANS8	R	Logical ID of the terminal.
42	Merchant Identifier	AN15	R	Logical ID of the merchant.
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data. – Status and configuration. – Up/download data (optional).
53	Security Control Information	B..99	R	Details of security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information Data. Not required if the token is sent.
61	Additional Business Data	B..999	O	Additional data included for business purposes.
111	Raw Data	B..99999	R	Offline data file. The format of this file is included in BIT48 (UP/DOWNLOAD DATA). Specific format in Annex 1.
128	MAC	B8	O	Message authentication code.

Response Message Format (MSGID = 1314)

BIT	Field Name	Type	Required/Optional	Description
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request.
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS). This value is on the ticket.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code. – Cancellation response code.
41	Terminal Identifier	ANS8	R	Logical ID of the terminal.
42	Merchant Identifier	AN15	R	Logical ID of the merchant.
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Transaction response data.
53	Security Control Information	B..99	R	Details of security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information Data.
61	Additional Business Data	B..999	O	Additional data included for business purposes.
64	MAC	B8	O	Message authentication code.

Valid flows for this transaction are:

NTF
UTF: If response is a bad formatted message.

Get Token

Administrative message to get an authentication token.

Request Message Format (MSGID = 1600)

BIT	Field Name	Type	Required/Optional	Description
11	Transaction ID Number	N6	R	Identifies TF as a sequence N.
12	Local Transaction Date	N12	R	Local date and time (YYDDHHMMSS).
24	Function Code	N3	R	Determines the purpose of the message. Fixed value: 900. See Annex 1 for values.
41	Terminal Identifier	ANS8	R	Logical ID of the terminal.
42	Merchant Identifier	AN15	R	Logical ID of the merchant.
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data. – Status and configuration.
53	Security Control Information	B..99	R	Details of security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information Data.
61	Additional Business Data	B..999	O	Additional data included for business purposes.
64	MAC	B8	O	Message authentication code.

Response Message Format (MSGID = 1610)

BIT	Field Name	Type	Required/Optional	Description
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request.
12	Local Transaction Date	N12	R	Local date and time (YYDDHHMMSS). This value is on the ticket.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code.
41	Terminal Identifier	ANS8	R	Logical ID of the terminal.
42	Merchant Identifier	AN15	R	Logical ID of the merchant.
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Transaction response data.
53	Security Control Information	B..99	R	Details of security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information Data.
61	Additional Business Data	B..999	O	Additional data added for commercial reasons.
111	Raw Data	B..99999	R	Received token value
128	MAC	B8	O	Message authentication code

DCC Verification Transaction

This is a financial Advice Transaction with request MSGID = 1220 (1221 if repeated Message).

Request Message Format (MSGID = 1220)

BIT	Field Name	Type	Required/Optional	Description
2	BIN	N8	R	Card BIN
3	Process Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be debited
11	Transaction ID Number	N6	R	Identifies TF as a sequence N
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS) of the offline transaction generated by the POI
19	Country Code	N3	R	Country code of the merchant/terminal
22	Point of Service Entry Mode (POS/POI)	AN12	R	Details of the transaction and the terminal (card data capture capability, card data capture method, cardholder authentication method, etc.).
24	Function Code	N3	R	Determines the purpose of the message. Fixed value: 300. See Annex 1 for values.
35	Card Data	B..99	O	Encrypted track 2 data for EMV, magnetic stripe and contactless cards. Important: Mandatory when a token is not sent.
41	Terminal Identifier	ANS8	R	Logical ID of the terminal
42	Merchant Identifier	AN15	R	Logical ID of the merchant
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data – Status and configuration – Transaction indicators – Manual entry of transaction data (only if card data is manually captured)
49	Transaction Currency Code	N3	R	Currency code used in the transaction
53	Security Control Information	B..99	R	Details of security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information Data
61	Additional Business Data	B..999	O	Additional data included for business purposes
64	MAC	B8	O	Message authentication code

Response Message Format (MSGID = 1230)

BIT	Field Name	Type	Required/Optional	Description
3	Process Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be debited. Same value as in the request if the transaction is approved. Otherwise, it will be set to 0.
6	Foreign Currency Amount	N12	O	Amount expressed in the card currency. Mandatory if the transaction is suitable for DCC processing
10	Exchange Rate	N8	O	Exchange rate from local currency to foreign currency. BIT6 = BIT4 x BIT10. The leftmost digit indicates the decimal position from left to right; the rest of the digits represent the exchange rate value: 1.424209=61424209. Mandatory if the transaction is suitable for DCC (Dynamic Currency Conversion) processing.
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS). The SWITCH generates this value, it is on the ticket.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code – DCC response code
41	Terminal Identifier	ANS8	R	Logical ID of the terminal
42	Merchant Identifier	AN15	R	Logical ID of the merchant
49	Local Currency Code	N3	R	Local currency code used in the transaction
51	Foreign Currency Code	N3	O	Transaction card currency code. Required if the transaction is suitable for DCC processing
53	Security Control Information	B..99	R	Details of security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information Data
56	Additional Data	B..99	O	Additional transaction data. Specific format in Annex 1. Data included in TLV format: – DCC transaction data (including card currency tag) Required if the transaction is suitable for DCC processing.
60	Transaction Data	ANS..99999	O	Transaction data
61	Additional Business Data	B..999	O	Additional data included for business purposes
64	MAC	B8	O	Message authentication code

Valid flows for this transaction are:

NTF
UTF: If transaction response is a bad formatted message.

Cash-out Transaction

This is a financial Advice Transaction with request MSGID = 1220 (1221 if repeated Message).

Request Message Format (MSGID = 1220/1221)

BIT	Field Name	Type	Required/Optional	Description
2	BIN	N8	R	Card BIN
3	Process Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be withdrawn
11	Transaction ID Number	N6	R	Identifies TF as a sequence N
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS)
19	Country Code	N3	R	Country code of the merchant/terminal
22	Point of Service Entry Mode (POS/POI)	AN12	R	Details of the transaction and the terminal (card data capture capability, card data capture method, cardholder authentication method, etc.).
23	Card Secuence Number	N3	O	For EMV and contactless cards only: PAN sequence of the card. If present on EMV or contactless cards, the PAN sequence number will be included here (using tag 5F34).
24	Function Code	N3	R	Determines the purpose of the message. Fixed value: 310. See Annex 1 for values.
35	Card Data	B..99	O	Encrypted track 2 data for EMV, magnetic stripe and contactless cards. Important: Mandatory when a token is not sent.
41	Terminal Identifier	ANS8	R	Logical ID of the terminal
42	Merchant Identifier	AN15	R	Logical ID of the merchant
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identification data – Status and configuration – Transaction indicators – Manual entry of transaction data (only if card data is manually captured) – Additional POI data
49	Transaction Currency Code	N3	R	Currency code used in the transaction
52	PinBlock	B8	O	Mandatory if there is online PIN verification
53	Security Control Information	B..99	R	Details of security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information Data
55	EMV ICC Data	B..255	O	Contactless or EMV cards only. Format in Annex 1. Data is included in TLV format: – emv icc/cless data
56	Additional Data	B..99	O	Additional transaction data
61	Additional Business Data	B..999	O	Additional data included for business purposes
64	MAC	B8	O	Message authentication code

Response Message Format (MSGID = 1230)

BIT	Field Name	Type	Required/Optional	Description
3	Process Code	N6	R	Additional transaction qualifiers
4	Transaction Amount	N12	R	Amount to be debited. Same value as in the request if the transaction is approved. Otherwise, it will be set to 0.
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS). It is on the ticket.
37	Reference Number	ANP12	O	Required if the response code is approved Switch generates transaction identifier. Data will be on the ticket.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: – Generic response code – Cash withdrawal response code
41	Terminal Identifier	ANS8	R	Logical ID of the terminal
42	Merchant Identifier	AN15	R	Logical ID of the merchant
48	Additional Information	B…999	R	Additional transaction information. Format Annex 1. Data is included in TLV format: – Transaction response data
53	Security Control Information	B..99	R	Details of security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information Data
55	EMV Issuer Data	B..255	O	EMV cards only. Required if CHIP related data is approved by issuer. Data is included in TLV format.
56	Additional Data	B..99	O	Additional transaction data. Specific format in Annex 1. Data included in TLV format: – DCC transaction data (including card currency tag) Required if the transaction is suitable for DCC processing.
60	Transaction Data	ANS..99999	O	Transaction data
61	Additional Business Data	B..999	O	Additional data included for business purposes
64	MAC	B8	O	Message authentication code

The valid flows for this transaction are:

NTF
CTF: If the transaction is accepted by the Switch but something incorrect happens at the POI (e.g., the printer cannot process the ticket).
UTF: If the transaction message is incorrectly formatted.
TTF: If the transaction response never arrives.

For more information on why the reference number is generated by the Switch, see Annex 3 of this guide.

Settlement Transaction

This is a Reconciliation Advice Transaction with request MSGID = 1520.

Request Message Format (MSGID = 1520)

BIT	Field Name	Type	Required/Optional	Description
11	Transaction ID Number	N6	R	Identifies TF as a sequence N
12	Local Transaction timestamp	N12	R	Local date and time (YYMMHHMMSS)
24	Function Code	N3	R	Determines the purpose of the message. Fixed value: 500 See Annex I for all values.
41	Terminal Identifier	ANS8	R	Logical ID of the terminal
42	Merchant Identifier	AN15	R	Logical ID of the merchant
48	Additional Information	B…999	R	Additional transaction information. Specific format in Annex 1. Data is included in TLV format: – Identifications Data – Status and configuration
53	Security Control Information	B..99	R	Security data details used for MAC. Specific format in ANNEX I. Data included in TLV format: – Security Information Data
61	Additional Business Data	B..999	O	Additional data included for business purposes
64	MAC	B8	O	Message authentication code

Response Message Format (MSGID = 1530)

BIT	Field Name	Type	Required/Optional	Description
11	Transaction ID Number	N6	R	Identifies TF as a sequence N. Same value as in the request
12	Local Transaction Date	N12	R	Local date and time (YYMMDDHHMMSS). It is on the ticket.
39	Response Code	N3	R	Transaction code. Values in Annex 1. Valid ones are: Valid Values: – Generic Response Code – Reconciliation Response Code
41	Terminal Identifier	ANS8	R	Logical ID of the terminal
42	Merchant Identifier	AN15	R	Logical ID of the merchant
48	Additional Information	B…999	R	Additional transaction information. Format Annex 1. Data is included in TLV format: – Transaction response data
53	Security Control Information	B..99	R	Details of security data used for PIN/TRACK/PAN encryption and MAC. Specific format in Annex 1. Data is included in TLV format: – Security Information Data
60	Transaction Data	ANS..99999	O	Transaction data
61	Additional Business Data	B..999	O	Additional data included for business purposes
74	Number of Credits Transactions	N10	R	Total number of Credits transactions
76	Number of Debits Transactions	N10	R	Total number of Debits transactions
86	Credits Amount	N16	R	Total Amount of Credits transactions
88	Debits Amount	N16	R	Total Amount of Debits transactions
97	Net Settlement Amount	X+N16	R	Net Settlement Amount where the first byte is either ‘C’ to indicate a positive or Credit value, or ‘D’ to indicate a negative or Debit value, followed by the numeric value (using 16 digits) result of the following operation: BIT97 = BIT86 – BITP88
128	MAC	B8	O	Message authentication code

Valid flows for this transaction are:

NTF
UTF: If transaction response is a bad formatted message.

Annex 1

In this section you will find specific information about some of the elements seen on this guide.

Proprietary tags

This is the list of proprietary tags used in these specifications in TLV format:

Tag	Length	Description	Format
DF01	45	Terminal Identification. Concatenation of the following fields: – Manufacturer Code: an5 Code to identify the manufacturer of the Point of Interaction (POI). – Family Code: an5 Code to identify the family of the POI. – Model Code: an5 Code to identify the model of the POI. – Serial Number: an30 Serial number of the POI. All left padded with the space character (0x20).	An45
DF02	9..59	Software Identification. Concatenation of the following fields: – Application Name Length: b1 – Application Name: an…30 Name of the financial application in the Point of Interaction (POI). – Application Version Length: b1 – Application Version: an…10 Version information of the financial application. – Application Release Length: b1 – Application Release: an…10 Release information of the financial application. – Application Date: an6 (YYMMDD) Date information of the financial application.	An9..59
DF03	10	GSM_SIM Identification. Concatenation of the following fields: – ICCID: n20.	N20
DF04	2	Original Message ID (BIT1).	N4
DF05	3	Original Transaction Identification Number (BIT11). This field will be: – OPTIONAL for pre-authorization cancellations (bit25=4001) REQUIRED for any other reason in the cancellation code.	N6
DF06	6	Original Transaction Local Timestamp (BIT12).	N12
DF07	19	PIN Security Data. Concatenation of the following fields: – KSN: b10 Key Serial Number. – Random Number: b8 Random number used in the cryptographic processes, if not used, it will be set to 0x00. – PIN Length: b1 Determines the length of the PIN entered for online verification, 0 if no PIN, 4 to 12 if entered.	B19
DF08	6	Currency Information. Concatenation of the following fields: – Currency Code: n3. Left padded with Hex ‘0’. – Currency Exponent: n1 Left padded with Hex ‘0’. – Currency Label: an3	B6
DF09	18	MAC Security Data. Concatenation of the following fields: – KSN: b10 Key Serial Number. – Random Number: b8 Random number used in the cryptographic processes, if not used, it will be set to 0x00.	B18
DF10	18	Encryption Security Data. Concatenation of the following fields: – Key Serial Number (KSN): b10. – Random Number: b8. Random number used in the cryptographic processes, if not used, it will be set to 0x00.	B18
DF11	25	Key Version. Concatenation of the following fields: – KEK Version: b2 Version of the KEK BDK. – KEK KCV: b3 KEK Key Check Value. – KAUT Version: b2 Version of the KAUT BDK. – KAUT KCV: b3 KAUT Key Check Value. – KPIN Version: b2 Version of the KPIN BDK. – KPIN KCV: b3 KPIN Key Check Value. – KPAN Version: b2 Version of the KPAN BDK. – KPAN KCV: b3 KPAN Key Check Value. – KMAC Version: b2 Version of the KMAC BDK. – KMAC KCV: b3 KMAC Key Check Value. If a key is not present, both version and KCV will be set to 0x00.	B25
DF12	2	Parameter Version. Determines the versions of the parameters loaded in the Point of Interaction (POI) memory.	N4
DF13	6	Functionalities. Concatenation of the following fields: – DCC: Flag indicating the DCC capabilities of the POI: – 0: No support for DCC – 1: Print data based DCC functionality – 2: Display data based DCC functionality – Digital signature capture: Flag with the POI’s capabilities regarding signature capture: – 0: Not supported – 1: Supported – EMV OFF: Flag informing if standard EMV default offline processing is possible: – 0: No default processing – 1: Default processing allowing offline approval – Magstripe OFF: Determines the ability of the POI to support offline magstripe based transactions. – 0: No support – 1: Support – Template ticket: Determines the ability of the POI to support template tickets. – 0: No support – 1: Support – Cash withdrawal: Determines the ability of the POI to support cash withdrawal functionality. – 0: No support – 1: Support – PSD2: Determines the ability of the POI to support PSD2 functionality (Simple and Double Tap SCA). – 0: No support – 1: Support – QR Code-Barcode (Not yet supported): – 0: No support – 1: Support – Donations: Determines the ability of the POI to support donations functionality. – 0: No support – 1: Support – Alipay: Determines the ability of the POI to support Alipay functionality. – 0: No support – 1: Support – Partial Approvals: Determines the ability of the POI to support partial payment approvals. – 0: No support – 1: Support – RFU (Reserved for future use):	N12
DF14	3	Language code according to ISO639-3: an3 Right padded with spaces.	An3
DF15	..5	Time zone abbreviation: an..5 Determines the current time zone code of the Point of Interaction (POI).	An..5
DF16	6	EMV Configuration Data. Concatenation of the following fields: – EMV CA Public Key Version. Type: b2 General EMV parameter stored in the Point of Interaction (POI). Examples: 0001 – EMV Terminal Capabilities. Type: b3 General EMV parameter stored in the POI. Examples: E0F088 – EMV Terminal Type. Type: b1 General EMV parameter stored in the POI. Examples: 22	B6
DF18	2	Acquirer code. Included in response messages to indicate the acquirer code which finally processed the transaction. Example: 2100	N4
DF19	8	Acquirer terminal ID. Included in response messages to indicate the terminal identification within processor system. Note: If the merchant has multi-acquirer capability, this field could be different of bit 41. DF19 must be printed in the receipt.	An8
DF20	2	Signature Indicator: Number of signatures captured and stored in the Point of Interaction (POI) (not yet uploaded).	N4
DF21	2	Offline Transaction Indicator: Number of offline transactions stored in the Point of Interaction (POI) (not yet uploaded).	N4
DF22	2	Previous EMV Failed Transaction Indicator: Number of previous EMV failed transactions not yet uploaded.	N4
DF23	2	Special Feature Indicator: Reports on special features performed/allowed by the Point of Interaction (POI) or SWITCH. 2 bytes in network order (MSB-LSB), where bit 1 will be the rightmost bit in the LSB byte. – Bit 1: Cash withdrawal functionality is allowed by SWITCH. – Bit 2: Simple Tap SCA functionality was performed by the POI. – Bit 3: Double Tap SCA functionality was performed by the POI. – Bit 4: Donation process was performed by the POI. – Bit 5: RFU (Reserved for future use). – Bit 6: RFU. – Bit 7: RFU. – Bit 8: RFU. – Bit 9: RFU. – Bit 10: RFU. – Bit 11: RFU. – Bit 12: RFU. – Bit 13: RFU. – Bit 14: RFU. – Bit 15: RFU. – Bit 16: RFU.	B2
DF24	5	Settlement Data. Concatenation of the following fields: – Settlement Date: n6 Settlement date in YYMMDD format. – Settlement Number ID: n4 Settlement number identification.	N10
DF25	8	Cash Withdrawal Data. Concatenation of the following fields: – Acquirer Fee Type: n2 Examples: 01 – Acquirer Fee Currency: n4 Currency of the acquirer fee amount Examples: 0978 -> EURO – Acquirer Fee Amount: n4 Fee amount in the terminal currency Examples: 0100 -> 1.00 0000 -> No fee – Additional Fee Type: n2 Examples: 01 – Additional Fee Amount: n4 Additional fee amount in the terminal currency Examples: 0100 -> 1.00 0000 -> No fee	N16
DF26	4	DCC (Dynamic Currency Conversion) Data. Concatenation of the following fields: – DCC Type: n2 – 00 -> Unknown – 01 -> Visa – 02 -> MasterCard – Mark-up Percentage: n6 Examples: 000101 -> 1.01 % 010000 -> 100 % 000000 -> 0 %	N8
DF27	..22	Previous Donation Query ID Data. Example: caritas00001	An..22
DF28	36	Merchant ticket transaction ID – electronic ticket reference. To be used in Comercia Portal get from Cloud the electronic ticket for a specific operation. This reference of electronic ticket has the following Universally Unique Identifier (UUID) format: The ID is in hexadecimal digits, meaning it uses the numbers 0 through 9 and letters A through F. The hexadecimal digits are grouped as 32 hexadecimal characters with four hyphens: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX. In order to obtain from portal the ticket storage in cloud, it is mandatory to call using “https://ticketdigital.in/receipt/”+ “Merchant ticket transaction id(DF28)”	An36
DF30	32	Manually entered card data. If the manually entered card data contains the full PAN, expiry date and CVV2, then this block will be encrypted as specified by the Point of Interaction (POI) cryptography. If the manually entered card data contains the last 4 digits of the PAN, then this block will not be encrypted. The last 4 digits of the PAN (for normal block compatibility) will be padded with zeros up to 19. For example, if the last 4 digits are 8118, the block will look like this: 00000000000000000000008118 when: Expiry Date: 0000 (not entered) CVV2: 000 (not entered) PAN: 000000000000008118	B32
DF31	1	QR-barcode information data. Valid values: – 00 -> Unknown Format – 01 -> EAN25 Barcode Format – 02 -> EAN39 Barcode Format – 03 -> EAN128 Barcode Format – 04 -> PDF417 Barcode Format – 05 -> QR Alipay Format	N2
DF40	2	Load Indicator. Bitmap indicating the Point of Interaction (POI) data to be loaded, with 2 bytes in network order (MSB-LSB), where bit 1 will be the rightmost bit in the LSB byte. – Bit 1: Offline transactions – Bit 2: Signatures – Bit 3: RFU (Reserved for future use) – Bit 4: RFU – Bit 5: RFU – Bit 6: RFU – Bit 7: RFU – Bit 8: RFU – Bit 9: RFU – Bit 10: RFU – Bit 11: RFU – Bit 12: RFU – Bit 13: RFU – Bit 14: RFU – Bit 15: RFU – Bit 16: RFU	B2
DF52	–	COF (Card-on-File). Only applicable for purchase, pre-authorization and pre-authorization confirmation. Concatenation of the following fields: – Usage: an1 R – Recurrent I – Installments C – One-time purchase D – Deferred E – Forward H – Re-authorization M – Incremental N – No show – First transaction indicator: an1 S – Yes N – No – TID: an15 15 left aligned characters Examples: – First transaction: CS – First transaction response: CS123456789123456, CS123456789 – Second transaction: CN123456789123456 – Second transaction response: CN123456789123456	An..17
DF60	0..42	Processor Data. Processor specific data used for transaction resolution. – Processor/Acquirer ID: an…42 String with the name or description of the acquiring entity.	An…42
DF70	20	File Information Data. Concatenation of the following fields: – File Name: an15 Left padded with the space character (0x20). – File Extension: an4 Left padded with the space character (0x20). – Compressed: an1 1 – Compressed File (GZIP Format) 0 – Uncompressed File	an19
DF73	1	Load mode: batch or one by one – 0x00: Batch – 0x01: One by one	B1
DF90	4	Key Load/Renewal Indicator Data containing challenge information indicating that a key load/renewal is requested: – RND: b4; Random number	B4
DF91	4	MAC Calculation Indicator Data containing the MAC calculated with KAUTH including RND: – MAC: b4; MAC Calculation	B4
DF92	80	Key Load/Renewal Values: – KEK Value: b16 – KAUT Value: b16 – KPIN Value: b16 – KPAN Value: b16 – KMAC Value: b16 If a key is not present, it will be set to 0x00.	B80
DF93	4	Key Deletion Indicator Data containing challenge information indicating that a key deletion is requested: – RND: b4; Random number	B4
DF94	2	Key remove flags. Bitmap indicating keys to be removed, 2 bytes in network order (MSB-LSB) where bit 1 will be right most bit in LSB byte. – Bit 1: KEK Deletion – Bit 2: KAUT Deletion – Bit 3: KPIN Deletion – Bit 4: KPAN Deletion – Bit 5: KMAC Deletion – Bit 6: RFU (Reserved for future use) – Bit 7: RFU – Bit 8: RFU – Bit 9: RFU – Bit 10: RFU – Bit 11: RFU – Bit 12: RFU – Bit 13: RFU – Bit 14: RFU – Bit 15: RFU	B2
DF95	78	Key Derivation Information. Concatenation of the following fields: – KEK IV: b8 KEK Initialization Vector. – KEK DD1: b8 KEK Derivation Data 1. – KEK DD2: b8 KEK Derivation Data 2. – KAUT IV: b8 KAUT Initialization Vector. – KAUT DD1: b8 KAUT Derivation Data 1. – KAUT DD2: b8 KAUT Derivation Data 2. – KPIN KSN: b10 KPIN Initial KSN Derivation Data. – KPAN KSN: b10 KPAN Initial KSN Derivation Data. – KMAC KSN: b10 KMAC Initial KSN Derivation Data.	B78

Data elements formats

In this section you will find the data elements formats.

Processing code (BIT3)

The processing code (BIT3) determines the effect of the transaction on the Cardholder account. This field is built with 3 bytes in BSD format (N6):

Byte Position	Value
1	Process type: – 00: Debits – 20: Refunds
2	RFU (reserved for future use)
3	RFU

Point of service entry mode (BIT22)

The point of service entry mode determines characteristics of the terminal and specifies the conditions under which the transaction took place.

This field consists of 12 alphanumerical characters in the following format:

Byte Position	Value
1	Card data capture capabilities: 1: Manual (No terminal) 2: Magnetic stripe 5: EMV chip 6: Manual (Entered) M: Contactless (EMV + Magnetic stripe) + EMV (chip) + Magnetic stripe N: Contactless with magnetic stripe + EMV (chip) + Magnetic stripe U: Contactless
2	Cardholder authentication capabilities: 0: None 1: PIN (Online/offline) 2: Software-based Mobile Point of Sale (MPOS) terminal with PIN on SCREEN
3	Card capture capabilities: 0: No capture 1: Capture
4	Attended or unattended: 0: No terminal (For Token only) (*) 1: Attended 2: Unattended M: Assisted Mobile Point of Sale (MPOS) terminal or Mobile operation in the Application N: MPOS terminal with integrated reader
5	Cardholder present: 0: Cardholder not present 1: Cardholder present
6	Card present: 0: Card not present 1: Card present
7	Card data capture method: 1: Manual without terminal 2: Magnetic stripe 3: QR or bar code 4: Partial PAN manual entry 5: EMV chip 6: Manual entry N: Contactless with magnetic stripe M: Contactless with EMV chip S: Magnetic stripe backup for EMV chip T: Manual entry backup for EMV chip L: Contactless with EMV chip for mobile devices K: Contactless with magnetic stripe for mobile devices
8	Cardholder authentication method: 0: Not authenticated 1: Online PIN 2: Offline PIN 3: Signature 4: Access code 5: Offline PIN and Signature
9	Authorization entity: 0: Default (calculated by the server) F: Payment by reference (COF)
10	Authorization data: 0: Default (calculated by the server)
11	Points of Interaction (POIs) with screen/printer in terminal: 0: Unknown 2: Printer 3: Screen 4: Printer and screen
12	Maximum PIN length: 0: No PIN capture 4..C: 4 to 12 digits

* Note: for payments transactions (pre-authorizations, sales, and refunds) with token generated already it should be sent the following values:

POSITION 1: 1 – Manual – No terminal
POSITION 2: 0 – None
POSITION 4: 0 – No terminal
POSITION 5: 4 – Not present, recurring payment
POSITION 6: 0 – Card Not Present
POSITION 7: 1 – Manual without terminal
POSITION 8: 0 – Not authenticated
POSITION 9: F – Payment by reference (COF)

Function code (BIT24)

These are the function codes and its descriptions:

Value	Description
100	Preauthorization transaction
150	AVS transaction. Zero amount preauthorization
185	DCC preauthorization transaction with cardholder currency
187	DCC preauthorization transaction with local currency
200	Normal transaction. Sale (1200) (first or single request) and Refund (1220)
201	Preauthorization completion transaction
202	Refund without reference
285	DCC sale transaction with cardholder currency
287	DCC sale transaction with local currency
300	DCC verification transaction
310	Cash withdrawal transaction
481	Pre-authorization cancellation
500	Settlement transaction
690	Key identification transaction
691	Key upload transaction
692	Key renewal transaction
693	Key deletion transaction
800	Offline upload transaction
802	EMV data upload transaction
900	Token acquisition transaction

Response Code Table (BIT39)

Response Codes are functionally grouped to be specified, in each transaction, in a simple way.

This is the list of valid Response Codes organized by category:

Value	Description	Category
000	Approved / Processed	Generic response code
010	Partially approved / Processed	Generic code
909	System error	Generic code
912	System unavailable	Generic code
916	Invalid MAC	Generic code
948	Invalid terminal local date and time	Generic code
100	Offline processing at terminal	Authorization response code
101	Declined: Expired card	Authorization response code
105	Declined	Authorization response code
106	Declined: PIN limit exceeded	Authorization response code
117	Declined: Incorrect PIN	Authorization response code
126	Declined: Invalid PIN block	Authorization response code
127	Declined: Invalid encrypted card data	Authorization response code
180	Declined: Card not supported	Authorization response code
195	Declined: Perform SCA double TAP process	Authorization response code
196	Declined: Perform SCA simple TAP process	Authorization response code
201	Not processed	Financial advice response code
400	Processed (for backward compatibility)	Cancellation response code
401	Not found	Cancellation response code
500	Processed (for backward compatibility)	Reconciliation response code
501	Not processed: Reconciliation data mismatch	Reconciliation response code
610	Not processed, error in key process	Key response code
621	No DCC information available	DCC response code

Additional Data (BIT48)

Transaction additional information included in the BIT48 of the request /response message in TLV format.

Tags are functionally grouped to be specified, in each transaction, in a simple way. If a group is included in a transaction, all mandatory tags of this group must be included.

This is the list of valid tags organized by category:

Identifier	Description	Required/Optional	Category
DF01	Terminal ID	R	Identification data
DF02	Software ID	R	Identification data
DF03	GSM_SIM ID	O	Identification data
DF11	Key version	R	Status and configuration data
DF12	Parameter version	R	Status and configuration data
DF13	Functionalities	R	Status and configuration data
DF14	Language code	R	Status and configuration data
DF15	Time zone abbreviation	R	Status and configuration data
DF16	EMV CA public key version	R	Status and configuration data
DF20	Signature indicator	R	Transaction indicator data
DF21	Offline transaction indicator	R	Transaction indicator data
DF22	Previous failed EMV transaction indicator	R	Transaction indicator data
DF23	Special features performed by the POI. Required if the special feature was performed by the POI (SCA, for example).	R	Transaction indicator data
DF27	Donation query ID data.	O	Donation transaction data
DF30	Manually entered card data (full PAN or last 4 digits).	R	Manual entry transaction data
DF31	QR entry transaction data	R	QR entry transaction data
DF40	Upload indicator	R	Transaction response data
DF52	COF	O	Transaction response data
DF60	Processor data	R	Transaction response data
DF90	Key renewal indicator	R	Transaction response data
DF93	Key deletion indicator	R	Transaction response data
DF24	Settlement data	O	Transaction response data
DF70	File information data	R	Upload/download data
DF73	Upload/download mode	O	Upload/download data

Security control information (BIT53)

Security control information data included in the BIT53 of the request message in TLV format.

Tags are grouped functionally to be specified, in each transaction, in a simple way. If a group is included in a transaction, all mandatory tags of this group must be included.

This is the list of valid tags organized by category:

Identifier	Description	Required/Optional
DF07	Security PIN data	O
DF09	MAC security data	O
DF10	Security encryption data	O

EMV ICC Data (BIT55)

Tags are grouped functionally to be specified, in each transaction, in a simple way. If a group is included in a transaction, all mandatory tags of this group must be included.

This is the list of valid tags organized by category:

Tag	Description	Required/Optional	Category
82	AIP	R	EMV ICC/CLess data
95	TVR	R	EMV ICC/CLess data
9A	Transaction date	R	EMV ICC/CLess data
9C	Transaction type	R	EMV ICC/CLess data
5F2A	Currency code	R	EMV ICC/CLess data
9F02	Amount	R	EMV ICC/CLess data
9F10	Issuer application data	R	EMV ICC/CLess data
9F1A	Terminal country code	R	EMV ICC/CLess data
9F26	Cryptogram	R	EMV ICC/CLess data
9F27	Cryptogram information	R	EMV ICC/CLess data
9F33	Terminal capabilities	R	EMV ICC/CLess data
9F34	CVM result	R	EMV ICC/CLess data
9F35	Terminal type	R	EMV ICC/CLess data
9F36	ATC	R	EMV ICC/CLess data
9F37	Random number	R	EMV ICC/CLess data
9F6E	Third party data	O	EMV ICC/CLess data
5F20	Cardholder name	O	EMV ICC/CLess data
5F34	Card number sequence	O	EMV ICC/CLess data
9F06	Terminal AID	R	EMV ICC/CLess data
50	Application label	O	EMV ICC/CLess data
9F12	Application preferred name	O	EMV ICC/CLess data
84	DF name	O	EMV ICC/CLess data
9F66	TTQ for Visa Contactless	O	EMV ICC/CLess data
71	Issuer scripts	O	EMV response data
72	Issuer scripts	O	EMV response data
89	Authorization number (same as BIT38)	O	EMV response data
8A	Authorization response code	R	EMV response data
91	Issuer authentication data	O	EMV response data

For more details, see “EMV Integrated Circuit Card Specification for Payments System”.

Additional data (BIT56)

Transaction additional data included in the BIT56 of the request /response message in TLV format.

Tags are grouped functionally to be specified, in each transaction, in a simple way. If a group is included in a transaction, all mandatory tags of this group must be included.

This is the list of valid tags organized by category:

Tag	Description	Required/Optional	Category
DF04	Original message ID	R	Original transaction data
DF05	Original transaction identification number	R	Original transaction data
DF06	Original transaction local timestamp	R	Original transaction data
DF08	DCC information of the cardholder’s currency	R	Transaction DCC data
DF14	DCC language code	R	Transaction DCC data
DF26	DCC data	R	Transaction DCC data
DF23	Special functionalities allowed by the SWITCH. Required if the special functionality is allowed by the SWITCH. (For example, Cash Withdrawal)	O	Special features data
DF25	Cash withdrawal data	O	Cash withdrawal transaction data

Data registry (BIT72)

These are the labels of the available data records (BIT72) organized by category:

Tag	Description	Required/Optional	Category
DF11	Data to identify the keys present in the Point of Interaction (POI)	R	Key identification data
DF95	Key Data Derivation Information (present in the POI)	R	Key identification data
DF90	Data containing server challenge information (RND1)	R	Key identification response data
DF90	Data containing terminal challenge information (RND2)	R	Key update data
DF91	MAC calculated with KAUTH including RND1	R	Key update data
DF11	Data to identify new versions of key updates	R	Key update response data
DF91	MAC calculated with KAUTH including RND2	R	Key update response data
DF92	New Key Values for loading/renewal	R	Key update response data
DF94	Key references to delete	R	Key update response data
DF95	Key Data Derivation Information	R	Key update response data

Annex 2

For transactions in CTF and TTF cases, the flow of a cancellation message could fail (timeout response, wrong response code, et cetera…). However, the message flow integrity will be ensured by a sequence number between POI and SWITCH that keeps all the transactions synchronized (Transaction Identification Number “BIT 11”).

Find below an explanation on how the POI and SWITCH must handle the sequence number on every
case:

Normal transaction flow (with any response code value)

A transaction with BIT11 = x is sent.
The POI establishes connection with the Switch and sends the message data (BIT11 = x) and the Switch sends the received message data to the POI.
The POI receives and validates the response correctly (any value of BIT39). After that, the POI increments its Transaction Identification Number (BIT11 = x + 1).
The POI closes the connection.
A new transaction is sent with BIT11 = x + 1.
The POI establishes connection with the Switch and sends the message data (BIT11 = x + 1).
The Switch receives the Transaction Identification Number of the increased transaction. In this way the Switch verifies that the previous transaction has been completed successfully.

Cancellation or Timeout Transaction Flow

A transaction with BIT11 = x was not completed correctly and the cancel message was not sent.
The POI establishes the connection to the Switch and sends MGID = 1420 (BIT11 = x).
The cancellation response is not received (timeout) or its response code (BIT39) is wrong.
The POI closes the connection.
The POI’s Transaction Identification Number does not increment (BIT11 = x).
The POI establishes the connection to the Switch and sends the financial message (BIT11 = x).
The Switch avoids the transaction because the POI did not increment its Transaction Identification Number.

The sequence number must be the same all flow long (transaction + cancellation message).

Annex 3

In order that the SWITCH is able to identify a transaction uniquely, it is highly recommended that the SWITCH generates a unique Reference Number for each transaction and POI of each merchant.

Reference Number will be used as an entry parameter to perform refunds or preauthorization completions, and must be unique during a long-enough period of time (so the solution is operational and not repetition occurs leading to possible conflict).

Find below a practical example showing why a transaction could not be unique if the Reference Number is generated by the POI:

Example:

A merchant has 2 POIs. A customer performs a sale on POI 1 wich generates this data:
- Reference number generated by POI = 1
- Sale amount = 22,33€
- Customer Card = x
- Transaction date = 08/09/2023
The same customer do a new Sale on POI 2, with the same card, the same date. By chance the Reference Number generated by POI 2 is the same too.
- Reference number generated by POI = 1
- Sale amount = 55,44€
- Customer Card = x
- Transaction date = 08/09/2023
If this customer performs a refund with card X, Reference Number = 1 and Transaction Date = 08/09/23, SWITCH will not be able to match a unique transaction to complete the refund.
The amount cannot be used as a parameter to reach a match, because the refund could be partial (minor than original transaction amount).

In case the transaction is offline approved, a defined prefix will be included on Reference Number. This prefix will determine a range of reference numbers that SWITCH never must use.

Annex 4

The message integrity will be verified with TLS HMAC or with MAC + TLS HMAC.

Since version 1.22 MAC is optional, it means that if bits 64 or 128 are not present within the bitmap, the switch will no use it during the communication. Since version 1.22 we recommend to don’t use the mac calculation because it has been deprecated.

When the MAC is used all outgoing requests from the POI and incoming responses from the EP will include a MAC field in BIT 64 or BIT 128, the only exception is for the notification messages where no KMAC is used. If the KMAC key is not loaded as it will happen in the initialization, the KAUTH key will be used. The algorithm to generate the MAC will be described on the document: “CGP_Security_Overwiew_v0.9”.

The data used for the MAC generation in the outgoing/incoming messages will be extracted from the following fields:

BIT	Field Name	Description
2	BIN	Bank Identification Number of the card
3	Processing Code	Additional transaction qualifiers
4	Transaction Amount	Amount to be withdrawn
11	Transaction ID Number	Identifies TF as a sequence N
12	Local Transaction Date	Local date and time (YYMMDDHHMMSS)
19	Country Code	Country code of the merchant/terminal
22	Point of Service Entry Mode (POS/POI)	Details of the transaction and the terminal (card data capture capability, card data capture method, cardholder authentication method, etc.).
25	Reason Code	Reason for cancellation
30	Local Currency Amount	Amount expressed in local currency
35	Card Data	Encrypted track 2 data for EMV, magnetic stripe, and contactless cards.
37	Reference Number	Reference number
38	Authorization Number	Authorization number
41	Terminal ID	Logical ID of the terminal
42	Merchant ID	Logical ID of the merchant
48	Additional Information	Additional transaction information.
49	Transaction Currency Code	Code of the local currency used in the transaction
50	Settlement Currency Code	Settlement currency code
51	Foreign Currency Code	Foreign currency code
52	PinBlock	Required if there is online PIN verification
72	Data Record	Data record