API के माध्यम से SMM पैनल में बैलेंस का स्वचालित टॉप-अप कैसे सेट करें

ऑटो-टॉप-अप सेट करने से पहले क्या तैयार करें

ऑटो-टॉप-अप SMM पैनल के बैलेंस को किसी पेमेंट सर्विस या आंतरिक बिलिंग से जोड़ता है। सर्विस बैलेंस की जाँच करती है, तय थ्रेशोल्ड तक पहुँचने पर पेमेंट बनाती है और भुगतान की पुष्टि होने के बाद ही राशि जमा करती है। इसके लिए पैनल के API डॉक्यूमेंटेशन, पेमेंट API तक पहुँच, टेस्ट और प्रोडक्शन एनवायरनमेंट के लिए अलग-अलग की, और सभी ऑपरेशन का लॉग ज़रूरी है।

डेवलपमेंट से पहले जाँचें कि पैनल का API बैलेंस लौटा सकता है या नहीं, टॉप-अप रिक्वेस्ट स्वीकार कर सकता है या नहीं, टॉप-अप हिस्ट्री दिखा सकता है या नहीं और बाहरी ऑपरेशन आईडी स्वीकार कर सकता है या नहीं। अगर पैनल API के ज़रिए टॉप-अप सपोर्ट नहीं करता, तो ऑटोमेशन सिर्फ़ रिक्वेस्ट बना सकता है या ऑपरेटर को नोटिफ़िकेशन भेज सकता है। इस विकल्प की कमी यह है कि पैसे फिर भी मैन्युअली जमा करने पड़ेंगे।

बैलेंस जाँच और पेमेंट के फ़ैसले को अलग रखें

बैलेंस की जाँच को शेड्यूल पर चलने वाले अलग टास्क से शुरू करना बेहतर है। यह बैलेंस लेता है, उसकी थ्रेशोल्ड से तुलना करता है और नतीजा टॉप-अप हैंडलर को देता है। मौजूदा अधूरे ऑपरेशन की जाँच किए बिना API के जवाब के ठीक उसी समय पेमेंट न बनाएँ: समानांतर टास्क एक ही कम बैलेंस देखकर कई भुगतान बना सकते हैं।

नए पेमेंट से पहले हैंडलर को जाँचना चाहिए कि "बनाया गया", "भुगतान की प्रतीक्षा में" या "पुष्टि हो रही है" स्टेटस वाला कोई ऑपरेशन तो नहीं है। अगर ऐसी एंट्री है, तो मिलान पूरा होने तक नई कोशिश शुरू नहीं होती। क्रमिक प्रोसेसिंग की कमी यह है कि बाहरी API के देर से जवाब देने पर टॉप-अप कई समानांतर रिक्वेस्ट की तुलना में देर से शुरू हो सकता है।

थ्रेशोल्ड और टॉप-अप राशि का लॉजिक चुनें

बैलेंस थ्रेशोल्ड सक्रिय ऑर्डर, सप्लायर के पास कतार और पेमेंट देरी के लिए बफ़र के साथ चुना जाता है। असमान गतिविधि वाले चैनल के लिए सिर्फ़ औसत खर्च पर निर्भर रहना जोखिम भरा है: स्ट्रीम, विज्ञापन लॉन्च या बड़े ऑर्डर के बाद कटौतियाँ तेज़ी से बढ़ सकती हैं। अलग से एक क्रिटिकल लेवल तय करें, जिस पर नोटिफ़िकेशन आता है, लेकिन पेमेंट ज़रूरी नहीं कि अपने आप बने।

टॉप-अप राशि तय हो सकती है या चुनी गई अवधि के खर्च से गणना की जा सकती है। तय राशि नियंत्रण और मिलान के लिए आसान है। इसकी कमी यह है कि शांत अवधि में बैलेंस पर अतिरिक्त पैसे पड़े रह सकते हैं, और ऑर्डर तेज़ी से बढ़ने पर एक टॉप-अप काफ़ी नहीं हो सकता। गणना की गई राशि ज़्यादा लचीली है, लेकिन इसके लिए असामान्य कटौतियों और रिफ़ंड से आँकड़ों को साफ़ करना ज़रूरी है।

वित्तीय सीमाएँ थ्रेशोल्ड से अलग सेट करें

