Follow an invoice from selection to confirmation
The details that distinguish a clear payment experience from an ambiguous transfer.
Content revised · English
- Guide type
- Account & orders
- Examples
- Illustrative, environment-specific
- Integration scope
- No remote machine connected
Choose an asset and a network together
The checkout selections are BTC, ETH, SOL, LTC and TRX on their native networks, USDT on Ethereum ERC-20 or TRON TRC-20, and USDC on Ethereum ERC-20 only. These are eight routes across seven assets. Monero, USDC on TRON, Lightning, cards and other token networks are not offered.
Read the complete invoice before a live transfer
The server quotes the complete USD order total in the selected asset, with a rate timestamp and an explicit expiry shown in checkout. Read the address, asset, network and exact amount together. The receiving address is fixed rather than generated for each invoice; an order reference must be explicitly associated with a verified transaction. Do not invent a memo or assume that an amount alone uniquely identifies an order. Wallet network or withdrawal fees remain separate from the order total.
Use one precise transfer, then wait for its own rule
The backend thresholds are BTC 2, LTC 6, ETH and USDT/USDC ERC-20 12, native TRX and USDT TRC-20 20, and SOL 1, with independently verified finalized status required. Confirmation times depend on network conditions. No connected monitor currently detects those transactions or supplies confirmation updates; chain timing is not a delivery guarantee.
Keep a receipt and reconcile exceptions
Save the order reference and wallet transaction ID. If an unpaid quote expires before any observation, refresh it through checkout. If a transaction is already observed or the amount, network or destination is wrong, ask billing to reconcile the evidence. Do not overwrite an observed payment with a new quote or automatically submit a second transfer.
Understand payment verification and refunds
The authenticated checkout displays the configured fixed receiving address, selected network, exact cryptocurrency amount and quote expiry. USD rates are obtained by the server. No blockchain transaction monitor is connected: detection and confirmation require a trusted backend integration. A payment state does not create a real server or service entitlement. Refund terms remain a launch proposal: they use the original asset and initial USD payment value at the current refund rate, with product eligibility and deductions explained separately.
Understand the payment request states
An order starts pending_crypto before a method is selected. A request may wait for a quote, await payment, expire, be observed or confirm. Backend verification can also flag underpayment or overpayment. A paid result records payment verification; it does not allocate infrastructure.
- awaiting_quote: a valid server rate is not yet available.
- awaiting_payment: an exact quote and receiving instructions are available.
- detected / confirming: a trusted observer has associated a transaction, with verification still in progress.
- underpaid / overpaid: the observed amount requires reconciliation.
- paid: payment verified, with service fulfilment still separate.
Leave with a verifiable result.
- Choose an asset and a network together.
- Know the local and refund boundaries.
- Keep recovery information and secrets outside public files.