Assets & networks

Merchant accepted assets & networks

GET /v1/merchant/accepted-assets (alias: GET /v1/assets) is the source of truth for which chains and tokens your merchant accepts in the current environment. Use it before building payment forms, token selectors, or hardcoding network lists. Results reflect your merchant settlement configuration (“Payments you accept”), intersected with platform payout policy. Any valid merchant API key can call this — no extra scopes required.

The response includes a flat deposit_pairs array (e.g. ethereum:usdc) plus nested chains with token metadata (EVM chain ids, contract/mint addresses).

Capability checks before write actions

• Use /v1/payouts/withdrawal-rail and /v1/payouts/destination-availability before creating crypto payouts — only operator-enabled withdrawal chains are accepted.
• Use /v1/payouts/fiat-availability before fiat bank payouts.
• Use merchant checkout quote-chain options before exposing checkout token selectors.
• Treat unavailable options as runtime conditions, not code errors.
• Capability endpoints require a valid API key only — no extra scopes.

Tron deposits

Tron USDT (and other enabled Tron tokens) use Tron-specific deposit observation and allocation. When your merchant uses IDENTITY_BASED or HYBRID deposit identity mode, pass top-level customer_id on payment intent create so returning customers receive a stable deposit address.

Details: /business/docs/payment-intents (customer identity section).

Asset key conventions

Asset identifiers are modeled as token and chain combinations in multiple endpoints (for example payout creation and balance lookup). Keep them normalized in your persistence layer.

Full endpoint references: /business/reference/assets and /business/reference/checkout.