Networks & assets

Networks and assets come from a server-side capability registry, exposed publicly:

• GET /v1/networks and GET /v1/assets — every network and asset the gateway knows, with its status
• GET /v1/capabilities — networks, assets and payment methods in one response

Read the registry at runtime; do not hard-code it. The registry is authoritative, and the API refuses anything that is not usable in your environment. On this platform only entries with environment: "live" and status enabled (or beta) can be used; entries with environment: "test" cannot be used for payments here.

Network availability

FeitPay enables live networks and assets in the registry; an entry that cannot be used is listed as disabled. Live payments are enabled once your account is verified and approved, and nothing in these docs should be read as a promise that a particular network or asset will be offered.

Assets accepted by live payments

Live payments are processed through the platform’s Bitcart account, which offers every asset the platform accepts. For each payment you can see what is on offer:

• the checkout session’s processor.methods — one entry per accepted asset, with the asset key (the coin symbol, plus the chain for tokens), the chain, the exact amount, the exchange rate Bitcart used and the address to pay;
• GET /v1/payout-assets — the assets the platform’s wallets hold, which are also the assets you can withdraw.

You cannot narrow the assets per payment intent: allowed_networks is refused for live payments (allowed_networks_unsupported).

Confirmations

For live payments, Bitcart decides when a payment is final using its own confirmation policy: only its invoice status complete makes an intent confirmed, and FeitPay records that status as processor evidence — never as its own chain observation.

For watch-only processing (the non-custodial mode described under Wallets, which this platform does not use for payments), each registry network has a confirmation policy (a default and optional tiers by amount); the number that applies to a payment is frozen in its quote as required_confirmations. Confirmations are computed by the gateway from the chain tip it has observed — a single unconfirmed provider response is never treated as final.

Token identity

For watch-only processing, a token payment is credited only when all of these match the registry entry of the quoted asset:

1. network (chain id),
2. contract address (canonical form),
3. decimals (from the registry — never from the transfer or the watcher).

Tokens with fee-on-transfer, rebasing or otherwise non-standard semantics are rejected unless explicitly supported. Symbols and names are display-only and never used for matching.

Live payments

For live payments, the asset of each payment method — including a token’s chain and contract — is the one shown in processor.methods, and the amount credited to your balance is what Bitcart reports for the method that was paid.

Fees and native coins

On EVM networks the customer pays gas in the native coin, on top of the amount due. Live payments land in the platform’s Bitcart wallets, and the network fee of a payout is paid by the platform’s hot wallet.