Payment orchestration: कई प्रदाताओं के बीच साफ भुगतान संरचना

पहले वह समस्या लिखें जिसे हल करना है

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

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

पेमेंट ऑर्केस्ट्रेशन

ऑर्डर और प्रयास को अलग पहचान दें

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

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

प्रदाता कनेक्शन

नियम में पात्रता और क्षमता दोनों रखें

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

नियम के साथ कारण भी रिकॉर्ड करें: किस संस्करण ने कौन सा प्रदाता चुना और क्यों। इससे समर्थन टीम समझ सकती है कि एक ऑर्डर दूसरे से अलग क्यों गया। संवेदनशील कार्ड विवरण या गुप्त कुंजी कारण के रिकॉर्ड में कभी न जोड़ें।

अस्थायी विफलता पर दूसरा चार्ज न बनाएँ

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

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

बदलाव को छोटे हिस्से में लागू करें

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

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

खरीद से पहले सीमा स्पष्ट करें

OrsunPay के प्रदाता कनेक्शन और orchestration पृष्ठ को अलग-अलग पढ़ें। किसी योजना या Soon चिह्नित सुविधा को चालू स्वचालित cascading समझकर आर्किटेक्चर न बनाएँ। उपलब्ध कनेक्टर, अनुबंध, मुद्रा और संचालन प्रक्रिया की पुष्टि के बाद ही लाइव बदलाव करें।

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

स्रोत

• Stripe Checkout
• Stripe Webhooks