External Host Interface Integration Guide

16. Transaction Matching Criteria

Transaction matching is the process of linking a new EHI message to a previous message in the same transaction lifecycle.

Transaction matching helps your system:

Track the full transaction lifecycle.
Link authorizations, advice messages, reversals, presentments, financial reversals, chargebacks, and chargeback reversals.
Prevent duplicate balance, block/reserve, ledger, or dispute impact.
Reconcile unmatched or incomplete transaction flows.
Support audit, investigation, and exception handling.

Updated 15 minutes ago

On this page

16.1 Matching principles 16.2 Common matching fields 16.3 Recommended matching matrix 16.4 Matching logic by message type 16.5 Matching confidence 16.6 Duplicate detection versus transaction matching 16.7 Unmatched transactions

16.1 Matching principles

Your system should apply the following principles when matching EHI transaction messages:

Identify the message type first using MTID, Txn_Type, or CutOffId.
Determine what previous message the current message should match to.
Use the original EHI fields in the JSON payload to perform the match.
Prefer stronger matching when multiple identifiers are available.
Treat a match as more reliable when more fields match correctly.
Treat a match as unreliable when some fields match and others do not.
Do not apply duplicate balance, block/reserve, ledger, dispute, or reconciliation impact for messages that were already processed.
Store unmatched messages for reconciliation or exception handling.
Preserve the original EHI JSON payload and matching result for audit and troubleshooting.

16.2 Common matching fields

The following fields are commonly used to link EHI messages within the same transaction lifecycle.

Field	Purpose
`Token`	Identifies the card token associated with the transaction.
`TXn_ID / Txn_ID`	Identifies the EHI transaction message. Useful for storing and duplicate detection.
`MTID`	Identifies the message category.
`Txn_Type`	Identifies the transaction type within the message category.
`traceid_lifecycle`	Helps link related messages in the same transaction lifecycle when present.
`Trans_link`	Helps link related authorization, reversal, and financial messages.
`Auth_Code_DE38`	May help match authorizations, presentments, reversals, and chargebacks when present.
`Ret_Ref_No_DE37`	May help link related authorization messages.
`TXN_Time_DE07`	May help identify the original transaction in authorization repeat scenarios.
`POS_Termnl_DE41`	May help identify the original authorization in repeat scenarios.
`Acquirer_Reference_Data_031`	Commonly used for clearing, presentment, financial reversal, and chargeback matching.
`Network_Transaction_ID`	May help with network-level transaction identification when present.
`SchemeTransactionIdentifier`	May help with scheme-level transaction identification when present.
`CutOffId`	Primary identifier for cut-off messages and cut-off duplicate detection.
`SendingAttemptCount`	May indicate repeated delivery attempts, but should not be used by itself as the transaction match key.
`x-correlation-id`	Payblr correlation identifier used for tracing the request through Payblr and your system.

16.3 Recommended matching matrix

Your system should use the following matrix as a practical guide for matching EHI messages.

Incoming message	Match to	Recommended matching approach
`0100 / A authorization request`	No previous transaction required	Treat as a new authorization decisioning request unless it is identified as a duplicate or retry.
`0101 / A authorization repeat`	Original `0100 / A` authorization request	Match using `Token`, `traceid_lifecycle`, `Trans_link`, `Ret_Ref_No_DE37`, `TXN_Time_DE07`, and `POS_Termnl_DE41` when available.
`0120 / J authorization advice`	Original `0100 / A` authorization request	Match using `Token` plus available lifecycle references such as `traceid_lifecycle`, `Auth_Code_DE38`, or `Trans_link`.
`0120 / D authorization reversal`	Original `0100 / A` authorization request	Match to the original authorization and release or adjust the related block.
`0400 / D authorization reversal request`	Original `0100 / A` authorization request	Match to the original authorization and release or adjust the related block.
`0420 / D authorization reversal advice`	Original `0100 / A` authorization request	Treat the same as `0400 / D` in practice and release or adjust the related block.
`1240 / P financial / first presentment`	Original authorization or authorization advice	Match to the related authorization when possible, then release related blocks and post or reconcile the transaction.
`05pp / P, 06pp / P, 07pp / P financial notification`	Original authorization or authorization advice	Use the same general presentment matching approach when applicable.
`1240 / E financial reversal`	Prior financial notification	Match to the prior financial notification and reverse or adjust the previous posted financial impact.
`25pp / E, 26pp / E, 27pp / E financial reversal`	Prior financial notification	Use the same general financial reversal matching approach when applicable.
`1240 / C chargeback`	Related financial notification	Optionally match to the related financial notification using clearing and transaction references.
`1240 / H chargeback non-credit`	Related financial notification	Use the same general chargeback matching approach as `1240 / C`.
`1240 / K chargeback reversal`	Original `1240 / C` or `1240 / H` chargeback	Match to the original chargeback and reverse or adjust the chargeback-related impact.
`Cut-off message`	Prior cut-off message with same `CutOffId`, for duplicate detection	Use `CutOffId` as the primary key for cut-off duplicate detection.

