ऑनलाइन पेमेंट स्टेटस: पेंडिंग ऑर्डर को दोबारा चार्ज किए बिना सँभालें

ऑर्डर और भुगतान की स्थिति अलग रखें

ऑर्डर तैयार होना भुगतान शुरू होने से पहले की घटना है। भुगतान प्रयास लंबित हो सकता है जबकि ऑर्डर अभी पूरा नहीं हुआ। सफल भुगतान के बाद भी सामान भेजना या सेवा सक्रिय करना अलग काम है। इन अवस्थाओं को एक अस्पष्ट paid या unpaid फ़ील्ड में समेटना समर्थन टीम को अधूरी तस्वीर देता है।

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

भुगतान सूचनाएँ

टाइमआउट को वास्तविक अस्वीकृति न मानें

वास्तविक अस्वीकृति तब है जब प्रदाता ने स्पष्ट अंतिम परिणाम दिया हो। अनुरोध भेजने के बाद उत्तर न मिलना अलग स्थिति है। भुगतान बना भी हो सकता है। ऐसी दशा में अस्पष्ट परिणाम को सुरक्षित रिकॉर्ड करें और ग्राहक को थोड़ी देर बाद स्थिति देखने का रास्ता दें।

आंतरिक रिकॉर्ड में अनुरोध की पहचान, समय और प्रदाता संदर्भ रखें, लेकिन गुप्त कुंजी या कार्ड डेटा नहीं। पुनः प्रयास की नीति उसी प्रदाता की idempotency और स्थिति प्राप्त करने की क्षमता के अनुसार बने। सभी त्रुटियों पर एक ही नया sale अनुरोध भेजना सुरक्षित नीति नहीं है।

भुगतान रिपोर्ट

सर्वर पर सत्यापित सूचना लागू करें

Webhook भुगतान का परिणाम आपके सर्वर तक पहुँचा सकता है, लेकिन उसे बिना सत्यापन स्वीकार न करें। हस्ताक्षर, अपेक्षित स्रोत और संबंधित ऑर्डर की जाँच करें। राशि, मुद्रा और प्रदाता का संबंध सही होना चाहिए। अज्ञात भुगतान की सूचना से किसी अनुमानित ग्राहक का ऑर्डर पूरा न करें।

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

ग्राहक को काम का संदेश दिखाएँ

लंबित पेज पर ऑर्डर संदर्भ, वर्तमान स्थिति और सहायता का रास्ता दें। ग्राहक को बार-बार भुगतान करने के लिए प्रेरित न करें। तकनीकी त्रुटि का कच्चा पाठ, सर्वर का पता या प्रदाता का पूरा जवाब दिखाने की जरूरत नहीं है। संदेश बताता हो कि पुष्टि प्राप्त की जा रही है।

यदि स्थिति देखने का API है, तो उसे व्यापारी या ग्राहक के उचित अधिकार तक सीमित रखें। केवल क्रम से अनुमान लग सकने वाली ऑर्डर पहचान जान लेने पर किसी दूसरे ग्राहक का भुगतान विवरण नहीं खुलना चाहिए। स्थिति अनुरोधों की आवृत्ति भी नियंत्रित रखें।

संचालन टीम के लिए अपवाद सूची बनाएँ

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

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

रिलीज से पहले कठिन स्थितियाँ चलाएँ

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

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

स्रोत

• Stripe Webhooks
• Stripe Checkout