Achekam

Refunding a subscriber twice by mistake

How a provider ends up refunding a subscriber twice when the bank also reverses the payment, the checks that prevent it, and how to put it right.

By Achekam · · 5 min read · For Telecoms businesses in South Africa, Nigeria, Kenya

double refund bank reversal

A subscriber cancels mid-month after a move and asks for the unused part of their payment back. The support agent agrees, and someone in finance processes a refund through the payment provider the same afternoon. What nobody knows is that the subscriber, tired of waiting for a reply, had already asked their bank to reverse the payment. A week later both credits have landed in the subscriber's account, and your provider is short by the full amount of the payment.

It happens more than providers admit, and it is almost always a timing problem between two teams and two systems. This article explains how a double refund happens, the checks that stop it, how refunds are recorded when Achekam does not send them itself, and what to do when one has already gone out.

How the money goes out twice

Stripe's documentation warns about exactly this risk for bank debit payment methods: if a business proactively refunds a payment while the customer's bank also starts a dispute, the customer might receive two credits for the same transaction. Its guide to refunding and cancelling payments explains the risk alongside the rules on partial refunds and fees, and it is worth reading whichever provider you use.

The underlying problem is that the subscriber has two routes to their money and you control only one of them. The refund you send goes through your payment provider. The reversal the subscriber asks for goes through their bank. Neither system knows about the other until the money has moved.

Check for a dispute before you refund

The simplest defence is a check before every refund: has the subscriber already gone to their bank?

Stripe states that while a dispute is open, a business cannot issue a refund outside the dispute process. Where your payment provider follows that rule, an open dispute blocks the second credit for you. But not every reversal reaches your provider as a dispute straight away, and debit orders collected through a bank or a separate collection service may show up only on the bank statement. So build the check into your refund routine rather than relying on the system:

  1. Look in the payment provider's dashboard for any dispute, chargeback or inquiry on the payment.
  2. Look at the bank statement for a reversal or unpaid debit for the same subscriber and amount.
  3. Ask the subscriber in writing whether they have contacted their bank about the payment.
  4. Refund only when all three are clear, and note the checks on the subscriber's account.

Stripe also notes that each dispute raises the business's dispute rate with that card network. A refund made promptly, before the subscriber feels the need to go to the bank, avoids the dispute as well as the double payment.

Cancel rather than refund where you can

Stripe explains that a payment can be cancelled before it is completed at no cost, while refunding all or part of a successful payment might incur a fee, and the processing fees from the original transaction are not returned. If a subscriber asks to stop a payment that has not completed yet, cancelling it is cleaner and cheaper than letting it go through and refunding afterwards.

Never more than was charged

Stripe states that a business can issue more than one refund against a charge but cannot refund a total greater than the original charge amount. That rule protects you inside one provider: two agents cannot both refund the full payment through the same dashboard.

It does not protect you across systems. A refund through the provider plus a reversal through the bank can easily add up to twice what was charged, because each system only sees its own side. Treat "never refund more than was charged" as your own rule across every channel, and check the subscriber's account in your books, not just the provider's dashboard, before approving a refund.

How refunds are recorded in Achekam

Achekam does not send refunds of online invoice payments through the gateway. The refund is made in the gateway's own dashboard and recorded by a person. Achekam also never charges a business's customer automatically: there are no saved cards or debit orders, so if you collect by debit order, that runs through your bank or collection service outside Achekam.

On the books side, customer payments are recorded against invoices, and administrators can refund or reverse a receipt. That gives you a clear rule for the two different events:

  • A refund you made through the gateway: an administrator records the refund against the subscriber's receipt, with the gateway's refund reference.
  • A reversal by the subscriber's bank: an administrator reverses the receipt, so the invoice shows as unpaid again, with the bank statement line as support.

Your bank reconciliation is the backstop. Bank lines are matched by suggestion and a person accepts each match, and a reconciliation completes only when there is no difference left or every leftover line is explained. An unexpected reversal on the statement cannot simply be ignored; someone has to explain it, which is often how a double refund is spotted.

Putting a double refund right

If both credits have gone out, act quickly and calmly:

  1. Record both events in the books as above, so the subscriber's account shows what they now owe you.
  2. Send a statement of account. The server produces it as a PDF that can be e-mailed, and the screen says whether it was sent, so you have a record of telling the subscriber.
  3. Explain in plain words that they received two credits for one payment, and ask how they would like to return one: a transfer, or a set-off against an invoice if they are still a subscriber.
  4. Fix the process that let it happen, usually the missing check between support and finance.

Most subscribers return the money once they see the statement. Those who do not are an ordinary debt, handled like any other overdue balance. How batch debit order receipts are recorded in the first place is covered in recording debit order batch receipts, and a related problem from another industry is set out in when a traveller has paid twice.

One rule to pin up

No refund leaves the business until someone has checked the payment provider's dashboard, the bank statement and the subscriber's own account for a reversal, and written down that they did.

General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.

Related articles

More on Telecoms

See how Achekam handles it with your own records: create your account