Why payments get stuck
“Stuck” is what businesses see; operators see state divergence — the payment is no longer moving toward a known terminal outcome within the corridor SLA. This page maps causes, signals, and investigation entry points without generic payment advice.
Pair with reject vs return vs pending when the last status is unclear.
Stuck = expected event did not arrive in time
Detection compares last known status and elapsed time to corridor SLA. Absence of pacs.002 (or equivalent) updates is treated as a signal, not silence.
pacs.002 status progression (simplified)
ACSP is acceptance into processing, not final settlement. PDNG without a follow-up status within the corridor window is a common stuck signal.
Common stuck patterns
- Pending without progression — ACSP or PDNG with no ACSC/RJCT within the expected window (pacs.002 reference).
- Missing status ingestion — the event occurred upstream but your monitoring never received it; looks stuck locally.
- Routing and intermediary delay — extra hops or correspondent queues (intermediary routing failure).
- Cut-off and liquidity timing — submission after value or FX cutoffs (cut-off failure (cross-border)).
- SLA breach without terminal code — internal or corridor timer fired before a final status (SLA breach monitoring).
Investigation flow
- Last status + timestamp → classify pending vs unknown.
- Elapsed time vs rail/corridor SLA → stuck flag or wait.
- Trace path for routing/cutoff; confirm ingestion of status/return messages.
- Escalate with evidence pack if client-facing SLA applies.
Operator reference
Preflight
Simulate stuck and SLA-breach scenarios deterministically — train investigation and monitoring without production risk.
Open API referencePreflight is a pre-execution and post-execution control layer for payments.
Preflight models these scenarios deterministically before and after execution.