भुगतान प्रणालियों में वेबहुक विश्वसनीयता (Webhook Reliability In Payment Systems)

वेबहुक कोई गारंटीशुदा संदेश नहीं है

आपका PSP आपको जो वेबहुक भेजता है वह यह गारंटी नहीं देता है कि "यह घटना ठीक एक बार और सही क्रम में होगी"। बल्कि, यह चार अलग-अलग तरीकों से टूट सकता है: एक ही घटना एक से अधिक बार आ सकती है, एक घटना बिल्कुल नहीं आ सकती है, घटनाएँ जिस क्रम में भेजी गई थीं उससे भिन्न क्रम में आ सकती हैं, और एक घटना मिनटों की देरी से आ सकती है।```text PSP → Webhook ⚠ Duplicate: aynı olay iki kez ⚠ Missing: olay hiç gelmez ⚠ Out-of-order: capture bildirimi, authorize bildiriminden önce gelir ⚠ Delayed: olay dakikalar sonra ulaşır

## पहले उल्लेख पर अवधारणाएँ```text
📦 Webhook
Bir dış sistemin (PSP), kendi tarafında gerçekleşen bir olayı bildirmek için sizin uç noktanıza yaptığı HTTP çağrısı.

📦 Signature Verification
Gelen webhook'un gerçekten PSP'den geldiğini, içeriğin değiştirilmediğini doğrulayan kriptografik kontrol.

📦 At-least-once Delivery
Bir olayın en az bir kez, bazen daha fazla kez teslim edileceğini garanti eden; ama sıra veya tekrar sayısı garantisi vermeyen teslimat modeli.

📦 ACK (Acknowledgement)
Webhook alıcısının, olayı aldığını PSP'ye bildiren hızlı HTTP cevabı (genellikle 200).

📦 Durable Write
İşlemin sonucu ne olursa olsun, olayın kalıcı depoya yazılmış olması; bellek içinde kalan bir kayıt değildir.
```ये सभी अवधारणाएँ एक नियम को पूरा करती हैं: आपके वेबहुक हैंडलर को पहले आने वाली किसी भी घटना को सुरक्षित रूप से रिकॉर्ड करना होगा, और उसके बाद ही भारी सामान उठाना होगा।

## डुप्लिकेट: एक ही घटना दो बार घटित होती है

यदि पीएसपी को आपसे समय पर 200 प्रतिक्रिया (नेटवर्क समस्या, सर्वर धीमापन) नहीं मिलती है, तो यह उसी घटना को फिर से भेजेगा। यह व्यवहार कोई बग नहीं है, बल्कि पीएसपी की कम से कम एक बार की गारंटी का स्वाभाविक परिणाम है। इवेंट आईडी + इनबॉक्स पैटर्न, जिसे हमने पांचवें खंड में विस्तृत किया है, यहां रक्षा की पहली पंक्ति है।```text
Webhook #1: evt_001 → işlenir
Webhook #2: evt_001 (tekrar) → inbox'ta zaten var, işlem atlanır, 200 döner
```## गुम: घटना कभी नहीं आती

कभी-कभी वेबहुक बिल्कुल नहीं आता है: नेटवर्क आउटेज, पीएसपी पक्ष पर एक त्रुटि, या आपका एंडपॉइंट अस्थायी रूप से पहुंच योग्य नहीं है। एक प्रणाली जो पूरी तरह से वेबहुक पर निर्भर करती है वह हमेशा के लिए "पता नहीं" स्थिति में रहेगी। इसीलिए वेबहुक प्राथमिक सूचना चैनल होना चाहिए, सत्य का एकमात्र स्रोत नहीं; पीएसपी की स्थिति क्वेरी एपीआई के साथ आवधिक समाधान हमेशा एक द्वितीयक सुरक्षा जाल के रूप में कार्य करना चाहिए।```text
Webhook (birincil, hızlı)
  + Periyodik durum sorgusu (ikincil, yavaş ama garantili)
  = webhook kaybolsa bile gerçek er ya da geç yakalanır
```## अव्यवस्थित: घटनाएँ अव्यवस्थित हो जाती हैं

नेटवर्क परत इस बात की गारंटी नहीं देती कि ईवेंट उसी क्रम में आएंगे जिस क्रम में उन्हें भेजा गया था। उदाहरण के लिए, एक "कैप्चर" अधिसूचना उस "अधिकृत" अधिसूचना से पहले आ सकती है जिसके पहले आने की उम्मीद है। यदि आपका हैंडलर इवेंट द्वारा किए गए टाइमस्टैम्प या संस्करण संख्या की जांच किए बिना राज्य मशीन को अपडेट करता है, तो यह वह जगह है जहां हमने दूसरे भाग में वर्णित गार्ड को काम में आना चाहिए।```text
Gelen: payment.captured (t=2)
Gelen: payment.authorized (t=1, ama sonra ulaştı)
  → guard: t=1 olayı, zaten t=2'ye ulaşmış bir state'i geriye alamaz, sessizce reddedilir
