ऑर्डर, पेमेंट और पेआउट: एक खरीद की तीन कहानियाँ

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

ऑपरेशन मैनेज करने के लिए तीन जुड़ी हुई कहानियाँ रखना सुविधाजनक है: कमर्शियल ऑर्डर, पेमेंट अटेम्प्ट और बैंक खाते की ओर पैसे की हलचल। इन्हें एक ही स्क्रीन पर दिखाया जा सकता है, लेकिन "पेमेंट हुआ / नहीं हुआ" के एक स्विच में नहीं समेटा जा सकता।

एक खरीद, समय के तीन पल

काल्पनिक उदाहरण: एक स्टोर 80 यूरो का सेट बेचता है। सोमवार 10:00 बजे ऑर्डर बनता है। 10:02 बजे प्रोवाइडर पेमेंट की पुष्टि करता है, लेकिन इवेंट स्टोर के सिस्टम तक 10:04 बजे पहुँचता है। मंगलवार को सामान डिस्पैच होता है। हमारे काल्पनिक कॉन्ट्रैक्ट की शर्तों के अनुसार पैसा बुधवार को पेआउट के लिए उपलब्ध होता है और गुरुवार के नियमित पेआउट में जाता है।

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

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

ऑर्डर का अपना लाइफ़साइकल होता है

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

पेमेंट दूसरे सवाल का जवाब देता है: पैसा जमा करने की किसी खास कोशिश के साथ क्या हुआ? कार्ड स्कीम में ऑथराइज़ेशन और डेबिट अलग-अलग चरण हो सकते हैं। उदाहरण के लिए, Adyen का डॉक्यूमेंटेशन ऑथराइज़ेशन, capture और settlement में फ़र्क करता है। किसी दूसरे प्रोवाइडर में नाम और स्टेटस का सेट अलग हो सकता है।

प्रोवाइडर के पास पूरी पेमेंट प्रक्रिया के लिए अलग ऑब्जेक्ट भी हो सकता है। Stripe PaymentIntent ऐसी प्रक्रिया का स्टेटस सहेजता है और पेमेंट अटेम्प्ट को जोड़ता है। अपना सिस्टम डिज़ाइन करते समय यह समझना ज़रूरी है कि कौन-सा आइडेंटिफ़ायर ऑर्डर बताता है, कौन-सा अटेम्प्ट और कौन-सा अंतिम वित्तीय ट्रांज़ैक्शन।

ऐसी पाबंदियाँ तय करें जो अपने आप जाँची जाएँ

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

पूरी लॉजिक को "बना → सफल → बंद" जैसे स्टेटस के क्रम से व्यक्त करने की कोशिश न करें। मान लीजिए ऑर्डर 10:03 बजे कैंसिल हुआ, और 10:02 बजे हुई पेमेंट की पुष्टि 10:04 बजे मिली। पेमेंट सच में हुआ, और कमर्शियल ऑर्डर सच में कैंसिल हुआ। प्रोसेसिंग का सुझाया गया नतीजा: दोनों तथ्य सहेजें, ऑटोमैटिक डिस्पैच रोकें और सहमति से मामला सुलझाने का टास्क खोलें। यहाँ रिफ़ंड को अभी मंज़ूरी देनी और पूरा करना है; ऑर्डर कैंसिल होने भर से उसे हो चुका नहीं माना जा सकता।

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

कौन-से फ़ील्ड जाँच को बचाते हैं

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

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

डेटा की पुरानी तस्वीर पर जाँच

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

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

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

मैनुअल फ़ैसला भी इतिहास छोड़ता है

दोबारा आया नोटिफ़िकेशन एक और डिस्पैच नहीं बनाना चाहिए। देर से आया नोटिफ़िकेशन नए डेटा को बिना निशान छोड़े ओवरराइट नहीं करना चाहिए। Adyen बताता है कि डुप्लिकेट संभव हैं और इवेंट के कालक्रम का ध्यान रखना ज़रूरी है। इस्तेमाल हो रहे API के नियमों के अनुसार ये सिनेरियो जाँचें।

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

अलग कतार में बिना ऑर्डर वाले पेमेंट, बिना पुष्टि वाले ऑर्डर, अनसुलझे रिफ़ंड और बैंक मिलान के बिना पेआउट रखें। हर एंट्री के लिए इंतज़ार की उम्र, ओनर और अगला कदम चाहिए।

मॉडल को एक ऐसे ऑर्डर पर जाँचें जो पेमेंट की पुष्टि मिलने से पहले कैंसिल हुआ। सिस्टम को दोनों तथ्य सहेजने चाहिए, सुलझाने का टास्क दिखाना चाहिए और न दोबारा डेबिट करना चाहिए, न ऑटोमैटिक डिस्पैच। ऐसा टेस्ट इंटरफ़ेस में रंग बदलने से बेहतर ढंग से स्टेटस का मतलब परखता है।