Skip to content
Switch to light mode

External Host Interface Integration Guide

12. Financial Reversal Messages

Financial reversal messages are sent when a previous financial or presentment impact needs to be reversed or adjusted.

As with all EHI messages, Payblr forwards this payload without transformation. Your system should process the EHI JSON payload using the EHI fields and return the required response for the message type.

A financial reversal is different from an authorization reversal. An authorization reversal releases or adjusts a previous authorization block. A financial reversal reverses or adjusts a previous financial or presentment transaction after funds were posted or taken.

A financial reversal may represent the cancellation or adjustment of all or part of a prior financial transaction, such as a purchase, refund, cashback, cash transaction, PIN change, or other transaction type.

On this page

12.1 Applicable identifiers

Financial reversal messages are identified using the EHI fields included in the forwarded JSON payload.

FieldExpected valueDescription
MTID1240Identifies a financial reversal notification when used with Txn_Type = E.
Txn_TypeEIdentifies the message as a financial reversal.
MTID25pp, where pp = spaceIdentifies a Visa financial reversal of a purchase.
MTID26pp, where pp = spaceIdentifies a Visa financial reversal of a refund or credit-to-cardholder.
MTID27pp, where pp = spaceIdentifies a Visa financial reversal of a cash withdrawal or disbursement.

Financial notifications can include first presentments and financial reversals, including 1240 / E and Visa 25pp / E, 26pp / E, and 27pp / E.

12.2 Financial reversal flow

Financial reversal flow

Platform

Payblr

System

Your Systems

1. Forward original EHI financial reversal payload

Financial reversal

Payblr forwards the original EHI financial reversal payload to your configured endpoint.

PayblrYour Systems

2. Validate Payblr request signature and timestamp

Your system validates the Payblr request signature and timestamp before processing.

Your SystemsprocessesYour Systems

3. Identify financial reversal using MTID and Txn_Type

Your system identifies the financial reversal using MTID and Txn_Type.

Your SystemsprocessesYour Systems

4. Check whether reversal was already processed

Your system checks whether the reversal was already processed to keep handling idempotent.

Your SystemsprocessesYour Systems

5. Match to prior financial / presentment message

Financial reversal

Your system matches the reversal to the prior financial / presentment message.

Your SystemsprocessesYour Systems

6. Reverse or adjust previous posted impact

Your system reverses or adjusts the previous posted impact.

Your SystemsprocessesYour Systems

7. Return acknowledgement response

Financial reversal

Your system returns the required acknowledgement response to Payblr.

Your SystemsPayblr

8. Relay acknowledgement through the transaction flow

Payblr relays the acknowledgement through the transaction flow.

PayblrprocessesPayblr
sequenceLaneCenter(index, columnCount)

12.3 How your system should process financial reversal messages

When your system receives a financial reversal message, they should:

  1. Validate Payblr’s integration headers, signature, timestamp, and EHI JSON payload before processing.
  2. Identify the message as a financial reversal using Txn_Type = E and the applicable MTID.
  3. Check whether the financial reversal was already received or processed using the applicable EHI identifiers.
  4. Match the financial reversal to the prior financial notification or presentment using the EHI matching criteria.
  5. If a matching financial notification is found, reverse or adjust the previous posted financial impact according to your ledger rules.
  6. If the financial reversal reverses only part of the original financial impact, adjust only the applicable amount.
  7. If the financial reversal relates to a refund or credit-to-cardholder, apply your internal refund or credit reversal rules.
  8. If no matching financial notification is found, store the reversal as unmatched and process it according to your reconciliation or exception-handling rules.
  9. Return the required acknowledgement response.
  10. Store the financial reversal message, matching result, response returned, and x-correlation-id for audit, duplicate handling, and reconciliation.

12.4 Financial reversal matching criteria

Your system should match financial reversal messages to the prior financial notification using the EHI fields.

Incoming messageMatch toMatching criteria
1240 / E financial reversalPrior financial notification 1240 / P or 1200 / WMatch to the prior financial notification and process accordingly.
25pp / E financial reversal of purchasePrior financial notification 05pp / P or 05pp / WUse the same approach as 1240 / E.
26pp / E financial reversal of refund / credit-to-cardholderPrior financial notification 06pp / P or 06pp / WUse the same approach as 1240 / E.
27pp / E financial reversal of cash withdrawal / disbursementPrior financial notification 07pp / P or 07pp / WUse the same approach as 1240 / E.

When matching financial reversals, your system should use the available EHI matching fields in the following order where applicable:

