प्लेबुक

भुगतान किया गया लेकिन कोई ऑर्डर नहीं: सुधार (Healing Paid But Unordered)

घटना प्रतिक्रिया गाइड: ग्राहक से शुल्क लिया गया लेकिन कोई ऑर्डर नहीं दिया गया; बहु-इरादतन टोकरी अव्यवस्था; डिडअप को सावधानीपूर्वक साफ करना।

वितरित भुगतान इंजन

भाग 15 का 22

वितरित भुगतान आर्किटेक्चर की एक श्रृंखला जो कैप्चर और पूर्ण के बीच के अंतर को पाटती है।

Distributed payment engine architecture diagram

पिछले अनुभाग में, हमने देखा कि सर्वसम्मति कार्यकर्ता कैसे बहाव का पता लगाता है। यह अनुभाग उस बहाव के सबसे कष्टप्रद रूप से निपटता है: ग्राहक से वास्तव में पीएसपी की ओर से शुल्क लिया गया है, लेकिन सिस्टम में बदले में कोई ऑर्डर नहीं है।

यह परिदृश्य घबराहट उत्पन्न करता है क्योंकि दो खराब समाधान आकर्षक लगते हैं: तुरंत रिफंड करें (हो सकता है कि ग्राहक वास्तव में ऑर्डर चाहता था, अनावश्यक रिफंड-पुनः प्रयास चक्र शुरू करना) या चुपचाप एक नया ऑर्डर बनाना (यह जाने बिना कि कौन सा कार्ट किस सौदे से मेल खाता है, गलत ऑर्डर उत्पन्न करने का जोखिम)।```text PSP kaydı: Charge #789 → Succeeded, amount: 249.00 Local kayıt: (hiçbir Order veya Payment satırı yok) │ ▼ Bu paranın hangi sepete ait olduğunu belirle │ ▼ Sipariş oluştur (heal) VEYA güvenle refund et


## पहले उल्लेख पर अवधारणाएँ```text
📦 Orphan Charge
PSP tarafında başarılı ama local sistemde hiçbir kayda bağlanamayan ücretlendirme.

📦 Multi-Intent Cart
Aynı sepet için birden fazla ödeme intent'i oluşturulmuş durum (örn. kullanıcı sayfayı iki kez yeniledi).

📦 Heal (İyileştirme)
Orphan charge'ı doğru sepete/siparişe geriye dönük olarak bağlama işlemi.

📦 Correlation ID
Bir ödeme intent'ini oluşturduğu sepete/isteğe bağlayan, ödeme akışının başında üretilen kimlik.
```ऑर्फ़न चार्ज अक्सर सहसंबंध आईडी के कहीं खो जाने से उत्पन्न होता है: इरादा बनाते समय दर्ज की गई आईडी ऑर्डर निर्माण चरण तक पहुंचने से पहले बाधित हो जाती है।

## घटना प्रतिक्रिया मार्गदर्शिका: पहला कदम

जब एक अनाथ आरोप का पता चलता है (आमतौर पर एक सुलह कार्यकर्ता या ग्राहक की शिकायत के माध्यम से), तो पहला कदम कार्रवाई करना नहीं है, बल्कि सहसंबंध श्रृंखला को फिर से स्थापित करना है:```text
1. PSP'nin charge metadata'sından correlation id'yi çıkar
2. Bu id ile local sistemde bir cart/intent kaydı ara
3. Kayıt bulunduysa → hangi aşamada kesintiye uğradığını belirle
4. Kayıt bulunamadıysa → refund'a yönel (heal edilecek bir hedef yok)
```सहसंबंध आईडी हमेशा पीएसपी के मेटाडेटा फ़ील्ड में लिखी जानी चाहिए (चार्ज बनाते समय); यह सबसे महत्वपूर्ण डिज़ाइन निर्णय है जो अनाथ शुल्कों को पूर्वव्यापी रूप से समाधान योग्य बनाता है।

## मल्टी-इंटेंट कार्ट: कौन सा पैसा किस ऑर्डर का है

यदि किसी ग्राहक ने चेकआउट पेज दो बार खोला (टैब रिफ्रेश, डबल क्लिक, नेटवर्क विलंब के बाद पुनः प्रयास करें), तो एक ही कार्ट के लिए दो अलग-अलग भुगतान इरादे हो सकते हैं। यदि पीएसपी की ओर से दोनों सफल हैं, तो सिस्टम के सामने अब 'खोया हुआ भुगतान' नहीं बल्कि 'कौन सा भुगतान जीतता है, दूसरे का क्या होता है' का सवाल है।```text
Cart #A
  ├─ Intent #1 → PSP: Succeeded
  └─ Intent #2 → PSP: Succeeded  (aynı sepet, iki farklı charge)
