Statuses and edge cases

Eight statuses

A paid status never goes back automatically. Only an operator can resolve a disputed case, and you get a webhook when that happens.

Amounts and tolerance

Customers often pay from exchanges, which deduct a withdrawal fee, so the page asks them to send the exact amount and reminds them about fees. To avoid support tickets over cents, an underpayment within the tolerance still counts as paid:

tolerance = max(1% of the amount, $1.50), capped at $3.00. For a $29 invoice that is $1.50, for a $250 invoice $2.50.

The webhook always carries both the invoice amount and what was received, so you decide what to do with an overpayment: ignore it, credit it, or refund it.

Edge cases

Partial payment

The invoice becomes partially_paid and the page shows how much is left, to the same address. The customer has until 24 hours after the invoice expiry to top up: then it becomes paid (or paid_overpaid). A top-up after that window gives paid_late. If nothing more arrives, the invoice stays partially_paid and our operator contacts you about a refund or a manual decision.

Late payment

Whether a payment is on time is decided by the block time of the transfer, not by when confirmations finished. A transfer sent in time but confirmed after the timer is on time. After expiry the address stays reserved for 72 hours; a full payment in that window gives paid_late, a partial one needs_review.

Payment found at the last minute

If a transfer was seen before expiry and is still collecting confirmations, the invoice does not expire. It waits for the result.

Paid twice

A second transfer to an already paid invoice moves it to paid_overpaid if the total goes over the tolerance, and you get a new webhook with the new received_usd_cents.

Network change

Switching network closes the invoice (cancelled, cancel_reason: "network_changed") and creates a new one with the same external_order_id, linked by replaced_by / replaces. A network can only be changed before any transfer is seen. Handle events by external_order_id and ignore cancellations that have replaced_by.

Wrong coin

A different token sent to the address (for example USDC instead of USDT) is not counted. It goes to review, and the funds are still on your address.

Chain reorganisation

We count a transfer only after the network's confirmation threshold (TRON 19 blocks, BSC 15, or 30 for amounts over $500; Base 10 and Arbitrum 40 sequencer blocks, about 20 and 10 seconds; Polygon 15; TON 2 masterchain blocks) and its finality. If a counted transfer disappears anyway, our operator is alerted; we never silently roll back a paid status.

"I paid, but it is not showing"

On the page the customer can submit a transaction hash. We read it from the chain: if it went to the right address it is counted through the normal pipeline; if not, our operator sees it with the hash. Typical causes are the wrong network, the wrong address, or an exchange that has not sent the withdrawal yet.