In this case, when the actual transaction is received, you need to link the authorisation with the actual financial transaction. This section gives detailed instructions how to do that. In the authorisation and transaction messages from the card schemes, there is no single data element that could be used for linking the two. The issuer/processor is expected to create the link by combining many different fields until a unique match is found. This process requires a complex logic, which Enfuce has implemented. Enfuce creates unique IDs that enable linking authorisation and transaction in an easy way. This image illustrates the possible message combinations during a purchase (each vertical line represent a potential purchase use case). The different lines act as examples for different variations of authorisation messages and clearing transactions that can be linked to same purchase.

​
Examples of linking a transaction and authorisation

  1. Your customer makes a purchase and the merchant makes an authorisation which results in a financial transaction.
  2. Your customer fuels at an unattended fuel station (automated fuel dispenser). The terminal first makes an authorisation request and after the fueling has ended the amount of the authorisation is changed with advice and then a financial transaction is sent.
  3. Your customer makes a purchase, an authorisation request is completed, but the customer returns the item shortly. At this point the authorisation is reversed. No financial transaction is sent.
  4. Your customer makes a retail purchase, the merchant creates an authorisation and a financial transaction is sent. Your customer returns the purchased item after a week and the merchant creates a financial transaction reversal to reflect the return.
The authorisation request and financial transaction can exist without a linking message or transaction whereas adjustments, advice and reversals will always have a linking message or transaction. As you can see from the above examples, one purchase can contain one or multiple messages depending on the following criteria:
  • Is the authorisation done?
  • Is the authorisation amount changed?
  • Is authorisation or transaction reversed?
The Enfuce service is based on creating a “chain of events” where the next message always links to the previous one. The below section will describe where in notifications, Transaction API and data export files the necessary information can be found that enable the linking. The transactionId that is conveyed in the notification represents a unique Enfuce database id for that message.
If the subType is “AUTH” then the transactionID should be considered the link as it is the ID of the first message in the chain. If the subType is “AUTH_REV” “AUTH_ADJ” “AUTH_ADV” then there is a previous message and the linking id can be found from originalTransactionId.
The “Id” conveyed in the transaction API represents the unique Enfuce database id for that message. Unlike the Notification API and data export file, the Transaction API includes both authorisations and transactions. So the id for an “AUTH” is the unique id for the authorisation whereas the id for “FINANCIAL” is the unique id for the transaction.
The transaction API has additional functionality where it returns in the “linkId” field the id of the first message in the chain. Subsequently, the “linkId” is the same as the id for the first message in the chain. This simplifies it so that it’s not necessary to track back the chain as all messages in the chain have the same linkId.
The transactions are sent on a daily basis in the Data Export transaction file. For each transaction there is an “ID” that, like in the notification, represents a unique database id for that transaction.
In order to link it to a previous authorisation/transaction there is PREVIOUS_ID field:

​
Linking with IDs using previous examples

Let’s use our previous examples to make this more concrete:
Use case1st message in chain2nd message in chain3rd message in chain
1. Your customer makes a purchase and the merchant makes an authorisation which results in a financial transaction.Notification message: “AUTH” / transactionId: 112233
Transaction API: “AUTH” / id : 112233		Transaction API: “FINANCIAL” / linkId : 112233
Data Export transaction file: PREVIOUS_ID : 112233		n/a
2. Your customer fuels at an unattended fuel station (automated fuel dispenser). The terminal first makes an authorisation request and after the fueling has ended the amount of the authorisation is changed with advice and then a financial transaction is sent.Notification message: “AUTH” / transactionId : 445566
Transaction API:
“AUTH” / id : 445566		Notification message: “AUTH_ADJ” / transactionId: 445567
originalTransactionId : 445566
Transaction API:
“AUTH” / linkId : 445566		Transaction API:
“FINANCIAL” / linkId : 445566
Data Export transaction file: PREVIOUS_ID: 445567
3. Your customer makes a purchase, an authorisation request is completed, but the customer returns the item shortly. At this point the authorisation is reversed. No financial transaction is sent.Notification message: “AUTH” / transactionId : 778899
Transaction API:
“AUTH” / id : 778899		Notification message: “AUTH_REV” / originalTransactionId : 778899
Transaction API:
“AUTH” / linkId : 778899		n/a
4. Your customer makes a retail purchase, the merchant creates an authorisation and a financial transaction is sent. Your customer returns the purchased item after a week and the merchant creates a financial transaction reversal to reflect the return.Notification message: “AUTH” / transactionId : 123456
Transaction API:
“AUTH” / id : 123456		Transaction API:
“FINANCIAL” / “code”:”R1″ / linkId : 123456
Data Export transaction file:
ID: 123457
PREVIOUS_ID: 123456		Transaction API:
“FINANCIAL” / “code”:”r1″ / linkId : 123456
Data Export transaction file:
PREVIOUS_ID: 123457