वेबहुक दो बार आया। फिर भी ऑर्डर एक ही बार पूरा क्यों होना चाहिए

HTTP 200 भेजा जा चुका है, लेकिन बैलेंस में क्रेडिट नहीं है। वेबहुक इवेंट के लॉग में «सफल» लिखा है, कस्टमर सामान का इंतज़ार कर रहा है, और प्रोवाइडर अब तुरंत डिलीवरी दोहराने के लिए बाध्य नहीं है। ऐसी खराबी दो घटनाओं के जोड़ पर पैदा होती है: संदेश ले लिया गया, लेकिन बिज़नेस कार्रवाई पूरी नहीं हुई। वेबहुक को दस लाइन का हैंडलर लिखने से नहीं, बल्कि इसी सीमा से समझना ज़्यादा उपयोगी है।

पहले तय कीजिए कि किस सिस्टम पर भरोसा करना है

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

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

इवेंट लेने और कार्रवाई करने को अलग कीजिए

प्रस्तावित योजना संबंधित API के नियमों के अनुसार असलियत की जाँच से शुरू होती है। फिर इवेंट को इनकमिंग लॉग में दर्ज किया जाता है, और बिज़नेस प्रोसेसिंग अलग से होती है। संदेश को भरोसेमंद तरीके से सहेजने के बाद, कॉन्ट्रैक्ट में तय समय के भीतर प्राप्ति की पुष्टि भेजिए। अगर रिकॉर्ड नहीं बन पाया, तो सिस्टम को यह दिखावा नहीं करना चाहिए कि इवेंट ले लिया गया है। लंबा डिस्पैच, खरीदार को ईमेल या रिपोर्ट का अपडेट इस छोटे रास्ते में शामिल करना ठीक नहीं।

असलियत की जाँच भी प्रोवाइडर पर निर्भर करती है। PayPal नोटिफ़िकेशन के सिग्नेचर की जाँच का वर्णन करता है; खुद जाँच करते समय बॉडी के मूल बाइट्स अहम होते हैं। इसलिए पहले से जाँच लीजिए कि ऐप्लिकेशन का कोई बीच का हैंडलर जाँच से पहले मूल डेटा तो नहीं बदल देता। संबंधित डॉक्यूमेंटेशन पढ़े बिना एक सर्विस की शर्तें दूसरी पर लागू मत कीजिए।

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

डिलीवरी का दोहराव और बिज़नेस कार्रवाई का दोहराव अलग हैं

इवेंट आईडी की जाँच उसी डिलीवरी के दोहराव को रोक देगी। इसके अलावा कार्रवाई को भी सुरक्षित कीजिए: «पेमेंट ट्रांज़ैक्शन + क्रेडिट» की जोड़ी के लिए एक्ज़ीक्यूशन का सिर्फ़ एक अनुमत रिकॉर्ड होना चाहिए। यह सुरक्षा की अलग परत है, क्योंकि अलग-अलग संदेश एक ही बिज़नेस नतीजे का वर्णन कर सकते हैं। पूरी हुई कार्रवाई के रिकॉर्ड और अंदरूनी बैलेंस के बदलाव को एक सुसंगत ऑपरेशन की तरह डिज़ाइन कीजिए; वरना दोनों के बीच की विफलता दोहरे क्रेडिट की गुंजाइश छोड़ देगी।

डीडुप्लिकेशन की key अंदाज़े से मत चुनिए। Adyen एक जैसे eventCode और pspReference वाले दोहराव का वर्णन करता है, हालाँकि दूसरे फ़ील्ड अलग हो सकते हैं। यानी पूरे JSON का सार्वभौमिक हैश किसी खास फ़ॉर्मेट के नियमों की जगह नहीं लेता। साथ ही, बहुत व्यापक key किसी जायज़ बाद वाले इवेंट को छिपा सकती है, जैसे अलग आंशिक रिफ़ंड।

एक पेमेंट को अंत तक देखिए

