A tested set of payment methods with the right scanners and wallet setup.
1. Prepare receiving
Create your project and store, back up wallets and open Store → Payment methods. Enable only tested chains and assets. Checkout supplies the customer with the correct address and any required reference.
In Settings → Chain connections, check scanner readiness and independent providers. Verification defaults to two independent providers; reducing it to one weakens that check. Several URLs run by the same operator are not independent redundancy.
Temporary on-chain scanner outages do not automatically block invoice creation, but detection and verification can wait. Monero subaddress allocation and Lightning invoice generation need their external wallet/node connection at creation time.
Find public providers → A healthy node proves basic access, not usable transaction history or sufficient capacity.
2. Choose tokens deliberately
30 chains does not mean every token on 30 chains. Accepted tokens currently cover verified ERC-20 on the eight EVM networks and classic SPL on Solana. The other chains accept their native coin here.
Search the store’s CoinGecko catalog by name, ticker or ID. Check chain and contract/mint. USDC on Ethereum and USDC on Solana are different methods; enable each wanted version separately.
For a missing supported token, use Custom token beside token search. Verify its contract and choose a fixed USD price or a matching DEX market. Fixed pricing is not a live rate; a DEX quote does not guarantee liquidity. Fee-on-transfer and rebasing assets are not safe ordinary tokens. Current support matrix →
3. Find your chain
Open an entry for its particular requirements. These are invoice payment capabilities; seeing a token balance does not automatically make that token acceptable for checkout.
No matches. Change the search or filter.
BitcoinBTCNative coin only
A new address identifies each invoice. Keep the complete wallet backup: a wallet app may need to scan further than its initial address gap. Bitcoin Lightning is a separate payment method, explained below.
Addresses & wallet practice →EthereumETHCoin + verified tokens
New invoice addresses. Accept the native coin and verified ERC-20 contracts you enable in the store. Ordinary native transfers and token transfer logs are checked; contract-internal ETH movements are not a supported payment route.
Use Ethereum mainnet. Verified ERC-20 tokens such as USDC and USDT need ETH at each sending address when you move them later. Importing the recovery phrase into MetaMask may show only the first account.
Addresses & wallet practice →BaseETHCoin + verified tokens
New invoice addresses. Accept the native coin and verified ERC-20 contracts you enable in the store. Ordinary native transfers and token transfer logs are checked; contract-internal ETH movements are not a supported payment route.
Use Base, not Ethereum mainnet, even though both use ETH and similar addresses. Select the exact token contract; bridged and native versions are different assets.
Addresses & wallet practice →SolanaSOLCoin + verified tokens
Native SOL and verified classic SPL tokens are supported, including matching USDC/USDT mints. Token-2022 and its extensions are not accepted. Keep SOL for fees and token-account creation; use the address and payment request shown by checkout.
BNB ChainBNBCoin + verified tokens
New invoice addresses. Accept the native coin and verified ERC-20 contracts you enable in the store. Ordinary native transfers and token transfer logs are checked; contract-internal ETH movements are not a supported payment route.
Use BNB Smart Chain and verified EVM token contracts, often called BEP-20. This is not the former Beacon Chain. Fees use BNB, not ETH.
Addresses & wallet practice →TRONTRXNative coin only
Native TRX only. TRC-20 tokens, including USDT on TRON, are not invoice payment methods. A healthy basic node does not prove that indexed or solidified transaction history is available.
XRP LedgerXRPNative coin only
Invoices share a funded account and use a unique destination tag. The customer must include the exact tag; an X-address can encode it. XRP account reserves apply. Issued tokens are not accepted.
Addresses & wallet practice →HyperliquidHYPECoin + verified tokens
New invoice addresses. Accept the native coin and verified ERC-20 contracts you enable in the store. Ordinary native transfers and token transfer logs are checked; contract-internal ETH movements are not a supported payment route.
This integration is HyperEVM, not HyperCore or an exchange spot-deposit account. Use HYPE for fees and only verified contracts on HyperEVM.
Addresses & wallet practice →ZcashZECNative coin only
Only transparent ZEC payments are scanned. Do not use shielded transfers or assume a shielded balance will appear. Each invoice has its own transparent receiving address.
MoneroXMRNative coin only
Connect an external, project-specific view-only wallet RPC as well as a daemon. Each invoice gets a subaddress. A public daemon alone cannot see your payments. Keep the spending wallet elsewhere; Wholly Crypto cannot sweep XMR.
Addresses & wallet practice →CardanoADANative coin only
Native ADA only, with transaction history from a compatible source such as Koios. Cardano native tokens are not invoice assets. Account for minimum output requirements when moving funds.
StellarXLMNative coin only
A funded shared account uses a numeric MEMO_ID for each invoice. Copy the memo exactly, with the correct memo type. Account reserves apply. Stellar-issued assets, including USDC, are not accepted.
Addresses & wallet practice →Bitcoin CashBCHNative coin only
Use Bitcoin Cash, not Bitcoin. Native BCH payments get new invoice addresses. SLP and CashTokens are not accepted invoice assets. Confirm that the payer supports the displayed address format.
LitecoinLTCNative coin only
Use ordinary transparent LTC transfers to the new invoice address. MWEB private transfers are not covered by the invoice scanner. Allow for network fees when sending.
DogecoinDOGENative coin only
Native DOGE uses a new address for each invoice. Many small outputs can cost more to consolidate than one larger payment. Check fees and minimum send amounts before sweeping.
AvalancheAVAXCoin + verified tokens
New invoice addresses. Accept the native coin and verified ERC-20 contracts you enable in the store. Ordinary native transfers and token transfer logs are checked; contract-internal ETH movements are not a supported payment route.
Use Avalanche C-Chain. X-Chain and P-Chain are different networks and are not this checkout method. C-Chain token transfers need AVAX for fees.
Addresses & wallet practice →PolygonPOLCoin + verified tokens
New invoice addresses. Accept the native coin and verified ERC-20 contracts you enable in the store. Ordinary native transfers and token transfer logs are checked; contract-internal ETH movements are not a supported payment route.
Use Polygon PoS and POL for fees. Ethereum and Polygon zkEVM are not interchangeable with this network. Check the exact token contract rather than just its ticker.
Addresses & wallet practice →ArbitrumETHCoin + verified tokens
New invoice addresses. Accept the native coin and verified ERC-20 contracts you enable in the store. Ordinary native transfers and token transfer logs are checked; contract-internal ETH movements are not a supported payment route.
Use Arbitrum One. ETH on Ethereum mainnet or another Arbitrum network does not fund an Arbitrum One invoice. Keep ETH on this chain for token sweeps.
Addresses & wallet practice →OptimismETHCoin + verified tokens
New invoice addresses. Accept the native coin and verified ERC-20 contracts you enable in the store. Ordinary native transfers and token transfer logs are checked; contract-internal ETH movements are not a supported payment route.
Use OP Mainnet and its verified contracts. The same token ticker on a different network is not the same payment method. Token sending needs ETH on OP Mainnet.
Addresses & wallet practice →TONTONNative coin only
Invoices use a shared wallet and an exact invoice comment. Use a wallet that preserves the comment when paying. Native TON only: Jettons, including USDT on TON, are not accepted.
Addresses & wallet practice →AptosAPTNative coin only
Native APT is tracked through compatible Aptos REST transaction APIs. Other Move tokens are not invoice methods. Check the exact network and account address when paying.
SuiSUINative coin only
Native SUI requires a compatible history API, including supported GraphQL access. A working basic RPC health check is not enough. Other Sui coins/tokens are not invoice assets.
Cosmos HubATOMNative coin only
This means native ATOM on Cosmos Hub, not every Cosmos SDK chain or IBC token. The scanner needs indexed transaction events. Use the invoice address, not an exchange deposit address.
PolkadotDOTNative coin only
Use DOT on Polkadot Asset Hub, not the relay chain. A compatible Asset Hub transaction API or supported raw-block scanner is required. Other Asset Hub tokens are not invoice methods.
NEARNEARNative coin only
Native NEAR only. Detection checks successful receipts, not merely a submitted transaction. Preserve the account and derivation details in your wallet backup. NEP tokens are not accepted.
AlgorandALGONative coin only
Native ALGO uses compatible Indexer or algod transaction history. Account minimum balances apply. Algorand Standard Assets, including USDC ASAs, are not accepted invoice assets.
HederaHBARNative coin only
Native HBAR invoices use an EVM alias that resolves to its Hedera account after funding. Receive history comes from a Mirror REST API; an EVM relay alone is not enough. HTS tokens are not accepted.
KaspaKASNative coin only
Native KAS requires a compatible REST transaction source and accepted-chain evidence. DAG progress is not the same as a confirmed payment. KRC-20 tokens are not invoice assets.
TezosXTZNative coin only
Native XTZ needs applied operations from TzKT or a compatible Octez source. Failed operations do not pay an invoice. FA1.2 and FA2 tokens are not accepted invoice assets.
DashDASHNative coin only
Native DASH uses a new address for each invoice. Let the scanner apply your confirmation policy; do not assume an InstantSend label alone settles the Wholly Crypto invoice.
4. Bitcoin Lightning is a separate route
Lightning complements Bitcoin but is not an extra on-chain network in this list. Connect LND or Nostr Wallet Connect in settings, grant the store access and enable its Lightning payment method.
A public Bitcoin RPC or someone else’s public Lightning node cannot simply issue invoices for your wallet. You need authorized access to a compatible Lightning wallet and receiving capacity. Hosted-wallet custody and limits depend on the provider.
Checkout generates a BOLT11 invoice. Do not substitute an on-chain address. Manage backups, liquidity and withdrawals with the connected Lightning wallet. Set up Lightning →
5. Verify payments and move funds
Ask the customer to send the full checkout amount on the selected chain. A tag, memo or TON comment is part of the payment. If something is missing, do not blindly request another payment: inspect the invoice and Needs attention.
Wait for the verified invoice state settled and respect review flags. Explorers and wallet apps help compare transfers; they do not replace your invoice state.
New invoice addresses separate receipts, but spread balances across addresses. Sweeps can consolidate them. Budget for native fees and account reserves. Monero stays externally managed; outgoing mandatory-tag/memo/comment destinations need an external wallet.
Network background: Ethereum gas ↗ · Solana tokens ↗ · XRP tags ↗ · Stellar accounts ↗ · Monero view-only ↗