Authorization reversals with 0400 / D and 0420 / D should be treated the same in practice. Both should be treated as reversal advice messages that cannot be declined.

16.4 Matching logic by message type

Authorization repeat matching

For authorization repeats, your system should attempt to match the repeat message to the original authorization request.

OTHER.MTID = '0100'
AND OTHER.Txn_Type = 'A'
AND OTHER.Token = THIS.Token
AND OTHER.traceid_lifecycle = THIS.traceid_lifecycle
AND OTHER.Trans_link = THIS.Trans_link
AND OTHER.Ret_Ref_No_DE37 = THIS.Ret_Ref_No_DE37
AND OTHER.TXN_Time_DE07 = THIS.TXN_Time_DE07
AND OTHER.POS_Termnl_DE41 = THIS.POS_Termnl_DE41

If the original authorization is found, your system should return the same logical response as the original processing and avoid duplicate impact.

Authorization advice matching

For authorization advice messages, your system should attempt to match the advice to the original authorization request.

OTHER.Token = THIS.Token
AND (
    OTHER.traceid_lifecycle = THIS.traceid_lifecycle, if THIS.traceid_lifecycle exists
    OR OTHER.Auth_Code_DE38 = THIS.Auth_Code_DE38, if THIS.Auth_Code_DE38 exists
    OR OTHER.Trans_link = THIS.Trans_link, if THIS.Trans_link exists
)

If no matching authorization is found, your system should store the advice as unmatched and process it through reconciliation or exception handling.

Authorization reversal matching

For authorization reversals, your system should match the reversal to the original authorization request.

OTHER.MTID = '0100'
AND OTHER.Txn_Type = 'A'
AND OTHER.Token = THIS.Token
AND, if THIS.traceid_lifecycle exists:
    OTHER.traceid_lifecycle = THIS.traceid_lifecycle
AND, if THIS.Auth_Code_DE38 exists:
    OTHER.Auth_Code_DE38 = THIS.Auth_Code_DE38
AND, if THIS.Trans_link exists:
    OTHER.Trans_link = THIS.Trans_link

If the reversal matches a previous authorization, your system should release or adjust the related blocked amount. If the reversal amount matches the original authorization amount, it should be treated as a full reversal.

If blocks from a related 0120 / J authorization advice were applied, your system should apply those block updates before applying a 0400 / D reversal. Your system should not unblock more than the amount currently blocked for the same transaction set.

Financial / presentment matching

For financial or presentment messages, your system should attempt to match the financial message to the original authorization or authorization advice.

Match incoming financial / presentment message
TO related authorization or authorization advice
USING available transaction lifecycle fields such as:

Token
traceid_lifecycle
Trans_link
Auth_Code_DE38
Acquirer_Reference_Data_031
Network_Transaction_ID
SchemeTransactionIdentifier

If a match is found, your system should release or adjust the related block and post or reconcile the final financial transaction.

If no match is found, your system should treat the message as unmatched or offline presentment and process it according to your reconciliation or exception-handling rules.

Financial reversal matching

For financial reversals, your system should match the reversal to the prior financial notification.

Match incoming financial reversal
TO prior financial notification
USING:
Acquirer_Reference_Data_031, when available

