तुलना / श्रेणियाँ
पेमेंट गेटवे बनाम पेमेंट ऑर्केस्ट्रेशन
दोनों शब्द एक-दूसरे की जगह इस्तेमाल होते हैं, पर मतलब अलग हैं। गेटवे पेमेंट लेता है: मेथड दिखाता है, ऑथराइज़ करता है, कैप्चर करता है और सेटल करता है। ऑर्केस्ट्रेशन प्लेटफ़ॉर्म गेटवे के ऊपर बैठता है और हर ट्रांज़ैक्शन के लिए तय करता है कि कौन-सा इस्तेमाल हो। दूसरे की ज़रूरत है या नहीं, यह लगभग पूरी तरह इस पर निर्भर है कि आपके पास पहले से कितने प्रोवाइडर हैं, और क्यों हैं।
श्रेणी बनाम श्रेणी
हर परत असल में किसलिए है
जब आपको सिर्फ़ gateway चाहिए
अगर आपके पास एक ही प्रोवाइडर है, या आप अपना पहला चुन रहे हैं, तो ऑर्केस्ट्रेशन लेयर के पास ऑर्केस्ट्रेट करने को कुछ नहीं होता। यह जो फ़ायदे बेचती है — एक्वायरर्स के बीच routing, decline होने पर दूसरे प्रोवाइडर पर cascade करना, कॉरिडोर के हिसाब से रेट आर्बिट्रेज — सब मानकर चलते हैं कि आप पहले से कई प्रोवाइडर्स के साथ काम कर रहे हैं। एक gateway के ऊपर लेयर जोड़ने से आपको बस एक फ़ीस और एक अतिरिक्त hop मिलता है। इस चरण पर असल में नतीजे बदलते हैं: मेथड कवरेज, कन्वर्ट करने वाला checkout और साफ़-सुथरा reconciliation।
- 01आपके पास एक प्रोवाइडर है, या आप पहला चुन रहे हैं
- 02आपकी conversion की समस्या मेथड कवरेज है, routing नहीं
- 03आप कई एक्वायरर्स के साथ संबंध नहीं संभालना चाहते
- 04एक reconciliation मॉडल, अप्रूवल रेट के एक पॉइंट से ज़्यादा मायने रखता है
जब ऑर्केस्ट्रेशन अपनी फ़ीस वसूल करता है
जब वॉल्यूम इतना बड़ा हो कि एक प्रतिशत का अंश भी असली पैसा बन जाए, और आपके पास पहले से कई एक्वायरिंग संबंध हों क्योंकि कोई एक आपके मार्केट, आपकी रिस्क प्रोफ़ाइल या आपके रेट पूरे नहीं करता। इस स्तर पर issuer और कॉरिडोर के हिसाब से routing, soft decline को दूसरे एक्वायरर पर cascade करना और सभी प्रोवाइडर्स की रिपोर्टिंग को एक समान बनाना अच्छे विचार नहीं रहते, P&L की एक लाइन बन जाते हैं। शर्त हर मामले में एक ही है: कई प्रोवाइडर, जिन्हें रखने की आपके पास वजह हो।
- 01आप कवरेज, रिडंडेंसी या रेट के लिए पहले से कई एक्वायरर्स चला रहे हैं
- 02वॉल्यूम के कारण अप्रूवल रेट का एक पॉइंट, लेयर की फ़ीस से ज़्यादा मूल्यवान है
- 03आपको ऐसे प्रोवाइडर्स के बीच एक रिपोर्टिंग मॉडल चाहिए जिनके आँकड़े आपस में मेल नहीं खाते
- 04प्रोवाइडर्स के बीच failover कारोबार की ज़रूरत है, सिर्फ़ अच्छा-to-have नहीं
Protocore कहाँ फ़िट बैठता है
Protocore Gateway पहली लेयर है — यह पेमेंट लेता है और पैसा settle करता है — और दूसरी लेयर के वे हिस्से इसमें पहले से शामिल हैं जो एक-प्रोवाइडर वाले कारोबार के काम आते हैं, ऊपर से बेचे नहीं जाते: पढ़ी जा सकने वाली routing पॉलिसी, ग्राहक को failure दिखने से पहले वैकल्पिक रूट पर retry, और ऐसे decline कारण जिन पर ऑपरेटर सीधे कार्रवाई कर सके। अगर आप उस मोड़ पर पहुँचते हैं जहाँ आपको अपने एक्वायरर्स के बीच routing की सचमुच ज़रूरत हो, तो whitelabel प्लेटफ़ॉर्म आपके एक्वायरर्स को हमारे साथ जोड़ देता है। सीधी बात यह है कि यह सवाल पूछने वाले ज़्यादातर कारोबारों को बेहतर gateway चाहिए, मौजूदा gateway के ऊपर कोई लेयर नहीं।
- 01settle करने वाला gateway, routing और retry पॉलिसी के साथ
- 02कार्ड, वॉलेट, बैंक ट्रांसफ़र और USDC, एक पेज और एक reference पर
- 03whitelabel प्लेटफ़ॉर्म पर आपके अपने एक्वायरर्स हमारे साथ जुड़े
- 04एक प्रोवाइडर को ऑर्केस्ट्रेट करने पर कोई लेयर फ़ीस नहीं
आपकी समस्या किस लेयर में है?
बताइए कि आप कितने प्रोवाइडर्स चलाते हैं और पेमेंट कहाँ फ़ेल हो रहे हैं। हम बताएँगे कि समाधान routing में है या gateway में।