Free resource
Stuck payout checklist. What to check before anyone presses retry.
A free checklist for payouts stuck in pending, processing or unknown: what to check, in what order, what evidence to keep and when to escalate.
Last updated:
Download the CSV checklistOn this page 6 sections
What this checklist is
Twelve checks, in order, for a payout that is stuck in pending, processing or unknown, or that the recipient says never arrived. Each step says what to check, what evidence to keep, and when to stop and escalate. It is vendor-neutral and works with any payout provider or rail.
The rule behind every step: a payout with an unknown outcome is never sent again until evidence shows the first one did not move money. Most duplicate payouts start with someone pressing retry on a payout that had already been paid.
The checklist
| Step | Check | Evidence to keep | Stop and escalate if |
|---|---|---|---|
| 1. Freeze retries | Block every path that could send this payout again: retry loops, queue redelivery, operators, scripts and AI agents. | The payout id, idempotency key and the time the block was set. | Anyone has already resent it. Treat it as a possible duplicate and go to step 9. |
| 2. Read your own record | Confirm what was instructed: amount, currency, beneficiary, reference, provider and the time the request left your system. | The stored instruction and the request log line. | The instruction differs from what the customer or finance approved. |
| 3. Classify the last answer | Was the last provider answer a success, a definite rejection, a retryable error, or nothing at all (timeout, reset, server error)? | The raw response or the absence of one, with timestamps. | The answer was a definite rejection: the payout failed and can be fixed and re-approved. |
| 4. Look it up by your reference | Query the provider’s status endpoint by your client reference or idempotency key, not by a new request. | The lookup request and the provider’s answer, stored as a claim. | The provider says it never received the instruction and marks it safe to retry with the same key. |
| 5. Wait for the callback window | Check whether the provider’s webhook for this payout is still inside its documented window, and whether one arrived and was rejected by your verification. | Callback logs, including rejected or unverified deliveries. | A verified callback settles the status. |
| 6. Check the rail’s reference | Ask for, or find, the rail-level reference (for example the UTR or RRN on Indian rails, or the end-to-end reference on ISO 20022 rails). | The rail reference and where it came from. | The reference shows the credit reached the beneficiary bank or wallet. |
| 7. Check settlement evidence | Look for the payout in the provider’s settlement file or balance statement, and for the matching debit on your prefunded balance. | The file name, line and balance movement. | The payout is in the settlement file: money left the provider. |
| 8. Check your bank statement | Match the cash movement for the settlement that covers this payout. | The statement line and its date. | Cash evidence contradicts the provider’s status. |
| 9. Check for a duplicate | Search provider and settlement evidence for a second payout with the same beneficiary and amount around the same time. | Both references, if found. | Two payouts exist: start a recall with the provider and record the decision. |
| 10. Escalate with evidence | Send the provider one message with everything above, and open an exception with an owner and a due time. | The ticket reference and the exception id. | The window agreed with the provider has passed with no answer. |
| 11. Decide and record | A named person decides: wait, recall, refund the sender, or re-approve a new payout. The decision is recorded with its reason and evidence. | The decision, the person, the time and the evidence it relied on. | - |
| 12. Watch for late evidence | Keep the payout open until settlement and bank evidence agree. A return or late callback reopens it. | Any evidence that arrives after the decision. | - |
Where to start, by status
- Timeout or no answer: start at step 1. The outcome is unknown, not failed.
- Pending or processing: start at step 4, and check that the callback window has actually passed.
- Succeeded, but the recipient has nothing: start at step 6. Ask for the rail reference and check settlement evidence.
- Returned or reversed: match the return to the original payout, then decide at step 11.
What to send the provider
One message with everything, so the first reply can be an answer: your payout reference and idempotency key, the amount and currency, the time you sent it, the provider’s payout id if you have one, the rail reference if known, the masked beneficiary details, and what you have already checked. Ask for the status, the rail reference and whether the payout appears in their settlement report.
How to use the CSV
The CSV has one row per step with columns for the stage, the check, the evidence to keep, the stop condition, an owner, the time it was done and notes. Copy it for each stuck payout, or load it into your ticketing tool as a template. It opens in Excel, Google Sheets or Numbers.
Download and related reading
Download the stuck payout checklist (CSV)
The checklist is vendor-neutral: use and adapt it freely.
Let’s make it specific to you.
Bring your systems, payment flows, and questions. We’ll help define the next step.
Talk to the team