Skip to content
Switch to light mode

External Host Interface Integration Guide

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.

On this page

14.1 Applicable identifiers

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

FieldExpected valueDescription
CutOffIdVariesIdentifies the cut-off message. Use this as the primary identifier for cut-off processing and duplicate detection.
Cut_OffResultResponse fieldIndicates whether cut-off processing succeeded or failed.
MTIDNot the primary identifierCut-off messages should be identified using CutOffId when present.
Txn_TypeNot the primary identifierCut-off messages should be processed as cut-off traffic when CutOffId is present.
SendingAttemptCountVaries, when presentMay help identify repeated delivery attempts.

14.2 Cut-off flow

Cut-off flow

Platform

Payblr

System

Your Systems

1. Forward original EHI cut-off payload

Cut-off

Payblr forwards the original EHI cut-off 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 cut-off using CutOffId

Your system identifies the cut-off message using CutOffId.

Your SystemsprocessesYour Systems

4. Check whether CutOffId was already processed

Cut-off

Your system checks whether the CutOffId was already processed.

Your SystemsprocessesYour Systems
altNew CutOffId

5. Process according to internal cut-off rules

For a new CutOffId, your system processes the cut-off according to internal rules.

Your SystemsprocessesYour Systems

6. Return Cut_OffResult = 1, or 0 if failure

Cut-off

Your system returns Cut_OffResult = 1 on success, or 0 if processing failed.

Your SystemsPayblr
altDuplicate CutOffId

7. Do not process cut-off message again

For a duplicate CutOffId, your system does not process the cut-off message again.

Your SystemsprocessesYour Systems

8. Return same logical Cut_OffResult response

Cut-off

Your system returns the same logical Cut_OffResult response for the duplicate CutOffId.

Your SystemsPayblr

9. Relay cut-off response through the transaction flow

Payblr relays the cut-off response through the transaction flow.

PayblrprocessesPayblr
sequenceLaneCenter(index, columnCount)

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.

ScenarioRequired handling
New CutOffId receivedProcess the cut-off message and return the appropriate Cut_OffResult.
Duplicate CutOffId receivedDo not process the cut-off message again. Return the same logical response as the original processing.
Cut-off processing succeededReturn Cut_OffResult = 1.
Cut-off processing failedReturn Cut_OffResult = 0.
Temporary processing issueReturn the agreed failure response and log the issue for investigation.

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.

ResultCut_OffResult
Cut-off processed successfully1
Cut-off processing failed0

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.