देर से आने वाले क्रिप्टो भुगतान वेबहुक कैसे ठीक करें

देर से आने वाले क्रिप्टो भुगतान वेबहुक को कैसे ठीक करें

देर से आने वाला वेबहुक परेशान करता है, क्योंकि देखने में समस्या आसान लगती है, लेकिन अक्सर होती नहीं। भुगतान सही हो सकता है, वेबहुक भी सही हो सकता है, फिर भी आपका ऐप 12 मिनट तक “इंतज़ार हो रहा है” दिखा सकता है। क्रिप्टो भुगतान वेबहुक में देरी कैसे ठीक करें, यह समझने के लिए अंदाज़ों की नहीं, टाइमस्टैम्प की ज़रूरत है।

सबसे पहले, उसी इवेंट के चार समय मिलाकर देखें: इवेंट बनने का समय, प्रोवाइडर के भेजने का समय, आपके सर्वर पर पहुँचने का समय और आपके ऐप्लिकेशन में प्रोसेस होने का समय। अगर आप सिर्फ़ आख़िरी समय देखते हैं, तो असल में कुछ नहीं देख रहे। मान लीजिए इवेंट 10:01 पर बना, 10:02 पर भेजा गया, 10:02:04 पर पहुँचा और 10:08 पर प्रोसेस हुआ—तो देरी प्रोवाइडर की डिलीवरी में नहीं, आपकी तरफ़ है।

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

अगर आप सेटअप के उन विकल्पों के बारे में भी जानना चाहते हैं जो डिलीवरी के व्यवहार को प्रभावित करते हैं, तो हमारी ई-कॉमर्स के लिए क्रिप्टो पेमेंट गेटवे गाइड में बिना तकनीकी उलझनों में पड़े गेटवे से जुड़ी जानकारी मिल जाएगी।

1. दोनों तरफ़ के टाइमस्टैम्प देखकर पक्का करें कि वेबहुक सचमुच देर से आया है

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

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

सिर्फ़ “प्राप्त होने का समय” देखकर फ़ैसला न करें। कोई अनुरोध आपके इंफ़्रास्ट्रक्चर के किनारे पर 14:20 पर पहुँच सकता है, लेकिन कोड चलने से पहले 14:27 तक क्यू में पड़ा रह सकता है। यह प्रोवाइडर की तरफ़ से देर से आया वेबहुक नहीं है। देरी आपके अपने सिस्टम में है।

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

2. जाँचें कि देरी प्रोवाइडर की नहीं, आपके एंडपॉइंट की क्यू की वजह से तो नहीं

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

ऐसे चेकआउट एंडपॉइंट के बारे में सोचें जो 200 का जवाब देने से पहले इन्वेंट्री की पुष्टि करता हो, एनालिटिक्स लिखता हो, ईमेल भेजता हो और वॉलेट बैलेंस अपडेट करता हो। सामान्य लोड में यह डिज़ाइन काम कर सकता है। ज़्यादा लोड में इससे कतार लग जाती है। वेबहुक दरवाज़े पर देर से नहीं पहुँचा—वह आपके गलियारे में इंतज़ार कर रहा है।

देखें कि HTTP अनुरोध कितनी देर खुला रहता है। अगर प्रोवाइडर ने 09:12 पर वेबहुक भेजा और आपका ऐप 09:19 पर “प्रोसेस हुआ” लॉग करता है, तो अनुरोध के पूरे रास्ते की जाँच करें। रिवर्स प्रॉक्सी बॉडी को बफ़र कर रही हो सकती है। कोई वर्कर दूसरे जॉब में अटका हो सकता है। सर्वरलेस फ़ंक्शन को शुरू होने में 4 सेकंड लगे हों। इन समयों से वजह का पता चलता है।

छोटे हैंडलर मददगार हैं। जितने छोटे, उतना बेहतर। 200 मिलीसेकंड से कम में जवाब देने वाले अनुरोध को दूसरी क्यू में डालना आसान है। लेकिन जवाब देने से पहले 8 काम करने वाला हैंडलर ऐसा नहीं है।

3. छिपी हुई देरी के लिए रीट्राई और टाइमआउट की सेटिंग जाँचें

कुछ “देर से आए” वेबहुक असल में रीट्राई की वजह से देर से दिखते हैं। अगर आपका एंडपॉइंट टाइमआउट हो जाए, 2xx के अलावा कोई स्टेटस लौटाए या कनेक्शन बंद करने में बहुत समय लगाए, तो प्रोवाइडर बाद में फिर से कोशिश कर सकता है। तब वही इवेंट दोबारा दिखाई देता है और बाद वाली कोशिश प्रोसेस होती है। इससे लगता है कि इवेंट देर से आया।