थ्रेशोल्ड सिर्फ़ इस सवाल का जवाब देता है कि सिस्टम को टॉप-अप प्रक्रिया कब शुरू करने की अनुमति है। सीमाएँ दूसरे सवाल का जवाब देती हैं: यह कितनी राशि काट सकता है। एक ऑपरेशन की अधिकतम राशि, अवधि के लिए कुल लिमिट और जमा के बाद अनुमत बैलेंस तय करें। ये नियम पेमेंट बनाने से पहले जाँचे जाते हैं, उसके भुगतान के बाद नहीं।

ऑटो-टॉप-अप को ऑपरेशन और अवधि की लिमिट के बिना पैसे नहीं काटने चाहिए। अगर गणना की गई राशि अनुमत से ज़्यादा है, तो ऑपरेशन को मैन्युअल जाँच में भेजना और नोटिफ़िकेशन भेजना बेहतर है। सख्त लिमिट की कमी यह है कि खर्च तेज़ी से बढ़ने पर ज़िम्मेदार कर्मचारी के लिमिट बढ़ाने की पुष्टि करने से पहले बैलेंस खत्म हो सकता है।

अलग की बनाएँ और पहुँच सुरक्षित करें

ऑटो-टॉप-अप स्क्रिप्ट के लिए न्यूनतम अधिकारों वाली अलग API की इस्तेमाल करें: बैलेंस पढ़ना, पेमेंट बनाना, स्टेटस जाँचना और पुष्टि किए गए ऑपरेशन को जमा करना। उपयोगकर्ताओं, सर्विस सेटिंग, ऑर्डर और पैसे निकालने तक ऐसी की को पहुँच की ज़रूरत नहीं है। अगर सर्विस IP पते के आधार पर प्रतिबंध सपोर्ट करती है, तो सिर्फ़ इंटीग्रेशन सर्वर से अनुरोध की अनुमति दें।

की को एनवायरनमेंट वेरिएबल या सुरक्षित सीक्रेट स्टोरेज में रखें। उन्हें ब्राउज़र कोड, लॉग, सार्वजनिक रिपॉज़िटरी और एरर संदेशों में न भेजें। हर की का एक मालिक और बदलने की स्पष्ट प्रक्रिया होनी चाहिए। की के बार-बार रोटेशन की कमी यह है कि अगर नया सीक्रेट सभी कार्यप्रवाहों में अपडेट न हुआ, तो टॉप-अप रुक जाएगा।

अद्वितीय पहचानकर्ता के साथ पेमेंट बनाएँ

पेमेंट API को कॉल करने से पहले हर टॉप-अप को एक आंतरिक पहचानकर्ता दिया जाता है। इसे लॉग में सहेजा जाता है और आइडेम्पोटेंसी की या बाहरी ऑपरेशन नंबर के रूप में भेजा जाता है। नेटवर्क टाइम-आउट पर वही रिक्वेस्ट उसी पहचानकर्ता के साथ दोहराई जा सकती है: पेमेंट सर्विस को पहले से बना ऑपरेशन लौटाना चाहिए, पैसे दोबारा नहीं काटने चाहिए।

नीचे एक सामान्य रिक्वेस्ट का उदाहरण है। फ़ील्ड के नाम और पते किसी खास प्रोवाइडर के डॉक्यूमेंटेशन के मानों से बदलें। वेरिएबल PAYMENT_ID में पहले से बनाई गई अद्वितीय ID होती है, और CALLBACK_URL वेबहुक हैंडलर की ओर जाता है।

curl -X POST "$PAYMENT_API_URL/payments" \
-H "Authorization: Bearer $PAYMENT_API_KEY" \
-H "Idempotency-Key: $PAYMENT_ID" \
-H "Content-Type: application/json" \
-d '{"amount":"$TOPUP_AMOUNT","currency":"$CURRENCY","external_id":"$PAYMENT_ID","callback_url":"$CALLBACK_URL"}'

पेमेंट की विशिष्टता सिर्फ़ राशि और बनाने के समय से न तय करें। दो समान टॉप-अप वैध हो सकते हैं, लेकिन विफलता के बाद दोहराई गई रिक्वेस्ट नहीं। अपने डेटाबेस में बाहरी ID की कमी यह है कि इसे भरोसेमंद तरीके से सहेजना होगा और ऑपरेशन रद्द होने के बाद दोबारा इस्तेमाल नहीं करना होगा।

