# References

> Netzwerkcodes, Währungs-Netzwerk-Zuordnungen und Werte für Zahlungsstatus, die in der gesamten 2328.io API verwendet werden.

Diese Seite listet alle Referenzwerte auf, die in API-Anfragen und -Antworten verwendet werden.

## Netzwerkcodes

Diese Codes werden überall dort verwendet, wo ein `network`-Feld vorhanden ist:

| Code | Netzwerk |
|------|----------|
| `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 |

## Währungs-Netzwerk-Zuordnung

Jede Währung ist nur in einer Teilmenge der Netzwerke verfügbar. Verwenden Sie diese Tabelle, um eine gültige Kombination auszuwählen:

| Währung | Erlaubte Netzwerke |
|---------|--------------------|
| `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` ist der kanonische Asset-Code für die native Währung von TON. Die APIs für Zahlung, statische Wallets und Auszahlungserstellung akzeptieren derzeit den veralteten `TON`-Input und normalisieren ihn zu `GRAM`; Integrationen sollten den vom API zurückgegebenen kanonischen Wert speichern und verarbeiten. Das native Asset von Polygon ist `POL`, während sein Netzcode `POL-MATIC` ist. Senden Sie niemals `MATIC` als Netzcode.

Aktivierte Richtungen sind betriebliche Konfigurationen und können unabhängig von diesem Katalog geändert werden. Fragen Sie `/v1/directions` ab, bevor Sie Optionen präsentieren; behandeln Sie diese Tabelle als die gültige Codes-Übersicht, nicht als Garantie, dass jedes Paar derzeit aktiviert ist.

## Zahlungsstatus

Das Feld `payment_status` für Zahlungen sowie der Filter für `/v1/payment/list` nimmt folgende Werte an:

| Status | Beschreibung |
|--------|--------------|
| `pending` | Erstellt, wartet auf Initialisierung |
| `check` | Wartet auf Zahlung des Kunden |
| `paid` | Erfolgreich bezahlt |
| `underpaid_check` | Unterbezahlt (Aufstockung möglich) |
| `underpaid` | Unterbezahlt |
| `overpaid` | Überzahlt (gutgeschrieben) |
| `cancel` | Storniert / abgelaufen |
| `aml_lock` | Transaktion aufgrund von AML blockiert |

> **INFO:** Wenn Sie auf eine erfolgreiche Zahlung warten, sollten Sie sowohl `paid` als auch `overpaid` als erfolgreiche Status behandeln und die Bestellung des Kunden gutschreiben.

### Statusverwaltungsrichtlinie

| Status | Bestellung ausführen? | Weiter warten? | Betriebliche Aktion |
|--------|----------------|-------------------|--------------------|
| `pending` / `check` | Nein | Ja, bis zum Ablauf | Zeige ausstehenden Status an und gleiche normal ab. |
| `underpaid_check` | Standardmäßig Nein | Ja, Nachzahlung kann eintreffen | Speichere jede txid idempotent und zeige den Workflow für Restzahlungen an. |
| `paid` | Ja, einmal | Nein | Führe atomar aus dem verifizierten Ereignis aus. |
| `overpaid` | Ja, einmal | Nein | Ausführen und überschüssige/tatsächliche Beträge für merchant-Richtlinie behalten. |
| `underpaid` | Produktspezifisch | Nein | Explizite Teilzahlungs-/Manuell-Überprüfungsrichtlinie anwenden. |
| `cancel` | Nein | Nein | Als abgelaufen/storniert markieren, aber spätere On-Chain-Beweise eskalieren. |
| `aml_lock` | Nein | Keine automatische Erfüllung | Compliance-/Support-Überprüfung; Wert nicht automatisch freigeben. |

Status beschreiben die Sicht der Plattform auf die Zahlung. Sie ersetzen nicht Ihren lokalen Erfüllungsstatus. Speichern Sie beide, sodass eine erstattete, manuell überprüfte oder bereits erfüllte Bestellung nicht durch ein älteres webhook beschädigt werden kann.

Der `/v1/payment/list`-Anfragefilter akzeptiert derzeit `pending`, `check`, `paid`, `underpaid_check`, `underpaid`, `overpaid` und `cancel`. Er akzeptiert `aml_lock` nicht als Filter, obwohl eine AML-gesperrte Zahlung von anderen Zahlungsendpunkten zurückgegeben werden kann.

## Auszahlungsstatus

Das Feld `status` bei `/v1/payout` und `/v1/payout/status/{uuid}` nimmt einen der folgenden Werte an:

| Status | Beschreibung |
|--------|--------------|
| `pending` | Erstellt, wartet auf Verarbeitung |
| `completed` | Erfolgreich abgeschlossen — `txid` ist gesetzt |
| `failed` | Sendefehler — siehe `error_type` |
| `cancelled` | Storniert |

## Auszahlungs-Fehlertypen

Wenn eine Auszahlung den Status `status = failed` hat, beschreibt das Feld `error_type` den Grund:

| Code | Beschreibung |
|------|--------------|
| `aml_risk` | Auszahlung durch AML-Risikoprüfungen blockiert (Empfängeradresse als hohes Risiko gekennzeichnet) |