योजनाबद्ध PSP बदलाव: सब्सक्रिप्शन का ट्रांसफ़र और पुरानी देनदारियाँ बंद करना

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

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

पहले उसका नक्शा बनाएँ जो पीछे रह जाता है

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

रूटिंग का सुझाया गया सिद्धांत सरल है: नई कार्रवाई को वही प्रक्रिया संभाले जिससे वह असल में जुड़ी है। पुराने पेमेंट का रिफ़ंड पुराने आइडेंटिफ़ायर के साथ अपने-आप नए PSP को नहीं भेजा जा सकता। सभी पक्षों से सपोर्टेड रास्ता स्पष्ट करें और तय कार्रवाइयों के लिए ज़रूरी एक्सेस बनाए रखें। अगर पुराना अनुबंध ख़त्म हो रहा है, तो आगे की सर्विस और संभावित सीमाओं पर अलग से सहमति बनाएँ।

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

डेटा का ट्रांसफ़र अभी सब्सक्रिप्शन का ट्रांसफ़र नहीं है

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

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

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

एक इनवॉइस का एक ही एक्ज़ीक्यूटर होना चाहिए

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

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

ड्रिल में एक्सपोर्ट और स्विच के बीच ग्राहक का कैंसलेशन जोड़ें। सोमवार का डेटा स्नैपशॉट मंगलवार को लिया गया फ़ैसला नहीं दिखाता। बदलावों को ट्रांसफ़र करने की प्रक्रिया या प्रोडक्ट के लिए स्वीकार्य एक सीमित फ़्रीज़ विंडो चाहिए। अंदरूनी सेटिंग्स का फ़्रीज़ ग्राहक से सर्विस रद्द करने का उसका हक़ वाला तरीका नहीं छीनना चाहिए।

ट्रांसफ़र को समूहों में जाँचें

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

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

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