পেমেন্ট লাইফসাইকেল: authorization থেকে settlement
পেমেন্ট লাইফসাইকেল হলো একটি নির্দিষ্ট ধারাবাহিক ক্রম, যা ধরে পেমেন্ট অনুমোদনের মুহূর্ত থেকে মার্চেন্টের অ্যাকাউন্টে অর্থ পৌঁছানো পর্যন্ত এগোয়: authorization, capture, clearing, settlement ও payout। প্রতিটি ধাপ ঠিক একটি কাজ করে, এবং প্রতিটি ধাপের পর অর্থ আলাদা অবস্থায় থাকে। বেশিরভাগ মানুষ কার্ড পেমেন্টকে ট্যাপের মুহূর্তের একটি একক ঘটনা ভাবেন; আসলে এটি একটি শৃঙ্খল, আর পেমেন্টে প্রায় যা কিছু ঠিক বা ভুল হয়, তার কারণ এই ধাপগুলো আলাদা, একসঙ্গে ঘটে না।
এই শৃঙ্খল বোঝাই নিজে থেকে reconcile হওয়া পেমেন্ট আর সাপোর্ট টিকিটের মধ্যে পার্থক্য গড়ে দেয়। তাই একবার শুরু থেকে শেষ পর্যন্ত, ক্রম ধরে হেঁটে দেখা যাক।
Authorization: একটি hold, ট্রান্সফার নয়
Authorization একটি প্রশ্ন, অর্থের চলাচল নয়। কার্ড ট্যাপ করা হলে অনুরোধটি issuer-এর কাছে যায়, যা যাচাই করে অ্যাকাউন্টটি আছে কি না, ভালো অবস্থায় আছে কি না, এবং ওই পরিমাণের জন্য ব্যালান্স বা ক্রেডিট আছে কি না। থাকলে সে একটি hold বসায় — অর্থ আলাদা করে রাখে যাতে দুবার খরচ না হয় — এবং একটি authorization code ফেরত দেয়। কোনো অর্থ সরেনি। মার্চেন্টের হাতে এখন একটি প্রতিশ্রুতি আছে যে অর্থ ঠিক আছে, যা scheme-নির্ধারিত সময়সীমা পর্যন্ত বৈধ। কিছু সংগ্রহের আগে authorization বাতিল (void) করা যায়, আর ব্যবহার না হলে তা নিজেই মেয়াদোত্তীর্ণ হয়। এ কারণেই পেমেন্টের মুহূর্তেই কার্ডের ব্যালান্স কমে যায়, অথচ স্টেটমেন্টের লাইনটি পাকা হয় পরে: কমে যাওয়াটা hold, চার্জ নয়। Authorization সরাসরি decline-ও হতে পারে — অপর্যাপ্ত ব্যালান্স, ফ্রড রুল, মেয়াদোত্তীর্ণ কার্ড — এবং ভালো gateway পুনরায় চেষ্টা করার যোগ্য soft decline আর করা উচিত নয় এমন hard decline আলাদা করে। যেহেতু hold হলো issuer-এর প্রতিশ্রুতি যে অর্থ ঠিক আছে, তাই গ্রাহকের অ্যাকাউন্ট থেকে একটি টাকাও বের হওয়ার আগেই শুধু authorization code-এর ভরসায় মার্চেন্ট নিরাপদে পণ্য হস্তান্তর করতে পারে।
Capture: hold-কে দাবিতে রূপান্তর
Capture হলো মার্চেন্টের বলা “এখনই এটি সংগ্রহ করো।” এটি hold-কে অর্থের জন্য প্রকৃত অনুরোধে রূপ দেয়। Capture পূর্ণ হতে পারে, আংশিক হতে পারে (authorize করা অঙ্কের চেয়ে কম চূড়ান্ত অঙ্ক — pre-auth-এর চেয়ে সস্তা একটি পাঠানো পণ্য), অথবা বিলম্বিত হতে পারে (অর্ডারের সময় authorize, ডিসপ্যাচের সময় capture)। দোকানের কাউন্টারে auth ও capture একটি ধাপে হওয়াই ডিফল্ট; হোটেল, ফুয়েল পাম্প ও মার্কেটপ্লেস চলে শুধু auth করে পরে capture করার নিয়মে, কারণ কার্ড দেখানোর সময় তারা চূড়ান্ত অঙ্ক জানে না। Authorization ও capture-এর মধ্যবর্তী ফাঁকটি ইচ্ছাকৃত ও কাজের একটি জোড়: এখানেই মার্চেন্ট ঠিক করে প্রকৃতপক্ষে কত চার্জ করবে।
Clearing: যে batch মিলিয়ে দেয়
Capture হওয়া পেমেন্ট রিয়েল টাইমে একটি একটি করে settle হয় না। সেগুলো ফাইলে জড়ো হয়ে মার্চেন্টের acquirer ও card scheme-এর মধ্যে batch আকারে বিনিময় হয় — এটিই clearing। এই ধাপে লেনদেনগুলো মেলানো হয়, অঙ্কগুলো net করা হয়, এবং scheme fee ও interchange প্রয়োগ করা হয়, যাতে কে কাকে কত দেবে সে বিষয়ে সবাই একমত হয়। Clearing একটি reconciliation-এর কাজ, অর্থের চলাচল নয়: এটি সেই সম্মত মোট অঙ্ক তৈরি করে যার ওপর পরের ধাপ কাজ করে। কাঠামোগতভাবে এটি একটি batch প্রক্রিয়াও — আর কাউন্টারে তাৎক্ষণিক মনে হওয়া পেমেন্ট নগদ হয়ে পৌঁছাতে কয়েক দিন লাগার আসল কারণ এটিই। Batch-এর এই ধরন কম্পিউটারের কোনো সীমাবদ্ধতা নয়; হাজার হাজার প্রতিষ্ঠানকে দক্ষভাবে একে অপরের বিপরীতে net করার জন্যই scheme-গুলো এভাবে তৈরি, প্রতি কাপ কফির জন্য ট্রান্সফার না চালিয়ে প্রতি চক্রে একবার সম্মত মোট অঙ্ক বিনিময় করা হয়।
Authorization একটি প্রতিশ্রুতি, capture একটি দাবি, আর settlement-ই একমাত্র ধাপ যেখানে অর্থ সত্যিই সরে। তিনটিকে গুলিয়ে ফেললে ব্যবসা এমন রাজস্ব বুক করে যা এখনও তার হাতে আসেনি।
Settlement: অর্থ সত্যিই সরে
Settlement হলো যেখানে ব্যাংকগুলোর মধ্যে অর্থ সত্যিই হাতবদল হয়। Clearing থেকে পাওয়া net অঙ্ক ব্যবহার করে scheme অর্থ issuer থেকে acquirer-এর কাছে সরায়, প্রতিটি প্রতিষ্ঠান আলাদা আলাদা লেনদেনের বদলে তার net পজিশন settle করে। Settlement চলে একটি value date অনুযায়ী — যেদিন অর্থ প্রকৃতপক্ষে ব্যবহারযোগ্য হয় — আর সে কারণেই পেমেন্টে T+1 বা T+2 ছন্দ থাকে: অর্থ বাস্তব, কিন্তু তা আসে scheme-এর ক্যালেন্ডারে, গ্রাহকের ঘড়িতে নয়। এর আগের সবকিছু ছিল খাতাকলমের হিসাব; এই ধাপেই ledger এন্ট্রি ব্যবহারযোগ্য ব্যালান্সে পরিণত হয়। net হিসাবে যে প্রতিষ্ঠান দেনা, সে দেয়; যে পাওনা, সে পায় — আর net বলেই ব্যাংকগুলোর মধ্যে প্রকৃতপক্ষে যে অঙ্ক সরে তা দিনের পেমেন্টের gross মূল্যের একটি ভগ্নাংশ, যার ফলে লাখো লেনদেন বহনকারী একটি scheme-এর settlement চলাচল হাতেগোনা সংখ্যায় থাকে।
Payout: acquirer থেকে আপনার অ্যাকাউন্টে
Settlement অর্থ acquirer-এর কাছে পৌঁছে দেয়; payout তা মার্চেন্টের কাছে নেয়। একটি সূচি অনুযায়ী — দৈনিক, সাপ্তাহিক বা চাহিদামতো — acquirer মার্চেন্টের জমা ব্যালান্স তার ব্যাংক অ্যাকাউন্টে পাঠায়, প্রসেসিং ফি এবং রিফান্ড ও ডিসপিউটের জন্য রাখা কোনো রিজার্ভ বাদ দিয়ে। ব্যবসা বাস্তবে এই অঙ্কটিই দেখে, আর এখানেই reconciliation হয় কাজ করে, নয়তো কষ্ট দেয়: payout অনেক লেনদেন মিলিয়ে একটি net অঙ্ক, তাই একে আলাদা আলাদা অর্ডারের সঙ্গে মেলানো নিজেই একটি কাজ। যে gateway প্রতিটি অর্ডারের পরিচয় শেষ পর্যন্ত বহন করে, সে এটি সহজ করে দেয়; যে করে না, সে প্রতিটি payout-কে স্প্রেডশিটে পরিণত করে। আমাদের gateway-র ফ্লো, /products/gateway, এমনভাবে তৈরি যাতে একটি payout তার অন্তর্ভুক্ত অর্ডারগুলোর সঙ্গে reconcile হয়।
যেখানে ক্রিপ্টো একটি ব্রিজ যোগ করে
ক্রিপ্টো বা stablecoin পেমেন্ট এই শৃঙ্খলকে প্রতিস্থাপন করে না — এর সামনে একটি রূপান্তর লেগ যোগ করে। Issuer-এর authorization hold-এর বদলে পেমেন্ট on-chain নিশ্চিত হয়: গ্রাহক একটি ট্রান্সফারে সই করেন, আর ব্যাংক hold অনুমোদন করার বদলে নেটওয়ার্ক কনফার্মেশন যোগ করার সঙ্গে সঙ্গে finality আসে। নিশ্চিত হওয়ার পর একটি off-ramp ক্রিপ্টোকে ফিয়াটে রূপান্তর করে, এবং সেখান থেকে অর্থ অন্য সব পেমেন্টের মতো একই clearing, settlement ও payout পথে ঢোকে। নতুনত্ব ওই প্রথম লেগেই সীমাবদ্ধ; পেছনের অর্ধেক ইচ্ছাকৃতভাবে সাদামাটা থাকে। এটাই ডিজাইনের নিয়ম — settlement সাধারণ রাখুন এবং নতুন প্রক্রিয়া কেবল সেখানেই রাখুন যেখানে তা অনিবার্য — কারণ নিচের দিকের treasury, reconciliation ও অডিটর যেন বুঝতেই না পারে পেমেন্টটি কীভাবে শুরু হয়েছিল। কতগুলো কনফার্মেশনকে চূড়ান্ত ধরা হবে তা নীতিগত সিদ্ধান্ত, চেইনের কোনো বিধান নয়: উঁচু মান reorganisation-এর বিরুদ্ধে নিশ্চয়তার জন্য গতি ছাড়ে, আর ঝুঁকির সহনশীলতা যে গভীরতা ঠিক করে, settlement পথে ফিয়াট ছাড়ার আগে off-ramp ততটাই অপেক্ষা করে।
কেন এই জোড়গুলো অপারেশনের জন্য গুরুত্বপূর্ণ
রিফান্ড, reversal ও ডিসপিউট প্রতিটি একটি নির্দিষ্ট ধাপের সঙ্গে যুক্ত, আর ধাপটি ঠিকভাবে চেনাই পুরো খেলা। Capture-এর আগে বাতিল করলে আপনি একটি authorization void করেন — কোনো অর্থ কখনও সরেনি, ফেরত দেওয়ার কিছু নেই। Settlement-এর পরে বাতিল করলে আপনি রিফান্ড দেন — বিপরীত দিকে একটি নতুন পেমেন্ট, যার নিজস্ব লাইফসাইকেল আছে। Chargeback clearing পর্যন্ত পেছনে গিয়ে settle হয়ে যাওয়া অঙ্ক ফিরিয়ে আনে। সবগুলোকে একটাই অভেদ “cancel” ধরলে ledger সরে যায়; আলাদা আলাদা ধাপের ওপর অপারেশন হিসেবে দেখলে প্রতিটি ক্ষেত্রে একটি সঠিক, অডিটযোগ্য পদক্ষেপ থাকে। শব্দভান্ডার — authorization, capture, clearing, settlement, value date — /glossary-তে সংকলিত আছে।
যে একটি ধারণা সঙ্গে নিয়ে যাওয়ার মতো: পেমেন্ট একটি ঘটনা নয়, অবস্থার শৃঙ্খল। Authorization সংরক্ষণ করে, capture দাবি করে, clearing সম্মত হয়, settlement সরায়, payout পৌঁছে দেয় — আর ক্রিপ্টো লেগ কেবল সামনে একটি রূপান্তর জুড়ে দেয়। Settlement পর্যন্ত অর্থ একটি প্রতিশ্রুতি, তার পর একটি বাস্তবতা; আর যে ব্যবসা বাস্তবতার আগেই তা বুক করে, সে এমন অর্থ গুনছে যা তার এখনও নেই। পেমেন্ট কোন অবস্থায় আছে তা জানুন, বাকি পেমেন্ট অপারেশন আর রহস্যময় থাকবে না।
কোনো সিস্টেম বানাতে চান?
সমস্যাটা আমাদের জানান। আমরা আর্কিটেকচার ও একটি পরিকল্পনা নিয়ে ফিরে আসব।