External Host Interface (EHI) Integration Guide

Back
Next

11. Financial / Presentment Messages

Financial or presentment messages are sent when a transaction moves into the clearing or financial stage.

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

A presentment message is different from an authorization message. An authorization asks whether the transaction should be approved or declined. A presentment confirms that a financial transaction should be posted or reconciled. The first presentment is the point when the merchant sends a request to take all or part of the amount previously authorized on the card, and it may happen at the same time as the authorization or later.

11.1 Applicable identifiers

Financial / presentment messages are identified using the original EHI fields included in the forwarded payload.

11.2 Financial / presentment flow

11.3 How your system should process financial / presentment messages

When your system receives a financial or presentment message, they should:

  1. Validate Payblr’s integration headers, signature, timestamp, and raw payload before processing.

  2. Identify the message as a financial or presentment message using MTID and Txn_Type.

  3. Check whether the message was already received or processed using the applicable EHI identifiers.

  4. Attempt to match the presentment to the original authorization using the EHI matching criteria.

  5. If a matching authorization is found, release or adjust the related blocked amount.

  6. Post or reconcile the final transaction amount according to your internal ledger rules.

  7. If the presentment amount differs from the original authorization amount, adjust the block, posted amount, or ledger impact according to your internal rules.

  8. If no matching authorization is found, treat the message as an unmatched or offline presentment and process it according to your reconciliation or exception-handling rules.

  9. Return the required acknowledgement response.

  10. Store the financial message, matching result, response returned, and x-correlation-id for audit, duplicate handling, and reconciliation.

For first presentment, system should attempt to match the presentment to the original authorization, unblock the pending amount, reduce the cardholder’s available balance, and acknowledge the message with Acknowledgement=1.

11.4 Financial / presentment matching criteria

Your system should match financial / presentment messages to the original authorization when possible using the original EHI fields.

The 1240 / P is a financial notification / first presentment and it should be matched to an authorization message, either 0100 or 0120. Also, Visa 05pp / P, 06pp / P, and 07pp / P are financial notifications that follow the same first-presentment matching approach.

11.5 Processing outcome

11.6 Required response

Financial / presentment messages should be acknowledged after your system receives and process the message.

  • Acknowledgement: Required. Indicates that your system received and processed the financial / presentment message.

  • Responsestatus: Optional. May be included when required by the EHI response contract or program configuration.

For financial and presentment messages, your system generally returns an acknowledgement response instead of a new approve or decline decision. Financial notifications include first presentments, financial reversals, and chargebacks, and that a valid EHI response may include Acknowledgement=1.

11.7 Financial / presentment request example

{
    "MTID": 1240,
    "Txn_Type": "P",
    "Token": "100467819",
    "TXn_ID": "6151096710",
    "Txn_Amt": 20.0000,
    "Txn_CCy": 826,
    "Bill_Amt": -20.0000,
    "Bill_Ccy": 826,
    "Settle_Amt": 20.0000,
    "Settle_Ccy": 826,
    "Auth_Code_DE38": "137716",
    "Ret_Ref_No_DE37": "119008935414",
    "Trans_link": "210709935414323232",
    "traceid_lifecycle": "VIS1-20191231-000000000937589",
    "Acquirer_Reference_Data_031": "74456126366123456789014",
    "MCC_Code": "8931",
    "Merch_ID_DE42": "testMerchant",
    "Merch_Name_DE43": "Visa Test GB",
    "Txn_Ctry": "GBR",
    "Clearing_Process_Date": "20210710",
    "Settlement_Date": "20210712",
    "Network_Transaction_ID": "0000000000937589",
    "SchemeTransactionIdentifier": "VIS1WT",
    "SendingAttemptCount": 1
}

11.8 Response example

The example below shows a minimal acknowledgement response using the expected JSON response envelope.

{
    "Acknowledgement":"1"
}   

11.9 Implementation notes

  • Financial / presentment messages should not be treated as new authorization requests.

  • Your system should attempt to match the presentment to the original authorization when possible.

  • Financial / presentment messages may arrive at the same time as the authorization or later.

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

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

  • Presentment amounts may differ from authorization amounts. Your system should apply your internal ledger rules for differences.

  • Refund or credit-to-cardholder messages should be processed according to your credit-handling rules.

  • Your system should avoid duplicate posting, block release, balance adjustment, or ledger impact if the same financial message 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.