Stuck Payment Detection Guide

A stuck payment is one that has been submitted but has not yet received a final outcome (e.g. ACSC, RJCT, or scheme equivalent) within the expected window. The expectation is derived from scheme rules, corridor norms, or internal SLA. Detection is often event-driven: the absence of a settlement or rejection status by a given time triggers an alert or case. pacs.002 and similar status flows are the primary source for “last status” and timing.

Detection runs when the elapsed time since submission (or since last status update) exceeds the configured threshold. Thresholds can be set by rail, corridor, or product. Once triggered, the payment is flagged for triage: confirm whether it is genuinely stuck or delayed within normal variance. SLA breach thresholds may be aligned with the same or a different timer for escalation and client communication.

• Confirm the payment identifier and last known status (e.g. ACSP, PDNG) and the timestamp of that status.
• Compare elapsed time to the expected settlement window for the rail and corridor.
• Check whether a return or reject was sent but not yet ingested; trace the full path if needed.

• Ingest status updates (e.g. pacs.002) in near real time so that “no update” is distinguishable from “not yet received”.
• Define SLA and stuck thresholds per rail/corridor and feed them into monitoring so alerts are consistent and actionable.
• Use stuck detection to open cases or investigations and to trigger client or internal escalation where appropriate.