प्लेबुक
अपरिवर्तनीय चेकआउट स्नैपशॉट डिज़ाइन: वह निर्णय जो कार्ट को फ़्रीज़ कर देता है (Immutable Payment Snapshot Design)
भुगतान शुरू होते ही कार्ट को लाइव पढ़ने से राशि और मुद्रा अनिर्णीत रह जाती है। इरादे के क्षण में रुक जाने वाले स्नैपशॉट के बिना अंतिम रूप देना विश्वसनीय रूप से काम नहीं करेगा।
वितरित भुगतान इंजन
भाग 4 का 22
वितरित भुगतान आर्किटेक्चर की एक श्रृंखला जो कैप्चर और पूर्ण के बीच के अंतर को पाटती है।
टोकरी एक गतिशील लक्ष्य है
जब कोई ग्राहक भुगतान स्क्रीन पर आता है, तो कार्ट में कीमत, अभियान और स्टॉक जानकारी अभी भी परिवर्तन के अधीन है: अभियान समाप्त हो सकता है, कीमत अपडेट की जा सकती है, वही ग्राहक कार्ट को दूसरे टैब में बदल सकता है। यदि आप भुगतान का इरादा बनाते समय इस जानकारी को फ्रीज नहीं करते हैं, तो पीएसपी में जाने वाली राशि और अंतिम रूप देने पर अपेक्षित राशि दो अलग-अलग वास्तविकताओं का प्रतिनिधित्व कर सकती है।```text Sepet (canlı, değişken) --intent anında--> Payment Snapshot (donmuş, değişmez) ↓ PSP'ye gönderilen tutar = snapshot'taki tutar
## पहले उल्लेख पर अवधारणाएँ```text
📦 Payment Intent
Müşterinin ödeme yapma niyetini temsil eden, PSP'ye gönderilecek tutarı ve para birimini taşıyan kayıt.
📦 Snapshot
Bir anlık gerçeğin (fiyat, miktar, vergi, indirim) o an olduğu haliyle donmuş, sonradan değişmeyen kopyası.
📦 Price-at-Intent
Ödeme başlatıldığı anda geçerli olan fiyatın, sonraki kampanya veya fiyat değişikliklerinden bağımsız olarak korunması ilkesi.
📦 Basket Drift
Sepetin, ödeme süreci ilerlerken (kullanıcı başka bir sekmede değişiklik yaparak veya arka plan işleriyle) snapshot'tan farklılaşması.
📦 Amount Reconciliation
PSP'den gelen gerçek tahsilat tutarının, snapshot'taki beklenen tutarla karşılaştırılması.
```स्नैपशॉट कार्ट का "फोटो" नहीं है; टोकरी की वर्तमान स्थिति एक कानूनी रिकॉर्ड के रूप में जमी हुई है जिसे बाद में बदला नहीं जा सकता है।
## लाइव बास्केट पढ़ना भ्रामक क्यों है
कुछ सिस्टम भुगतान का इरादा बनने के बाद अंतिम चरण के दौरान "वर्तमान राशि" प्राप्त करने के लिए कार्ट को फिर से देखते हैं। यह दृष्टिकोण आकर्षक लगता है क्योंकि यह यह एहसास दिलाता है कि "सबसे अद्यतित डेटा" का उपयोग किया गया है; लेकिन वास्तव में यह समय के दो अलग-अलग बिंदुओं पर दो अलग-अलग वास्तविकताओं को भ्रमित करता है।```text
t0: Müşteri ödeme başlatır → Sepet: 3 ürün, 450 TL, kampanya aktif
t1: PSP'ye 450 TL isteği gider
t2: Kampanya süresi dolar, sepet artık 480 TL gösterir
t3: Finalization, sepete tekrar bakar → 480 TL bekler ama PSP 450 TL tahsil etmiştir
```यह असंगति अंतिमकरण गाथा को ऐसी स्थिति में छोड़ देती है जहां वह यह तय नहीं कर पाती है कि किस राशि को "सही" माना जाए। परिणाम: मैन्युअल समीक्षा, ग्राहक शिकायत, या चुपचाप गलत वित्तीय रिकॉर्ड।
## स्नैपशॉट द्वारा समस्या का समाधान
सही तरीका यह है कि भुगतान आशय के निर्माण के समय कार्ट की वर्तमान स्थिति - राशि, मुद्रा, लाइन आइटम, कर, छूट - को एक अलग, अपरिवर्तनीय रिकॉर्ड के रूप में फ्रीज कर दिया जाए। यह रिकॉर्ड बास्केट तालिका से स्वतंत्र है; भले ही टोकरी बदल जाए, अभियान समाप्त हो जाए, या उत्पाद की कीमत अपडेट हो जाए, स्नैपशॉट वही रहता है।```text
PaymentSnapshot
amount: 450.00
currency: TRY
lines: [...]
createdAt: t0
(sepet t1, t2, t3'te değişse de bu kayıt asla değişmez)
```पीएसपी को भेजी गई राशि हमेशा स्नैपशॉट से पढ़ी जाती है, लाइव कार्ट से नहीं। फ़ाइनलाइज़ेशन गाथा हमेशा स्टॉक ड्रॉप, वित्तीय रिकॉर्डिंग और ऑर्डर पुष्टिकरण के चरणों में इस स्नैपशॉट का संदर्भ देती है। इस तरह, कार्ट का भविष्य चाहे जो भी हो, भुगतान संबंधी सभी निर्णय उसी, निश्चित सत्य पर आधारित होते हैं।
## राशि और मुद्रा सत्यापन
स्नैपशॉट बस रुकता नहीं है; आपको पीएसपी से लौटाई गई वास्तविक संग्रह राशि को भी सत्यापित करना होगा। यदि पीएसपी की प्रतिक्रिया में राशि स्नैपशॉट में राशि से मेल नहीं खाती है (उदाहरण के लिए एक पूर्णांक अंतर, मुद्रा रूपांतरण त्रुटि, या एकीकरण दोष), तो इस घटना को स्वचालित रूप से "पूर्ण" के रूप में चिह्नित नहीं किया जाना चाहिए; विवाद की कतार में पड़ना चाहिए.```text
PSP cevabı: amount=450.00, currency=TRY
Snapshot: amount=450.00, currency=TRY
→ eşleşti, işleme devam
PSP cevabı: amount=449.99, currency=TRY
Snapshot: amount=450.00, currency=TRY
→ eşleşmedi, finalization DURDURULUR, inceleme kuyruğuna düşer
```यह सत्यापन चरण एकीकरण त्रुटियों और संभावित छेड़छाड़ परिदृश्यों दोनों को जल्दी पकड़ लेता है।
## "लाइव कार्ट पर लौटें" का लालच
स्नैपशॉट तंत्र स्थापित होने के बाद भी, कुछ टीमें अंतिम रूप देने के दौरान यह कहकर बास्केट में लौट आती हैं, "लेकिन स्टॉक बदल गया होगा, आइए वर्तमान डेटा देखें।" यह स्नैपशॉट के उद्देश्य को कमजोर करता है: स्टॉक नियंत्रण को एक अलग कदम के रूप में माना जाना चाहिए (और इसकी अपनी विफलता/मुआवजा तर्क के साथ); राशि और मुद्रा का निर्णय कभी भी लाइव डेटा पर आधारित नहीं होना चाहिए। दोनों को भ्रमित करना चर्चा के लिए जमे हुए कानूनी रिकॉर्ड को फिर से खोलने जैसा है।
## इस एपिसोड में सबसे भ्रमित करने वाला मैचअप```text
❌ Finalization'da sepete tekrar bakmak, “en güncel veri” kullanmaktır
✓ Finalization'da sepete tekrar bakmak, iki farklı zaman noktasındaki gerçeği karıştırmaktır
❌ Snapshot sadece bir loglama/audit kaydıdır
✓ Snapshot, ödeme ve finalization kararlarının tek referans kaynağıdır
❌ PSP'den gelen tutar her zaman beklenen tutarla eşleşir, doğrulama gereksizdir
✓ Tutar/para birimi uyuşmazlığı otomatik değil, kuyruğa düşen bir olay olmalıdır
❌ Stok güncelliği ile ödeme tutarı aynı mekanizmayla kontrol edilebilir
✓ Stok kontrolü ayrı bir adımdır; tutar kararı asla canlı veriye dönmemelidir
अपनी डिज़ाइन चेकलिस्ट का स्नैपशॉट लें
- क्या आपके द्वारा पीएसपी को भेजी गई राशि लाइव कार्ट या जमे हुए स्नैपशॉट रिकॉर्ड से पढ़ी गई है?
- अंतिमकरण गाथा में प्रत्येक चरण किस स्रोत (स्नैपशॉट या लाइव टेबल) से राशि/राशि पढ़ता है?
- यदि पीएसपी से लौटाई गई राशि स्नैपशॉट में दी गई राशि से मेल नहीं खाती तो क्या होगा? क्या यह स्वचालित रूप से गुजरता है या रुक जाता है?
- क्या आपने परीक्षण किया है कि स्नैपशॉट बनने के बाद बास्केट तालिका बदलने पर भी स्नैपशॉट नहीं बदलता है?
- क्या स्नैपशॉट का मुद्रा फ़ील्ड हमेशा PSP को भेजी गई मुद्रा के समान होता है; यदि कोई रूपांतरण है, तो यह चरण कहाँ लॉग किया गया है?
यदि आप इन पाँच प्रश्नों में से एक का भी स्पष्ट उत्तर नहीं दे पाते हैं, तो संभवतः आपके सिस्टम में "मूक राशि बहाव" का जोखिम है।
इस अनुभाग से याद रखने योग्य बातें
- जैसे ही भुगतान का इरादा बन जाता है, कार्ट राशि, लाइनें और मुद्रा को एक अलग और अपरिवर्तनीय स्नैपशॉट के रूप में फ्रीज कर दिया जाना चाहिए।
- अंतिमकरण गाथा किसी भी चरण में लाइव कार्ट में वापस नहीं आनी चाहिए; प्रत्येक निर्णय में स्नैपशॉट का संदर्भ होना चाहिए।
- पीएसपी से लौटाई गई वास्तविक राशि की तुलना स्नैपशॉट में अपेक्षित राशि से की जानी चाहिए; विवाद का समाधान स्वचालित रूप से नहीं होना चाहिए, बल्कि समीक्षा के अधीन होना चाहिए।
- स्टॉक का अद्यतन नियंत्रण एक अलग जिम्मेदारी है; राशि/मुद्रा निर्णय में भ्रमित न हों।
टोकरी भविष्य का एक खाका है; भुगतान अतीत में रुका हुआ निर्णय है. इन दोनों को एक ही रिकॉर्ड से पढ़ना दो अलग-अलग समयों को एक ही वास्तविकता जैसा बनाना है।
FAQ
Frequently asked questions
भुगतान आशय क्या है?
एक रिकॉर्ड जो ग्राहक के भुगतान करने के इरादे को दर्शाता है और पीएसपी को भेजी जाने वाली राशि और मुद्रा को वहन करता है।
स्नैपशॉट क्या है?
किसी क्षणिक वास्तविकता (कीमत, मात्रा, कर, छूट) की एक जमी हुई प्रति, जो उस समय जैसी है, जो बाद में नहीं बदलती।
क्या यह सच है कि "फ़ाइनलाइज़ेशन पर कार्ट को दोबारा देखने का मतलब "सबसे ताज़ा डेटा" का उपयोग करना है?"
फ़ाइनलाइज़ेशन में टोकरी को फिर से देखना समय के दो अलग-अलग बिंदुओं पर वास्तविकता को भ्रमित करने वाला है
यह अनुभाग क्या ठीक करता है?
यह खंड बताता है कि क्यों "लाइव कार्ट पर वापस लौटना" एक जोखिम है, शॉर्टकट नहीं, और कैसे अपरिवर्तनीय स्नैपशॉट इसे हल करता है। जैसे ही भुगतान का इरादा बन जाता है, कार्ट राशि, लाइनें और मुद्रा को एक अलग और अपरिवर्तनीय स्नैपशॉट के रूप में फ्रीज कर दिया जाना चाहिए। जब कोई ग्राहक भुगतान स्क्रीन पर आता है, तो कार्ट में कीमत, अभियान और स्टॉक जानकारी अभी भी परिवर्तन के अधीन है: अभियान समाप्त हो सकता है, कीमत अपडेट की जा सकती है, वही ग्राहक कार्ट को दूसरे टैब में बदल सकता है। यदि आप भुगतान का इरादा बनाते समय इस जानकारी को फ्रीज नहीं करते हैं, तो पीएसपी में जाने वाली राशि और अंतिम रूप देने पर अपेक्षित राशि दो अलग-अलग वास्तविकताओं का प्रतिनिधित्व कर सकती है।
इंजीनियरिंग सिद्धांत सीखे गए
- जैसे ही भुगतान का इरादा होता है, टोकरी की राशि, लाइनें और मुद्रा को एक अपरिवर्तनीय स्नैपशॉट के रूप में फ्रीज कर दिया जाना चाहिए।
- अंतिम निर्णयों को कभी भी लाइव कार्ट में वापस नहीं जाना चाहिए; हमेशा स्नैपशॉट का संदर्भ देना चाहिए.
- यदि पीएसपी से लौटाई गई राशि और स्नैपशॉट मेल नहीं खाते हैं, तो यह एक स्वचालित घटना नहीं होनी चाहिए बल्कि समीक्षा के अधीन होनी चाहिए।
जारी रखें पढ़ रहे हैं
जारी रखें पढ़ रहे हैं
श्रृंखला में अगला
एपीआई (एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस) अनुरोध से परे इडेम्पोटेंसी (दोहराए जाने योग्य सुरक्षित लेनदेन)।
निष्क्रियता कोई एक हेडर नहीं है. यह एक रक्षा स्टैक है जिसे एपीआई कुंजी से लेकर स्टेप पॉइंटर तक पांच अलग-अलग परतों पर अलग से स्थापित किया जाना चाहिए।
श्रृंखला में अगला
संग्रहण (कब्जा करना) आसान लेकिन अंतिम रूप देना कठिन क्यों है?
पीएसपी के लिए पैसा प्राप्त करना बस एक कदम है। आदेश समाप्त करें; यह एक ऐसी गाथा है जिसके सफल होने के लिए इन्वेंट्री, वित्त, रिपोर्टिंग और सफाई कदमों की…
वही सिलसिला
भुगतान प्रणालियों में वेबहुक विश्वसनीयता
वेबहुक बार-बार आते हैं, गायब हो जाते हैं, क्रम से बाहर आते हैं और देरी से आते हैं। हस्ताक्षर सत्यापित करें, तेज़ ACK दें, कभी भी समकालिक भारी सामान न…