Wallet, refunds and your transaction history: reading the ledger
A wallet without a readable history is just a number someone else controls. Here is what each row means and how to check one against another.
What a row contains
Every movement — in or out — records four things: the amount, whether it was a credit or a debit, a source, and the balance immediately after it. Most also carry a description and a link to whatever caused them.
The running balance is the most useful column and the one people ignore. It tells you the order things actually happened in, which is not always the order you remember, and it is how you find the row that does not fit.
The sources you will see
- Deposit — a top-up that a gateway confirmed. Carries the gateway and the amount actually charged in your local currency.
- Order — a debit when an order is placed. Names the order.
- Refund — a credit from a cancelled or partly delivered order. Names the same order, so the pair can be read together.
- Adjustment — a manual change by an admin. Rare, and it should carry a reason.
Checking a refund yourself
Open the order and take the remains figure and the rate. The refund should be remains × rate ÷ 1,000, rounded. If the order was for 1,000 at ৳10 per 1,000 and 300 remained, the refund is ৳3.
Doing that calculation before writing to support answers most refund questions in ten seconds, and on the rare occasion the number is genuinely wrong it turns a vague complaint into a specific one that can actually be fixed.
Why total spent does not equal the sum of your orders
Because refunds unwind it. When an order is partly refunded, both your balance and your lifetime spend are adjusted, so "total spent" reflects what you actually spent rather than what you were briefly charged.
If those two numbers were allowed to drift apart, every partial delivery would inflate your spend forever, and any discount tier based on it would be wrong.
What "balance is not withdrawable" means in practice
Balance is credit for services on the panel. It cannot be sent back to your bKash, transferred to another account, or converted to cash. This is standard across the industry and it should be stated plainly wherever you buy — ours is in the refund policy.
The practical consequence is to top up what you intend to spend rather than parking money. A large balance is not savings; it is a prepayment.
When a deposit does not appear
Check the history first. If there is no deposit row, the payment did not reach us — which is different from it having failed, because the money may still have left your account.
Take the transaction ID from your bKash, Nagad or bank message and open one ticket with it. Do not pay again: duplicate payments are traceable and do get credited, but they make the reconciliation slower rather than faster.
When an order charged more than you expected
Three usual explanations, in order of likelihood:
- Drip-feed. The charge is quantity × runs. Ten runs of 500 is 5,000 units, not 500.
- The rate changed. Prices follow the supplier, and the order records the rate at the moment you placed it — which is the figure on the order, not the one you remember from last week.
- Custom comments. Priced per line, so the charge follows how many lines you pasted.
The order page shows the rate it used, so the comparison is always available.
Reading a drip-feed order in the ledger
A drip-feed order is one debit, not one per run. The full amount — quantity × runs — leaves your balance when you place it, which is why a drip-feed order looks disproportionately expensive in the history next to a single order of the same quantity.
If it is cancelled part-way, the credit that comes back covers the runs that had not happened. So a drip-feed order can produce one large debit and one partial credit days later, and the pair only makes sense read together.
Discounts, and where they show up
An account discount is applied to the rate, not as a separate line. The order records the rate you actually paid, so the discount is visible as a lower rate rather than as a credit row — which is why searching the ledger for a "discount" line finds nothing.
If you want to check a discount is applying, compare the rate on your order against the public price list. The gap is the discount.
Adjustments should always carry a reason
An adjustment row is a manual change made by an administrator — correcting a failed credit, compensating for something that went wrong, or fixing an earlier mistake. It should always name the reason.
An adjustment on your account that you did not expect and that carries no explanation is worth asking about immediately. On a well-run panel there will be a good answer; the point is that you should be able to get one.
Exports and record-keeping
If you are reselling or managing client accounts, export the history periodically and keep it. A client asking in three months what they were charged for a specific order is a question best answered with a row rather than a memory, and it is the difference between a professional operation and a defensive one.
Currency, and why the number can look wrong
The ledger stores every row in one base currency and displays it in whichever you have selected. Switch from taka to dollars and the same historical row shows a different figure — not because anything changed, but because the display rate is applied at the moment you look.
So a debit you remember as ৳620 may read as $5.01 today and $5.04 next month. If you are reconciling against a bank statement, set the display back to the currency you actually paid in first.
The principle underneath all of it
Your balance and the sum of your ledger rows should always reconcile exactly. That is not a nice-to-have: if a panel's balance can disagree with its own history, then neither number means anything, and no dispute about either can ever be settled.
Comments
No comments yet — be the first.