Reconciling your wallet against your own sales

Your wallet balance is always the sum of the movements in its ledger, and nothing edits a movement once it is written — a mistake is put right with an opposing entry, never by rewriting the past. So reconciling is not an investigation: it is matching each entry to one of your own records, usually by the order number the entry carries, and then explaining whatever is left. This guide is the procedure, and the three discrepancies you will actually meet.

What the ledger holds

Every line has a movement type, a detail, an amount, the balance after it and a date, and you can export the whole thing as CSV from your wallet page.

• Top-up — money in, credited by itself once the network confirmed a USDT payment you made from the top-up page. The amount is the package you chose; where a commission applied, the detail states what you paid and the commission inside it.
• Purchase — money out, one line per order, carrying that order's number.
• Refund — money in, returned automatically when an order could not be filled, carrying the order's number.
• Manual adjustment — a correction made by a person, either direction, which exists because a ledger that cannot be corrected forward would have to be corrected backwards.

A type may only move in the direction it means: a purchase can never credit and a top-up can never debit. That is enforced rather than assumed, which is why "a purchase that added money" is not one of the discrepancies below — it cannot be written.

The procedure

1. 1 Export the ledger for the period from your wallet page, and export or list your own sales for the same period.
2. 2 Check the endpoints of the period. The balance shown after the last entry before the period, plus every movement in it, must equal the balance after the last entry in it. If that does not hold, you have exported an incomplete range rather than found a problem.
3. 3 Match purchases to your own sales by order number. Each purchase line carries one, and each of your sales should point at one.
4. 4 Match refunds to purchases. Every refund line refers to an order that was also purchased, so each one should pair with a purchase line earlier in the ledger.
5. 5 Match top-ups to your own record of what you sent. Each top-up line is one payment you opened; its page in your dashboard, reached from "Your payments" on the Wallet page, carries the payment reference, what was credited and what you paid.
6. 6 List what is left over on both sides — ledger lines with no sale, and sales with no ledger line — and work through the three cases below.
7. 7 Record the period as reconciled with the closing balance, so next month starts from an agreed number rather than from the beginning of time.

The three discrepancies you will actually see

A refund you were not expecting. An order could not be filled, so its whole value came back by itself. Nothing was claimed and nothing is owed; the sale on your side is the thing that needs cancelling. If you are subscribed to order.refunded this should already have been handled by your integration, and a refund in the ledger that your system did not react to is worth checking: it usually means an event was missed while a webhook endpoint was failing.

A purchase whose order has no code yet. The money left your wallet when the order was created, because that is when the charge is committed, and the order is filled immediately afterwards. A purchase line whose order is still pending is an order in flight or one under review — not a missing code and not a double charge. Read it back by number; it will settle as delivered or refunded, and if it settles as refunded the money is returned in full.

A top-up that has not appeared. Sending the coins is not the same as the balance being credited. Nothing is credited until the network has confirmed that the whole amount arrived, so a payment that is not yet in the ledger is waiting for that confirmation rather than lost — and one that arrived short of the amount asked for credits nothing by itself and waits for a person here instead. The payment's own page says which. Subscribe to wallet-movement notifications if you want to be told rather than to check.

What cannot be a discrepancy

Some things are worth ruling out before you spend an hour on them.

• A balance that does not equal the sum of its ledger. It does, always; the balance is only ever written in the same transaction as the entry that explains it, and every balance is recomputed from its own ledger and checked on a schedule.
• An order charged twice for one purchase. A replayed request with the same idempotency key returns the first order rather than placing a second. If you see two purchases for one sale, you sent two different keys — see retrying an order without buying it twice.
• A charge for an order that was never delivered. A failure refunds itself. What you can see is a charge for an order that has not *yet* been settled, which is the second case above.
• A price on an order that is not the price you were shown. The price is worked out on our server from your account at the moment of the order and is never read from the request, so the figure on the receipt is the figure that was quoted. If your own records disagree, they are quoting a list price rather than yours — how your price is decided explains the two levels.

Doing it without a spreadsheet

If you are already integrated, the same reconciliation is GET /v1/orders for the period against your own sales table, plus GET /v1/balance as a closing check. Store the order number we return against every sale you make, and reconciliation stops being a monthly exercise and becomes a query. The endpoints are in the API reference.

Questions

Can a ledger entry be deleted or edited?

No. It is append-only, and a correction is a new entry in the opposite direction. That is what makes the ledger usable as evidence months later.

Why is the detail on some lines written in Arabic?

Because it is written into the row at the moment the movement is posted rather than rendered when you read it — it is stored content, like a product name, not a label on a screen. The order number inside it is the part you match on, and it is the same in either language.

Who can top up the wallet?

The account owner. A member of your team buys from the same balance but never funds it, and every purchase line records which of them placed the order.

My balance went down and I placed no order.

Check the order numbers on the purchase lines against who on your team placed them. Every order records the person who placed it, which is one of the reasons for giving each of them a login rather than sharing one.