# 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 |

> **INFO:** 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) |