USDC checkout & networks

Supported native USDC#

These are the USDC token contracts, not Iceberg receiving wallets or payout-pool contracts. They come from Circle’s native USDC directory. All amounts use six decimal places. Bridged USDC.e and a matching token symbol alone are not accepted.

Use an authenticated invoice#

Checkout fixes the account size, price, network, token, payer and recipient on the server. The paying wallet signs an ownership authorization and then authorizes a direct USDC transfer. Iceberg does not need a token allowance or hold the payer’s signing key.

The current integration receives USDC at a configured EVM address. The invoice inside the app displays that recipient. Do not substitute a token-contract address, send to a placeholder or send on a different network.

Confirmation and recovery#

A transaction hash alone is not proof of payment. The server checks a successful canonical receipt, the configured network and native token, exact payer/recipient/amount, invoice timing and finalized block status. A receipt log can create only one payment entitlement.

Finality is network-dependent and can be materially slower than the first wallet confirmation. The UI keeps checking the original transfer. An already authorized payment can settle after its invoice authorization window without requiring another transfer.

The server stores pending hashes. After reopening the app, recover the owned invoice and original transfer, or use the provided hash-recovery control. Do not send again while confirmation is pending.

Fees and the difference from payouts#

The checkout has no payment-provider commission. Network gas and any wallet/network charges still apply. Infrastructure and paid RPC costs are separate operating costs.

Paying an access fee and requesting a payout are distinct flows. This direct-receiver checkout is not a deployed payout-pool smart contract. Wallet payout signing and transfers are not activated.