External Host Interface (EHI) Integration Guide

Back

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.

16.1 Matching principles

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

  1. Identify the message type first using MTID, Txn_Type, or CutOffId.

  2. Determine what previous message the current message should match to.

  3. Use the original EHI fields in the JSON payload to perform the match.

  4. Prefer stronger matching when multiple identifiers are available.

  5. Treat a match as more reliable when more fields match correctly.

  6. Treat a match as unreliable when some fields match and others do not.

  7. Do not apply duplicate balance, block/reserve, ledger, dispute, or reconciliation impact for messages that were already processed.

  8. Store unmatched messages for reconciliation or exception handling.

  9. 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.

16.3 Recommended matching matrix

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

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.

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.

Your system should perform both checks.

When a message is received, your system should:

  1. Identify the message type.

  2. Check whether the exact message or same logical event was already processed.

  3. If it is a duplicate, return the same logical response and do not apply duplicate impact.

  4. If it is not a duplicate, match it to the related transaction when applicable.

  5. Apply the correct balance, block/reserve, ledger, dispute, or reconciliation impact.

  6. 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:

  1. Store the original EHI JSON payload.

  2. Store the message as unmatched.

  3. Return the required acknowledgement response, unless the message type requires a different response.

  4. Avoid unsupported or duplicate financial impact.

  5. Route the message to reconciliation or exception handling.

  6. Preserve all original EHI identifiers for investigation.