USDT · Binance Pay · no card ever touches this platform
Checkout that refuses to lie
Every other write on this platform may be queued when the true store is unreachable. This one may not. If an order cannot be created right now, the button disables and says so — because "saved" and "this did not happen" must never be ambiguous where money is involved.
Payment status
not started
The Binance app renders the real QR on their own domain — this platform never
mints payment codes itself.
Trade number
not issued yet
Try the failure states
The interesting part of a payment surface is what it does when things break. These buttons drive this page through each state so you can read the exact wording.
Double-entry, at the edge
Where the money goes
One payment produces one balanced ledger group. Every figure below is an integer number of minor units; no floating-point arithmetic happens anywhere in this path.
| Account | Direction | Minor units | Displayed |
|---|
The group key is deterministic — 'ord:' + order_id — and
UNIQUE(entry_group, account) is what makes replay harmless.
Not a lock, not a transaction spanning requests. D1 has no row locking, so the design cannot
ask for one.
Replay the webhook fifty times, nothing changes
Finalisation is lock-free. The race is decided by the database, not by the application.
// 1. Exactly one invocation can flip a pending order to paid.
const r = await db.prepare(
"UPDATE orders SET status='paid', paid_at=?1 WHERE id=?2 AND status<>'paid'"
).bind(now, id).run();
// 2. meta.changes tells us whether WE were the winner.
if (r.meta.changes === 0) return { ok: true, already: true };
// 3. Downstream writes are keyed deterministically, so even a
// crash between 2 and 3 cannot double-credit on the retry.
const group = 'ord:' + id; // UNIQUE(entry_group, account)
And if the webhook never arrives at all, the five-minute cron re-queries Binance for
orders stuck pending and finalises them through the exact same function. The webhook is
an optimisation, not a dependency.