A payment that came back
A customer sends money to a supplier. It leaves, the app shows it as sent, and two days later it comes back because the account number was wrong or the receiving account was closed. The money lands in your account at the provider with a return reference and a reason code.
Your ops person spots it in the provider portal, or in the daily reconciliation, or when the customer asks why their supplier says they were never paid. They search for the original payment by amount and date, find two possible matches, pick the right one, credit the customer's balance by hand in the admin panel, and write a message to the customer in the helpdesk. Some returns wait a week before anyone notices them.
Why returns fall between the cracks
Outbound payments were built with care, because that is the product. Returns were an afterthought, because they are relatively rare. Rare is still a daily event once you have volume.
- The return comes with its own reference, and the link to the original is in a field your system does not read.
- Reason codes are scheme or provider codes that support staff cannot interpret.
- Nothing credits the customer automatically, so the money sits unallocated.
- The customer gets no message, or a generic one that does not say what to do.
- Recalls, rejections before sending and returns after sending are all handled the same way, even though they are different.
What slow return handling does
The customer's money is in limbo from their point of view, which is the worst feeling a payments product can create. Supplier relationships suffer, because the payment the customer thought was made was not. Unallocated funds build up in your provider account and turn into a reconciliation problem. Support handles angry tickets about something ops could have fixed earlier.
The returns process we build
What we build treats returns as a normal flow with its own handling, not an exception.
- Return and rejection events are read from the provider's webhooks or statement files as they arrive.
- Each is matched to the original payment using the provider's original reference field, then amount, date and counterparty as a fallback.
- Reason codes are translated into plain categories you approve, such as wrong account details, account closed or refused by the receiving bank.
- For confident matches, the customer's balance is credited through your ledger with a linked entry, and the original payment is marked returned.
- The customer gets a message in the app and by email explaining what happened in plain words and what they can do, such as checking the recipient's details.
- Unclear matches and unusual codes go to a small ops queue with the candidates side by side.
| Reason category | Customer message says | Ops involvement |
|---|---|---|
| Wrong account details | Check the details with your recipient and try again | None if matched |
| Receiving account closed | Ask your recipient for new details | None if matched |
| Refused by the receiving bank | The recipient's bank did not accept it | Review if repeated |
| Unknown or unusual code | We are looking into it | Always |
| No confident match | No message until matched | Always |
The wording of customer messages is yours. We draft them for your review, and your team can change them without a code release.
Returns on an ordinary day
Most returns are matched, credited and explained without anyone touching them. Customers see the money back and a clear reason, often before they notice the supplier has not been paid. Ops open a short queue of unclear items each morning, and each has the likely matches ready.
Unallocated funds stop piling up in the provider account, which makes the daily reconciliation cleaner too.
Signs returns are hurting you
- Returns are spotted in the provider portal or the daily reconciliation.
- Ops search for the original payment by amount and date.
- Customers learn about a return from their recipient.
- Support cannot explain reason codes.
- Unallocated money sits in your provider account for days.