बैलेंस जाँचें और ऑपरेशन की स्थिति सहेजें

बैलेंस की रिक्वेस्ट नए टॉप-अप के फ़ैसले से पहले और सफल जमा के बाद होनी चाहिए। सामान्य रिक्वेस्ट ऐसी हो सकती है: curl -X GET "$PANEL_API_URL/balance" -H "Authorization: Bearer $PANEL_API_KEY". जवाब में सिर्फ़ राशि ही नहीं, जाँच का समय भी सहेजें, ताकि पुराने डेटा पर फ़ैसला न लिया जाए।

हर ऑपरेशन के लिए आंतरिक ID, प्रोवाइडर के पास पेमेंट ID, राशि, करेंसी, बनाने का समय, स्टेटस, API के जवाब और गलती का कारण वाली एंट्री रखें। उपयुक्त स्टेटस श्रृंखला: "बनाया गया", "भुगतान की प्रतीक्षा में", "भुगतान हो गया", "जमा हो रहा है", "जमा हो गया", "रद्द किया गया", "जाँच की ज़रूरत है"।

पैनल में जमा सिर्फ़ पुष्टि किए गए और अभी तक प्रोसेस न किए गए भुगतान के लिए अनुमत है। इतिहास के बिना स्टेटस न बदलें: विवाद के समय दिखना चाहिए कि कौन-सी रिक्वेस्ट भेजी गई थी और ऑपरेशन क्यों बदला गया। विस्तृत लॉग की कमी यह है कि इसमें संवेदनशील डेटा हो सकता है, इसलिए इसकी पहुँच सीमित की जाती है।

वेबहुक स्वीकार करें और पेमेंट स्टेटस का मिलान करें

सफल भुगतान का पेज और उपयोगकर्ता का रीडायरेक्ट पैसे आने की पुष्टि नहीं करते। पुष्टि पेमेंट सर्विस से आने वाला वेबहुक या उसके API के ज़रिए स्टेटस की दोबारा जाँच होती है। वेबहुक मिलने पर हस्ताक्षर, भेजने का समय, पेमेंट ID, बाहरी ID, राशि और करेंसी जाँचें। इसके बाद ही ऑपरेशन को पुष्ट भुगतान की स्थिति में ले जाएँ।

वेबहुक की जाँच के बाद प्रोवाइडर से पेमेंट का मौजूदा स्टेटस माँगना उपयोगी है। उदाहरण के लिए: curl -X GET "$PAYMENT_API_URL/payments/$PROVIDER_PAYMENT_ID" -H "Authorization: Bearer $PAYMENT_API_KEY". स्टेटस को लॉग के डेटा से मिलाएँ, फिर उसी आंतरिक ID के साथ SMM पैनल में जमा करने की रिक्वेस्ट भेजें।

दोहराया गया वेबहुक दूसरी जमा नहीं बनाना चाहिए। हैंडलर बाहरी ID से ऑपरेशन ढूँढता है, "जमा हो गया" स्टेटस देखता है और नई कार्रवाई के बिना सफल जवाब लौटाता है। वेबहुक की कमी यह है कि हैंडलर के उपलब्ध न होने पर वे देर से आ सकते हैं या पहुँच ही नहीं सकते।

टाइम-आउट, रीट्राई और अटके पेमेंट संभालें

पेमेंट बनाने के बाद टाइम-आउट पर दूसरी ID के साथ नई रिक्वेस्ट न भेजें। पहले आंतरिक पहचानकर्ता से ऑपरेशन ढूँढें या उसी आइडेम्पोटेंसी की के साथ रिक्वेस्ट दोहराएँ। अगर प्रोवाइडर ने मूल रिक्वेस्ट स्वीकार की है, तो वह मौजूदा पेमेंट लौटाएगा। यह कनेक्शन टूटने पर दोहरी कटौती से बचाता है।

अगर तय समय में वेबहुक नहीं आया, तो बैकग्राउंड टास्क API के ज़रिए पेमेंट स्टेटस माँगता है। दोहरी जाँच बढ़ते अंतराल और सीमित कोशिशों के साथ की जाती है, ताकि API और लॉग पर ज़्यादा भार न पड़े। जो ऑपरेशन लंबे समय तक प्रतीक्षा में रहता है, उसे मिलान के बिना रद्द न मानकर मैन्युअल जाँच में भेजें।