```यहां सही व्यवहार कार्ट को लॉक करना है (उसी कार्ट के विरुद्ध नए इरादों को बनने से रोकना) और 'विजेता' के रूप में केवल एक इरादे का चयन करें और स्वचालित रूप से दूसरे को वापस कर दें - दोनों को ऑर्डर में संलग्न करने से दोहरी कीमत बनती है।

## डेडअप को सावधानीपूर्वक साफ़ करना: क्यों 'आक्रामक' विलोपन जोखिम भरा है

ऑर्फ़न शुल्कों का भुगतान करते समय सबसे बड़ी गड़बड़ी 'समान राशि, समान ग्राहक, हाल का समय' जैसे ढीले मानदंडों पर कटौती तर्क को आधार बनाना है। यह मानदंड गलती से दो अलग-अलग जानबूझकर ऑर्डर (ग्राहक ने वास्तव में दो अलग-अलग चीजें खरीदी) को एक ही ऑर्डर के रूप में मान सकता है।```text
❌ Gevşek dedup
Aynı müşteri + aynı tutar + 5 dakika içinde → tek sipariş say

✓ Sıkı dedup
Aynı correlation id VEYA aynı idempotency key → tek sipariş say
```डेडअप निर्णय हमेशा सिस्टम द्वारा उत्पन्न पहचान (सहसंबंध आईडी, निष्क्रियता कुंजी) पर आधारित होना चाहिए; मात्रा और समय जैसे अप्रत्यक्ष संकेतों का उपयोग केवल सत्यापन की एक अतिरिक्त परत के रूप में किया जाना चाहिए, प्राथमिक मानदंड के रूप में नहीं।

## ठीक करना या वापसी: निर्णय मानदंड

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

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

## अक्सर भ्रमित होने वाले भेद```text
❌ Orphan charge her zaman refund edilmeli
✓ Correlation id ile eşleşen bir hedef varsa heal etmek doğru olabilir

❌ Aynı tutar + aynı müşteri = aynı sipariş
✓ Dedup, sistemin kendi ürettiği kimliğe (correlation id) dayanmalı

