उसी ऑर्डर को उसके मूल request_id और बिना बदले विवरण के फिर भेजें। कनेक्शन का समय समाप्त होने पर नई कुंजी न बनाएँ। NotPanel स्वीकार हो चुका ऑर्डर लौटा सकता है, या प्रक्रिया जारी होने पर इंतज़ार करने को कह सकता है।
ग्राहक ने एक खरीद की है। पैनल को भेजने के बाद जवाब खो जाए, तो अगला कदम उसी खरीद का परिणाम पता करना है। अनिश्चित जवाब दूसरी खरीद करने की अनुमति नहीं है।
टाइमआउट के बाद तीन संभावनाएँ रहती हैं
- अनुरोध पहुँचा ही नहीं और कोई ऑर्डर स्वीकार नहीं हुआ।
- ऑर्डर स्वीकार हुआ, लेकिन उसका जवाब खो गया।
- अनुरोध पर काम जारी है और परिणाम अभी पता नहीं है।
टाइमआउट इन स्थितियों का अंतर नहीं बताता। खरीद बनाने वाले POST को दोहराने की सुरक्षा केवल HTTP से नहीं मिलती; यह API के नियमों पर निर्भर है। देखें RFC 9110, §9.2.2.
NotPanel दोबारा भेजे गए अनुरोध को कैसे पहचानता है
request_id वैकल्पिक है, खाली नहीं हो सकता और अधिकतम 128 अक्षर का होता है। idempotency_key उसका दूसरा नाम है; दोनों भेजने पर request_id चुना जाता है। उसी खाते, कुंजी और सभी ऑर्डर पैरामीटर का प्रयोग करें। स्वीकार हो चुका ऑर्डर मूल ID लौटाता है; उसी कुंजी से अलग पैरामीटर भेजना अस्वीकार होता है।
दोनों फ़ील्ड छोड़ने पर NotPanel उसी खाते के समान add को 60 सेकंड तक सुरक्षा देता है। देर से होने वाले दोबारा प्रयास को इस छोटी अवधि पर निर्भर न रखें। अनिश्चित परिणाम वाला अनुरोध जाँच के दौरान सुरक्षित रहता है।
इस अवधि में जानबूझकर की गई दो समान खरीद भी एक अनुरोध मानी जाती हैं। तुरंत दो अलग ऑर्डर चाहिए तो हर नई खरीद को अलग request_id दें। अनिश्चित परिणाम से बचने के लिए कुंजी कभी न बदलें।
ऑर्डर बनाने के पैरामीटर और जवाब पढ़ें
टाइमआउट के बाद मूल request_id बनाए रखें।
उसी कुंजी और बिना बदले ऑर्डर विवरण के साथ फिर प्रयास करें।
मिली ऑर्डर ID सहेजें; परिणाम अनिश्चित हो तो इंतज़ार करें।
भेजने से पहले खरीद की पहचान सहेजें
खरीद 8427 की एक ऑर्डर लाइन के लिए पहले request_id और पूरा विवरण सहेजें। नीचे नमूना फ़ील्ड और पढ़ने के लिए लाइन ब्रेक हैं; वास्तविक फ़ॉर्म सामान्य तरीके से encode करें। वास्तविक मान केवल तब भेजें जब भुगतान वाला ऑर्डर करना हो।
POST https://notpanel.com/api/v3
Content-Type: application/x-www-form-urlencoded
key=YOUR_API_KEY
&action=add
&service=YOUR_SERVICE_ID
&link=YOUR_TARGET_URL
&quantity=YOUR_VALID_QUANTITY
&request_id=checkout-8427-line-1टाइमआउट के बाद checkout-8427-line-1 को उसी सेवा, लक्ष्य, मात्रा और वैकल्पिक फ़ील्ड के साथ भेजें—ऐप दोबारा शुरू हो तब भी। मिली ऑर्डर ID सहेजकर status में इस्तेमाल करें। request_id ऑर्डर बनाने के प्रयास की पहचान है; status में ऑर्डर ID का विकल्प नहीं।
पूरा जवाब पढ़कर निर्णय लें
- टाइमआउट या अनिश्चित जवाब
- कुंजी और विवरण वही रखें। सीमित प्रयास करें, बीच में रुकें और Retry-After मानें। प्रयास खत्म होने पर रिकॉर्ड को अनसुलझा सहेजें।
- REQUEST_PROCESSING या REQUEST_UNCONFIRMED
- इंतज़ार करके केवल मूल अनुरोध दोहराएँ। दूसरी कुंजी से नया ऑर्डर न बनाएँ।
- REQUEST_ID_CONFLICT
- सहेजे गए पैरामीटर जाँचें। मूल ऑर्डर के लिए मूल विवरण वापस भेजें; नई कुंजी केवल जानबूझकर अलग खरीद के लिए है।
- गलत विवरण, पहचान या अनुरोध सीमा की त्रुटि
- error_code और retryable पढ़ें। फ़ील्ड या कुंजी सुधारें और सीमा की प्रतीक्षा मानें। हर त्रुटि को अपने-आप दोहराना सही नहीं है।
ग्राहकों की खरीद से पहले रिकवरी जाँचें
अपने टेस्ट वातावरण में नकली API से शुरुआत करें। वास्तविक खरीद या किसी विशेष NotPanel टेस्ट कुंजी की ज़रूरत नहीं है।
- स्वीकार ऑर्डर के बाद जवाब खोने की स्थिति बनाएँ; वही कुंजी और विवरण दोबारा जाना चाहिए।
- क्लाइंट दोबारा शुरू करें और सहेजी हुई पहचान वापस पाएँ।
- पहले प्रक्रिया जारी, फिर सफलता का जवाब दें; केवल एक ऑर्डर ID सहेजी जाए।
- कुंजी टकराव या दोबारा प्रयास न करने वाली त्रुटि दें; स्वचालित प्रयास रुकने चाहिए।
- दो नई समान खरीद को अलग कुंजी दें। बाद में वास्तविक टेस्ट करें तो इच्छित ऑर्डर ही करें और ऑर्डर व वॉलेट के रिकॉर्ड जाँचें।
अक्सर पूछे जाने वाले सवाल
क्या टाइमआउट का मतलब दो बार पैसे कटना है?
नहीं। इसका मतलब ऐप को उपयोगी जवाब नहीं मिला। डुप्लिकेट शुल्क मानने से पहले मिले ऑर्डर और वॉलेट के रिकॉर्ड जाँचें।
क्या request_id अनिवार्य है?
नहीं। request_id और idempotency_key वैकल्पिक हैं। इनके बिना उसी खाते के समान add को 60 सेकंड सुरक्षा मिलती है। स्पष्ट कुंजी हर खरीद की पहचान तय करती है।
क्या हर प्रयास में नई कुंजी बनानी चाहिए?
नहीं। पहले प्रयास से पहले एक कुंजी सहेजें और बिना विवरण बदले वही दोहराएँ। नई खरीद की कुंजी नई होती है।
क्या request_id से status देख सकते हैं?
status को ऑर्डर ID चाहिए। मूल add को उसी कुंजी और पैरामीटर से दोहराकर ID पाएँ। परिणाम अनिश्चित रहे तो दूसरा ऑर्डर बनाने के बजाय जानकारी सहायता के लिए सहेजें।
आगे पढ़ें: API इंटीग्रेशन गाइड · वेबहुक और स्टेटस जाँच · त्रुटियों की जानकारी.
