# Références

> Codes de réseau, correspondances devise-réseau et valeurs de statut de paiement utilisés dans l'API 2328.io.

Cette page liste toutes les valeurs de référence utilisées dans les requêtes et réponses de l'API.

## Codes de réseau

Ces codes sont utilisés partout où un champ `network` est présent :

| Code | Réseau |
|------|--------|
| `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 |

## Correspondance devise-réseau

Chaque devise n'est disponible que sur un sous-ensemble de réseaux. Utilisez ce tableau pour choisir une combinaison valide :

| Devise | Réseaux autorisés |
|--------|-------------------|
| `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` est le code d'actif canonique pour la monnaie native de TON. Les API de paiement, de portefeuille statique et de création de paiements acceptent actuellement l'entrée héritée `TON` et la normalisent en `GRAM` ; les intégrations doivent stocker et gérer la valeur canonique renvoyée par l'API. L'actif natif de Polygon est `POL`, tandis que son code réseau est `POL-MATIC`. Ne jamais envoyer `MATIC` comme code réseau.

Les directions activées sont une configuration opérationnelle et peuvent changer indépendamment de ce catalogue. Consultez `/v1/directions` avant de présenter les choix ; considérez ce tableau comme la carte de codes valide, et non comme une garantie que chaque paire est actuellement activée.

## Statuts de paiement

Le champ `payment_status` sur les paiements et le filtre `/v1/payment/list` prennent les valeurs suivantes :

| Statut | Description |
|--------|-------------|
| `pending` | Créé, en attente d'initialisation |
| `check` | En attente du paiement du client |
| `paid` | Payé avec succès |
| `underpaid_check` | Sous-payé (peut être complété) |
| `underpaid` | Sous-payé |
| `overpaid` | Surpayé (crédité) |
| `cancel` | Annulé / expiré |
| `aml_lock` | Transaction bloquée pour cause d'AML |

> **INFO:** Lorsque vous attendez un paiement réussi, vous devez traiter à la fois `paid` et `overpaid` comme des états de succès et créditer la commande du client.

### Politique de gestion des statuts

| Statut | Exécuter la commande ? | Continuer à attendre ? | Action opérationnelle |
|--------|----------------|-------------------|--------------------|
| `pending` / `check` | Non | Oui, jusqu'à l'expiration | Afficher l'état en attente et effectuer le rapprochement normalement. |
| `underpaid_check` | Non par défaut | Oui, un complément peut arriver | Stocker chaque txid de manière idempotente et afficher le flux de paiement restant. |
| `paid` | Oui, une fois | Non | Exécuter atomiquement à partir de l'événement vérifié. |
| `overpaid` | Oui, une fois | Non | Remplir et conserver les montants excédentaires/réels conformément à la politique du commerçant. |
| `underpaid` | Spécifique au produit | Non | Appliquer une politique de paiement partiel explicite/examen manuel. |
| `cancel` | Non | Non | Marquer comme expiré/annulé, mais escalader toute preuve ultérieure sur la chaîne. |
| `aml_lock` | Non | Pas d'exécution automatique | Examen de conformité/support ; ne pas libérer la valeur automatiquement. |

Les statuts décrivent la vue de la plateforme sur le paiement. Ils ne remplacent pas votre état local de traitement. Conservez les deux afin qu'une commande remboursée, examinée manuellement ou déjà traitée ne puisse pas être corrompue par un ancien webhook.

Le filtre de requête `/v1/payment/list` accepte actuellement `pending`, `check`, `paid`, `underpaid_check`, `underpaid`, `overpaid` et `cancel`. Il n’accepte pas `aml_lock` comme filtre même si un paiement verrouillé par AML peut être retourné par d’autres points de paiement.

## Statuts de retrait

Le champ `status` sur `/v1/payout` et `/v1/payout/status/{uuid}` prend l'une des valeurs suivantes :

| Statut | Description |
|--------|-------------|
| `pending` | Créé, en attente de traitement |
| `completed` | Terminé avec succès — `txid` est défini |
| `failed` | Erreur d'envoi — voir `error_type` |
| `cancelled` | Annulé |

## Types d'erreurs de retrait

Lorsqu'un retrait a `status = failed`, le champ `error_type` indique la raison :

| Code | Description |
|------|-------------|
| `aml_risk` | Retrait bloqué par les contrôles de risque AML (adresse du destinataire signalée comme à haut risque) |