কীভাবে 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 অপ্রাপ্যতা যাচাই করা হয়েছে।