उसी ऑर्डर को उसके मूल request_id और बिना बदले विवरण के फिर भेजें। कनेक्शन का समय समाप्त होने पर नई कुंजी न बनाएँ। NotPanel पर दोबारा प्रयास मूल ऑर्डर को replayed: true के साथ लौटाता है, या पहला प्रयास पहुँचा ही न हो तो ऑर्डर बना देता है।
ग्राहक ने एक खरीद की है। पैनल को भेजने के बाद जवाब खो जाए, तो अगला कदम उसी खरीद का परिणाम पता करना है। अनिश्चित जवाब दूसरी खरीद करने की अनुमति नहीं है।
टाइमआउट के बाद तीन संभावनाएँ रहती हैं
- अनुरोध पहुँचा ही नहीं और कोई ऑर्डर स्वीकार नहीं हुआ।
- ऑर्डर स्वीकार हुआ, लेकिन उसका जवाब खो गया।
- कनेक्शन टूटते समय अनुरोध पहुँच गया; उसी request_id से दोबारा प्रयास बताता है कि ऊपर के दो में से क्या हुआ।
टाइमआउट इन स्थितियों का अंतर नहीं बताता। खरीद बनाने वाले 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 का विकल्प नहीं। request_id से ऑर्डर खोजने के लिए order_details इस्तेमाल करें।
पूरा जवाब पढ़कर निर्णय लें
- टाइमआउट या अनिश्चित जवाब
- कुंजी और विवरण वही रखें। सीमित प्रयास करें, बीच में रुकें और Retry-After मानें। प्रयास खत्म होने पर रिकॉर्ड को अनसुलझा सहेजें।
- INTERNAL_ERROR, API_DISABLED या ORDER_PLACEMENT_PAUSED (retryable: true)
- इंतज़ार करें, Retry-After हो तो उसका पालन करें, फिर वही add उसी request_id से भेजें। आपको मूल ऑर्डर या केवल एक नया ऑर्डर मिलेगा। दूसरी कुंजी से नया ऑर्डर न बनाएँ।
- REQUEST_ID_CONFLICT
- सहेजे गए पैरामीटर जाँचें। मूल ऑर्डर के लिए मूल विवरण वापस भेजें; नई कुंजी केवल जानबूझकर अलग खरीद के लिए है।
- गलत विवरण, पहचान या अनुरोध सीमा की त्रुटि
- error_code और retryable पढ़ें। फ़ील्ड या कुंजी सुधारें और सीमा की प्रतीक्षा मानें। हर त्रुटि को अपने-आप दोहराना सही नहीं है।
ग्राहकों की खरीद से पहले रिकवरी जाँचें
अपने टेस्ट वातावरण में नकली API से शुरुआत करें। वास्तविक खरीद या किसी विशेष NotPanel टेस्ट कुंजी की ज़रूरत नहीं है।
- स्वीकार ऑर्डर के बाद जवाब खोने की स्थिति बनाएँ; वही कुंजी और विवरण दोबारा जाना चाहिए।
- क्लाइंट दोबारा शुरू करें और सहेजी हुई पहचान वापस पाएँ।
- पहले दोबारा प्रयास योग्य 500 या 503 लौटाएँ, फिर replayed: true वाला जवाब; केवल एक ऑर्डर ID सहेजी जाए।
- कुंजी टकराव या दोबारा प्रयास न करने वाली त्रुटि दें; स्वचालित प्रयास रुकने चाहिए।
- दो नई समान खरीद को अलग कुंजी दें। बाद में वास्तविक टेस्ट करें तो इच्छित ऑर्डर ही करें और ऑर्डर व वॉलेट के रिकॉर्ड जाँचें।
अक्सर पूछे जाने वाले सवाल
क्या टाइमआउट का मतलब दो बार पैसे कटना है?
नहीं। इसका मतलब ऐप को उपयोगी जवाब नहीं मिला। डुप्लिकेट शुल्क मानने से पहले मिले ऑर्डर और वॉलेट के रिकॉर्ड जाँचें।
क्या request_id अनिवार्य है?
नहीं। request_id और idempotency_key वैकल्पिक हैं। इनके बिना उसी खाते के समान add को 60 सेकंड सुरक्षा मिलती है। स्पष्ट कुंजी हर खरीद की पहचान तय करती है।
क्या हर प्रयास में नई कुंजी बनानी चाहिए?
नहीं। पहले प्रयास से पहले एक कुंजी सहेजें और बिना विवरण बदले वही दोहराएँ। नई खरीद की कुंजी नई होती है।
क्या request_id से ऑर्डर खोज सकते हैं?
हाँ, order_details से: उसी request_id के साथ action=order_details भेजें और add दोहराए बिना ऑर्डर व उसका नंबर पाएँ। कोई ऑर्डर नहीं बना हो तो ORDER_NOT_FOUND मिलता है। status action को अब भी ऑर्डर नंबर चाहिए।
आगे पढ़ें: API इंटीग्रेशन गाइड · वेबहुक और स्टेटस जाँच · त्रुटियों की जानकारी.