Matching priorityMatching criteria
1Match using Acquirer_Reference_Data_031, when available.
2If Acquirer_Reference_Data_031 cannot be matched, try matching using traceid_lifecycle and Trans_link.
3If those cannot be matched, try matching using Auth_Code_DE38 and Merch_ID_DE42.

Visa financial reversals 25pp / E, 26pp / E, and 27pp / E follow the same approach as 1240 / E. If matching cannot be done using Acquirer_Reference_Data_031, try traceid_lifecycle and Trans_link, and then Auth_Code_DE38 and Merch_ID_DE42.

12.5 Processing outcome

ScenarioRequired handling
Prior financial notification foundMatch the reversal to the prior financial notification and reverse or adjust the previous posted impact.
Prior financial notification not foundStore the reversal as unmatched and process according to your reconciliation or exception-handling rules.
Full financial reversalReverse the full previous financial impact according to your ledger rules.
Partial financial reversalReverse or adjust only the applicable portion of the prior financial impact.
Financial reversal of purchaseReverse or adjust the previous purchase posting.
Financial reversal of refund / credit-to-cardholderReverse or adjust the previous refund or credit impact.
Financial reversal of cash withdrawal / disbursementReverse or adjust the previous cash transaction impact.
Duplicate financial reversalDo not reverse or adjust funds again. Return the same logical acknowledgement.

12.6 Required response

Financial reversal messages should be acknowledged after your system receives and processes the message.

  • Acknowledgement: Required. Indicates that your system received and processed the financial reversal message.
  • Responsestatus: Optional. May be included when required by the EHI response contract or program configuration.

For financial reversal messages, your system generally returns an acknowledgement response instead of a new approve or decline decision.

12.7 Financial reversal request example

Available JSON guide example:

{
  "Network_Start_To_KillDate": "30000000",
  "POS_Date_DE13": "20230206",
  "Traceid_Message": "VIS1-20230206-0021214765435",
  "Network_Response_Settle_ID": "0000000",
  "Network_Transaction_ID": "000000000209",
  "Clearing_Process_Date": "2023-02-06",
  "Settlement_Date": "2023-02-10",
  "DCC_Indicator": 0,
  "multi_part_txn": 0,
  "multi_part_txn_final": 0,
  "multi_part_number": 1,
  "multi_part_count": 1,
  "SettlementStatus": "P",
  "txn_type": "C",
  "Matching_Txn_ID": 0,
  "Reason_ID": 0,
  "Merch_Name": "APP APP",
  "Merch_Country": "DOM",
  "Merch_Postcode": "00000",
  "Merch_Tel": "0",
  "Merch_URL": "0",
  "Merch_Tax_id": "0",
  "GPS_POS_Capability": "000000000000000000000000000000000000000000000000",
  "GPS_POS_Data": "9613000000000",
  "Acquirer_Reference_Data_031": "73820217034000000001",
  "Response_Source_Why": 0,
  "Message_Why": 0,
  "traceid_lifecycle": "VIS1-20230206-0021214765435",
  "PaymentToken_id": 0,
  "PaymentToken_creatorStatus": 0,
  "PaymentToken_lang": "  ",
  "PaymentToken_activationMethod": 0,
  "Acquirer_id_DE32": "0000000000",
  "MCC_Code": "5999",
  "Amt_Tran_Fee_DE28": "D00000000",
  "Bill_Amt": 70.00,
  "Bill_Ccy": 840
}

Actual request fields may vary by network, transaction type, configuration, and available transaction data. Use the full official Thredd JSON guide example or a confirmed UAT JSON payload when adding a complete request example to this page.

12.8 Response example

Minimal acknowledgement response:

{
  "Acknowledgement": "1"
}

12.9 Implementation notes

  • Financial reversal messages should not be treated as new authorization requests.
  • Financial reversals are different from authorization reversals. Authorization reversals release or adjust authorization blocks, while financial reversals reverse or adjust posted financial impact.
  • Your system should attempt to match the financial reversal to the prior financial notification when possible.
  • Your system should use Acquirer_Reference_Data_031 for matching when available.
  • If Acquirer_Reference_Data_031 cannot be matched, your system should try traceid_lifecycle and Trans_link.
  • If those fields cannot be matched, your system should try Auth_Code_DE38 and Merch_ID_DE42.
  • If no matching financial notification is found, your system should store the reversal and route it to reconciliation or exception handling.
  • Your system should avoid duplicate posting, balance, block, reserve, or ledger impact if the same financial reversal is received more than once.
  • Your system should store key identifiers such as Token, TXn_ID, traceid_lifecycle, Trans_link, Auth_Code_DE38, Ret_Ref_No_DE37, Acquirer_Reference_Data_031, and x-correlation-id.