विकल्प / ऑर्केस्ट्रेशन
पेमेंट ऑर्केस्ट्रेशन का विकल्प खोज रहे हैं
ऑर्केस्ट्रेशन approval rate और लागत बचत के नाम पर बिकता है, और दोनों वास्तविक हैं — एक निश्चित स्केल के ऊपर, जब एक से ज़्यादा acquirer हों। उससे नीचे यह लेयर बिना किसी राउटिंग फ़ायदे के फ़ीस, निर्भरता और एक अतिरिक्त हॉप जोड़ती है। ईमानदार मूल्यांकन यह तय करने से शुरू होता है कि आप उस रेखा के किस तरफ़ हैं।
परखें
लेयर जोड़ने से पहले छह सवाल।
असल में आप कितने प्रोवाइडर चलाते हैं?
एक acquirer हो तो राउटिंग के लिए कुछ बचता ही नहीं। जो भी फ़ायदे बताए जाते हैं, वे मानकर चलते हैं कि आपके पास कई संबंध हैं जिन्हें रखने की आपके पास वजह है।
आपके लिए approval rate का एक प्वाइंट कितने का है?
इसे अपने सालाना वॉल्यूम से गुणा करें, फिर लेयर की फ़ीस और उसे चलाने की इंजीनियरिंग लागत से तुलना करें। छोटे वॉल्यूम पर यह गणित शायद ही टिकता है।
क्या आपकी decline समस्या सच में राउटिंग की है?
जो राउटिंग की समस्या लगती है, उसका बड़ा हिस्सा अक्सर मेथड कवरेज, ऑथराइज़ेशन से पहले ग्राहक खो देने वाला checkout, या ज़रूरत से सख़्त 3-D Secure नीति होता है।
पैसा कौन सेटल करता है?
ऑर्केस्ट्रेटर आम तौर पर नहीं करता — सेटलमेंट उसी प्रोवाइडर के पास रहता है जिसने पेमेंट लिया, यानी आपका रिकंसिलिएशन अब भी कई प्रोवाइडरों में फैला रहता है, जब तक लेयर वह भी हल न करे।
आपकी रिपोर्टिंग का क्या होता है?
आपस में असहमत प्रोवाइडरों की रिपोर्टिंग को एकरूप करना अक्सर असली मूल्य होता है। इसे डेमो डेटासेट पर नहीं, अपने प्रोवाइडर मिश्रण पर दिखाने को कहें।
निर्भरता के रूप में यह लेयर आपको क्या क़ीमत देती है?
आप हर पेमेंट के रास्ते में एक और सिस्टम जोड़ते हैं। पूछें कि उसके धीमा या ख़राब होने पर क्या होता है, और क्या आप उसे बायपास करके सीधे प्रोवाइडर पर फ़ेलओवर कर सकते हैं।
ऑर्केस्ट्रेशन कब सच में जवाब है
जब आपके पास पहले से कई acquiring संबंध हों क्योंकि कोई एक आपके बाज़ारों, रिस्क प्रोफ़ाइल या दरों को कवर नहीं करता — और आपका वॉल्यूम इतना बड़ा हो कि प्रतिशत का एक अंश भी असली पैसा हो। तब issuer और कॉरिडोर के हिसाब से राउटिंग, soft decline को दूसरे acquirer पर कैस्केड करना, और प्रोवाइडरों के पार एक रिपोर्टिंग मॉडल अच्छे विचार नहीं रहते, P&L की एक पंक्ति बन जाते हैं। पूर्वशर्त कभी नहीं बदलती: कई प्रोवाइडर, जिन्हें रखने की आपके पास वजह हो।
- 01कई acquirer, कवरेज, रिडंडेंसी या दरों के लिए रखे गए
- 02ऐसा वॉल्यूम जहाँ approval का एक प्वाइंट लेयर की फ़ीस से भारी पड़े
- 03प्रोवाइडरों के बीच फ़ेलओवर, एक व्यावसायिक आवश्यकता के रूप में
- 04आपस में असहमत प्रोवाइडरों के पार एक रिपोर्टिंग मॉडल
जब यह ग़लत ख़रीद है
जब आपके पास एक ही प्रोवाइडर हो, या जो समस्या आप सुलझा रहे हैं वह राउटिंग से पहले की हो। एक गेटवे के ऊपर लेयर जोड़ने से सिर्फ़ फ़ीस और एक अतिरिक्त हॉप मिलता है। और अगर पेमेंट इसलिए फ़ेल हो रहे हैं कि ग्राहक का पसंदीदा मेथड पेज पर नहीं है, checkout ऑथराइज़ेशन से पहले लोगों को खो देता है, या 3-D Secure उस ट्रैफ़िक को चैलेंज कर रहा है जिसे ज़रूरत नहीं — तो कितनी भी राउटिंग उसे नहीं बचाएगी; इलाज checkout में है, उसके ऊपर नहीं।
- 01एक ही प्रोवाइडर — ऑर्केस्ट्रेट करने को कुछ नहीं
- 02नुक़सान ऑथराइज़ेशन से पहले होता है, उसके समय नहीं
- 03असली कमी राउटिंग की नहीं, मेथड कवरेज की है
- 04आपके वॉल्यूम पर फ़ीस राउटिंग के फ़ायदे से ज़्यादा है
Protocore Gateway कहाँ फ़िट बैठता है
हम नीचे की परत हैं — एक गेटवे जो पेमेंट लेता है और पैसा सेटल करता है — जिसमें ऑर्केस्ट्रेशन के वे हिस्से अंदर ही बने हैं जो एक-प्रोवाइडर वाले बिज़नेस के काम के हैं, ऊपर से बेचे नहीं जाते: आपकी भाषा में लिखी राउटिंग नीति, ग्राहक को फ़ेलियर दिखने से पहले वैकल्पिक रूट पर रीट्राई, और ऐसे decline कारण जिन पर ऑपरेटर कार्रवाई कर सके। अगर आप सच में multi-acquirer स्केल पर पहुँचते हैं, तो whitelabel प्लेटफ़ॉर्म आपके अपने acquirer को हमारे साथ जोड़ देता है। यह सवाल पूछने वाले ज़्यादातर बिज़नेस को बेहतर गेटवे चाहिए, मौजूदा गेटवे के ऊपर कोई लेयर नहीं।
- 01राउटिंग नीति और रीट्राई शामिल, लेयर फ़ीस नहीं
- 02असल में सेटल करने वाला गेटवे, एक करेंसी में
- 03Whitelabel प्लेटफ़ॉर्म पर जुड़े आपके अपने acquirer
- 04कार्ड, वॉलेट, ट्रांसफ़र और USDC एक पेज और एक रेफ़रेंस पर
FAQ
हर किसी से पूछने लायक सवाल।
नहीं। ऑर्केस्ट्रेशन जो भी फ़ायदे बेचता है — राउटिंग, कैस्केडिंग, रेट आर्बिट्राज — सब कई प्रोवाइडर मानकर चलते हैं। एक गेटवे के ऊपर वह लेयर बस फ़ीस और एक अतिरिक्त हॉप है, जिसके पास चुनने को कुछ नहीं।
सुधार सकता है, अगर आपके decline सच में राउटिंग से जुड़े हों और उन्हें भेजने के लिए वैकल्पिक रूट हों। अगर नुक़सान ऑथराइज़ेशन से पहले हो रहा है — ग़लत मेथड, भारी checkout, ज़रूरत से सख़्त 3-D Secure नीति — तो राउटिंग के पास करने को कुछ नहीं।
आम तौर पर नहीं। सेटलमेंट उसी अंतर्निहित प्रोवाइडर के पास रहता है जिसने पेमेंट लिया, इसलिए आपका रिकंसिलिएशन उन्हीं प्रोवाइडरों में फैला रहता है, जब तक प्लेटफ़ॉर्म इसे साफ़ तौर पर हल न करे। शुरू में ही पक्का कर लें — यह लोगों को चौंकाता है।
हाँ, अगर आपके गेटवे में शामिल हो। राउटिंग नीति, soft decline पर रीट्राई और पढ़ने लायक़ decline कारणों के लिए अलग प्लेटफ़ॉर्म नहीं चाहिए, जब वे पेमेंट लेने वाले गेटवे का ही हिस्सा हों।
पता लगाइए कि आपकी समस्या किस लेयर में है।
बताइए कि आप कितने प्रोवाइडर चलाते हैं और पेमेंट कहाँ फ़ेल हो रहे हैं। हम साफ़ बताएँगे कि इलाज राउटिंग है, checkout है, या दोनों नहीं — तब भी जब जवाब हम नहीं हैं।