When a Payment Gateway Says Yes but the Money Never Arrives

A customer pays, the gateway says yes, and the transfer moves on. Days later finance finds the money never reached your account, or reached it twice, or arrived for a payment your platform had already cancelled. For a money transfer operator this is not an edge case. Between the moment a gateway reports success and the moment funds are settled and yours, a payment can be reversed, duplicated, recalled, disputed or simply forgotten. If the payout has already gone, the loss is yours.

This guide is for operations leads, finance teams and the people who decide whether a transfer waits or goes.

RemitSo is one way to run this: every gateway is handled the same safe way, alerts say in plain language when a payment does something unexpected, and Scout lists payments needing action. Your team still chooses when to hold, release, refund or recover. The method below works on any platform.

The customer's bank or card issuer approves the payment and the gateway reports it. Later the funds are captured, cleared and settled into your account. Depending on the method, that gap is seconds or days, and during it the payment can still change.

The operational question is never "did the gateway say yes?" It is "is this money ours, finally enough, to send a payout against?" Those are different questions, and the answer depends on the payment method, the gateway and your appetite for risk.

Each of these needs a different response.

The provider never answers

The confirmation never arrived, or arrived in a form your platform could not apply. Without a poller that asks the gateway and gives up cleanly, these payments wait until the customer complains.

Success arrives for an attempt you already closed

Your platform timed out the attempt, or the customer cancelled and tried another method, and then the first gateway reports success. The funds are real. If your platform ignores the message because the attempt is closed, you are holding a customer's money with no transfer attached to it.

The customer paid twice

A double tap or a retry after a slow screen. One transfer, two payments; someone must refund the extra at the provider.

The bank takes the money back

A direct debit is returned, a bank transfer is recalled, a push payment is reversed after a fraud report. The money was in your account and now it is not.

A chargeback is raised

The cardholder disputes the payment and the funds are pulled pending the outcome.

The customer says they paid, but nothing has arrived

For manual bank transfer, the customer clicks "I have made payment". That is a claim, not a confirmation. A person needs to check the account and match the deposit before the transfer moves.

The refund never reaches the customer

You decided to refund, the refund was sent, and it failed: a closed card, a rejected bank account. The customer believes they have their money back; they do not.

Each failure mode maps to a state your platform should record and a decision someone should own. The table below is a starting point; extend it with the methods and gateways you use.

Two principles sit behind the table. First, a payment that changes after the fact should be left in its state and flagged, not silently rewritten, so that a person decides and the history stays readable. Second, every state should be one your platform defines, with defined transitions between them, so that a payment cannot drift into a state nobody recognises.

Most operators add gateways one at a time, each built to the gateway's own model, each with slightly different rules for what counts as paid, when an attempt expires and what happens to a late confirmation. Operations teams learn the quirks by getting burnt.

The fix is to record every payment method consistently, so the same situation produces the same state and the same safe behaviour whichever gateway it came through. Your release rule can then differ by method deliberately, not by accident of integration.

When you assess your own platform, ask for each gateway: what happens when a confirmation arrives after expiry, when two captures arrive for one transfer, and when the gateway never answers. If the answers differ between gateways for no business reason, you have a gap.

Reconciliation is where the gaps above are caught if they were not caught in the moment. A practical routine has four layers.

1. Every day, clear the exceptions. Work the list of payments still waiting for a provider, payments the poller gave up on and refunds that failed. Each should end the day either resolved or with a named owner and a note.
2. Every day, match deposits. For manual bank transfers, match each deposit to what the customer declared, to the cent. If the amount does not match, hold it; do not move money on a near match.
3. Every settlement, match the gateway report. Compare the gateway's settlement report with the payments your platform recorded as cleared for the same period. Differences fall into a short list: timing, fees, reversals, duplicates and payments you never recorded.
4. Every month, read the accounts. In a double-entry ledger, each payment, refund, fee and reversal is posted, and a balance can be traced to the transactions behind it. Unexplained balances in a gateway's clearing account are almost always one of the failure modes above.

When a gateway disputes your version, quote the logs: the outbound requests and raw responses, and the webhook messages it sent you, with the reason any failed.

Holding every transfer until final settlement would make most remittance products uncompetitive. The aim is a written release rule per payment method, applied consistently. Before releasing, check:

