Skip to main content

​
Supported Networks And Tokens

PayChain support is network-based. Every invoice, payout route, dynamic payout recipient, withdrawal, balance, and transaction should carry the correct chain, networkId, and token.
Catalog note: Treat supported networks as an expanding list, not a fixed promise frozen into your code. New supported networks are provisioned by PayChain, and your integration should discover the current catalog from the API or dashboard.

​
Current catalog source

Use these surfaces to confirm what is currently available:
SurfaceBest for
Dashboard network/token selectorsOperators choosing rails in the UI.
GET /api/v1/networksDeveloper discovery of active networks.
GET /api/v1/networks/supportedPublic supported-network list where available.
GET /api/v1/tokensToken discovery across supported networks.
GET /api/v1/tokens?networkId=...Token discovery for one network.
Do not hardcode: Network availability, token availability, and sponsored gas behavior can change. Cache the catalog if needed, but refresh it regularly.

​
Network list format

Use this format when reviewing or documenting supported rails. The rows below are examples of how to read the catalog, not an exhaustive permanent list.
NetworkchainnetworkIdEnvironmentCommon assetsNotes
Base Mainnetevmbase-mainnetLiveETH, USDCCommon stablecoin checkout rail.
BNB Smart Chain Mainnetevmbnb-mainnetLiveBNB, USDT, USDC where enabledCommon emerging-market payment rail.
Ethereum Mainnetevmeth-mainnetLiveETH, USDC, USDT where enabledHigher-cost settlement rail; confirm economics before using for small invoices.
Solana Mainnetsolsol-mainnetLiveSOL, USDC where enabledFast settlement rail; token account behavior can affect gas usage.
Base Sepoliaevmbase-sepoliaSandbox/testTest assetsUse for EVM testing where enabled.
Ethereum Sepoliaevmeth-sepoliaSandbox/testTest assetsUse for EVM testing where enabled.
Solana Devnetsolsol-devnetSandbox/testTest assetsUse for Solana testing where enabled.
List maintenance note: The table above is a human-readable guide. The API and dashboard remain the source of truth for the current production catalog, especially as PayChain adds more networks.

​
Token matching rules

Invoice and payout routing asset fields must match exactly:
  • chain
  • networkId
  • token
If a customer sends the wrong asset or uses the wrong network, do not treat the transfer as a valid invoice payment unless PayChain marks the invoice settled.

​
Choosing a network

Choose a network based on:
  • Customer payment behavior.
  • Stablecoin availability.
  • Network cost.
  • Settlement speed.
  • Payout destination support.
  • Gas-credit impact for sponsored outbound operations.
  • Your compliance and operational policy.

​
Developer discovery example

​
SDK

const networks = await paychain.networks.list();
const tokens = await paychain.tokens.list();
const baseTokens = await paychain.tokens.forNetwork('base-mainnet');

​
REST

curl "$PAYCHAIN_API_URL/networks" \
  -H "x-api-key: $PAYCHAIN_API_KEY"

curl "$PAYCHAIN_API_URL/tokens?networkId=base-mainnet" \
  -H "x-api-key: $PAYCHAIN_API_KEY"
REST integrations can use the equivalent network and token endpoints from the OpenAPI reference.

​
When PayChain adds a new network

When PayChain adds support for a new network, it appears in the dashboard and network/token APIs after provisioning. Merchants do not need to manually provision the network inside PayChain. Your team only needs to decide whether your own checkout, app, or backend flow should display that rail to customers. The safest integration pattern is to read the catalog, display only the networks and tokens your product supports, and avoid assuming that every token exists on every network.

​
Common mistakes

  • Hardcoding one network and assuming all customers can use it.
  • Treating chain: evm as enough without checking networkId.
  • Creating an invoice on one network and routing payout recipients on another.
  • Assuming all tokens exist on all networks.
  • Assuming sponsored gas behavior is identical across every rail.