A customer does not care that a partner's API returned an error. They care that the money has not arrived. The payout problems that turn into complaints are rarely the clean refusals; they are the payouts sitting in an unclear state while nobody looks. This guide is for payout operations and support leads who want to find those first.
It covers how to tell a refused payout from a stuck one, which ones are safe to retry, a worked timeline, and a checklist your team can run every day. Timings and thresholds are illustrative.
Refused, in error, or not answered
Most payout tooling has two outcomes: success and failed. Real operations have at least three kinds of problem, and each needs a different response.
| State | What you know | Tell the customer? | First action |
|---|---|---|---|
| Refused by the partner | The partner has said no, with a reason | Yes, with what to fix | Correct the details or refund |
| In error on your side | The instruction did not leave cleanly: a fault, a missing setting, a timeout, an answer you could not read | No, not yet | Find out whether the partner received it |
| Not answered | The partner took it but has not confirmed; it is getting old | Only if it passes the time you promised | Chase the partner |
The middle row is the dangerous one. After a timeout, the money may have been accepted by the partner while the reply was lost. Retry blindly and you may pay twice. Mark it failed and you tell a customer their transfer failed when it may already be in the recipient's account.
Causes, signals and whether a retry is safe
| Cause | Signal | Whose side | Next action | Retry safe? |
|---|---|---|---|---|
| Invalid account or name mismatch | Partner refuses with a reason | Recipient details | Ask the sender to correct details | Only after correction |
| Unsupported method or bank | Partner refuses | Setup | Fix the delivery option, then resend or refund | After the fix |
| Compliance refusal at the partner | Partner refuses with a compliance reason | Partner | Compliance review, not a retry | No |
| Missing setting on your side | Instruction never sent | Yours | Fix the setting and resend | Yes, nothing left you |
| Timeout after sending | No reply to the call | Unknown | Check the call log, then ask the partner | Only once the partner confirms it does not hold it |
| Partner outage | Calls failing across many payouts | Partner | Wait, or route new transfers elsewhere | Not until the partner confirms what it holds |
| Accepted, then silent | No status change past the usual time | Partner | Chase on a schedule, escalate | No |
| Reversed after payout | Partner reports a reversal | Partner or recipient bank | Contact the sender, refund or resend | After the reason is known |
Watch out: "if it failed, try again" is the most expensive rule in payouts. Retry only when you know the partner does not hold the instruction.
A GBP to NGN payout, minute by minute
A customer in the UK sends £500 to a bank account in Nigeria. Payment clears at 10:02. Illustrative timings:
| Time | What happens | Customer sees |
|---|---|---|
| 10:02 | Payment cleared; transfer ready for payout | Payment received |
| 10:03 | Payout sent to the partner; the call times out. The payout stops in Error, with the reason and whose side it is on. The team's subscribers get the alert. | No change; no failure message |
| 10:05 | The payout appears on Scout, under payouts needing action. | No change |
| 10:12 | The operator opens the outbound call log: the request went out, no response came back. Correlation ID noted. | No change |
| 10:20 | Operator asks the partner, quoting the correlation ID. The partner confirms it never received the instruction. | No change |
| 10:22 | Operator retries, confirming the partner was asked. The partner accepts. | Sent to Bank |
| 10:40 | Partner confirms payment. | Completed, with a push notification |
Had the partner said "we have it" at 10:20, the right move was not to resend but to wait for its confirmation, chasing on schedule. Either way, the customer was never told the transfer had failed, and the support team never heard about it.
Doing it with RemitSo
The timeline above is how RemitSo handles payouts.
- Failed means refused. A payout is marked failed, and the customer told, only when the partner refuses it. A fault on the platform's side, an outage, a timeout or an unreadable answer stops it in Error with the reason and whose side it is on. Nothing is left sitting in Processing.
- Retry asks first. Where the partner may already hold the payout, Retry asks the operator to confirm with the partner first. A payout the partner may hold is never resent without that confirmation.
- Every payout chased. Payouts are asked about on a schedule that fits them: often when new, less as they age. One the partner stops answering about appears on Scout and is never cancelled automatically.
- Scout, every five minutes. Scout shows payouts needing action, including those in Error and those overdue at a partner, plus partners failing calls under system health.
- Logs for the 10:12 check. Every outbound call to a partner is logged with payloads, status, errors and correlation ID, keys masked. Every incoming webhook is saved before processing, so nothing is lost, and a failed one can be retried in one click.
- Alerts in plain language. "Payout not sent because of a fault on our side" says whose side the fault was on and whether the partner must be asked before retrying. "Payout attempt failed", "Payout reversed" and "Payout completed successfully" go to whoever subscribes.
- Status words that fit the method. Customers see "Sent to Bank", "Ready for Pickup" or "Sent to Wallet" in the app, push, email and statements. A payout is never sent before the payment has cleared.
Holds agreed with a partner by phone are recorded on the payout by hand, with a required reason that is kept. For the logging side in detail, see payout partner failures, API and webhook logs and why payouts fail only when the partner refuses. With the AI Assistant, an optional add-on, an operator can also ask whether a failure was the platform's, a setting's or a partner's.
Set an age limit for each payout method
A payout does not need an error to be a problem. Age is a signal. Set your own limits per corridor and method from what your partners normally achieve; the examples below are a starting point, not a standard.
| Payout method | Look at it after | Chase the partner after | Tell the customer after |
|---|---|---|---|
| Instant bank transfer | 15 minutes | 1 hour | The time you promised |
| Standard bank transfer | Next business day | 2 business days | The time you promised |
| Mobile wallet | 15 minutes | 1 hour | The time you promised |
| Cash pickup | Not collected after 7 days | Check the code is live | Remind the sender |
Watch patterns too. Ten errors on one partner in an hour is a partner problem, not ten customer problems. A rising refusal rate on one corridor while others are steady points to that corridor's partner, bank network or a rule change. A platform-wide failure rate hides both.
A daily payout checklist
- Start of shift: clear every payout in Error. For each, check the call log before deciding.
- Every hour: look at payouts past their age limit, grouped by partner.
- Before any retry: confirm the partner does not hold the instruction, and note who you spoke to.
- Refusals: group by reason. Several name mismatches on one corridor may mean the recipient form needs changing.
- Partner health: any partner failing calls? Tell support before the customers call.
- End of day: reconcile what the partner says it paid with what you show as delivered; investigate every difference.
- Weekly: review refusal and error counts by partner and corridor, and adjust age limits.
Tell customers what is true, when it is true
Do not tell a customer a payout failed when it is in error on your side; fix it first. Do not show "Delivered" until the partner confirms. When a payout passes the time you promised, say so before they ask, and give a next update time. Accurate status is part of the service, not a support extra. See also retry logic and idempotency.
Sources
- Financial Stability Board: Recommendations for Regulating and Supervising Bank and Non-bank Payment Service Providers Offering Cross-border Payment Services: Final report (12 December 2024), which names operational, third-party and resilience risks among those supervision should address.
Checked October 2026. Regulations change; confirm current requirements with the regulator or your adviser.
Frequently asked questions
What is the difference between a failed payout and a stuck one?
A failed payout has a known outcome: the partner refused it. A stuck payout has no outcome yet; it may have been paid and the confirmation lost. They need different actions.
Should a timed-out payout be retried automatically?
No. The partner may have accepted it. Check the call log, ask the partner, and retry only when it confirms it does not hold the instruction.
When should the customer be told a payout failed?
When the partner has refused it and you know what the customer must do. A fault on your side is yours to fix, not theirs to worry about.
How does RemitSo stop a payout being paid twice?
A payout in Error is not resent automatically. Where the partner may already hold it, Retry asks the operator to confirm with the partner first.
What happens if a partner stops replying about a payout?
RemitSo keeps chasing on a schedule, and the payout appears on Scout for an operator. It is never cancelled automatically.
Which payout figures should we track?
Payouts in error, payouts past their age limit, refusals by reason, and all three by partner and corridor. Add daily reconciliation differences.