Payout Failed or Not Sent? Telling Customers Only When the Partner Refuses

A customer gets a message saying their transfer failed. An hour later their family receives the money anyway. Or the opposite happens: the operator retries a "failed" payout, the partner pays both, and the business is out of pocket while it chases a refund across borders. Both come from the same mistake: treating every problem on a payout as a failure. This guide is for payout operations and support leads who want customers told the truth, and every payout sent exactly once.

The principle: only the payout partner can fail a payout. Everything else is a problem for your team to look at, and the customer does not need to hear about it yet.

RemitSo, a white label remittance platform, works this way since releases 2026.09.5 and 2026.10.5. A payout is failed, and the customer told, only when the partner refuses it. Your team still decides when to retry, when to call the partner and what to tell a customer who asks.

The third row is the dangerous one. When a request times out, the partner may have received it and paid. Sending it again without checking is how businesses pay twice.

In RemitSo, a refused credential, a partner outage, a timeout or an answer the platform could not read no longer fails the payout. It stops the payout in Error, with:

• The reason, in plain words.
• Whose side the fault was on: the platform, a setting on your installation, or the partner.
• An alert to whoever is subscribed to Payout not sent because of a fault on our side.

The customer is not told the payout failed. From their side, the transfer is still on its way, which is the truth.

When someone presses Retry, the console asks them to confirm with the partner first wherever the partner may be holding the payout. If nothing was sent, for example the payout stopped at the name check or the quote, Retry goes straight through.

Two quieter problems cause just as many complaints:

• Unknown answers. A partner returns a status the platform does not recognise. Older systems leave the payout in Processing with nothing to say so. RemitSo stops it in Error and raises the alert, and does not send it again until someone has checked with the partner.
• Silence. A partner accepts a payout and never says anything again. RemitSo asks about every payout on a schedule that fits it: often while it is new, less often as it ages. A payout the partner stops answering about appears on Scout, the page that lists everything waiting on a person. It is never cancelled blindly.

And one rule underneath all of it: a payout is never sent for a transfer whose payment has not cleared, however the transfer got there.

1. A customer pays at 17:58. The payment clears and the payout is sent to the partner at 18:01.
2. The partner's system is slow and the request times out. Nobody knows whether it arrived.
3. The payout stops in Error, with a reason saying the partner did not answer and the outcome is unknown. The customer's app still shows the transfer on its way.
4. The on-call operator gets the alert, opens the payout and sees whose side it is on. Retry asks them to confirm with the partner first.
5. They check the partner's portal. The payout arrived and is being processed. They wait. The next status check picks up the payment and the customer is notified it was paid.

Nobody told the customer it failed. Nobody sent it twice.

• The partner's own reason on a refused account check, instead of "Name lookup failed", so support can tell the customer exactly what to fix.
• A "Stranded before sending" filter on the transactions list for payouts left behind by older versions.
• Bulk payout updates, previewed row by row: upload up to 500 transfers with their new status, see what each row would do or why it is refused, and only then apply. A payout the partner may still hold is refused rather than overwritten.
• A refused payout update says why on the form, instead of doing nothing.
• The AI Assistant, an optional add-on, can answer "whose side is this on?" for any transfer in seconds.

Payout handling is part of every RemitSo installation. Read how payouts, alerts and Scout fit together in the admin features, see what customers see in the customer app, follow each change in the release notes, or book a demo.