Introduction/References

References

Network codes, currency-network mappings, and payment status values used across the 2328.io API.

This page lists all the reference values used across API requests and responses.

Network codes

These codes are used wherever a network field is present:

Code	Network
`TRX-TRC20`	Tron TRC-20
`BSC-BEP20`	BNB Smart Chain
`ETH-ERC20`	Ethereum (ERC-20)
`BASE`	Base
`AVAX-C`	Avalanche C-Chain
`POL-MATIC`	Polygon (Matic)
`TON`	TON
`BTC`	Bitcoin
`LTC`	Litecoin
`DASH`	Dash
`SOL`	Solana
`DOGE`	Dogecoin
`ZEC`	Zcash
`XRP`	XRP Ledger
`XMR`	Monero

Currency-network mapping

Each currency is only available on a subset of networks. Use this table to pick a valid combination:

Currency	Allowed networks
`USDT`	TRX-TRC20, BSC-BEP20, ETH-ERC20, BASE, AVAX-C, POL-MATIC, TON, SOL
`USDC`	BSC-BEP20, ETH-ERC20, BASE, AVAX-C, POL-MATIC, SOL
`BTC`	BTC
`ETH`	ETH-ERC20, BASE
`BNB`	BSC-BEP20
`TRX`	TRX-TRC20
`LTC`	LTC
`DASH`	DASH
`GRAM`	TON
`AVAX`	AVAX-C
`POL`	POL-MATIC
`SOL`	SOL
`DOGE`	DOGE
`ZEC`	ZEC
`XRP`	XRP
`XMR`	XMR

GRAM is the canonical asset code for the TON native currency. The payment, static-wallet, and payout creation APIs currently accept legacy TON input and normalize it to GRAM; integrations should store and handle the canonical value returned by the API. The Polygon native asset is POL, while its network code is POL-MATIC. Never send MATIC as a network code.

Enabled directions are operational configuration and can change independently of this catalog. Query /v1/directions before presenting choices; treat this table as the valid code map, not a guarantee that every pair is currently enabled.

Payment statuses

The payment_status field on payment info and webhook payloads can take the following values:

Status	Description
`pending`	Created, awaiting initialization
`check`	Awaiting payment from customer
`paid`	Paid successfully
`underpaid_check`	Underpaid (can top up)
`underpaid`	Underpaid
`overpaid`	Overpaid (credited)
`cancel`	Cancelled / expired
`aml_lock`	Transaction blocked due to AML

When listening for a successful payment, you should treat both paid and overpaid as successful states and credit the customer's order.

Status handling policy

Status	Fulfill order?	Continue waiting?	Operational action
`pending` / `check`	No	Yes, until expiry	Display pending state and reconcile normally.
`underpaid_check`	No by default	Yes, top-up can arrive	Store each txid idempotently and show the remaining-payment workflow.
`paid`	Yes, once	No	Fulfill atomically from the verified event.
`overpaid`	Yes, once	No	Fulfill and retain excess/actual amounts for merchant policy.
`underpaid`	Product-specific	No	Apply explicit partial-payment/manual-review policy.
`cancel`	No	No	Mark expired/cancelled, but escalate any later on-chain evidence.
`aml_lock`	No	No automatic fulfillment	Compliance/support review; do not release value automatically.

Statuses describe the platform's view of the payment. They do not replace your local fulfillment state. Store both so a refunded, manually reviewed, or already fulfilled order cannot be corrupted by an older webhook.

The /v1/payment/list request filter currently accepts pending, check, paid, underpaid_check, underpaid, overpaid, and cancel. It does not accept aml_lock as a filter even though an AML-locked payment can be returned by other payment endpoints.

Payout statuses

The status field on /v1/payout and /v1/payout/status/{uuid} takes one of:

Status	Description
`pending`	Created, awaiting processing
`completed`	Completed successfully — `txid` is set
`failed`	Sending error — see `error_type`
`cancelled`	Cancelled

Payout error types

When a payout has status = failed, the error_type field describes why:

Code	Description
`aml_risk`	Payout blocked by AML risk checks (recipient address flagged as high-risk)