বিকল্প / Orchestration
পেমেন্ট orchestration-এর বিকল্প খুঁজছেন
orchestration বিক্রি হয় approval rate ও খরচ সাশ্রয়ের কথা বলে, এবং দুটিই বাস্তব, তবে একটি স্কেলের ওপরে এবং একাধিক acquirer থাকলে। এর নিচে layer শুধু একটি ফি, একটি নির্ভরতা এবং অতিরিক্ত একটি hop যোগ করে, routing-এ কোনো লাভ ছাড়াই। সৎ মূল্যায়ন শুরু হয় আপনি সেই রেখার কোন পাশে তা বের করে।
যাচাই করুন
layer যোগ করার আগে ছয়টি প্রশ্ন।
আপনি আসলে কয়টি প্রোভাইডার চালান?
একটি acquirer থাকলে routing করার মতো কিছু নেই। প্রস্তাবিত সব লাভই ধরে নেয় যে আপনার রাখার কারণ আছে এমন একাধিক সম্পর্ক রয়েছে।
এক পয়েন্ট approval rate আপনার কাছে কতটুকু মূল্যবান?
বার্ষিক ভলিউমের সাথে গুণ করে দেখুন, তারপর layer-এর ফি ও তা চালানোর ইঞ্জিনিয়ারিংয়ের সাথে তুলনা করুন। ছোট ভলিউমে এই হিসাব প্রায়ই টেকে না।
আপনার decline সমস্যা কি সত্যিই routing-এর?
যা routing সমস্যা মনে হয়, তার অনেকটাই আসলে মেথড কাভারেজ, authorization-এর আগেই গ্রাহক হারানো চেকআউট, অথবা অতি কড়া 3-D Secure নীতি।
টাকা settle করে কে?
orchestrator সাধারণত করে না। settlement থাকে যে প্রোভাইডার পেমেন্ট নিয়েছে তার কাছেই, অর্থাৎ layer এটিও সমাধান না করলে আপনার reconciliation এখনও একাধিক প্রোভাইডারজুড়ে থাকে।
আপনার রিপোর্টিংয়ের কী হবে?
পরস্পরবিরোধী প্রোভাইডারগুলোর রিপোর্টিং normalise করাই প্রায়ই আসল মূল্য। ডেমো ডেটাসেটে নয়, আপনার নিজের প্রোভাইডার মিশ্রণে তা দেখতে চান।
layer-টি নির্ভরতার দিক থেকে আপনার কত খরচ ঘটায়?
প্রতিটি পেমেন্টের পথে আপনি একটি সিস্টেম যোগ করছেন। এটি degraded হলে কী হয়, আর সরাসরি প্রোভাইডারে fail over করা যায় কি না, জিজ্ঞেস করুন।
orchestration যখন সত্যিই সমাধান
যখন কোনো একক প্রোভাইডার আপনার মার্কেট, ঝুঁকি প্রোফাইল বা রেট কভার করে না বলে আপনার ইতিমধ্যে একাধিক acquiring সম্পর্ক আছে, এবং আপনার ভলিউম এত বড় যে শতাংশের ভগ্নাংশও আসল অর্থ। তখন issuer ও corridor অনুযায়ী routing, soft decline দ্বিতীয় acquirer-এ cascade করা, এবং প্রোভাইডারজুড়ে একটি রিপোর্টিং মডেল আর ভালো ধারণা থাকে না, P&L-এর একটি লাইন হয়ে ওঠে। পূর্বশর্ত কখনো বদলায় না: রাখার কারণ আছে এমন একাধিক প্রোভাইডার।
- 01কাভারেজ, redundancy বা রেটের জন্য রাখা একাধিক acquirer
- 02যে ভলিউমে এক পয়েন্ট approval layer-এর ফির চেয়ে বেশি মূল্যবান
- 03ব্যবসায়িক প্রয়োজন হিসেবে প্রোভাইডারদের মধ্যে failover
- 04পরস্পরবিরোধী প্রোভাইডারজুড়ে একটি রিপোর্টিং মডেল
যখন এটি ভুল কেনাকাটা
যখন আপনার একটিমাত্র প্রোভাইডার, অথবা যে সমস্যা সমাধান করছেন তা routing-এর আগের ধাপে। একক gateway-এর ওপরে layer যোগ করলে শুধু একটি ফি ও একটি অতিরিক্ত hop কেনা হয়। আর গ্রাহকের পছন্দের মেথড পেজে না থাকায়, authorization-এর আগেই চেকআউটে গ্রাহক হারানোয়, বা 3-D Secure অপ্রয়োজনে ট্রাফিকে challenge দেওয়ায় পেমেন্ট ব্যর্থ হলে কোনো routing তা ফেরাতে পারে না। সমাধান চেকআউটে, তার ওপরে নয়।
- 01একটিমাত্র প্রোভাইডার, orchestrate করার কিছু নেই
- 02ক্ষতি authorization-এ নয়, তার আগেই ঘটে
- 03আসল ফাঁক routing নয়, মেথড কাভারেজ
- 04আপনার ভলিউমে ফি routing-এর লাভের চেয়ে বেশি
Protocore Gateway কোথায় মানায়
আমরা নিচের layer, অর্থাৎ যে gateway পেমেন্ট নেয় এবং টাকা settle করে, আর একক-প্রোভাইডার ব্যবসার জন্য orchestration-এর গুরুত্বপূর্ণ অংশগুলো ওপরে বিক্রি না করে ভেতরেই দেওয়া: আপনার চেনা ভাষায় লেখা routing policy, গ্রাহক ব্যর্থতা দেখার আগে বিকল্প route-এ retry, এবং অপারেটর কাজে লাগাতে পারেন এমন decline কারণ। সত্যিই multi-acquirer স্কেলে পৌঁছালে whitelabel প্ল্যাটফর্ম আমাদেরগুলোর পাশাপাশি আপনার নিজের acquirer সংযুক্ত করে। এই প্রশ্ন করা বেশিরভাগ ব্যবসার দরকার একটি ভালো gateway, বিদ্যমান gateway-এর ওপরে আরেকটি layer নয়।
- 01routing policy ও retry অন্তর্ভুক্ত, কোনো layer ফি ছাড়া
- 02একটি কারেন্সিতে আসলেই settle করা gateway
- 03whitelabel প্ল্যাটফর্মে আপনার নিজের acquirer সংযুক্ত
- 04কার্ড, ওয়ালেট, ট্রান্সফার ও USDC একটি পেজে ও একটি রেফারেন্সে
FAQ
যে কাউকে করার মতো প্রশ্ন।
না। orchestration যা কিছু বিক্রি করে, routing, cascading, rate arbitrage, সবই একাধিক প্রোভাইডার ধরে নেয়। একটি gateway-এর ওপরে layer মানে একটি ফি ও একটি অতিরিক্ত hop, যেখানে বেছে নেওয়ার কিছু নেই।
বাড়াতে পারে, যদি আপনার decline সত্যিই routing-ধরনের হয় এবং পাঠানোর মতো বিকল্প route থাকে। ক্ষতি authorization-এর আগে ঘটলে, যেমন ভুল মেথড, ভারী চেকআউট, বা অতি কড়া 3-D Secure নীতি, routing-এর কাজ করার কিছু থাকে না।
সাধারণত না। settlement থাকে যে অন্তর্নিহিত প্রোভাইডার পেমেন্ট নিয়েছে তার কাছেই, তাই প্ল্যাটফর্ম স্পষ্টভাবে এটিও সমাধান না করলে আপনার reconciliation ওই প্রোভাইডারগুলোজুড়েই থাকে। শুরুতেই নিশ্চিত করে নিন, এটি অনেককে অবাক করে।
হ্যাঁ, যদি আপনার gateway-তে তা থাকে। পেমেন্ট নেওয়া gateway-এরই অংশ হলে routing policy, soft decline-এ retry এবং পাঠযোগ্য decline কারণের জন্য আলাদা প্ল্যাটফর্ম লাগে না।
আপনার সমস্যা কোন layer-এ, তা বের করুন।
আপনি কয়টি প্রোভাইডার চালান আর কোথায় পেমেন্ট ব্যর্থ হচ্ছে তা জানান। সমাধান routing, চেকআউট, নাকি দুটোর কোনোটিই, তা আমরা স্পষ্ট বলব, উত্তর আমরা না হলেও।