नेटवर्क की अस्थायी गलती या API के उपलब्ध न होने के जवाब पर रीट्राई मान्य है। भुगतान से इनकार, गलत राशि, वेबहुक के अमान्य हस्ताक्षर या लिमिट से अधिक होने पर रिक्वेस्ट अपने आप न दोहराएँ। रीट्राई की कमी यह है कि वे स्टेटस लॉजिक को जटिल बनाते हैं और प्रोवाइडर पर बड़े पैमाने की विफलता के समय अतिरिक्त भार पैदा कर सकते हैं।

पुष्ट भुगतान को SMM पैनल में जमा करें

जमा करने से पहले हैंडलर एक बार फिर जाँचता है: राशि लिमिट से ज़्यादा नहीं है, करेंसी मेल खाती है, ऑपरेशन रद्द नहीं हुआ और उसका स्टेटस अभी "जमा हो गया" नहीं है। रिक्वेस्ट में राशि और पेमेंट की बाहरी पहचानकर्ता भेजा जाता है। अगर पैनल का API आइडेम्पोटेंसी की सपोर्ट करता है, तो वही आंतरिक ऑपरेशन ID इस्तेमाल करें।

रिक्वेस्ट का सामान्य रूप: curl -X POST "$PANEL_API_URL/balance/topups" -H "Authorization: Bearer $PANEL_API_KEY" -H "Content-Type: application/json" -H "Idempotency-Key: $PAYMENT_ID" -d '{"amount":"$TOPUP_AMOUNT","currency":"$CURRENCY","external_id":"$PAYMENT_ID"}'

पैनल के जवाब के बाद बैलेंस दोबारा माँगें और नतीजा लॉग में सहेजें। अगर पेमेंट सर्विस से पैसे कट गए, लेकिन पैनल के API ने गलती लौटाई, तो नया पेमेंट न बनाएँ। ऑपरेशन दोबारा जमा करने की कोशिश या मैन्युअल मिलान तक "जाँच की ज़रूरत है" स्टेटस में रहता है। ऐसी सतर्क योजना की कमी यह है कि बैलेंस कुछ समय तक अपने आप नहीं भर सकता।

नोटिफ़िकेशन, स्विच और स्टार्टअप जाँच जोड़ें

नोटिफ़िकेशन विचलन के लिए ज़रूरी हैं: बैलेंस क्रिटिकल लेवल से नीचे गया, पेमेंट अस्वीकार हुआ, वेबहुक नहीं मिला, लिमिट पार हुई, API उपलब्ध नहीं है या ऑपरेशन को मैन्युअल जाँच चाहिए। संदेश में आंतरिक ID, स्टेटस और कारण बताना काफ़ी है। इसमें API की, वेबहुक हस्ताक्षर और पेमेंट विवरण शामिल न करें।

इंटीग्रेशन हटाए बिना ऑटो-टॉप-अप के लिए अलग स्विच रखें। यह प्रोवाइडर बदलने, तकनीकी काम, गलती की आशंका या खर्च में तेज़ बदलाव के समय ज़रूरी है। स्विच की कमी स्पष्ट है: काम के बाद अगर इसे दोबारा चालू न किया गया, तो सक्रिय ऑर्डर के दौरान बैलेंस खत्म हो सकता है।

ऑटो-टॉप-अप चालू करने से पहले चेकलिस्ट

• जब तक कोई अधूरा ऑपरेशन है, बैलेंस जाँच पेमेंट नहीं बनाती।
• हर पेमेंट के लिए अद्वितीय आंतरिक ID और आइडेम्पोटेंसी की बनाई जाती है।
• एक ऑपरेशन और चुनी गई अवधि के लिए लिमिट सेट हैं।
• वेबहुक हस्ताक्षर, राशि, करेंसी और पहचानकर्ता से जाँचे जाते हैं।
• वेबहुक न मिलने पर API के ज़रिए स्टेटस का दोबारा मिलान शुरू होता है।
• टाइम-आउट पहले पेमेंट की जाँच से पहले दूसरा पेमेंट नहीं बनाता।
• पैनल में जमा एक बार होता है और लॉग में दर्ज होता है।
• टेस्ट मोड सफलता, इनकार, वेबहुक के डुप्लिकेट और API के उपलब्ध न होने पर जाँचा गया है।