भुगतान त्रुटि वर्गीकरण (Payment Failure Taxonomy)

पिछले अनुभाग में, हमने देखा कि PaymentFailed जैसी सिमेंटिक घटनाएं प्रदाता के स्थिति कोड को छुपाती हैं। लेकिन एक PaymentFailed घटना भी पर्याप्त नहीं है; क्योंकि 'असफल' शब्द बहुत अलग वास्तविकताओं को शामिल करता है।

एक कार्ड अस्वीकृति, एक नेटवर्क टाइमआउट, 429 लौटाने वाला पीएसपी और 500 लौटाने वाला पीएसपी सभी 'विफलता' के रूप में दिखाई दे सकते हैं; लेकिन प्रत्येक को पूरी तरह से अलग कार्रवाई की आवश्यकता होती है। यह अध्याय एक वर्गीकरण के निर्माण पर चर्चा करता है जो इन अंतरों को दृश्यमान बनाता है।```text PaymentFailed ├─ Business Decline (kart reddedildi — retry etme) ├─ Timeout (belirsiz sonuç — dikkatli retry) ├─ Rate Limited (429) (çok istek — backoff ile retry) └─ Infrastructure (5xx) (provider tarafı arıza — retry)

## पहले उल्लेख पर अवधारणाएँ```text
📦 Business Decline
PSP'nin, kartın kendisiyle ilgili bir nedenle isteği reddetmesi: yetersiz bakiye, dolandırıcılık şüphesi.

📦 Transient Hata
Aynı isteğin tekrar denenmesi mantıklı olan, geçici bir arıza: timeout, 5xx, 429.

📦 Permanent Hata
Tekrar denemenin sonucu değiştirmeyeceği hata: geçersiz kart numarası, desteklenmeyen para birimi.

📦 Belirsiz Sonuç
İsteğin PSP'ye ulaşıp ulaşmadığının bilinmediği durum: bağlantı timeout'u.
```व्यवसाय में गिरावट की पुनः कोशिश करना समय की बर्बादी है; अनिश्चित परिणाम का पुनः प्रयास न करना भुगतान छूटने का वास्तविक जोखिम है। इन दो जोखिमों के बीच अंतर करने के लिए वर्गीकरण मौजूद है।

## चार बुनियादी श्रेणियां

**व्यापार में गिरावट**: पीएसपी ने अनुरोध प्राप्त किया, इसे संसाधित किया और अपना निर्णय लिया - कार्ड अस्वीकार कर दिया गया। यह कोई सिस्टम त्रुटि नहीं है, यह एक व्यावसायिक निर्णय है। दोबारा प्रयास करने से परिणाम नहीं बदलता; उपयोगकर्ता को कोई अन्य भुगतान विधि सुझाना आवश्यक है।

**समयबाह्य/अनिश्चित परिणाम**: अनुरोध भेजा गया था लेकिन प्रतिक्रिया कभी नहीं आई। यहां खतरा यह है - भुगतान पीएसपी की ओर से हुआ होगा, केवल प्रतिक्रिया आपके पास जाएगी। इस श्रेणी को अंधी 'पुनः प्रयास करें' के साथ संबोधित नहीं किया जा सकता है; सबसे पहले, स्थिति पर सवाल उठाया जाना चाहिए (निष्क्रियता कुंजी के साथ), फिर कोई निर्णय लिया जाना चाहिए।

**दर सीमित (429)**: पीएसपी अस्थायी रूप से आपको अनुरोध मात्रा को नियंत्रित करने से मना कर रहा है। ये कोई गलती नहीं, एक संकेत है. तुरंत दोबारा प्रयास करने से स्थिति और खराब हो जाएगी; बैकऑफ़ के साथ इंतज़ार करना ज़रूरी है.

**इंफ्रास्ट्रक्चर (5xx)**: पीएसपी की ओर से कोई खराबी है। यदि अनुरोध संसाधित नहीं किया गया है, तो आमतौर पर दोबारा प्रयास करना सुरक्षित होता है - लेकिन यदि 5xx लगातार प्राप्त होता है, तो यह एक सर्किट ब्रेकर सिग्नल है।```text
Hata alındı
  │
  ├─ PSP isteği net biçimde reddetti mi? → Business Decline → retry etme
  │
  ├─ Yanıt hiç gelmedi mi? → Belirsiz Sonuç → önce durumu sorgula
  │
  ├─ 429 mu? → Rate Limited → backoff ile retry
  │
  └─ 5xx mi? → Infrastructure → retry, ama circuit breaker'ı izle
