Compare payment networks

A payment can be visible before it is confirmed. Check the invoice address, transaction outputs and required confirmations. Several small outputs can increase the cost of a later sweep.

Check Ethereum mainnet and the exact token contract. A token balance cannot pay its own gas: each sending address needs ETH on Ethereum.

ETH on Ethereum cannot pay Base fees. Check Base as the deposit network and distinguish native USDC from bridged USDC variants.

Check the mint and token-account owner, not just the symbol. Token-2022 is not supported. Keep SOL available for fees and account creation.

Choose BNB Smart Chain, not Ethereum or Beacon Chain. A matching 0x address does not make a transfer cross-chain. Token sends need BNB on this network.

A healthy TRON node may lack the transaction history the scanner needs. Check scanner readiness. This checkout accepts TRX, not USDT-TRC20.

Copy the destination tag exactly. A missing or different tag may leave a payment unmatched. Keep the account reserve and do not sweep to a destination that requires an outgoing tag.

Use HyperEVM, not HyperCore or a spot-account deposit. HYPE for fees must be on HyperEVM. A HyperCore balance is not an invoice payment here.

Only transparent payments are supported. Do not use a shielded payment request. Outgoing transfers use transparent t1 funds, not shielded balances.

Check the project’s view-only wallet connection and its sync progress as well as the daemon. A healthy public daemon alone cannot identify your incoming XMR.

Keep enough ADA for minimum output requirements. Sending uses pure-ADA outputs; outputs containing other tokens are retained, not swept.

Use the exact numeric MEMO_ID from checkout. Text memos and missing memos are not equivalent. Keep the account reserve; outgoing destinations must not require a memo.

Check that the wallet is sending BCH, not BTC. Confirm CashAddr compatibility. CashTokens and SLP balances cannot pay a native BCH invoice.

Use a transparent LTC transfer, not MWEB. A restored wallet may need a wider address scan to find older invoice receipts.

Confirm the DOGE network and invoice address. Small receipts across many outputs can make consolidation expensive; review the fee before sweeping.

Select Avalanche C-Chain, not the X-Chain or P-Chain. Token sending needs AVAX on C-Chain; staking balances elsewhere cannot pay that gas.

Select Polygon PoS, not Polygon zkEVM. Outgoing fees use POL on PoS. An Ethereum token contract is not automatically the same asset here.

Select Arbitrum One, not Nova or Ethereum. Keep ETH on Arbitrum One for sending. Network fees can include both execution and data costs.

Select OP Mainnet. Sending needs ETH, not OP tokens, for fees. Verify that the destination supports deposits on this network.

Keep the payment comment exactly as shown. A missing comment can prevent invoice matching. Jettons, including USDT, are not accepted by this TON method.

Check the Aptos account and successful APT transfer. Other coins and fungible assets are not accepted here. Leave APT available for outgoing gas.

Check a successful native SUI transfer and the exact recipient. A healthy JSON-RPC endpoint alone does not prove usable payment history. Sending also needs spendable SUI gas objects.

Use Cosmos Hub native ATOM, not an IBC token on another zone. Sending supports destinations without a required outgoing memo; do not omit an exchange’s required memo.

Use the supported Polkadot Asset Hub route, not a Relay Chain deposit. Receiving history and the sending runtime must both be compatible with the configured providers.

Only successful native transfer receipts count. A submitted transaction, failed receipt or token-contract call is not proof of a paid NEAR invoice.

Plan for the receiving account’s minimum balance. Only native ALGO is accepted; an ASA or USDC transfer does not pay this method.

The receiving alias must resolve after account funding. Mirror history is needed to verify HBAR receipts; outgoing transfers use a compatible EVM relay, not the read-only Mirror API.

A rising DAG score is not proof of payment. Check accepted outputs to the invoice address. Sending also requires provider support for raw parent transactions and fee mass.

Only applied native XTZ transfers count. Failed operations and FA1.2/FA2 tokens do not pay the invoice. Sending needs a compatible verified protocol.

Check the transparent DASH address and the configured confirmation policy. Do not treat an InstantSend label alone as settlement of the merchant invoice.

If payment cannot route, check incoming liquidity, wallet availability and request expiry. A healthy API is not a routing guarantee. After an uncertain payment, verify settlement before asking the customer to retry.