दोनों तरफ़ की टाइमआउट सेटिंग जाँचें। आपके ऐप में 15 सेकंड की अनुमति हो सकती है, जबकि प्रोवाइडर 5 सेकंड में जवाब चाहता हो। या आपका ऐप 12 सेकंड तक काम करता रहे, लेकिन प्रॉक्सी 10 सेकंड में कनेक्शन काट दे। ऐसी बेमेल सीमाओं से टाइमिंग की गड़बड़ियाँ बेतरतीब लगती हैं। लेकिन वे बेतरतीब नहीं होतीं। इसलिए वेबहुक रीट्राई और टाइमआउट कैसे जाँचें, यह जानने के लिए ऐप, प्रॉक्सी और प्रोवाइडर—तीनों की सेटिंग और लॉग की तुलना करें।

देर से आए किसी एक इवेंट के रिस्पॉन्स कोड देखें। 500, 502, 504 या 200 देने से पहले लंबे इंतज़ार की वजह से दूसरी डिलीवरी हो सकती है। अगर दूसरी डिलीवरी 6 मिनट बाद पहुँचती है, तो ऑर्डर अपडेट “देर से” दिखाई देगा, लेकिन मुमकिन है कि पहली डिलीवरी चुपचाप विफल हो गई हो।

अगर आपकी टीम इन मुश्किल स्थितियों की जाँच कर रही है, तो प्रोडक्शन में बदलाव करने से पहले क्रिप्टो भुगतान का परीक्षण कैसे करें लेख भी पढ़ें।

4. डिलीवरी के रास्ते में नेटवर्क और इंफ़्रास्ट्रक्चर की देरी जाँचें

सिर्फ़ अपने कोड को नहीं, पूरे रास्ते को मापें। DNS लुकअप, TLS हैंडशेक, CDN का व्यवहार, WAF की जाँच, प्रॉक्सी के पड़ाव और अलग-अलग क्षेत्रों के बीच की दूरी—ये सभी वेबहुक के हैंडलर तक पहुँचने से पहले देरी बढ़ा सकते हैं। एक पड़ाव से शायद ज़्यादा फ़र्क़ न पड़े, लेकिन पाँच पड़ाव डाल सकते हैं।

अगर प्रोवाइडर एक क्षेत्र में है और ऐप दूसरे में, तो हर अनुरोध में 90 मिलीसेकंड, 200 मिलीसेकंड या उससे भी ज़्यादा का अंतर हो सकता है। यह कम लगता है—जब तक कि ट्रैफ़िक बढ़ने के दौरान वेबहुक न आए और नेटवर्क पथ पर दबाव न पड़ने लगे। तब 200 मिलीसेकंड, 2 सेकंड बन जाते हैं और 2 सेकंड से सपोर्ट टिकट बन जाता है।

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

एक सीधा परीक्षण मददगार होता है: प्रोवाइडर वाले ही क्षेत्र से एक ज्ञात अनुरोध भेजें और उसके पहुँचने के समय की तुलना प्रोडक्शन वेबहुक से करें। अगर टेस्ट अनुरोध 40 मिलीसेकंड में पहुँचता है, लेकिन वेबहुक को 2 सेकंड लगते हैं, तो शायद नेटवर्क पथ ही एकमात्र समस्या नहीं है। बाकी देरी आपके स्टैक के अंदर है।

5. इवेंट फ़ाइनल होने की देरी और वेबहुक डिलीवरी की देरी को अलग-अलग समझें

क्रिप्टो भुगतान सिस्टम अक्सर वेबहुक भेजने से पहले कन्फ़र्मेशन का इंतज़ार करते हैं। ऐसा जान-बूझकर किया जाता है। भुगतान ब्लॉकचेन पर दिखाई दे सकता है, लेकिन उसे फ़ाइनल मानना अभी सुरक्षित न हो। रीऑर्ग का जोखिम, इंटरनल सेटलमेंट के चरण और नीतिगत जाँच—इन सबकी वजह से वेबहुक जान-बूझकर देर से भेजा जा सकता है।

यहीं टीमें दो तरह की देरी को एक समझ लेती हैं। हो सकता है भुगतान 15:00 बजे ब्लॉकचेन पर पहुँचा हो, लेकिन फ़ाइनल स्टेटस भेजने से पहले प्रोवाइडर 1, 2 या 6 कन्फ़र्मेशन का इंतज़ार करे। ऐसे में वेबहुक देर से नहीं आया। वह ठीक वही कर रहा है जो बिज़नेस का नियम कहता है।

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

अगर मर्चेंट अलग-अलग इम्प्लिमेंटेशन विकल्पों की तुलना कर रहे हैं, तो फ़्रीलांसरों के लिए क्रिप्टो पेमेंट गेटवे यह समझने में भी मदद कर सकता है कि इनवॉइस और आंशिक अपडेट के लिए भुगतान की स्थिति कब बदलती है।

6. भुगतान प्लेटफ़ॉर्म में बैचिंग, डिबाउंस या एग्रीगेशन लॉजिक जाँचें

