SMM پینل میں API کے ذریعے بیلنس کی خودکار ٹاپ اپ کیسے سیٹ کریں

آٹو ٹاپ اپ سیٹ کرنے سے پہلے کیا تیار کریں

آٹو ٹاپ اپ 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 کی عدم دستیابی پر جانچا گیا ہے۔