Checkout

What the customer sees, why the amount has odd decimals, and every way a payment can go sideways on the customer’s side.

The hosted page

Redirect to checkout_url and the customer gets a mobile-first page that: picks asset and network with loud wrong-network warnings, renders a QR code and a plain-address copy button, shows the exact amount and a live countdown, updates status without a refresh, walks an underpayment through its remaining balance, and offers an "I have paid" transaction-hash fallback.

Both the QR and the plain address are always shown. Many wallets scan only plain addresses, and a QR-only checkout quietly loses those customers.

Why the amount has odd decimals

Payaider is non-custodial, so funds go to your shared receiving address. There is no per-invoice address to match on, which leaves exactly one discriminator on-chain: the amount.

So every concurrently-payable invoice reserves a globally unique amount for its (wallet, token), uniquified in the last few decimals. A $100.00 order becomes 100.0431 USDT. The amount is always rounded up — the customer never pays less fiat value than you priced, and the dust is yours.

Approved assets

Each (asset, network) pair has exactly one approved contract. A transfer of any other contract is discarded, however it labels itself — matching is never on a symbol.

Asset	The only approved contract	Decimals
USDT on TRON	`TR7NHqjeKQxGTCi8q8ZY4pL8otSzgjLj6t`	6
USDT on BNB Chain	`0x55d398326f99059fF775485246999027B3197955`	18
USDC on Base	`0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913`	6

On Base, only Circle-native USDC is accepted. Bridged USDbC is a different asset that customers do still hold; it is refused rather than silently credited.

How long confirmation takes

Network	First signal	Settlement signal
TRON	~3s to first inclusion	Solidified height (~57s). Solid height never rolls back.
BNB Chain	~0s to first inclusion	BFT fast finality (~1.1s) via the `finalized` tag.
Base	~2s to first inclusion	Four tiers: sequencer ~2s, `safe` ~2 min, `finalized` ~20 min.

Confirmation policy is a config table of (network, amount tier) → finality signal, not a hardcoded block count. On TRON and BNB Chain it is a finality signal, not a count of confirmations; the old "15 confirmations on BNB" convention is obsolete and must never ship.

When it goes wrong

What happened	What Payaider does	What you do
Customer sends the wrong amount	Tolerant attribution matches it, then classifies `underpaid` or `overpaid`. Ambiguity goes to review, never to a guess.	Show the remaining amount, or accept as paid.
Customer pays after the countdown	The address is watched for 24 hours past expiry. A matching transfer becomes `paid_late` in a review queue.	Resolve it: fulfil, or refund off-platform.
Customer sends on the wrong network	Nothing to detect — but the funds are in your address on that chain.	Recover them yourself from that chain; the support runbook explains how.
Customer withdraws from an exchange and the fee is deducted	Stage-2 attribution knows the standard per-token withdrawal fees and matches anyway.	Usually nothing.
Customer pays from an exchange to your exchange deposit address	Nothing happens on-chain at all — it settles internally at the exchange, invisible to every watcher.	This is why exchange deposit addresses cannot be registered as wallets. Use self-custody.
Customer insists they paid and nothing matched	The "I have paid" fallback takes their transaction hash and runs the full verification pipeline on that specific transaction.	Point them at the fallback on the checkout page.