पेमेंट दोबारा करें या रुकें: डिक्लाइन को दोहरे डेबिट में बदलने से कैसे बचें

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

पहला सवाल: क्या डिक्लाइन की पुष्टि हुई है?

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

Stripe बताता है कि नेटवर्क की गड़बड़ी इस बात का सबूत नहीं कि ट्रांज़ैक्शन नहीं हुआ। उसी रिक्वेस्ट को अनुमत तरीके से दोहराने के लिए तय विंडो के भीतर वही आइडेम्पोटेंसी key और पैरामीटर इस्तेमाल होते हैं; अनिश्चित नतीजे के लिए रिकंसिलिएशन ज़रूरी है। ठोस नियम API वर्ज़न पर निर्भर करते हैं। स्रोत: Stripe, Advanced error handling.

soft और hard तभी उपयोगी हैं जब साथ में कोड हो

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

Stripe की रेफ़रेंस में अतिरिक्त ऑथेंटिकेशन की माँग कस्टमर की संबंधित कार्रवाई की ओर ले जाती है, कार्ड की एक्सपायरी के लिए दूसरा कार्ड चाहिए, और सामान्य डिक्लाइन में इश्यूअर से संपर्क करना पड़ सकता है। सलाह कोड के हिसाब से बदलती है, इसलिए «हर डिक्लाइन दोहराओ» वाला एक नियम गलत है। स्रोत: Stripe, Decline codes.

एक छोटी सुरक्षित पॉलिसी का उदाहरण

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

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

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

एक लिमिट की जगह दो काउंटर

रिक्वेस्ट की तकनीकी डिलीवरी को ऑथराइज़ेशन की नई कोशिश से अलग कीजिए। लॉग में दो काउंटर उपयोगी हैं: भरोसेमंद जवाब पाने के लिए एक ही कार्रवाई कितनी बार भेजी गई, और ऑर्डर पर कितनी स्वतंत्र पेमेंट कोशिशें हुईं। वरना तीन नेटवर्क सबमिशन को तीन नए पेमेंट समझा जा सकता है, या उल्टा, नई कोशिशों को «रीट्राई» जैसे सामान्य शब्द के पीछे छिपाया जा सकता है।

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

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

डुप्लिकेट से सुरक्षा कहाँ रखें

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

ट्रांसपोर्ट की सफलता के बाद भी बिज़नेस नतीजा जाँचना ज़रूरी है। Adyen बताता है कि HTTP 200 के साथ भी ऑथराइज़ेशन डिक्लाइन आ सकता है; नतीजा जवाब के पेमेंट फ़ील्ड बताते हैं। इसलिए HTTP कोड को पेड ऑर्डर का अकेला संकेत नहीं माना जा सकता। स्रोत: Adyen, Refusal reasons.

रिकवरी की कीमत सही समूह पर आँकिए

उन 15 ऑर्डर पर लौटिए जो ट्रेनिंग उदाहरण में दोहराए जा सकते थे। मान लीजिए एक-एक अतिरिक्त कोशिश से छह ऑर्डर रिकवर हुए। इस कदम की सफलता 6 / 15 = 40% है, और हर रिकवर हुए ऑर्डर पर 15 / 6 = 2.5 अतिरिक्त कोशिशें लगीं। ये इस खास योग्य समूह के आँकड़े हैं, सभी सौ मूल केसों की कुल रिकवरी दर नहीं।

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

कामकाजी नियमावली में मालिक के साथ एक इमरजेंसी स्टॉप चाहिए: ऑटोमैटिक दोहराव कौन रोक सकता है, कौन-सा सिग्नल इसे चालू करता है और रुकने के बाद कतार कैसे प्रोसेस होती है। जमा हुई स्थितियों की जाँच के साथ सामान्य काम पर लौटने का तरीका अलग से तय कीजिए। आउटेज के बाद पुरानी कतार को बस फिर से चालू करने से ऐसी रिक्वेस्ट दोबारा उठ सकती हैं जिनका मतलब अब बदल चुका है।

रुकने के बाद कस्टमर को क्या बताएँ

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