क्रिप्टो पेमेंट गेटवे API: इंटीग्रेट करने से पहले जाँचने वाली 12 बातें
हर क्रिप्टो पेमेंट API इनवॉइस बना सकता है। असली फ़र्क़ रीट्राई, आंशिक पेमेंट और फ़ेल हुए webhooks में दिखता है। डेवलपर्स के लिए 12-पॉइंट चेकलिस्ट, साथ में यह कि mistKET API हर पॉइंट को कैसे संभालता है।
हर क्रिप्टो पेमेंट गेटवे API एक ही वादा करता है: इनवॉइस बनाएँ, पेमेंट पाएँ, callback प्राप्त करें। फ़र्क़ बाद में दिखते हैं — जब दो रिक्वेस्ट आपस में टकराती हैं, जब ग्राहक इनवॉइस से थोड़ा कम भेजता है, जब आपका सर्वर एक घंटे के लिए डाउन रहता है, या जब कोई हमलावर पकड़ी गई रिक्वेस्ट को दोबारा भेजता है। API को सोच-समझकर चुनना, उसे जल्दी इंटीग्रेट करने से कहीं ज़्यादा समय बचाता है।
यह उन डेवलपर्स और CTO के लिए चेकलिस्ट है जो कोड लिखने से पहले क्रिप्टो पेमेंट API की तुलना कर रहे हैं। हर पॉइंट में आप देखेंगे कि क्या देखना है, यह क्यों ज़रूरी है और mistKET API इसे कैसे संभालता है। अगर आप चुन चुके हैं और स्टेप-बाय-स्टेप कोड चाहते हैं, तो सीधे हमारी क्रिप्टो पेमेंट API इंटीग्रेशन गाइड पर जाएँ।
कम से कम कौन-से endpoints होने चाहिए
काम के क्रिप्टो पेमेंट API में "पेमेंट बनाएँ" से ज़्यादा होना चाहिए। कम से कम ये देखें:
| क्षमता | क्यों चाहिए | mistKET endpoint |
|---|---|---|
| इनवॉइस बनाना | हर ऑर्डर के लिए एक पेमेंट रिक्वेस्ट, समय-सीमा के साथ | POST /invoices |
| इनवॉइस फ़ेच करना | webhook छूट जाने पर मिलान | GET /invoices/{uuid} |
| इनवॉइस की लिस्ट और फ़िल्टर | बैक-ऑफ़िस व्यू और रात का मिलान (reconciliation) | GET /invoices |
| इनवॉइस कैंसल करना | ऑर्डर छोड़ दिए जाने पर स्टॉक खाली करना | POST /invoices/{uuid}/cancel |
| सपोर्टेड एसेट | सिर्फ़ वही नेटवर्क दिखाना जिन पर अभी भुगतान हो सकता है | GET /assets |
| रेट कोट | इनवॉइस बनाने से पहले क्रिप्टो रकम दिखाना | GET /rate |
| हेल्थ चेक | मॉनिटरिंग और सुरक्षित फ़ॉलबैक | GET /health |
अगर कोई प्रोवाइडर इनवॉइस फ़ेच या लिस्ट नहीं करने देता, तो आपको webhooks पर आँख मूँदकर भरोसा करना पड़ता है — और पहली बार डिलीवरी फ़ेल होते ही यह बुरी स्थिति बन जाती है।
1. ऑथेंटिकेशन: क्या हर रिक्वेस्ट साइन होती है?
हेडर में भेजी गई API key सबसे कमज़ोर विकल्प है: जो भी उसे बीच में पकड़ ले या लीक कर दे, वह इनवॉइस बना और कैंसल कर सकता है। ऐसा API चुनें जिसमें हर रिक्वेस्ट एक ऐसे secret से साइन होती हो जो कभी नेटवर्क पर नहीं जाता। mistKET की रिक्वेस्ट में X-Api-Key, X-Api-Timestamp और timestamp व raw body का HMAC-SHA256 सिग्नेचर होता है। secret मर्चेंट पैनल में सिर्फ़ एक बार दिखाया जाता है।
2. रीप्ले प्रोटेक्शन
अकेला सिग्नेचर किसी को पकड़ी गई रिक्वेस्ट दोबारा भेजने से नहीं रोकता। timestamp विंडो और nonce सपोर्ट देखें। mistKET सर्वर टाइम से ±300 सेकंड से ज़्यादा अलग timestamp को रिजेक्ट करता है और स्टेट बदलने वाली रिक्वेस्ट में एक ही सिग्नेचर दो बार स्वीकार नहीं करता। इसका सिग्नेचर वर्ज़न 2 हर रिक्वेस्ट में nonce जोड़ता है और method व path को भी साइन करता है, ताकि सिग्नेचर किसी दूसरे endpoint पर दोबारा इस्तेमाल न हो सके।
3. इनवॉइस बनाते समय idempotency
नेटवर्क टाइमआउट होते ही हैं। अगर आपका चेकआउट "इनवॉइस बनाएँ" कॉल को दोबारा आज़माता है, तो एक ऑर्डर के लिए दो इनवॉइस नहीं बनने चाहिए। अच्छा API idempotency key देता है। mistKET में यह काम आपकी अपनी order_id करती है: उसी ऑर्डर ID से दोबारा कॉल करने पर नया इनवॉइस बनाने के बजाय मौजूदा इनवॉइस "idempotent": true के साथ लौटता है।
4. असली पेमेंट को कवर करने वाला स्टेटस मॉडल
"पेड / नॉट पेड" काफ़ी नहीं है। ग्राहक थोड़ा कम भेजते हैं क्योंकि एक्सचेंज ने फ़ीस काट ली, या ज़्यादा भेज देते हैं, या समय-सीमा ख़त्म होने के बाद भुगतान करते हैं। जाँचें कि API इन मामलों को साफ़-साफ़ दिखाता है। mistKET इनवॉइस new, pending, underpaid, paid, confirmed, overpaid, expired और cancelled स्टेटस से गुज़रते हैं, साथ में paid_amount, remaining_amount, can_pay_remaining और under_review जैसे फ़ील्ड होते हैं, ताकि आपके कोड को कभी अंदाज़ा न लगाना पड़े।
paid का मतलब है कि ट्रांसफ़र डिटेक्ट हो गया है और कन्फ़र्मेशन का इंतज़ार है; ऑर्डर सिर्फ़ confirmed या overpaid पर ही डिलीवर करें।5. दिखने वाले कन्फ़र्मेशन
API को बताना चाहिए कि पेमेंट को कितने ब्लॉक कन्फ़र्मेशन मिले हैं और कितने ज़रूरी हैं, साथ ही ट्रांज़ैक्शन हैश और एक्सप्लोरर लिंक भी। इससे पेमेंट से जुड़े सपोर्ट टिकट झटपट जाँच में बदल जाते हैं। mistKET हर इनवॉइस के लिए confirmations, required_confirmations और हैश, रकम, स्टेटस व एक्सप्लोरर URL वाला transactions[] ऐरे लौटाता है।
6. रेट लॉक और प्राइसिंग करेंसी
आप फ़िएट में कीमत तय करते हैं; ग्राहक क्रिप्टो में भुगतान करता है। पूछें कि कौन-सी फ़िएट करेंसी स्वीकार होती हैं और बताया गया रेट कितनी देर तक टिका रहता है। mistKET USD, EUR, TRY, RUB, GBP और AED (या सीधे क्रिप्टो सिंबल) में कीमत स्वीकार करता है, इनवॉइस की पूरी अवधि तक रेट लॉक रखता है और हर इनवॉइस के लिए यह अवधि 5 से 1,440 मिनट के बीच सेट करने देता है।
7. नेटवर्क का चुनाव
क्या आप API कॉल में नेटवर्क तय कर सकते हैं, या ग्राहक को होस्टेड पेज पर चुनने देते हैं? दोनों काम के हैं: नेटवर्क तय करना बॉट्स और ऑटोमेटेड फ़्लो के लिए ठीक है, ग्राहक को चुनने देना गलत नेटवर्क पर पेमेंट कम करता है। mistKET दोनों को pay_currency + network या asset_id से सपोर्ट करता है, और जब किसी नेटवर्क पर कोई खाली पता नहीं होता तो GET /assets available: false बताता है। आज TRON (TRC-20) पर USDT चालू है; और एसेट व नेटवर्क अनुरोध पर हर मर्चेंट के लिए चालू किए जाते हैं। TRON आम डिफ़ॉल्ट क्यों है, यह जानने के लिए USDT TRC20 vs ERC20 देखें।
8. साइन किए, रीट्राई होने वाले और ट्रेस करने लायक webhooks
ज़्यादातर इंटीग्रेशन webhooks पर ही टूटते हैं। चार चीज़ें जाँचें: payload साइन है, पुरानी डिलीवरी रिजेक्ट करने के लिए timestamp है, फ़ेल डिलीवरी घंटों तक (सेकंडों तक नहीं) रीट्राई होती है, और हर डिलीवरी की एक ID है जिससे डुप्लिकेट हटाए जा सकें। mistKET webhooks को अलग webhook secret से साइन करता है, X-Mistket-Delivery और X-Mistket-Event हेडर भेजता है, और non-2xx जवाब मिलने पर 10 सेकंड, 30 सेकंड, 2 मिनट, 10 मिनट, 30 मिनट, 1 घंटे, 2 घंटे और 3 घंटे पर रीट्राई करता है; डिलीवरी हिस्ट्री डैशबोर्ड में दिखती है। हैंडलर डिज़ाइन पर विस्तार से जानकारी हमारे क्रिप्टो पेमेंट webhooks लेख में है।
9. डॉक्यूमेंटेड एरर और रेट लिमिट
आपको पहले से पता होना चाहिए कि गलत सिग्नेचर, ब्लॉक हुआ IP या वैलिडेशन एरर कैसा दिखता है। mistKET एक जैसा { "success": false, "error": … } body लौटाता है, वैलिडेशन एरर में हर फ़ील्ड का ब्योरा देता है, स्टैंडर्ड कोड (401, 403, 404, 422, 429, 503) इस्तेमाल करता है और अपनी लिमिट डॉक्यूमेंट करता है: हर API key पर प्रति मिनट 120 रिक्वेस्ट।
10. नेटवर्क-लेवल कंट्रोल
IP allow-list का मतलब है कि लीक हुई key आपके सर्वरों के अलावा कहीं से भी बेकार है। mistKET आपको डैशबोर्ड में यह सेट करने देता है; दूसरे पतों से आने वाली रिक्वेस्ट को 403 मिलता है। साइन की गई रिक्वेस्ट और छोटी timestamp विंडो के साथ मिलकर यह हमले के सबसे आम रास्ते बंद कर देता है।
11. SDK पर कोई निर्भरता नहीं
SDK तब तक सुविधाजनक हैं जब तक वे आपकी भाषा के वर्ज़न से पीछे न रह जाएँ। सीधे HTTPS और JSON पर बना API, जिसमें साइनिंग सिर्फ़ एक HMAC कॉल है, PHP, Node.js, Python, Go या shell स्क्रिप्ट — कहीं से भी चलता है। mistKET अपने API डॉक्यूमेंटेशन में PHP, Node.js और Python के लिए कॉपी-पेस्ट क्लाइंट देता है, लेकिन इनमें से कोई भी ज़रूरी नहीं है।
12. नॉन-डेवलपर्स के लिए मैनुअल रास्ता
API-फ़र्स्ट बिज़नेस को भी कभी-कभी किसी एक क्लाइंट को अलग से बिल करना पड़ता है। जाँचें कि इनवॉइस पैनल में भी बनाए जा सकें और लिंक के रूप में शेयर हो सकें, ताकि सेल्स और सपोर्ट टीम को डेवलपर्स को न बुलाना पड़े। mistKET में वही इनवॉइस मर्चेंट पैनल में उपलब्ध हैं, और हर होस्टेड चेकआउट पेज एक पेमेंट लिंक की तरह काम करता है।
GET /invoices/{uuid} कॉल करके तुलना करें। इससे आपकी साइनिंग, webhook हैंडलर और मिलान एक ही बार में वेरिफ़ाई हो जाते हैं।क्रिप्टो पेमेंट API परखते समय ख़तरे के संकेत
- बिना साइन वाले webhooks या ऐसे webhooks जो सिर्फ़ एक गुप्त URL से "सुरक्षित" हैं।
- इनवॉइस बनने के बाद उसे फ़ेच करने का कोई तरीका नहीं।
- underpaid या overpaid स्टेटस नहीं — एज केस सपोर्ट चैट में पहुँच जाते हैं।
- सिर्फ़ कुछ मिनट तक रीट्राई, या कोई डिलीवरी लॉग नहीं।
- बिना डॉक्यूमेंटेशन वाली रेट लिमिट और एरर फ़ॉर्मेट।
- प्रति ट्रांज़ैक्शन अस्पष्ट प्राइसिंग — हमारी क्रिप्टो पेमेंट गेटवे फ़ीस गाइड से तुलना करें।
mistKET API एक्सेस कैसे पाएँ
मर्चेंट को mistKET टीम ख़ुद जोड़ती है: Telegram पर @mistnetwork को अपनी वेबसाइट, बिज़नेस का प्रकार और अनुमानित वॉल्यूम लिखकर भेजें। मंज़ूरी मिलने के बाद आप मर्चेंट पैनल में अपनी API key, secret और webhook सेटिंग बनाते हैं। एक आम इंटीग्रेशन में बस एक दोपहर लगती है।
शुरू करने से पहले डेवलपर सेक्शन, प्राइसिंग और पूरा API रेफ़रेंस देख लें।
