सेंड API आइडेम्पोटेंसी: डुप्लिकेट, रिट्राई और पैसे

टाइमआउट होते हैं। लोड बैलेंसर रिट्राई करते हैं। मोबाइल क्लाइंट डबल-टैप करते हैं। आइडेम्पोटेंसी के बिना “एक बार भेजें” उत्पाद प्रीपेड डबल चार्ज और डुप्लिकेट OTP UX बन जाता है। यह गाइड व्हाइट-लेबल प्रीपेड मैसेजिंग API जोड़ने वाले इंजीनियरिंग और टेक्निकल प्रोडक्ट के लिए है — जहाँ हर डुप्लिकेट वॉलेट में दिखता है।.

IOSOR मनी-अवेयर इंटीग्रेशन चाहता है: प्रमाणित कॉल, मिलाए जा सकने वाले डेबिट, और विदेशी ब्रांड पेलोड न दिखाने वाली क्लाइंट त्रुटियाँ। करीब USD 1,000+ मासिक प्लेटफ़ॉर्म उपयोग पर डुप्लिकेट अनुशासन वैकल्पिक नहीं रहता। हर सेंड को पहले लेजर घटना, फिर नेटवर्क कॉल मानें ताकि वित्त और ऑन-कॉल एक कहानी साझा करें।.

डुप्लिकेट पैसे की समस्या क्यों बनते हैं

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

रिट्राई झेलने वाली आइडेम्पोटेंसी कुंजियाँ

गंभीर सेंड पथ क्लाइंट-जनित कुंजी (या समकक्ष) स्वीकार करता है जो:

1. बिज़नेस इंटेंट प्रति अद्वितीय हो (TCP प्रयास प्रति नहीं)
2. स्पष्ट TTL विंडो में रीप्ले पर वही स्वीकृत परिणाम लौटाए
3. उसी इंटेंट के लिए चुपचाप दूसरा डेबिट न बनाए
4. मैसेज ID और प्रीपेड संदर्भ के साथ लॉग हो
5. टाइमआउट, गेटवे रिट्राई और सपोर्ट रीड्राइव पर काम करे

अगर एकमात्र सलाह “टाइमआउट बढ़ाएँ” है, तो आपके पास आइडेम्पोटेंसी कहानी नहीं। कुंजियाँ रनटाइम और वर्कर में स्थिर हों ताकि दूसरी प्रोसेस उसी क्लिक के लिए नई कुंजी न गढ़े।.

रिट्राई बजट बनाम उपयोगकर्ता रीसेंड

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

दोनों को लो-बैलेंस स्टॉप और स्पष्ट रिजेक्ट कारणों से जोड़ें ताकि उत्पाद और वित्त एक सत्य साझा करें। प्रकाशित करें कौन से HTTP स्टेटस और प्लेटफ़ॉर्म कोड सुरक्षित रिट्राई हैं; बाकी हार्ड स्टॉप—मानव या नया बिज़नेस इंटेंट।.

खरीदार / इंजीनियरिंग चेकलिस्ट

1. आइडेम्पोटेंसी कुंजी अर्थ और TTL दस्तावेज़ीकृत।
2. एक इंटेंट पर एक डेबिट सिद्ध करने वाला रीप्ले टेस्ट।
3. ऑटो-रिट्राई बजट उपयोगकर्ता रीसेंड से अलग।
4. अनुरोध, मैसेज स्थिति और प्रीपेड लेजर पर सहसंबंध ID।
5. वास्तविक कॉरिडोर पर स्टेजिंग — मॉक हरा लॉन्च नहीं।
6. सेंड क्रेडेंशियल के लिए कुंजी स्वच्छता और न्यूनतम विशेषाधिकार।

आइडेम्पोटेंसी कुंजी के साथ सेंड लागू करें। क्लाइंट टाइमआउट और समान रिट्राई बाध्य करें। उस इंटेंट के लिए एकल डेबिट और एकल दृश्य संदेश सिद्ध करें। जानबूझकर उपयोगकर्ता रीसेंड जोड़ें और अलग प्रीपेड इकाई दिखाएँ।

लाल झंडे

• कुंजी के बिना “200 तक रिट्राई”
• गैर-आइडेम्पोटेंट webhook हैंडलर
• लॉग या टिकट में पूरी सीक्रेट कुंजियाँ
• एंड यूज़र पर ब्रांड पेलोड चिपकाने वाली त्रुटियाँ
• वित्त को यह सिद्ध करने का तरीका नहीं कि डुप्लिकेट रोका गया

अगर सेल्स डेक या रनबुक पेस्ट में कोई दिखे—इंजीनियरिंग सबूत से अंतर बंद करे तक इंटीग्रेशन रोकें।.

IOSOR से शुरू करें

भेजने वाले कंसोल में क्लाइंट-जनित आइडेम्पोटेंसी कुंजी से एक OTP या अलर्ट चलाएँ। क्लाइंट टाइमआउट थोपें, फिर कुंजी TTL के अंदर वही अनुरोध दोहराएँ।

एपीआई दर सीमाओं को कैसे संभालें? · ई164 एनएएनपी ओवरले का सही तरीका क्या है? · वेबहुक कुंजियों को कैसे सुरक्षित रखें?

IOSOR सार

करें: हर भेज को पहले ledger घटना मानें। कुंजी व्यापार इरादे पर अद्वितीय है, TCP प्रयास पर नहीं। ऑटो-रीट्राई का बजट है; उपयोगकर्ता का पुनः-भेज टैप अलग उत्पाद क्रिया है, अपनी prepaid लागत के साथ।