A refund you cannot fund is worse than a refusal
Promising a refund and then discovering the balance is not there turns a disappointed customer into an angry one. Reserving first, and treating disputes as objects with deadlines, fixes both halves.
There is one thing worse than telling a customer you cannot refund them: telling them you can, and then failing.
The first is a disappointment. The second is a complaint, a review and usually a chargeback.
Why refunds fail late
The usual order is: accept the refund, tell the customer, then attempt it.
By the time it is attempted, the merchant’s balance may have settled out to their bank. The refund fails. The customer has already been told. Nobody involved has done anything wrong, and yet here you are.
Reserve first, promise second
A refund here reserves the amount atomically before it is accepted.
If the money cannot be reserved, the refund is refused at the point of request — while you are still talking to the customer, when you can say "I need to arrange this, give me an hour" instead of "it has been sent" followed by silence.
Being refused early is worse than being accepted and working. It is much better than being accepted and failing.
Partial refunds that cannot overrun
Every payment reports how much of it is still refundable.
Refund half today, a quarter next week, and the remaining figure is a number the system knows — not something your support team tracks in a spreadsheet and occasionally gets wrong in the customer’s favour.
Splits
Where a payment was split between several recipients — a marketplace, a platform taking a fee, a cooperative sharing proceeds — a refund has to come from somewhere.
The policy is recorded on the payment: each recipient gives back their share pro rata, or the merchant absorbs the whole amount. Both are legitimate; what matters is that it was decided in advance rather than argued afterwards.
A recovery that fails — a recipient whose balance is short — can be retried, rather than being silently abandoned and discovered during a year-end reconciliation.
Disputes are objects, not inboxes
A dispute lives in an inbox at most companies. Inboxes do not have deadlines; people do, and people forget.
Here a dispute is an object: a state, a timetable, the evidence attached to it. A deadline approaching is visible before it is missed, which is the only time that information is useful.
The cashier limit applies here too
A cashier can refund up to the limit the business sets. Above it, the refund is refused and has to be made by somebody with the authority.
Refunds are where a counter leaks, and the limit is what stops a slow leak becoming a flood.
What it costs
A refund returns money to the payer. Where a provider’s fee on the original payment is not returned by that provider, the statement shows it rather than absorbing it quietly — so you know the real cost of a return.
What you can check
These are facts about the running platform, not adjectives. Each one is visible in the product, in the API reference or in the ledger.
- A refund reserves the amount atomically; a refund that cannot be funded is refused at the point of request rather than failing later.
- The refundable balance of a payment is a figure the API reports, so partial refunds cannot quietly exceed the original.
- Disputes are objects with states and deadlines, not email threads, so a missed deadline is visible before it is missed.
- Where a payment was split between recipients, refunds are allocated pro rata or absorbed by the merchant according to the recorded policy, and failed recoveries can be retried.
- A cashier can refund only up to the limit the business sets; above it the refund is refused.
What it costs
Refunding returns the money to the payer. Where a provider fee on the original payment is not returned by the provider, the statement shows that rather than absorbing it silently.
Is it switched on?
Whether this is available depends on the authorisations in place and on what the administrator of a given deployment has switched on. That changes, and an article does not — so the live answer lives on the feature page, which reads it from the platform itself: Refunds and disputes on the features page.
Read next
- Settlement and statements — Know what was taken, not just what arrived.
- Team and roles — Delegate the counter, not the business.
- The ledger — Books that cannot be quietly edited.
Frequently asked questions
Can I refund more than once on the same payment?
Yes, up to what is still refundable. The remaining refundable amount is reported, so a series of partial refunds cannot quietly exceed the original payment.
What happens to a refund on a payment that was split?
It follows the policy recorded on the payment: each recipient gives back their share pro rata, or the merchant absorbs the whole amount. A recovery that fails can be retried rather than silently abandoned.
Why was my refund refused?
Most often because the amount could not be reserved — the funds were not available at the moment of the request. Being refused at that point is deliberately better than being promised a refund that fails afterwards.
Send with a QR code, add money by card or mobile money, issue a virtual card. Sandbox balances let you explore before any real money moves.
Keep reading
Un remboursement que vous ne pouvez pas financer est pire qu’un refus
Promettre un remboursement puis découvrir que le solde n’est pas là transforme un client déçu en client en colère. Réserver d’abord, et traiter les litiges comme des objets avec des échéances, corrige les deux moitiés.
Recurring billing people do not have to fight to escape
Subscriptions fail twice: a payment that bounces loses a customer who wanted to stay, and a cancellation that does not work loses one for ever. Dunning fixes the first; honest cancellation prevents the second.
Paying many people at once, without paying anybody twice
Bulk payouts fail in two directions: the whole file stops because of one bad row, or the retry pays the good rows again. Validating first and reporting per row removes both.