When a customer transfers the wrong amount via Paystack
What happens when a Nigerian customer pays by Paystack Pay with Transfer but sends the wrong amount or uses an expired account number.
By Achekam · · 4 min read · For Running a business businesses in Nigeria
"I've paid," says the customer, and sends a screenshot of a transfer from their banking app. Your invoice still shows as unpaid. Looking closer, the amount on the screenshot is not quite the invoice total: a digit dropped, or a round figure instead of the exact one. Or the amount is right, but they sent it to the account number Paystack showed them yesterday.
Paystack's Pay with Transfer channel is convenient for customers who are used to paying from their banking app, but it is strict about amount and timing, and for good reason. This article explains how the temporary account works, what Paystack's documentation says about wrong amounts and expiry, what Achekam does and does not record, and how to sort things out with the customer.
A temporary account for one payment
Paystack's documentation says Pay with Transfer, available to businesses in Nigeria and Ghana only, generates a temporary bank account number tied to the customer's transaction. The number becomes invalid after that transaction, or when it passes its expiry time.
Customers who pay suppliers by transfer every day are used to saving account numbers. That habit is exactly what goes wrong here. The number on the Paystack screen is not your business's account; it belongs to one payment, for one amount, for a limited time.
Between 15 minutes and 8 hours
According to Paystack's documentation, a Pay with Transfer account number can be set to expire between a minimum of 15 minutes and a maximum of 8 hours from the current time, and expires after 8 hours if no expiry is set. Values outside that range default to 15 minutes or 8 hours.
So a customer who opens the payment page in the morning, gets distracted, and makes the transfer the next day is sending money to a number that no longer works for that payment. If a customer is likely to pay later, they should open the link again when they are ready to pay, not reuse a number from an earlier visit.
The rejected-transfer event
Paystack says that to confirm a bank transfer payment you must implement webhooks and listen for two events:
- charge.success, sent when the customer's transfer succeeds;
- bank.transfer.rejected, sent when the customer sent an incorrect amount or was flagged by Paystack's fraud system.
A wrong amount, in other words, does not become a partial payment. Paystack treats it as a rejected transfer. Paystack also mentions an endpoint for checking a pending charge manually, and Inbound Transfer Approvals, which let businesses accept or reject transfers they receive.
What happens to the customer's money after a rejection is a question for Paystack and the customer's bank. Do not promise the customer an outcome you have not confirmed with Paystack.
Check the amount before delivering value
Paystack's guidance on accepting payments goes further than transfers. When verifying a transaction, it says, you should also check that the amount matches the value of the service you are delivering, and not deliver value if it does not.
That is sound advice for anyone releasing goods on the strength of a payment notice. A screenshot is not a payment. A transfer of the wrong amount is not payment of the invoice. Release goods or start work only when the payment is confirmed in full, or when you have agreed something different with the customer and recorded it.
Paystack sets out each channel, including how Pay with Transfer accounts expire and the events that confirm or reject a transfer, on its payment channels documentation page.
What Achekam records, and what it does not
Achekam takes Paystack payments on invoices, and each payment is confirmed with Paystack before it is recorded. A verified payment is recorded as a receipt against the invoice, debiting the Paystack clearing account and crediting trade receivables, and the invoice shows as paid or part-paid. The amount is checked against what the link asked for, and a repeated notification never pays twice.
So a rejected transfer does not appear as a receipt. Nothing unverified is recorded, and the invoice stays open. That is the correct result: your books show what Paystack confirmed, not what a screenshot suggested.
If the notification for a genuine payment goes missing, Achekam still picks the payment up, because the server asks Paystack about open payments on a schedule and while the pay page is open. A correct payment that "hasn't shown yet" usually needs patience, not a manual entry.
Sorting it out with the customer
Most of these cases end well with a calm conversation.
- Check the invoice in Achekam. If it shows paid, the payment was confirmed; tell the customer.
- Check Paystack for a rejected transfer or a pending charge linked to that customer.
- If the amount was wrong, explain that the transfer was rejected, ask the customer to confirm with their bank where the money is, and send a fresh pay link for the correct amount.
- If the number had expired, send a fresh link and ask them to use the new number at once, then take up the earlier transfer with Paystack and their bank.
- If you agree to accept a different amount, for example an agreed part payment, take it through a route that records it properly. Customer payments in Achekam can be recorded against an invoice, a part payment leaves the invoice part-paid, and any extra is held on the customer's account.
A line for your invoice e-mail
"If you choose Pay with Transfer, send the exact amount shown, to the account number shown, within the time shown. That number works for this payment only."
The other ways your customers can pay through Paystack are covered in Paystack payment methods your Nigerian customers can use, and the wider picture of naira collections is in collecting naira payments.
General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.
