Your deposit says Pending: how a payment actually settles
The money has left your bKash, and the wallet still reads what it did five minutes ago. Before anything else: this almost never means the money is gone, and it almost always resolves without anyone doing anything.
The sequence, in order
A top-up is not one event. It is four, and knowing which one you are waiting on tells you everything.
- We create the deposit. You press the button, we write a pending record with your amount and a reference, and send you to the gateway. This never fails silently.
- You pay at the gateway. You are on bKash's or Nagad's page now, not ours. We know nothing about what happens here until we are told.
- The gateway tells us. This is the step that matters, and the one that stalls.
- We credit the wallet. Once the gateway confirms, the balance moves and a transaction row appears in your history. This is immediate.
Where it stalls, and what each one means
You closed the tab too early. The most common by far. The payment succeeded at the gateway, but the confirmation was still travelling when the page was closed. This resolves on its own — the gateway retries, and separately we ask the gateway about any deposit still pending. Give it a few minutes.
The gateway is slow. Mobile money networks queue at busy hours. A confirmation that normally arrives in two seconds can take several minutes on a Friday evening. Nothing is wrong; it is a queue.
The payment genuinely failed. Insufficient balance, a wrong PIN, a cancelled confirmation. In this case the money never left your account — check your bKash statement rather than your memory of pressing the button. The deposit stays pending on our side because nothing ever confirmed it, and it will expire.
What resolves without you
Most of it. A pending deposit is not something we wait for you to report — we ask the gateway about it, and the credit lands when the answer comes back. If you paid successfully, the overwhelmingly likely outcome is that you refresh in ten minutes and it is there.
What to do, in order
- Check your bKash or Nagad statement first. Did the money actually leave? This single check answers most cases.
- Refresh the deposits page. Not the browser's back button — open the page fresh.
- Wait ten minutes. Genuinely. Most of what gets reported in the first two minutes has resolved by the tenth.
- Then contact support with the transaction ID from your bKash or Nagad message and the amount. Those two things let us match the payment in seconds.
What not to do
Do not pay again. The single most expensive mistake here. If the first payment succeeded and is queued, a second one is a second deposit, and now you are waiting on a refund instead of a credit.
Do not open five tickets. It does not make anything faster and it splits the answer across five threads.
Why a wallet instead of paying per order
Because this problem would otherwise happen on every single order. A gateway round trip per order means a gateway failure per order, orders half-placed while a payment is in flight, and a refund path for every one of them.
The wallet moves the risky step to once per top-up. After that, ordering is instant and cannot half-succeed: the balance either covers it or it does not.
The transaction history is the record
Every movement is a row: top-ups in, order charges out, refunds back. If you are ever unsure whether something was charged, that page is the answer rather than the order list — the order tells you what was requested, and the ledger tells you what was paid.
Refunds appear there too, which is where people usually find the money they thought had vanished on a partial delivery.
What is never stored
Your PIN, your card number, your OTP. Those are entered on the gateway's page, not ours, and we never receive them. What we keep is the amount, the gateway's reference, and the status — which is all that is needed to match a payment and all that should ever be held.
Anyone asking you for a PIN or an OTP to "confirm" a deposit is not us, and no legitimate panel or gateway will ever ask.
Manual top-ups, and why they take longer
Where a payment is sent by hand — a send-money to a listed number rather than through the gateway — the confirmation step is a person rather than an automatic message. You submit the transaction ID, and someone checks it against the receiving account before the balance moves.
That is slower by nature, and it is worth knowing which of the two you used. A gateway payment that has not landed in ten minutes is unusual; a manual one that has not landed in ten minutes is simply normal, and messaging about it does not speed it up.
The thing that does speed it up is submitting the right transaction ID the first time. Copy it from the message you received, not from memory, and send the exact amount you stated — a payment of a different amount cannot be matched confidently and will be held rather than credited.
What a failed deposit leaves behind
A pending row, and nothing else. It holds no money, blocks nothing, and expires on its own. You can start a fresh top-up immediately without waiting for it to clear, and the two will not interfere with each other.
The only thing to avoid is treating a pending row as proof that you paid. It is proof that you started, which is not the same. Your bKash or Nagad statement is the record of whether money moved; ours is the record of whether it arrived.
Topping up before you need to
Every problem in this article happens at the worst possible moment, which is the moment you are trying to place an order. None of it happens if the balance is already there.
If you order regularly, keep a working balance rather than topping up per order. It removes the gateway from the critical path entirely: orders become instant and cannot half-succeed, and a slow confirmation on a Friday evening becomes something you notice on Saturday rather than something standing between you and a client's deadline.
Comments
No comments yet — be the first.
