External Host Interface (EHI) Integration Guide

Back
Next

14. Cut-off Messages

Cut-off messages are sent as part of cut-off processing and should be handled separately from standard transaction messages.

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

Cut-off messages are not authorization requests, financial messages, reversals, or chargebacks. They should not be processed as transaction approvals, declines, postings, or reversals.

CutOffId is the field used for cut-off messages. The response should contain Cut_OffResult, with 1 indicating success and 0 indicating failure.

14.1 Applicable identifiers

Cut-off messages are identified using the EHI fields included in the forwarded JSON payload.

14.2 Cut-off flow

14.3 How your system should process cut-off messages

When your system receives a cut-off message, it should:

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

  2. Identify the message as cut-off traffic using CutOffId.

  3. Check whether the same CutOffId was already received or processed.

  4. If the cut-off message is new, process it according to your internal cut-off, reconciliation, or operational rules.

  5. If the cut-off message is a duplicate, do not process it again.

  6. Return the required Cut_OffResult response.

  7. Store the cut-off message, CutOffId, response returned, processing outcome, and x-correlation-id for audit, duplicate handling, and reconciliation.

14.4 Duplicate handling for cut-off messages

Your system should treat CutOffId as the primary identifier for detecting duplicate cut-off messages.

14.5 Required response

Cut-off messages must return a cut-off response using Cut_OffResult. This field indicates whether the cut-off message was processed successfully.

For compatibility, some flows may also accept an acknowledgement response, but the preferred cut-off response is Cut_OffResult.

14.6 Cut-off request example

  {
"CutOffId":38077,
"ProductId":99883,
"CutOffDate":"2022-11-29 13:00:01.837",
"FirstTransactionId":6154805771,
"LastTransactionId":6154805771,
"AuthsAcknowledged":1,
"AuthsNotAcknowledged":0,
"FinancialsAcknowledged":0,
"FinancialsNotAcknowledged":0,
"LoadsUnloadsAcknowledged":0,
"LoadsUnloadsNotAcknowledged":0,
"BalanceAdjustExpiryAcknowledged":0,
"BalanceAdjustExpiryNotAcknowledged":0
}

14.7 Response examples

Cut-off success response:

{
"Cut_OffResult": 1
}

Cut-off failure response:

{
"Cut_OffResult": 0
}

14.8 Implementation notes

  • Cut-off messages should not be treated as authorization requests.

  • Cut-off messages should not be treated as financial, reversal, or chargeback messages.

  • Your system should identify cut-off traffic using CutOffId.

  • Your system should use CutOffId as the primary duplicate detection key for cut-off traffic.

  • If the same CutOffId is received again, your system should not process the cut-off message again.

  • Your system should return the same logical response for duplicate cut-off messages.

  • Your system should return Cut_OffResult = 1 when the cut-off message is processed successfully.

  • Your system should return Cut_OffResult = 0 when cut-off processing fails.

  • Your system should store CutOffId, response returned, processing outcome, and x-correlation-id.