এখন বিভিন্ন ধরনের software, mobile app, website বা online platform-এ payment system ব্যবহার করা হয়। Ecommerce website থেকে শুরু করে subscription-based application, marketplace, booking platform কিংবা অন্য যেকোনো ধরনের online service—অনেক ক্ষেত্রেই customer-এর কাছ থেকে payment নেওয়ার প্রয়োজন হয়।
কিন্তু payment নেওয়ার জন্য তো একটাই payment gateway নেই। Stripe, PayPal, Hubtel বা অন্য কোনো local কিংবা international payment provider ব্যবহার করতে হয়।
তখন প্রশ্ন আসতে পারে, এত ধরনের payment gateway কি প্রতিবার নতুন করে শুরু থেকে শিখতে হয়?
আমি কয়েকটা payment gateway নিয়ে কাজ করেছি। আর একটা জিনিস শুরু থেকেই আমার মাথায় ছিল—সব payment gateway আলাদা হলেও, payment নেওয়ার মূল process টা কিন্তু পুরোপুরি আলাদা না। Gateway ভেদে API আলাদা হতে পারে। কোথাও Payment Intent, কোথাও Order, কোথাও Transaction বা Checkout Session থাকতে পারে। কিন্তু এগুলোর পেছনের মূল কাজটা প্রায় একই।
Payment gateway integrate করার সময় আমি সাধারণত এই বিষয়গুলো মাথায় রাখি:
- Payment Initiation
- Payment Status
- Webhook / Callback
- Payment Verification
- Webhook Security
- Idempotency
- Refund
- Error & Retry Handling
- Payment Status Reconciliation
এখন এগুলো একটু সহজভাবে বলি।
১. Payment Initiation
ধরেন, আপনার website-এ একজন customer একটি product কিনতে চায়। সে payment button-এ click করলো। এখান থেকেই শুরু হলো Payment Initiation। আপনার backend payment gateway-কে বলবে, এই customer এত টাকা payment করবে, এই currency-তে করবে, এবং এই payment কোন order-এর জন্য। Gateway অনুযায়ী এই API-এর নাম আলাদা হতে পারে। কিন্তু concept একই—একটি payment process শুরু করা।
২. Webhook বা Callback এবং Security
তারপর customer payment করার পর আরেকটা গুরুত্বপূর্ণ বিষয় আসে—payment আসলেই successful হয়েছে কিনা, সেটা কীভাবে নিশ্চিত হব? এখানেই আসে Webhook বা Callback। Payment gateway সাধারণত আপনার backend-কে জানায় যে payment successful হয়েছে, failed হয়েছে, refund হয়েছে, ইত্যাদি। কিন্তু শুধু একটা request আসলেই সেটাকে বিশ্বাস করা যাবে না। দেখতে হবে request টা সত্যিই payment provider থেকে এসেছে কিনা। এজন্য অনেক gateway webhook signature verification দেয়। কিছু ক্ষেত্রে provider-এর নির্দিষ্ট IP allowlist করার সুবিধাও থাকতে পারে।
৩. Idempotency
ধরেন, কোনো কারণে একই payment request দুইবার চলে গেল। অথবা একই webhook একাধিকবার আসলো। এখন যদি আপনার system প্রতিবার সেটাকে নতুন event হিসেবে process করে, তাহলে একই order দুইবার update হতে পারে, এমনকি কিছু ক্ষেত্রে duplicate transaction-এর সমস্যাও হতে পারে। তাই একই কাজ বারবার request আসলেও যেন একবারের বেশি process না হয়, সেটা handle করতে হয়।
৪. Payment Status
Payment শুরু করলেই সবসময় সঙ্গে সঙ্গে successful হবে না। এটা pending থাকতে পারে, processing হতে পারে, failed হতে পারে, successful হতে পারে বা পরে refunded হতে পারে। তাই শুধু “paid” এবং “unpaid” রাখলেই সব situation handle করা যায় না। আপনার application-এর order এবং payment-এর অবস্থার সাথে gateway-এর payment status ঠিকভাবে synchronize করতে হয়।
৫. Payment Status Reconciliation
তবে একটা বিষয় মাথায় রাখা দরকার—সবসময় webhook বা callback আসবেই, এমন ধরে নেওয়া ঠিক না। Network issue, temporary server problem, webhook delivery failure বা অন্য কোনো কারণে আপনার system webhook নাও পেতে পারে। ধরেন, customer payment successfully করেছে, কিন্তু কোনো কারণে আপনার backend সেই webhook পেল না। তাহলে database-এ order এখনও PENDING, কিন্তু gateway-এর কাছে payment SUCCESSFUL। এই ধরনের situation handle করার জন্য শুধু webhook-এর উপর পুরোপুরি নির্ভর না করে, pending বা uncertain অবস্থায় থাকা payment গুলো background job দিয়ে সময় সময় check করা যেতে পারে। সেখানে gateway-এর API ব্যবহার করে payment-এর latest status যাচাই করা যায়।
সহজভাবে flow টা এমন হতে পারে: Order Pending → Webhook পাওয়া যায়নি → Background Job → Gateway থেকে Latest Status Check → Order/Payment Update। এটাকে অনেকটা নিজের system এবং payment gateway-এর মধ্যে status মিলিয়ে নেওয়া বা Payment Status Reconciliation বলা যায়। এভাবে কোনো কারণে webhook miss হলেও payment-এর আসল অবস্থার সাথে নিজের database-এর অবস্থাটা পরে synchronize করা সম্ভব।
৬. Refund
Refund-এর ক্ষেত্রেও একই ব্যাপার। এক gateway-তে refund API একভাবে কাজ করবে, অন্য gateway-তে অন্যভাবে। কিন্তু concept একই—আগের একটি successful payment-এর টাকা customer-কে ফেরত দেওয়া এবং সেই পরিবর্তনটা নিজের system-এ track করা।
উপসংহার
আমার কাছে নতুন payment gateway integrate করার সময় সবচেয়ে বড় সুবিধাটা এখানেই। আমি নতুন করে ভাবি না, “এই gateway আবার কীভাবে কাজ করে?” বরং আগে দেখি, আমার জানা flow-গুলো এই gateway কীভাবে implement করেছে। Payment শুরু করার API কোনটা? Payment successful হওয়ার খবর কীভাবে পাব? Webhook কীভাবে verify করব? একই request দুইবার এলে কী হবে? কোনো কারণে webhook না এলে payment-এর আসল status কীভাবে check করব? Payment failed বা refund হলে system কীভাবে update করব? এই প্রশ্নগুলোর উত্তর খুঁজলেই নতুন gateway-এর documentation অনেক সহজ মনে হয়। তাই আমার কাছে payment gateway integration মানে শুধু API call করা না—মূল concept গুলো বুঝে নেওয়া। তারপর নতুন gateway এলে সেই concept-এর সাথে তাদের API এবং documentation-কে মিলিয়ে নেওয়া। Gateway পরিবর্তন হবে, API পরিবর্তন হবে, নাম পরিবর্তন হবে। কিন্তু payment-এর মূল flow এবং যে সমস্যাগুলো handle করতে হয়, সেগুলোর অনেকটাই একই থাকবে।