IF no match is found:
Try traceid_lifecycle and Trans_link

IF no match is found:
Try Auth_Code_DE38 and Merch_ID_DE42

Financial reversal messages include 1240 / E and related financial reversal variants. Financial reversals should match to a financial notification such as 1240 / P or 1240 / N, then be processed according to your ledger and reconciliation rules.

Chargeback matching

For chargebacks, your system may match the chargeback to the related financial notification.

OTHER.Acquirer_Reference_Data_031 = THIS.Acquirer_Reference_Data_031
AND OTHER.Token = THIS.Token
AND OTHER.Auth_Code_DE38 = THIS.Auth_Code_DE38
AND OTHER.Trans_link = THIS.Trans_link

Some fields may be blank or unavailable. If a reliable match cannot be confirmed, your system should store the chargeback as unmatched and process it through reconciliation or exception handling.

1240 / C identifies a chargeback notification and may be matched to a financial notification using fields such as Acquirer_Reference_Data_031, Token, Auth_Code_DE38, and Trans_link. 1240 / H follows the same approach.

Chargeback reversal matching

For chargeback reversals, your system may match the reversal to the original chargeback.

OTHER.MTID = '1240'
AND OTHER.Txn_Type IN ('C', 'H')
AND OTHER.Acquirer_Reference_Data_031 = THIS.Acquirer_Reference_Data_031
AND OTHER.Token = THIS.Token
AND OTHER.Auth_Code_DE38 = THIS.Auth_Code_DE38
AND OTHER.Trans_link = THIS.Trans_link

If the original chargeback is found, your system should reverse or adjust the previous chargeback-related impact. If no original chargeback is found, your system should store the chargeback reversal as unmatched.

Cut-off matching

Cut-off messages should not be matched using normal transaction lifecycle fields.

Your system should use CutOffId as the primary identifier for cut-off processing and duplicate detection.

OTHER.CutOffId = THIS.CutOffId

If the same CutOffId is received again, your system should not process the cut-off again. Your system should return the same logical cut-off response as the original processing.

16.5 Matching confidence

Your system should classify each match based on confidence.

Match confidence	Description	Recommended handling
High confidence match	Multiple key identifiers match correctly.	Process the message normally and link it to the existing transaction lifecycle.
Medium confidence match	Some strong identifiers match, but not all fields are available.	Process according to internal rules and flag for monitoring if needed.
Low confidence match	Only weak or partial identifiers match.	Store and route to reconciliation or exception handling before applying sensitive impact.
No match	No reliable related transaction was found.	Store as unmatched and process according to reconciliation or exception-handling rules.
Conflicting match	Some fields match but others conflict.	Treat as unreliable and route to exception handling.

A match is more reliable when more matching fields align correctly. If some fields match and others do not, your system should treat the match as unreliable and investigate before applying ledger-sensitive changes.

16.6 Duplicate detection versus transaction matching

Transaction matching and duplicate detection are related but not the same.

Concept	Purpose	Example
Transaction matching	Links a new message to a previous related transaction message.	Matching a presentment to the original authorization.
Duplicate detection	Determines whether the same message was already received and processed.	Detecting that a repeated reversal message was already applied.

Your system should perform both checks.

When a message is received, your system should:

Identify the message type.
Check whether the exact message or same logical event was already processed.
If it is a duplicate, return the same logical response and do not apply duplicate impact.
If it is not a duplicate, match it to the related transaction when applicable.
Apply the correct balance, block/reserve, ledger, dispute, or reconciliation impact.
Store the matching and duplicate detection result.

16.7 Unmatched transactions

Some EHI messages may not have a matching previous transaction in your system.

Examples include:

Authorization advice without a matching authorization.
Authorization reversal without a matching authorization.
Presentment without a matching authorization.
Financial reversal without a matching financial notification.
Chargeback without a matching financial notification.
Chargeback reversal without a matching chargeback.

When this happens, your system should:

Store the original EHI JSON payload.
Store the message as unmatched.
Return the required acknowledgement response, unless the message type requires a different response.
Avoid unsupported or duplicate financial impact.
Route the message to reconciliation or exception handling.
Preserve all original EHI identifiers for investigation.