प्राप्ति और पूरा प्रसंस्करण अलग रखें
गारंटी प्रदाता पर निर्भर है। Stripe संभावित डुप्लिकेट और क्रम की गारंटी न होने का उल्लेख करता है। सफल HTTP उत्तर टिकाऊ प्राप्ति या निर्धारित प्रसंस्करण से जुड़ा हो, केवल मेमोरी में अनुरोध आने से नहीं।
| स्थिति | अपेक्षित व्यवहार | उपयोगी प्रमाण |
|---|---|---|
| एक घटना दो बार मिली | दोहरा व्यावसायिक प्रभाव रोकें। | प्रसंस्कृत ID और स्थायी परिणाम। |
| पुरानी घटना बाद में आई | नई स्थिति को अंधाधुंध न बदलें। | प्रामाणिक स्थिति और संक्रमण नियम। |
| भारी प्रसंस्करण | टिकाऊ प्राप्ति के बाद स्थगित काम। | कतार स्थिति और वर्कर परिणाम। |
| डिलीवरी गायब | प्रदाता नियमों से मिलान और पुनर्प्राप्ति। | पहचाना अंतर और सत्यापित सुधार। |
सत्यापनीय प्राप्ति बनाएँ
- प्रदाता के प्रोटोकॉल के अनुसार HTTPS, हस्ताक्षर और रीप्ले सुरक्षा जाँचें। Stripe मूल बॉडी पर हस्ताक्षर सत्यापित करता है; पहले JSON बदलने से सत्यापन बिगड़ सकता है।
- उचित पावती से पहले घटना या प्रसंस्करण को टिकाऊ रूप से दर्ज करें। डिलीवरी ID, घटना ID और कार्रवाई की इडेम्पोटेंसी कुंजी अलग पहचानें।
- डुप्लिकेट, गलत क्रम, वर्कर रुकना और पुनः शुरू होना जाँचें। पुरानी घटना सुरक्षित निर्णय न दे तो ऑब्जेक्ट की प्रामाणिक स्थिति पढ़ें।
पुनर्प्राप्ति और मिलान की व्यवस्था करें
प्रयास, समय, अप्रसंस्कृत घटनाएँ और प्रदाता से मिलान लिखें। तेज पावती बाद की विफलता छिपा सकती है। अंतिम व्यावसायिक कार्रवाई भी देखें और लॉग में गोपनीय व व्यक्तिगत डेटा सीमित रखें।
प्राथमिक स्रोत
बार-बार होने वाले वेबहुक को सुरक्षित रूप से हैंडल करें।
टाइमआउट या जवाब न मिलने के बाद भी कोई नोटिफ़िकेशन दोहराया जा सकता है। भरोसा ओरिजिन वेरिफ़िकेशन, एक इवेंट आइडेंटिफ़ायर और प्रोसेसिंग पर निर्भर करता है जो एक नए मैसेज को डुप्लीकेट से अलग करता है।
- प्रोवाइडर के मैकेनिज़्म का इस्तेमाल करके हर रिक्वेस्ट को वेरिफ़ाई करें।
- रीट्राई, डुप्लीकेट और बदले हुए अराइवल ऑर्डर को टेस्ट करें।
- प्रोसेसिंग या ड्यूरेबल क्यूइंग के बाद लगातार एक्नॉलेज करें।
प्राथमिक स्रोत: IETF RFC 9457 — Problem Details for HTTP APIs. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.