Introduktion/Referenser

Referenser

Nätverkskoder, valuta-nätverkskopplingar och betalningsstatusvärden som används i 2328.io API.

Den här sidan listar alla referensvärden som används i API-förfrågningar och svar.

Nätverkskoder

Dessa koder används överallt där fältet network finns:

Kod	Nätverk
`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

Valuta-nätverkskoppling

Varje valuta finns endast tillgänglig på en delmängd av nätverken. Använd den här tabellen för att välja en giltig kombination:

Valuta	Tillåtna nätverk
`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 är den kanoniska tillgångskoden för TON:s inhemska valuta. Betalnings-, statisk-plånbok- och utbetalnings-API:er accepterar för närvarande legacy TON-inmatning och normaliserar den till GRAM; integrationer bör lagra och hantera det kanoniska värdet som returneras av API:et. Polygons inhemska tillgång är POL, medan dess nätverkskod är POL-MATIC. Skicka aldrig MATIC som nätverkskod.

Aktiverade riktningar är operativ konfiguration och kan ändras oberoende av denna katalog. Fråga /v1/directions innan du presenterar val; behandla denna tabell som den giltiga kodmappen, inte som en garanti för att varje par för närvarande är aktiverat.

Betalningsstatusar

Fältet payment_status på betalningar och filtret /v1/payment/list tar följande värden:

Status	Beskrivning
`pending`	Skapad, väntar på initialisering
`check`	Väntar på betalning från kunden
`paid`	Betald
`underpaid_check`	Underbetald (kan fyllas på)
`underpaid`	Underbetald
`overpaid`	Överbetald (krediterad)
`cancel`	Avbruten / utgången
`aml_lock`	Transaktionen blockerad på grund av AML

När du lyssnar efter en lyckad betalning bör du behandla både paid och overpaid som lyckade tillstånd och kreditera kundens order.

Statushanteringspolicy

Status	Uppfyll beställning?	Fortsätt vänta?	Operativ åtgärd
`pending` / `check`	Nej	Ja, tills det går ut	Visa väntande tillstånd och gör avstämning normalt.
`underpaid_check`	Nej som standard	Ja, påfyllning kan komma	Spara varje txid idempotent och visa arbetsflödet för återstående betalning.
`paid`	Ja, en gång	Nej	Uppfyll atomärt från den verifierade händelsen.
`overpaid`	Ja, en gång	Nej	Uppfyll och behåll överskjutande/faktiska belopp för handlarens policy.
`underpaid`	Produktspecifik	Nej	Tillämpa explicit partiell betalnings-/manuell granskningspolicy.
`cancel`	Nej	Nej	Markera som utgången/avbruten, men eskalera all senare kedjebaserad bevisning.
`aml_lock`	Nej	Ingen automatisk uppfyllelse	Efterlevnads-/supportgranskning; frigör inte värde automatiskt.

Statusar beskriver plattformens syn på betalningen. De ersätter inte ditt lokala uppfyllelse-tillstånd. Spara båda så att en återbetald, manuellt granskad eller redan uppfylld order inte kan förstöras av en äldre webhook.

/v1/payment/list-begäransfiltret accepterar för närvarande pending, check, paid, underpaid_check, underpaid, overpaid och cancel. Det accepterar inte aml_lock som en filter trots att en AML-låst betalning kan returneras av andra betalningsändpunkter.

Uttagsstatusar

Fältet status på /v1/payout och /v1/payout/status/{uuid} antar något av:

Status	Beskrivning
`pending`	Skapat, väntar på bearbetning
`completed`	Slutfört framgångsrikt — `txid` är satt
`failed`	Sändningsfel — se `error_type`
`cancelled`	Avbrutet

Feltyper för uttag

När ett uttag har status = failed beskriver fältet error_type orsaken:

Kod	Beskrivning
`aml_risk`	Uttag blockerat av AML-riskkontroller (mottagaradressen flaggades som högrisk)