External Host Interface (EHI) Integration Guide

Back
Next

15. Transaction Lifecycle Overview

EHI messages should be processed as part of a transaction lifecycle, not as isolated events.

As with all EHI messages, Payblr forwards each EHI JSON payload to your configured endpoint. Your system is responsible for identifying the message type, matching it to related transactions when possible, and applying the correct balance, block/reserve, ledger, dispute, and reconciliation logic.

Not every transaction follows the same lifecycle. Some transactions may only include an authorization and presentment. Others may include advice messages, reversals, financial reversals, chargebacks, or retries.

Your system should use the EHI fields, such as MTID, Txn_Type, Token, TXn_ID, traceid_lifecycle, Trans_link, Auth_Code_DE38, Acquirer_Reference_Data_031, and CutOffId, to determine how each message should be processed.

15.1 Standard transaction lifecycle

The lifecycle below shows a typical transaction flow from authorization through financial posting and reconciliation.

15.2 Lifecycle stages

15.3 Message classification rules

Your system should first identify the message type before applying any transaction logic.

When a message is received, your system should:

  1. Check whether the payload contains CutOffId.

  2. If CutOffId is present, process the message as a cut-off message.

  3. If CutOffId is not present, identify the message using MTID and Txn_Type.

  4. Determine whether the message requires a real-time decision, acknowledgement, reversal handling, posting, dispute handling, or cut-off response.

  5. Apply the correct matching criteria for the message type.

  6. Check whether the message was already received or processed.

  7. Apply only the appropriate balance, block/reserve, ledger, dispute, or reconciliation impact.

  8. Return the required JSON response.

15.4 Lifecycle decision guide

15.5 Unmatched lifecycle events

Some messages may arrive without a matching prior transaction in your system.

Examples include:

  • Authorization advice without a matching original 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 unmatched message.

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

  3. Route the message to reconciliation or exception handling.

  4. Avoid applying unsupported or duplicate balance, block/reserve, ledger, or dispute impact.

  5. Preserve the EHI fields so the message can be investigated later.