कुछ प्लेटफ़ॉर्म जान-बूझकर इवेंट रोककर रखते हैं। वे स्टेटस में हुए बदलावों को बैच करते हैं, बार-बार आने वाले अपडेट को कुछ देर रोकते हैं या कई छोटे संकेतों को मिलाकर एक साफ़-सुथरा वेबहुक भेजते हैं। यह अच्छा डिज़ाइन हो सकता है। लेकिन इसकी वजह से भी वेबहुक मूल इवेंट के 4 मिनट बाद आ सकता है।

“सिर्फ़ फ़ाइनल स्टेटस भेजें,” “30 सेकंड के अंतराल में हुए बदलावों को एक साथ भेजें” या “चेन और इंटरनल लेजर—दोनों के सहमत होने तक इंतज़ार करें” जैसे नियम ढूँढ़ें। इन नीतियों से अनावश्यक संदेश कम होते हैं, लेकिन जान-बूझकर देरी भी होती है। अगर आपका ऐप तुरंत, हर इवेंट के लिए अपडेट की उम्मीद करता है, तो नीति टूटी हुई लगेगी—भले ही वह ठीक काम कर रही हो।

यह न मानें कि ज़्यादा वेबहुक हमेशा बेहतर होते हैं। एक भुगतान के लिए 6 अपडेट भेजने वाला प्लेटफ़ॉर्म अनावश्यक शोर पैदा कर सकता है। जानकारी को समेटकर 1 अपडेट भेजने वाला प्लेटफ़ॉर्म देरी कर सकता है। सही विकल्प इस बात पर निर्भर करता है कि आपके ऑर्डर फ़्लो को क्या चाहिए और फ़ुलफ़िलमेंट से पहले आप कितनी अनिश्चितता बर्दाश्त कर सकते हैं।

अगर आपको भुगतान के लिए मापन का कोई तरीका चाहिए, तो क्रिप्टो भुगतान की सफलता कैसे मापें लेख काम आएगा, क्योंकि देरी और सफलता के मेट्रिक्स अक्सर एक ही इवेंट ट्रेल का इस्तेमाल करते हैं।

7. देरी कहाँ से शुरू होती है, यह पता लगाने के लिए ऑब्ज़र्वेबिलिटी जोड़ें

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

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

रीट्राई के साथ इवेंट ID को भी ट्रैक करें। दो बार आया देर से आने वाला वेबहुक बता सकता है कि पहली कोशिश स्वीकार हुई, अस्वीकार हुई या आपके इंफ़्रास्ट्रक्चर की वजह से बस देर हुई। यह तब काम आता है जब प्रोवाइडर कहता है कि इवेंट “डिलीवर” हो गया था, क्योंकि डिलीवर होने और प्रोसेस होने में फ़र्क़ है।

वेबहुक मिलने और प्रोसेस होने के बीच के अंतर के लिए एक अलर्ट रखें। एक सिस्टम में 10 सेकंड का अंतर सामान्य हो सकता है और दूसरे में बड़ी समस्या। सीमा अपने SLA के हिसाब से तय करें, किसी और के ब्लॉग पोस्ट के हिसाब से नहीं।

एक छोटी-सी बात: टाइमज़ोन के बिना टाइमस्टैम्प जाल बन सकता है। देखने में साफ़-सुथरा लगता है, लेकिन बाद में परेशानी देता है।

8. देर से आने वाले भुगतान स्टेटस अपडेट के लिए सुरक्षित वैकल्पिक व्यवस्था रखें

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

एक वैकल्पिक रास्ता चुनें और उसकी समय-सीमा तय करें। उदाहरण के लिए, अगर 5 मिनट बाद भी भुगतान का वेबहुक न आए, तो उसे रिकन्सिलिएशन के लिए चिह्नित करें। तय समय तक सेटलमेंट अपडेट न मिले, तो प्रोवाइडर या चेन की स्थिति पोल करें। अगर भुगतान की पुष्टि फिर भी न हो, तो उसे मैन्युअल समीक्षा के लिए भेजें। यह क्रम आसान है, और यहाँ आसान होना अच्छी बात है।

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

अगर आपकी टीम मैन्युअल कामकाज से भी दूर जा रही है, तो मैन्युअल क्रिप्टो भुगतान से कैसे माइग्रेट करें लेख बताता है कि जब भुगतान की स्थिति सामान्य वर्कफ़्लो की अपेक्षा से देर से आए, तब वैकल्पिक व्यवस्था क्यों ज़रूरी होती है।

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

एक आख़िरी बात: स्टेजिंग में ऐसा टेस्ट इवेंट रखें जिसका इवेंट ID पहले से पता हो और ऑर्डर ID तय हो। प्रॉक्सी, क्यू या रीट्राई सेटिंग में हर बदलाव के बाद इसे चलाएँ। एक टेस्ट उस देरी को पकड़ सकता है जो नहीं तो हफ़्तों तक छिपी रहती।