```## विलंबित: घटना विलंब से आती है

पीएसपी की ओर से कतार में लगने या आपकी ओर से प्रसंस्करण में देरी के कारण वेबहुक को आने में कुछ मिनट लग सकते हैं। इस मामले में, आपके हैंडलर को "अभी" और "घटना घटित होने के क्षण" के बीच अंतर करना होगा; यदि व्यावसायिक निर्णय अपने स्वयं के टाइमस्टैम्प के बजाय घटना के संसाधित होने के क्षण के आधार पर किए जाते हैं, तो अनुक्रमण त्रुटियाँ बढ़ जाती हैं।

## आपको हेवी ड्यूटी को समकालिक रूप से क्यों नहीं चलाना चाहिए

हस्ताक्षर सत्यापन, न्यूनतम सत्यापन और टिकाऊ लेखन के अलावा आपके वेबहुक हैंडलर पर कोई भारी काम नहीं किया जाना चाहिए। स्टॉक में कमी, वित्तीय रिकॉर्डिंग और सूचनाएं भेजने जैसे कदमों को एक अलग पृष्ठभूमि कार्य में स्थानांतरित किया जाना चाहिए।```text
Webhook Handler (hızlı, senkron)
  1. İmzayı doğrula
  2. Minimal şema kontrolü yap
  3. Olayı inbox'a yaz (durable)
  4. 200 OK döndür

Arka plan Job (yavaş, asenkron)
  5. İnbox'taki olayı oku
  6. Gerçek iş kararlarını uygula (stok, finans, bildirim)
```यह अंतर दो कारणों से महत्वपूर्ण है: पहला, पीएसपी आमतौर पर वेबहुक प्रतिक्रिया के लिए एक छोटा टाइमआउट (कुछ सेकंड) लगाता है; यदि हेवी ड्यूटी इस समय से अधिक हो जाती है, तो PSP अनुरोध को असफल मानता है और इसे दोबारा भेजता है, जिससे डुप्लिकेट की संख्या बढ़ जाती है। दूसरा, हेवी ड्यूटी का समकालिक संचालन आपके वेबहुक हैंडलर को बाहरी सिस्टम के प्रदर्शन पर निर्भर बनाता है (यदि स्टॉक सेवा धीमी है); यह निर्भरता वेबहुक के समयबाह्य का कारण भी बन सकती है।

## इस एपिसोड में सबसे भ्रमित करने वाला मैचअप```text
❌ Webhook, tek ve güvenilir gerçek kaynağıdır
✓ Webhook birincil bildirim kanalıdır; periyodik durum sorgusu ikincil güvenlik ağıdır

❌ 200 dönmek, işin tamamlandığı anlamına gelir
✓ 200, olayın güvenle alındığı anlamına gelir; işin tamamlanması ayrı bir asenkron adımdır

❌ Webhook'lar her zaman gönderildiği sırayla ulaşır
✓ Sıralama garanti edilmez; guard'lar olmadan state machine geriye kayabilir

❌ İmza doğrulaması opsiyoneldir, IP allowlist yeterlidir
✓ İmza doğrulaması, sahte veya değiştirilmiş webhook'lara karşı asıl savunmadır

आपके वेबहुक हैंडलर के लिए चेकलिस्ट

1. क्या आपका वेबहुक हैंडलर प्रत्येक अनुरोध पर हस्ताक्षर सत्यापन करता है, या यह केवल आईपी अनुमति सूची पर निर्भर करता है?
2. इनबॉक्स में ईवेंट लिखने से पहले हैंडलर कौन से भारी कार्य समकालिक रूप से चलाता है?
3. यदि वेबहुक कभी नहीं आता है, तो आपके सिस्टम को नोटिस करने में कितने घंटे/दिन लगेंगे? क्या आपके पास सुलह का काम है?
4. क्या दो वेबहुक अव्यवस्थित होकर आपकी राज्य मशीन को अमान्य स्थिति में डाल सकते हैं? क्या आपने अपने गार्डों का परीक्षण किया है?
5. पीएसपी का वेबहुक टाइमआउट क्या है और आपका हैंडलर इसका कितना उपयोग कर रहा है?

यदि आप इन पाँच प्रश्नों में से किसी का उत्तर "नहीं, हमने जाँच नहीं किया" है, तो आपकी वेबहुक विश्वसनीयता संभवतः एक अप्रयुक्त धारणा पर आधारित है।

इस अनुभाग से याद रखने योग्य बातें

1. वेबहुक डुप्लिकेट, गायब, ऑर्डर से बाहर और विलंबित हो सकते हैं; आपके हैंडलर को इन चारों को धारणा के रूप में लेना चाहिए।
2. हस्ताक्षर सत्यापन धोखाधड़ी वाले वेबहुक के खिलाफ सुरक्षा की मुख्य पंक्ति है; आईपी ​​अनुमति सूची पर्याप्त नहीं है.
3. हैंडलर को भारी सामान उठाने का कार्य अतुल्यकालिक कार्य को सौंपते हुए तेजी से एसीके जारी करना चाहिए; सिंक्रोनस हेवी वर्क से टाइमआउट और डुप्लिकेट दोनों का खतरा बढ़ जाता है।
4. वेबहुक प्राथमिक चैनल है लेकिन सत्य का एकमात्र स्रोत नहीं है; आवधिक स्थिति मतदान हमेशा एक द्वितीयक सुरक्षा जाल होना चाहिए।

वेबहुक पर "भविष्य" के रूप में भरोसा करना डिज़ाइन द्वारा नहीं है; यह डिज़ाइन करना कि "यह नहीं आ सकता है, यह फिर से आ सकता है, यह क्रम से बाहर हो सकता है" डिज़ाइन है।