11. Financial / Presentment Messages

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, store 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 store 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.