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. Your integration should discover the current catalog from the API or dashboard.

Current catalog source

Use these surfaces to confirm what is currently available:

Surface	Best for
Dashboard network/token selectors	Visual confirmation of enabled rails.
`GET /api/v1/networks`	Developer discovery of active networks.
`GET /api/v1/networks/supported`	Public supported-network list.
`GET /api/v1/tokens`	Token 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.

Network	`chain`	`networkId`	Environment	Common assets	Notes
Base Mainnet	`evm`	`base-mainnet`	Live	ETH, USDC	Common stablecoin checkout rail.
BNB Smart Chain Mainnet	`evm`	`bnb-mainnet`	Live	BNB, USDT, USDC	Common emerging-market payment rail.
Ethereum Mainnet	`evm`	`eth-mainnet`	Live	ETH, USDC, USDT	Higher-cost settlement rail; confirm economics before using for small invoices.
Solana Mainnet	`sol`	`sol-mainnet`	Live	SOL, USDC	Fast settlement rail; token account behavior can affect gas usage.
Stellar Mainnet	`stellar`	`stellar-mainnet`	Live	XLM, USDC, USDT	Stellar payments require the returned Memo ID by default.
Base Sepolia	`evm`	`base-sepolia`	Sandbox/test	Test assets	Use for EVM testing.
Ethereum Sepolia	`evm`	`eth-sepolia`	Sandbox/test	Test assets	Use for EVM testing.
Solana Devnet	`sol`	`sol-devnet`	Sandbox/test	Test assets	Use for Solana testing.

The table above is a human-readable guide. The API and dashboard remain the source of truth for the current production catalog.

Token matching rules

Invoice and payout routing asset fields must match exactly:

chain
networkId
token

For Stellar issued assets, token is display-friendly only. Matching requires the registered canonicalAssetId in the form stellar:{assetCode}:{issuerAddress}. Native XLM uses stellar:XLM:native. PayChain does not auto-discover arbitrary Stellar assets. 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.

Start here

Developers

Go live

Supported networks tokens

Supported Networks And Tokens

Current catalog source

Network list format

Token matching rules

Choosing a network

Developer discovery example

SDK

REST

When PayChain adds a new network

Common mistakes

​Supported Networks And Tokens

​Current catalog source

​Network list format

​Token matching rules

​Choosing a network

​Developer discovery example

​SDK

​REST

​When PayChain adds a new network

​Common mistakes

Supported Networks And Tokens

Current catalog source

Network list format

Token matching rules

Choosing a network

Developer discovery example

SDK

REST

When PayChain adds a new network

Common mistakes