• Is the payment in a cleared state under your rule for this method? Not "authorised", not "customer says paid".
• Is there exactly one payment for this transfer? If there are two, decide which funds the transfer before releasing.
• Does the amount received match the amount declared? A mismatch is a hold, not a rounding question.
• Has anything happened to the payment since it cleared? A recall or chargeback that arrives before the payout is a reason to stop.
• Do your risk rules have anything to say? Card chargeback history, repeated declines or payment details reused across customers may justify a hold even on a cleared payment.

Once a payout is approved and sent, it should be locked: what goes out is what was approved. If something then goes wrong on the payment side, the response is to ask the partner to stop or return the payout where they can, or to recover the funds, not an edit.

The numbers below are illustrative, chosen to show the reasoning rather than to describe any real operator.

An operator takes card payments through one gateway and bank payments through a second. At 16:00 on Friday, the operations lead opens the list of payments needing action and the day's alerts.

Step 1: see the whole picture

• 9 payments on the bank gateway still waiting for the provider to answer.
• 2 bank payments the poller gave up on.
• 1 "Payment received on closed attempt" on the card gateway.
• 1 "Duplicate payment captured" on the card gateway.
• 3 "Customer clicked 'I have made payment'" for manual bank transfer.
• 1 "Chargeback raised on a payment" on a card transfer paid out last week.

Step 2: look for a pattern

Nine waiting payments on one gateway in an hour is a pattern. The webhook log shows nothing from the bank gateway since 15:10; the outbound API log shows status checks to it returning 503. The gateway is having a problem. The lead tells the gateway, with the time window and a few request IDs, and leaves the 9 on hold. They are not released on the strength of the customer's screen.

The 2 the poller gave up on are older and are looked up in the gateway's own portal. One was paid; it is recorded as such and the transfer released. The other was never completed by the customer; it expires and the customer is told they can retry the payment.

Step 3: handle the card cases

The closed-attempt payment belongs to a customer who timed out on card, switched to bank transfer and paid that way too. The transfer is already funded by the bank payment, so the card payment is refunded at the gateway and recorded with a reason. The duplicate capture is a double tap: two identical captures seconds apart. One funds the transfer; the other is refunded.

Step 4: verify the manual transfers

Of the 3 customers who clicked "I have made payment", 2 deposits are in the account and match the declared amounts exactly; they are released. The third deposit is short by a bank fee. It is held, and the customer is contacted about the shortfall.

Step 5: the chargeback

The disputed card payment funded a payout that has already been paid. The payment is left in its state. Finance gathers the evidence of the transfer and decides to contest; compliance reviews the customer's history and puts further transfers on hold pending the outcome.

Step 6: close the day

At 17:20 the bank gateway recovers. The poller collects 8 confirmations; 1 payment was never completed. Everything is resolved or owned before the team leaves.

1. Work the payments still waiting for a provider, and look for a pattern by gateway.
2. Resolve every payment the poller gave up on by checking the gateway directly.
3. Link or refund every payment received on a closed attempt.
4. Refund the extra on every duplicate capture at the provider, with a reason.
5. Verify "I have made payment" claims against deposits, to the cent.
6. Stop any unpaid transfer where the bank took money back or a chargeback was raised; start recovery on any already paid out.
7. Fix and reissue refunds that failed to reach the customer.
8. End the day with every item resolved or owned.

RemitSo gives operations and finance teams the controls described above. Your team still writes the release rule and makes each decision.

• Payment Gateway Safety Net: every way a customer can pay is recorded consistently, so every gateway behaves the same safe way and your team learns one set of rules, not one per gateway.
• Payment polling engine: rebuilt with stronger reconciliation and expiry handling, so a missing confirmation is chased and an abandoned attempt expires cleanly.
• Defined payment states: payment states and the transitions between them are defined and reviewable, so a payment cannot drift into a state nobody recognises.
• Scout, payments needing action: payments still waiting for a provider, payments the poller gave up on and refunds that failed to reach the customer, measured every five minutes. See the admin features.
• Plain-language alerts: "Payment received on closed attempt", "Duplicate payment captured", "Chargeback raised on a payment", "Bank took money back", "Customer clicked 'I have made payment'" and "Payment successfully cleared" go to the people subscribed to them.
• Deposits matched to the cent: anything unclear is held; if the amount does not match, the money does not move.
• Double-entry accounting: every payment, refund, fee and reversal is posted; mistakes are reversed, never edited, and any balance can be traced to the transactions behind it.
• Outbound API and webhook logs: the raw request, response, status and error for every gateway call, and every incoming message saved before processing, so you have the evidence when a gateway's version differs from yours.
• Payouts locked once approved and never edited.

See the release notes or book a demo.