Skip to content
Switch to light mode

External Host Interface Integration Guide

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, Txn_ID, traceid_lifecycle, Trans_link, Auth_Code_DE38, Acquirer_Reference_Data_031, and CutOffId, to determine how each message should be processed.

On this page

15.1 Standard transaction lifecycle

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

Standard transaction lifecycle

Platform

Payblr

System

Your Systems

1. Forward authorization message

Lifecycle

Payblr forwards the authorization message to your configured endpoint.

PayblrYour Systems

2. Decide, match, and reserve block when applicable

Your system decides, matches, and reserves a block when applicable.

Your SystemsprocessesYour Systems

3. Forward advice, repeat, or reversal when applicable

Payblr forwards advice, repeat, or reversal messages when applicable.

PayblrYour Systems

4. Update or adjust authorization impact

Your system updates or adjusts the authorization impact.

Your SystemsprocessesYour Systems

5. Forward financial / presentment message

Lifecycle

Payblr forwards the financial / presentment message to your endpoint.

PayblrYour Systems

6. Post or reconcile final transaction

Your system posts or reconciles the final transaction.

Your SystemsprocessesYour Systems

7. Forward reversal, chargeback, or cut-off message when applicable

Payblr forwards reversal, chargeback, or cut-off messages when applicable.

PayblrYour Systems

8. Apply reconciliation, dispute, or operational handling

Your system applies reconciliation, dispute, or operational handling.

Your SystemsprocessesYour Systems

9. Return required JSON response

Lifecycle

Your system returns the required JSON response for each EHI message.

Your SystemsPayblr
sequenceLaneCenter(index, columnCount)

15.2 Lifecycle stages

Lifecycle stageMessage typePurposeExpected handling by your system
Authorization decisioning0100 / ARequest an authorization decisionApprove, decline, or partially approve based on your internal rules.
Authorization repeat0101 / ARepeat or retry an authorization-related message.Match to the original authorization and return the same logical response when possible.
Authorization advice0120 / JNotify your system of an authorization-related eventMatch to the original authorization and update block, balance, ledger, or reconciliation records.
Authorization reversal0120 / D advice / 0400 / D / 0420 / DReverse or adjust a previous authorization impact.Match to the original authorization and release or adjust the blocked amount.
Financial / presentment1240 / P, 05pp / P, 06pp / P, 07pp / PPost or reconcile the final financial transaction.Match to the authorization when possible, release related block, and post or reconcile the transaction.
Financial reversal1240 / E, 25pp / E, 26pp / E, 27pp / EReverse or adjust a previous financial posting.Match to the prior financial notification and reverse or adjust the posted impact.
Chargeback1240 / C, 1240 / HNotify your system of a dispute-related financial eventUpdate dispute, ledger, transaction history, and reconciliation records.
Chargeback reversal1240 / KReverse or adjust a previous chargeback impact.Match to the original chargeback when possible and reverse or adjust the chargeback-related impact.
Cut-offCutOffIdSupport cut-off and reconciliation processing.Process using CutOffId and return the required Cut_OffResult.

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

If the message is...Your system should...
An authorization decisioning messageReturn the required authorization decision within the processing window.
An authorization repeatMatch to the original authorization and return the same logical response when possible.
An authorization adviceMatch to the original authorization when possible and update transaction records, blocks, balances, or reconciliation status.
An authorization reversalMatch to the original authorization and release or adjust the previous authorization block.
A financial / presentment messageMatch to the related authorization when possible, release related block, and post or reconcile the final transaction.
A financial reversalMatch to the prior financial notification and reverse or adjust previous posted financial impact.
A chargebackUpdate dispute, ledger, transaction history, and reconciliation records.
A chargeback reversalMatch to the original chargeback when possible and reverse or adjust the chargeback-related impact.
A duplicate or retryReturn the same logical response as the original processing and avoid duplicate impact.
A cut-off messageProcess using CutOffId and return Cut_OffResult.
An unmatched messageStore the message and route it to reconciliation or exception handling.

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.