❌ Multi-intent bir hata durumudur, göz ardı edilebilir
✓ Multi-intent normal bir kullanıcı davranışıdır (yenileme, çift tıklama), tasarlanmalıdır
```## हील और रिफंड निर्णय की तुलना

| कसौटी | चंगा | रिफंड |
| --- | --- | --- |
| सहसंबंध आईडी मिलान | हाँ | कोई नहीं या अस्पष्ट |
| ग्राहक अनुभव | आदेश दिख रहा है, रुकावट महसूस नहीं हो रही है | पैसे वापस, कोई ऑर्डर नहीं |
| जोखिम | बेमेल का खतरा | ग्राहक असंतोष का जोखिम |

## घटना प्रतिक्रिया चेकलिस्ट

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

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

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

> घबराहट के समय में सबसे सुरक्षित कार्रवाई तुरंत समाधान नहीं है; यह तब तक कुछ नहीं करने के बारे में है जब तक आपको सही सबूत नहीं मिल जाता।

अगले भाग में हम इस तरह के बहाव की जड़ तक पहुँचते हैं: क्यों पीएसपी, ऑर्डर और वित्त के बीच एक वितरित लेनदेन (2पीसी) स्थापित करना एक जाल है, और क्यों सागा + सुलह ही वास्तविक उत्तर है।

FAQ

Frequently asked questions

अनाथ शुल्क क्या है?

मूल्य निर्धारण जो पीएसपी पक्ष पर सफल है, लेकिन स्थानीय सिस्टम पर किसी भी रिकॉर्ड से नहीं जोड़ा जा सकता है।

मल्टी-इंटेंट कार्ट क्या है?

एक ही कार्ट के लिए एकाधिक भुगतान इरादे बनाए गए (उदाहरण के लिए उपयोगकर्ता ने पृष्ठ को दो बार ताज़ा किया)।

क्या यह सच है कि "अनाथ शुल्क हमेशा वापस किया जाना चाहिए"?

यदि सहसंबंध आईडी से मेल खाने वाला कोई लक्ष्य है, तो उपचार सही हो सकता है।

यह अनुभाग क्या ठीक करता है?

यह परिदृश्य घबराहट उत्पन्न करता है क्योंकि दो खराब समाधान आकर्षक लगते हैं: तुरंत रिफंड करें (हो सकता है कि ग्राहक वास्तव में ऑर्डर चाहता था, अनावश्यक रिफंड-पुनः प्रयास चक्र शुरू करना) या चुपचाप एक नया ऑर्डर बनाना (यह जाने बिना कि कौन सा कार्ट किस सौदे से मेल खाता है, गलत ऑर्डर उत्पन्न करने का जोखिम)। अनाथ शुल्कों को हल करने की कुंजी भुगतान प्रवाह की शुरुआत में सहसंबंध आईडी को सुरक्षित रूप से उत्पन्न करना है। पिछले अनुभाग में, हमने देखा कि सर्वसम्मति कार्यकर्ता कैसे बहाव का पता लगाता है। यह अनुभाग उस बहाव के सबसे कष्टप्रद रूप से निपटता है: ग्राहक से वास्तव में पीएसपी की ओर से शुल्क लिया गया है, लेकिन सिस्टम में बदले में कोई ऑर्डर नहीं है।

इंजीनियरिंग सिद्धांत सीखे गए

  • अनाथ आरोपों को हल करने की कुंजी प्रवाह की शुरुआत में सहसंबंध आईडी को सुरक्षित रूप से उत्पन्न करना है।
  • डिडअप निर्णय हमेशा पहचान पर आधारित होना चाहिए, न कि राशि/समय जैसे अप्रत्यक्ष संकेतों पर।
  • घबराहट में सबसे सुरक्षित कदम यह है कि जब तक आपको सही सबूत न मिल जाए तब तक कुछ न करें।

जारी रखें पढ़ रहे हैं

जारी रखें पढ़ रहे हैं

श्रृंखला में अगला

निबंध

अंततः वितरित लेन-देन से बेहतर संगति क्यों है?

पीएसपी, ऑर्डर और वित्त के बीच 2पीसी स्थापित करना एक जाल है। सागा और सुलह वितरित भुगतान स्थिरता का वास्तविक उत्तर हैं।

श्रृंखला में अगला

निबंध

भुगतान समाधान कार्यकर्ता निर्माण

सफ़ाईकर्मी बहाव में सुधार कैसे करते हैं: जबकि पीएसपी सफल है, स्थानीय पंजीकरण समाप्त हो सकता है; वृद्धावस्था को कैसे पुनर्प्राप्त करें फाइनलाइज पेंडिंग।

वही सिलसिला

निबंध

वेबहुक के अंतर्गत आशावादी समवर्तीता

जब वेबहुक के साथ समकालिक प्रतिक्रिया एक ही समय में समान भुगतान को छूती है तो संस्करण टोकन और लीज़ दौड़ को कैसे हल करते हैं? टर्मिनल भुगतान में बासी पढ़ने…

Paylaş