एक काल्पनिक उदाहरण में ऑर्डर M-418 की कीमत 72 यूरो है। पुष्ट पेमेंट का इवेंट सबसे पहले सहेजा जाता है। वर्कफ़्लो ऑर्डर ढूँढता है, रकम, करेंसी और अकाउंट मिलाता है, पेमेंट अपडेट करता है और डिस्पैच का एक जॉब बनाता है। प्रोसेसिंग का देर से आया नोटिफ़िकेशन इतिहास में रहता है, लेकिन ऑर्डर को पीछे नहीं ले जाता। पेमेंट का दूसरा कन्फ़र्मेशन एक और डिस्पैच नहीं बनाता। रिफ़ंड का इवेंट अपनी आईडी और नियमों के अनुसार प्रोसेस होता है, इसलिए नहीं फेंका जाता कि ऑर्डर पहले ही पेड है।

अगर संदेश एक-दूसरे का खंडन करते हैं, तो ट्रांज़ैक्शन को रिव्यू में डालिए और अनुमत तरीके से मौजूदा डेटा माँगिए। जिस मेथड में उपयुक्त ऑनलाइन क्वेरी नहीं है, उसके लिए तय रिपोर्ट और प्रोवाइडर के पास एस्केलेशन इस्तेमाल कीजिए। नए वेबहुक का न आना अपने आप में डिक्लाइन का सबूत नहीं है।

लाल कतार से बाहर निकलने का रास्ता होना चाहिए

एरर की अलग कतार तभी तक उपयोगी है जब तक उससे इवेंट को सुरक्षित तरीके से काम में वापस लाया जा सके। प्रस्तावित प्रक्रिया में रिकॉर्ड में रुकने की वजह होती है: अज्ञात ऑर्डर, रकम का टकराव, असमर्थित प्रकार या तकनीकी गलती। पहली तीन वजहों के लिए फैसला चाहिए, आखिरी दोबारा कोशिश से सुलझ सकती है। «सब दोबारा चलाओ» वाला एक बटन यह फ़र्क मिटा देता है और रिकवरी को नए इंसिडेंट में बदल देता है।

दोबारा प्रोसेसिंग से पहले ऑपरेटर को दिखाइए कि क्या पहले ही हो चुका है: क्रेडिट, डिस्पैच, रिफ़ंड, कस्टमर को नोटिफ़िकेशन। दोहराना सिर्फ़ छूटा हुआ अनुमत कदम है। अगर पार्सर ठीक करने के बाद पूरा बिज़नेस सीनेरियो फिर से चलाया जाए, तो इवेंट का आइडेम्पोटेंट रिसेप्शन ईमेल भेजने या डिलीवरी बनाने के आइडेम्पोटेंट होने की गारंटी नहीं देता। साइड इफ़ेक्ट को अलग से टेस्ट कीजिए, कोड अपडेट के बाद भी।

सुंदर प्रतिशत से उम्र ज़्यादा अहम है

एक काल्पनिक कतार में 900 ताज़ा इवेंट हैं और एक संदेश कल से अटका है। औसत प्रोसेसिंग समय ठीक दिख सकता है, जबकि एक खरीदार बिना नतीजे के बैठा है। ट्रांज़ैक्शन के प्रकार के हिसाब से सबसे पुराने अनप्रोसेस्ड इवेंट की उम्र और बिना मालिक वाले इवेंट की संख्या पर नज़र रखिए। रिफ़ंड, सामान जारी करने और सूचना वाले नोटिफ़िकेशन के लिए स्वीकार्य देरी अलग हो सकती है।

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

एरर की कतार से कल का एक इवेंट चुनिए। अगर कर्मचारी सुरक्षित तरीके से सिर्फ़ छूटी हुई कार्रवाई पूरी कर सकता है और दिखा सकता है कि बाकी क्यों नहीं दोहराई जाएँगी, तो रिकवरी का रास्ता सच में मौजूद है। अगर उसे ऑर्डर का स्टेटस हाथ से बदलना पड़ता है, तो वेबहुक हैंडलर अब भी काम को सिस्टम के अंदाज़ों पर छोड़ रहा है।