```## क्यों एक 'पुनः प्रयास' नियम पर्याप्त नहीं है

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

## हम कोड में वर्गीकरण का प्रतिनिधित्व कैसे करते हैं

सिमेंटिक इवेंट के `failureReason` फ़ील्ड में इन चार श्रेणियों में से एक होना चाहिए, न कि प्रदाता का कच्चा त्रुटि टेक्स्ट। प्रदाता गेटवे इस श्रेणी में कच्ची त्रुटि को मैप करने के लिए जिम्मेदार है - यह पिछले अनुभाग में अनुवाद परत का विस्तार है।

| असफलता का कारण | क्या पुनः प्रयास करना उचित है? कार्रवाई |
| --- | --- | --- |
| व्यापार गिरावट | नहीं | उपयोगकर्ता को कोई अन्य विधि सुझाएं |
| अस्पष्ट समयबाह्य | पहले प्रश्न करें | स्थिति जांच फिर निर्णय |
| रेटलिमिटेड | हाँ | बैकऑफ़ के साथ पुनः प्रयास करें |
| इंफ्रास्ट्रक्चरत्रुटि | हाँ | पुन: प्रयास + सर्किट ब्रेकर देखें |

## अक्सर भ्रमित होने वाले भेद```text
❌ Her hata retry edilmelidir
✓ Business decline retry edilmemelidir; sonuç değişmez

❌ Timeout = hata yok, sadece tekrar dene
✓ Timeout = belirsizlik; önce gerçek durum sorgulanmalı

❌ 429 bir arızadır
✓ 429 bir sinyaldir; sistem sizi kasıtlı olarak yavaşlatıyor
```## श्रेणियों के बीच त्वरित तुलना

| श्रेणी | क्या परिणाम स्पष्ट है? क्या पुनः प्रयास करने का कोई मतलब बनता है | विशिष्ट कारण |
| --- | --- | --- | --- |
| व्यापार में गिरावट | हाँ | नहीं | कार्ड, बैलेंस, धोखाधड़ी |
| समय समाप्ति | नहीं | पहले प्रश्न करें | नेटवर्क, पीएसपी धीमापन |
| दर सीमित | हाँ | हाँ (प्रतीक्षा) | वॉल्यूम नियंत्रण |
| इंफ्रास्ट्रक्चर | हाँ | हाँ | पीएसपी साइड की खराबी |

## वर्गीकरण स्थापित करते समय चेकलिस्ट

1. क्या प्रदाता द्वारा लौटाया गया प्रत्येक त्रुटि कोड स्पष्ट रूप से चार श्रेणियों में से किसी एक को दर्शाता है?
2. जब कोई नया अनमैप्ड त्रुटि कोड आता है, तो क्या सिस्टम डिफ़ॉल्ट रूप से स्थिति की क्वेरी करता है या आँख बंद करके पुनः प्रयास करता है? (सही डिफ़ॉल्ट: क्वेरी स्थिति।)
3. टाइमआउट परिदृश्य में, क्या पूर्व-पुनः प्रयास स्थिति जांच वास्तव में लागू की गई है?
4. क्या 429 के लिए बैकऑफ़ समय PSP के `Retry-After` हेडर (यदि कोई हो) को ध्यान में रखता है?
5. क्या 5xx आवृत्ति की निगरानी एक मीट्रिक के रूप में की जाती है जो सर्किट ब्रेकर को ट्रिगर करेगी?
6. क्या व्यवसाय में गिरावट के बाद उपयोगकर्ता प्रवाह कभी भी पुनः प्रयास चक्र में प्रवेश नहीं करता है?

## इस लेख से आपको क्या याद रखना चाहिए

1. 'विफल' कोई एक राज्य नहीं है; वे चार अलग-अलग वास्तविकताएँ हैं जिनके लिए कम से कम चार अलग-अलग क्रियाओं की आवश्यकता होती है।
2. व्यवसाय में गिरावट का पुनः प्रयास नहीं किया जाता है; टाइमआउट का आँख बंद करके पुन: प्रयास नहीं किया जाता है, पहले इसके बारे में पूछताछ की जाती है।
3. 429 एक सिग्नल है, 5xx एक गलती है; दोनों का दोबारा प्रयास किया गया है लेकिन अलग-अलग अनुशासन के साथ।
4. वर्गीकरण त्रुटि को आपके स्वयं के `failureReason` एनम से पढ़ने योग्य बनाता है, न कि कच्चे प्रदाता पाठ से।

> यदि त्रुटि को समझे बिना पुनः प्रयास नीति लिखी गई थी; यह न केवल बेकार है, बल्कि चुपचाप नुकसान पहुंचाता है।

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