परिचय/संदर्भ

References

2328.io API में उपयोग किए जाने वाले Network codes, currency-network mappings, और payment status values।

यह page API request और response में उपयोग की जाने वाली सभी reference values को सूचीबद्ध करता है।

Network codes

ये codes वहाँ उपयोग किए जाते हैं जहाँ कहीं भी network field उपस्थित होता है:

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

प्रत्येक currency केवल कुछ networks के subset पर उपलब्ध है। एक मान्य संयोजन चुनने के लिए इस table का उपयोग करें:

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 TON मूल मुद्रा के लिए कैनॉनिकल एसेट कोड है। पेमेंट, स्टेटिक-वॉलेट, और पेआउट क्रिएशन API वर्तमान में लेगसी TON इनपुट स्वीकार करते हैं और इसे GRAM में सामान्यीकृत करते हैं; इंटीग्रेशन को API द्वारा लौटाई गई कैनॉनिकल वैल्यू को स्टोर और हैंडल करना चाहिए। पॉलीगॉन मूल एसेट POL है, जबकि इसका नेटवर्क कोड POL-MATIC है। कभी भी MATIC को नेटवर्क कोड के रूप में न भेजें।

सक्षम दिशाएँ संचालन कॉन्फ़िगरेशन हैं और यह कैटलॉग से स्वतंत्र रूप से बदल सकती हैं। विकल्प प्रस्तुत करने से पहले /v1/directions से क्वेरी करें; इस तालिका को वैध कोड मैप के रूप में मानें, यह गारंटी नहीं है कि हर जोड़ी वर्तमान में सक्षम है।

Payment statuses

भुगतानों पर payment_status field और /v1/payment/list filter निम्नलिखित values लेता है:

Status	Description
`pending`	बनाया गया, initialization की प्रतीक्षा में
`check`	Customer से भुगतान की प्रतीक्षा में
`paid`	सफलतापूर्वक भुगतान हुआ
`underpaid_check`	कम भुगतान (top up कर सकते हैं)
`underpaid`	कम भुगतान
`overpaid`	अधिक भुगतान (credited)
`cancel`	रद्द / expired
`aml_lock`	AML के कारण transaction blocked

सफल भुगतान सुनते समय, आपको paid और overpaid दोनों को सफल states के रूप में मानना चाहिए और customer के order को credit करना चाहिए।

स्थिति प्रबंधन नीति

स्थिति	क्या आदेश पूरा करें?	क्या प्रतीक्षा जारी रखें?	संचालनात्मक कार्रवाई
`pending` / `check`	नहीं	हाँ, समाप्ति तक	लंबित स्थिति प्रदर्शित करें और सामान्य रूप से मेल बैठाएं।
`underpaid_check`	डिफ़ॉल्ट रूप से नहीं	हाँ, टॉप-अप आ सकता है	प्रत्येक txid को आइडम्पोटेंट तरीके से संग्रहीत करें और शेष-भुगतान कार्यप्रवाह दिखाएँ।
`paid`	हाँ, एक बार	नहीं	सत्यापित घटना से परमाणु रूप से पूरा करें।
`overpaid`	हाँ, एक बार	नहीं	व्यापारी नीति के लिए अतिरिक्त/वास्तविक राशि पूरी करें और बनाए रखें।
`underpaid`	उत्पाद-विशिष्ट	नहीं	स्पष्ट आंशिक-भुगतान/मैनुअल-समीक्षा नीति लागू करें।
`cancel`	नहीं	नहीं	अवधि समाप्त/रद्द का मार्क करें, लेकिन किसी भी बाद के ऑन-चेन साक्ष्य को बढ़ाएं।
`aml_lock`	नहीं	स्वचालित पूर्ति नहीं	अनुपालन/समर्थन समीक्षा; मूल्य को स्वतः जारी न करें।

स्थिति भुगतान पर प्लेटफ़ॉर्म के दृष्टिकोण का वर्णन करती हैं। वे आपकी स्थानीय पूर्ति स्थिति की जगह नहीं लेती। दोनों को संग्रहीत करें ताकि कोई रिफंड किया गया, मैनुअल समीक्षा किया गया, या पहले से पूरी की गई आदेश पुराने वेबहुक द्वारा भ्रष्ट न हो।

वर्तमान में /v1/payment/list अनुरोध फ़िल्टर pending, check, paid, underpaid_check, underpaid, overpaid, और cancel को स्वीकार करता है। यह aml_lock को फ़िल्टर के रूप में स्वीकार नहीं करता हालांकि अन्य भुगतान एंडपॉइंट से AML-लॉक किए गए भुगतान को लौटाया जा सकता है।

Payout statuses

/v1/payout और /v1/payout/status/{uuid} पर status field इनमें से एक लेता है:

Status	Description
`pending`	बनाया गया, processing की प्रतीक्षा में
`completed`	सफलतापूर्वक पूर्ण — `txid` set है
`failed`	भेजने में त्रुटि — `error_type` देखें
`cancelled`	रद्द कर दिया गया

Payout error types

जब किसी payout का status = failed होता है, तो error_type field कारण बताता है:

Code	Description
`aml_risk`	AML risk checks द्वारा payout block (प्राप्तकर्ता address को high-risk के रूप में flag किया गया)