Core concepts

Assets & networks

Assets and network capabilities are dynamic. Always query capability endpoints instead of hardcoding token/chain assumptions.

Supported assets

GET/v1/assetsList supported chain/token assets

/v1/assets is the source of truth for enabled assets in your current environment. Results reflect platform payout allowlists, unblocked networks, and your merchant settlement configuration.

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.

Do not hardcode network lists

Network policy can differ by environment and merchant configuration. Query capability endpoints at startup and cache briefly.

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.