Skip to main content
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: