Payment reject vs return vs pending
Operators lose time when these outcomes are conflated. Reject, return, pending, and settled describe different lifecycle stages and require different triage — on SWIFT, SEPA, and ISO 20022 status flows alike.
This hub is the cross-rail narrative; linked pages hold scheme-specific codes and playbooks.
Payment outcomes by stage
Reject = not accepted or processing stopped early. Pending = accepted into flow, no terminal outcome yet. Return = processed but reversed with a reason code. Settled = terminal success.
Definitions (operator-grade)
- Reject
- The payment or message was not accepted, or processing ended with an explicit rejection before settlement — e.g. SWIFT NACK, pacs.002 RJCT. Fix the message or data and resubmit where applicable.
- Pending
- In-flight: accepted into the pipeline but no terminal outcome yet — e.g. pacs.002 PDNG or ACSP. Monitor against corridor SLA; see why payments get stuck.
- Return
- Processed but not completed; scheme or bank issues a return reason — e.g. SEPA R01, beneficiary-side SWIFT business return. Investigate reason code and client impact.
- Settled
- Terminal success — e.g. pacs.002 ACSC. Close monitoring; archive evidence if required.
SWIFT failure stages
NACK = format/network reject before business processing. Routing failures occur at correspondent hops. Business rejects/returns happen at beneficiary processing.
Triage order
- Identify the last known status and timestamp (status message, gateway, or ops console).
- Classify: reject vs pending vs return vs settled — do not assume “failed” without the code.
- Match to rail: SWIFT NACK/routing vs SEPA R-code vs pacs.002 status.
- Follow the linked reference or playbook; escalate if pending exceeds SLA.
Deep reference
- SWIFT error codes overview— NACK, routing, business rejects
- SEPA return codes overview
- pacs.002 status codes
- Investigate a rejected SWIFT payment
Preflight
Model rejects, returns, and stuck pending states in sandbox before and after execution — same control plane for demos and investigation training.
Open API referenceWhy payments fail (routing hub) → · Full reference index →
Preflight is a pre-execution and post-execution control layer for payments.
Preflight models these scenarios deterministically before and after execution.