ট্রাফিক পরিসংখ্যানের জন্য আমরা Google Analytics ব্যবহার করি। আপনি সম্মতি দিলেই কেবল অ্যানালিটিক্স কুকি সেট হয়। সম্মতি না দিলে কুকিবিহীন সিগন্যাল থেকে পরিসংখ্যান অনুমান করা হয়। কুকি নীতি.
Gateway · পেমেন্ট
একটি ওয়ার্কড উদাহরণ পুরো পেজ জুড়ে চলে — Arc Studio SRL, অর্ডার 9F21-0716, €49.00। গ্রাহক বেছে নেন কার্ড, Apple Pay, Google Pay, USDC বা ব্যাংক ট্রান্সফার, আর মার্চেন্টের দিকের গল্প একই থাকে — একটি রেফারেন্স, একটি রসিদ, একটি ইউরো অ্যামাউন্ট।
নিশ্চয়তা
মেথডের বিভক্তি মার্চেন্টেরই মাথাব্যথা, আর তা জমতে থাকে: নিজস্ব ড্যাশবোর্ডসহ একটি কার্ড প্রসেসর, নিজস্ব রিলিজ সাইকেলসহ একটি ওয়ালেট SDK, আলাদা পেজে থাকা এবং কোথাও রিকনসাইল না হওয়া একটি ক্রিপ্টো অপশন। প্রতিটি নতুন মেথড মানে আরেকটি ইন্টিগ্রেশন, আরেক সেট রিপোর্ট, আরেকটি জায়গা যেখানে পেমেন্ট হারিয়ে যেতে পারে। Gateway এসবকে এক পেজ ও এক রেকর্ডে গুটিয়ে আনে।
মোবাইলে একই checkout — এক পেজে কার্ড, ওয়ালেট ও USDC। · রসিদ — 52.95 USDC এসেছে, €49.00 সেটেল হয়েছে, স্পষ্ট ভাষায়।
কার্ড, Apple Pay, Google Pay, USDC, ব্যাংক ট্রান্সফার এবং আপনার ক্রেতারা যেসব লোকাল মেথড আশা করেন, সবই থাকে একই হোস্টেড পেজে, সামনের গ্রাহক সম্ভবত যেটি ব্যবহার করবেন সেই ক্রমে সাজানো। পেজ ডেস্কটপ, ফোন ও ইন-অ্যাপে মানিয়ে নেয়; নতুন মেথড চালু করা একটি টগল, কোনো প্রজেক্ট নয়।
লিংক ব্যাক অফিস — প্রতিটি লিংক তার স্ট্যাটাসসহ, এ মাসে সংগৃহীত €2,304.50।
USDC-র দাম নির্ধারিত হয় গ্রাহক কনফার্ম করার আগে পেজে দেখানো রেটে, সেটেল হয় ইউরোতে, এবং কার্ডের আয়ের সঙ্গে একই পেআউটে এসে পৌঁছায়। আপনাকে কখনো টোকেন পজিশন ধরে রাখতে হয় না, ট্রেজারি ফাংশন খুলতে হয় না, আর আপনার অ্যাকাউন্ট্যান্ট কখনো দ্বিতীয় কারেন্সি দেখেন না। রসিদে রূপান্তর এক লাইনে লেখা থাকে — গ্রাহক ক্রিপ্টোতে দিয়েছেন; খাতায় আছে €49.00।
রিফান্ড চলমান — অর্ডারের বিপরীতে, কারণ বাধ্যতামূলক, ফেরত যায় মূল রুটে।
সবকিছু ঝোলে অর্ডারের সঙ্গে, পেমেন্ট মেথডের সঙ্গে নয়। অর্ডার 9F21-0716 বহন করে তার লাইন আইটেম, €0.50 প্রসেসিং ফি, মোট অঙ্ক, অথরাইজেশনের ফল, রসিদ ও রিফান্ড। তাই রিকনসিলিয়েশন একটি লুকআপ, ডিসপিউট একটি স্ক্রিন, আর রিফান্ড অর্ডারকে নির্দেশ করে — কার্ড, ওয়ালেট বা চেইনকে নয়।
Checkout ব্র্যান্ডিং — লোগো, রং, টাইপ ও কর্নার, সেভ করার আগে লাইভ প্রিভিউ।
কার্ড আমাদের দিকে ভল্টে রাখা হয় এবং টোকেন দিয়ে রেফার করা হয়, তাই ফিরে আসা গ্রাহক এক ট্যাপে পেমেন্ট করেন আর আপনার সিস্টেম কার্ড নম্বরের বদলে একটি রেফারেন্স সংরক্ষণ করে। সাবস্ক্রিপশন আপনার নির্ধারিত সময়সূচিতে সেই টোকেনের বিপরীতে চলে, নিজের soft decline নিজেই রিট্রাই করে, এবং রিইস্যুর পরও কার্ডধারীকে অনুসরণ করে — প্রতিটি সাইকেল তৈরি করে নিজস্ব অর্ডার ও নিজস্ব রসিদ।
মেথড কনফিগ — প্রতি checkout-এ মেথড টগল, পাশে সেটেলমেন্ট ও রাউটিং।
কার্ড ট্রাফিক চলে আপনার চেনা ভাষায় লেখা একটি রাউটিং পলিসি অনুযায়ী, soft decline হলে গ্রাহক ব্যর্থতা দেখার আগেই বিকল্প রুটে রিট্রাই করে, এবং 3-D Secure-এ যায় পলিসি চাইলে, ডিফল্টভাবে নয়। কোনো পেমেন্ট সত্যিই প্রত্যাখ্যাত হলে কারণ আসে অপারেটরের কাজে লাগার মতো ভাষায়, ইস্যুয়ারের কাঁচা কোডে নয়।
লোগো আপলোড করুন, রং, টাইপ ও কর্নার ঠিক করুন, আর সেভ করার আগে আসল checkout-এর প্রিভিউ দেখুন। চালান আমাদের ডোমেইনে, আপনার ডোমেইনে, বা আপনার নিজের অ্যাপের ভেতরে — powered-by ফুটারসহ বা পুরোপুরি whitelabel। ডেমো checkout-টি Arc Studio SRL-এর, আর দেখতেও তাদেরই মনে হয়।
পদ্ধতি
checkout-এ দেখানো প্রতিটি পদ্ধতি, তার পেছনের rail, আর যে মুদ্রায় অর্থ জমা হয়। আসল কথা ডান কলামে: গ্রাহক যা-ই বেছে নিন, মার্চেন্টের payout একটাই ইউরো অঙ্ক।
ইন্টিগ্রেশন
idempotency key দিয়ে একটি অর্ডার তৈরি করুন, hosted checkout-এ রিডাইরেক্ট করুন, signed ফলাফল গ্রহণ করুন। পুরো ইন্টিগ্রেশন মাত্র কয়েকটি endpoint আর একটি webhook।
কোনো ইন্টিগ্রেশন ছাড়াই — back office থেকে লিংক তৈরি করুন, একবার-ব্যবহারযোগ্য বা সংগ্রহমূলক, তারপর পাঠিয়ে দিন। পেমেন্ট জমা হয় API-র পেমেন্টের মতো একই জায়গায়।
iOS ও Android-এ একই checkout নেটিভভাবে দেখানো হয়, ফলে wallet শিট ও 3-D Secure-এর সময়ও গ্রাহক আপনার অ্যাপের ভেতরেই থাকেন।
ডেভেলপার ছাড়াই বিদ্যমান স্টোরফ্রন্ট যুক্ত করুন: ইনস্টল করুন, কী পেস্ট করুন, sandbox কার্ডে একটি টেস্ট পেমেন্ট নিন।
নিজের লেআউট রাখুন, শুধু পেমেন্ট ইনপুট এমবেড করুন। সেগুলো আমাদের দিকে hosted ও PCI-স্কোপে থাকে, তাই কার্ডের ডেটা এখনও আপনার সার্ভারে পৌঁছায় না।
ইন্টিগ্রেশন
আপনার backend API দিয়ে অর্ডার তৈরি করে: অঙ্ক, মুদ্রা, আপনার রেফারেন্স।
গ্রাহক hosted page-এ কার্ড, wallet বা USDC বেছে নেন।
অর্থ যাচাই করে আটকে রাখা হয়; নীতি দাবি করলে তবেই 3-D Secure যুক্ত হয়।
চার্জ সম্পন্ন হয় এবং settlement-এর সারিতে যায়।
একটি signed order.paid webhook আসে; স্বাক্ষর যাচাই করুন এবং অর্ডার পূরণ করুন।
দিনের অর্ডার ব্যাচ হয়ে EUR-এ payout হয় — checkout থেকে ব্যাংক লাইন পর্যন্ত একটাই রেফারেন্স।
ফিচার
হোস্টেড checkout-এ কার্ড, Apple Pay, Google Pay ও USDC পাশাপাশি থাকে। বামে অর্ডার 9F21-0716 — তিনটি আইটেম, €0.50 প্রসেসিং ফি, প্রদেয় €49.00 — আর ডানে পেমেন্ট পদ্ধতির পছন্দ। গ্রাহক বেছে নেন; পেজ নিজেকে মানিয়ে নেয়; মার্চেন্ট ইন্টিগ্রেট করেছেন একবারই।
একই checkout URL ফোনের লেআউটে সাজিয়ে যায়: অর্ডার ছোট হয়ে সামারি বারে ঢোকে, পদ্ধতির বোতামগুলো জায়গায় থাকে, কার্ড ফর্মে লেবেল বজায় থাকে। ডেস্কটপে যা চালু হয়, মোবাইলেও তা-ই চালু হয় — আর ব্রাউজারের বদলে নিজের অ্যাপের ভেতরেই পেমেন্ট করাতে চাইলে iOS ও Android SDK একই অর্ডারের বিপরীতে একই checkout নেটিভভাবে দেখায়।
USDC-তে পেমেন্টের শেষে মেলে এমন রসিদ, যা মার্চেন্টের অ্যাকাউন্ট্যান্টও পড়ে বুঝতে পারেন। পদ্ধতি: Base-এ 52.95 USDC →︎ EUR settlement, রসিদে ছাপা রেটে, 1 EUR = 1.0807 USDC। রেফারেন্স 9F21-0716, গ্রাহকের ইমেইলে পাঠানো এবং তখনই ডাউনলোডযোগ্য। গ্রাহক দিয়েছেন ক্রিপ্টো; হিসাবে উঠেছে €49.00।
পেমেন্ট লিংকের জন্য আছে সত্যিকারের ডেস্ক: Arc Studio SRL-এর paid, active ও expired মিলিয়ে ৮টি লিংক, প্রতিটি সারিতে পরিমাণ, পেমেন্ট সংখ্যা ও স্ট্যাটাস। ওপরের কার্ডগুলো হিসাব রাখে — ৪টি active লিংক, এই মাসে ১৮টি লিংক পেমেন্টে €2,304.50 সংগৃহীত, আজ €49.00 পরিশোধিত। তৈরি করুন, খুঁজুন, এক্সপোর্ট করুন — শেষ।
Refund লক্ষ্য করে অর্ডারকে, পেমেন্ট পদ্ধতিকে নয়। 9F21-0716-এ ড্রয়ার খুললে পরিমাণ আগে থেকেই পূর্ণ €49.00 বসানো থাকে, সাথে বাধ্যতামূলক কারণ এবং ঐচ্ছিক নোট, যা এক্সপোর্টে ও গ্রাহকের রসিদে যায়। অর্থ নিজে থেকেই মূল পেমেন্ট rail ধরে ফেরত যায় — কার্ড refund কার্ডে, USDC অর্ডার তাদের EUR settlement হিসেবে — সাধারণত ১–৩ কার্যদিবসে।
ব্র্যান্ডিং একটি সেটিংস পেজ, কোনো সার্ভিস প্রকল্প নয়: লোগো আপলোড করুন, accent, ink ও surface রং ঠিক করুন, টাইপফেস ও কোণের স্টাইল বেছে নিন। সেভ করার আগেই লাইভ প্রিভিউতে আপনার আসল checkout দেখা যায় — ডেস্কটপ বা মোবাইল — আর accent রঙেই বদলায় পে বোতামের ফোকাস, স্ট্যাটাস টিক ও সক্রিয় ট্যাব। চালান আপনার sandbox-এর সাথে পাওয়া checkout হোস্টে, অথবা নিজের ডোমেইনে।
পেমেন্ট পদ্ধতি হলো প্রোভাইডারসহ টগল: 3-D Secure-সহ কার্ড, ওয়ালেট বোতাম হিসেবে Apple Pay ও Google Pay, Ethereum, Base ও Solana জুড়ে USDC, vIBAN রেফারেন্সসহ SEPA ব্যাংক ট্রান্সফার। পাশের settlement প্যানেলে শর্তটি সরাসরি বলা আছে: গ্রাহক নিশ্চিত করার আগেই কনভার্সন দেখেন; আপনি সবসময় EUR-এ settle করেন।
অর্ডার তৈরি করুন, হোস্টেড পেজে রিডাইরেক্ট করুন, ফলাফল পান। পেমেন্ট UI, পদ্ধতির লজিক ও রসিদ — সবই Gateway সামলায়। পদ্ধতি বদলালে আপনার টিমকে checkout ফ্রন্টএন্ড বানাতে, প্যাচ করতে বা হালনাগাদ রাখতে হয় না।
সবকিছু অর্ডারের সাথে বাঁধা, পেমেন্ট পদ্ধতির সাথে নয়। অর্ডার 9F21-0716-এ আছে তার আইটেমগুলো — €38.50 ব্র্যান্ড আইডেন্টিটি স্প্রিন্ট, €6.00 টাইপফেস লাইসেন্সিং, €4.00 রাশ ডেলিভারি — সাথে €0.50 প্রসেসিং ফি ও একটি মোট অঙ্ক। পেমেন্ট যেভাবেই হোক, query, reconcile ও refund করা হয় ওই রেফারেন্স ধরেই।
পদ্ধতি ও ব্র্যান্ডিংয়ের পরিবর্তন প্রযোজ্য হয় নতুন checkout সেশনে — যে স্ক্রিনে সেভ করেন সেখানেই তা লেখা আছে। পেমেন্টের মাঝখানে থাকা গ্রাহকের হাতের নিচে পেজ কখনো বদলে যায় না।
কার্ড পথটি একঘেয়ে অংশ, যা সামলানো হয়ে গেছে: ইনলাইন ভ্যালিডেশন, পড়ার মতো রাউটিং নীতির অধীনে ফ্লোতেই গাঁথা strong customer authentication-সহ 3-D Secure, আর ইন্টিগ্রেশন টেস্টের জন্য প্রতি sandbox-এ টেস্ট কার্ড। ক্রিপ্টো নেওয়ার কারণে কার্ড ফ্লো কখনো খারাপ হয় না।
ওয়ালেট এখানে বোতাম, কোনো প্রকল্প নয়। Apple Pay ও Google Pay একই পেজে ওয়ান-ট্যাপ শিট হিসেবে আসে এবং ডিভাইস টোকেনে পেমেন্ট করে — আসল কার্ড নম্বর পেজে কখনো পৌঁছায় না — একই অর্ডার ও একই রসিদের মাধ্যমে। চালু করা মানে পদ্ধতি স্ক্রিনে একটি টগল।
ক্রিপ্টোর দাম ধরা হয় checkout-এ দেখানো রেটে এবং settle হয় ইউরোতে। মার্চেন্ট কখনো ভুলে টোকেন পজিশন ধরে বসে থাকেন না; হিসাব থাকে এক মুদ্রায়।
USDC পদ্ধতিতে একটি টগলের পেছনে Ethereum, Base ও Solana। গ্রাহক তাঁর ওয়ালেট যে নেটওয়ার্কে, সেখানেই পে করেন; মার্চেন্টের দিকে কিছু বদলায় না।
Pay-by-transfer-এ থাকে vIBAN রেফারেন্স, ফলে আসা SEPA পেমেন্ট গঠনগতভাবেই নিজের অর্ডার চিনিয়ে দেয়। যাঁরা ব্যাংক থেকে পরিশোধযোগ্য ইনভয়েস চান, তাঁদের জন্য এটি চালু করুন — reconciliation স্বয়ংক্রিয়ই থাকবে।
কার্ড ও ওয়ালেটের বাইরে checkout-এ থাকে ইউরোপীয় ক্রেতার প্রত্যাশিত account-to-account ও স্থানীয় পদ্ধতি, যা একটি লম্বা তালিকায় ঠেসে না দিয়ে গ্রাহকের দেশ অনুযায়ী সাজিয়ে দেখানো হয়।
BNPL থাকে অন্য সবকিছুর মতোই একই পদ্ধতির সারিতে — গ্রাহক পেমেন্ট ভাগ করেন, মার্চেন্ট টাকা পান একবারে, আর অর্ডার রেফারেন্স বদলায় না। একটি টগল, একই রসিদ, একই reconciliation।
গ্রাহক সম্ভবত কোনটি ব্যবহার করবেন, সেই অনুযায়ী পেজ পদ্ধতি সাজায় — দেশ, ভাষা, ডিভাইস, এবং আগে আপনার কাছে পেমেন্ট করেছেন কি না — যাতে প্রাসঙ্গিক অপশন থাকে প্রথমে, চতুর্থে নয়।
গ্রাহকের মুদ্রায় পরিমাণ দেখান, নিশ্চিত করার আগেই কনভার্সন জানিয়ে দিন, আর settle করুন EUR-এই। গ্রাহক দেখেন পরিচিত অঙ্ক; আপনার ledger-এ থাকে একটিই।
হোস্টেড পেজ তার লেবেল, এরর ও রসিদ স্থানীয় ভাষায় দেখায়। ভুল ভাষার বোতামের কারণে কেউ পেমেন্ট ছেড়ে চলে যান না।
ফিরে আসা গ্রাহক সংরক্ষিত কার্ডে এক ট্যাপে পেমেন্ট করেন। কার্ড আমাদের দিকে vault-এ থাকে এবং টোকেন দিয়ে রেফারেন্স হয়, তাই আপনার সিস্টেমে জমা থাকে রেফারেন্স, কখনো PAN নয় — আর দ্বিতীয়বার কেনা প্রথমবারের চেয়ে ছোট।
রিকারিং চার্জ চলে আপনার ঠিক করা সময়সূচিতে — পরিমাণ, বিরতি, শুরু ও শেষ — টোকেনাইজড কার্ডের বিপরীতে। প্রতিটি সাইকেল নিজস্ব অর্ডার ও নিজস্ব রসিদ তৈরি করে, তাই সাবস্ক্রিপশনও বাকি সবকিছুর মতো লাইন ধরে ধরে reconcile হয়।
রিকারিং চার্জে soft decline হলে তা বাদ না দিয়ে সময়সূচি ধরে আবার চেষ্টা করা হয়, আর গ্রাহককে জানানো হয় কেবল যখন তা জরুরি। ব্যর্থ নবায়ন আর নীরব churn হয়ে থাকে না।
সংরক্ষিত কার্ড রাখা হয় নেটওয়ার্ক টোকেন হিসেবে, যা পুনরায় ইস্যু ও মেয়াদ শেষের পরও কার্ডধারীর সাথে থাকে। কার্ড বদলালে যে সাবস্ক্রিপশন আগে বন্ধ হয়ে যেত, তা এখন চার্জ হয়েই চলে।
অর্ডার তৈরি হয় API দিয়ে idempotency key-সহ — পুনরায় পাঠানো রিকোয়েস্ট মূল ফলাফলই ফেরত দেয়, দ্বিতীয়বার চার্জ করে না — আর ডেভেলপার সেকশনে আছে কী ও ডকুমেন্টেশন। Checkout হোস্টেড; ইন্টিগ্রেশন মুষ্টিমেয় কয়েকটি endpoint, ডকুমেন্টেশন সেটিংসের ঠিক পাশেই।
পেমেন্ট ঘটামাত্রই আপনার ব্যাকএন্ড জানতে পারে: অর্ডার লাইফসাইকেলের signed webhook ইভেন্ট — paid, failed, refunded — আপনার দিকে signature verification এবং আমাদের দিকে replay protection সহ।
নেটিভ অ্যাপ একই checkout অ্যাপের ভেতরেই দেখায়, ব্যবহারকারীকে ব্রাউজারে পাঠায় না। পদ্ধতির লজিক, ওয়ালেট শিট ও 3-D Secure সামলায় SDK; অর্ডার ও রসিদ সেগুলোই, যা আপনার ব্যাকএন্ড আগে থেকেই চেনে।
শপিং-কার্ট প্লাগইন ডেভেলপার ছাড়াই বিদ্যমান স্টোরকে Gateway-র সাথে যুক্ত করে — ইনস্টল করুন, কী পেস্ট করুন, একটি টেস্ট পেমেন্ট নিন। API-র অর্ডারগুলো যে ব্যাক অফিসে আসে, এগুলোও আসে সেখানেই।
পেমেন্ট যখন আপনার নিজের লেআউটের ভেতরেই হতে হবে, তখন পেমেন্ট ফিল্ড সরাসরি এমবেড করুন: ইনপুটগুলো আমাদের দিকে হোস্টেড ও PCI-scoped, ঘিরে থাকা পেজ পুরোপুরি আপনার, আর কার্ড ডেটা আপনার সার্ভারে কখনো পৌঁছায় না।
একটি লিংক একটি পেমেন্টের পরেই বন্ধ হতে পারে, অথবা পেমেন্ট নিতেই থাকতে পারে — ডেমোর ওয়ার্কশপ সিটে এ পর্যন্ত ৩টি পেমেন্ট এসেছে, কনসালটেশন আওয়ারে ৬টি। লিংক ডিফল্টভাবে ৩০ দিন পর নিজে থেকেই মেয়াদোত্তীর্ণ হয়, আর মেয়াদ শেষ হলে চুপচাপ ব্যর্থ না হয়ে লিংক সেটি স্পষ্ট জানিয়ে দেয়।
আসল কোনো অর্থ নড়ার আগে, sandbox key-র সঙ্গে ইস্যু করা কার্ড দিয়ে test session-এ integration চালানো যায়। ফ্লো হুবহু একই, তাই test-এ যা পাস করে, লাইভেও তা-ই চলে।
কার্ড ট্রাফিক চলে এমন একটি routing policy অনুযায়ী, যা আপনার চেনা শর্তে লেখা — কার্ড ব্র্যান্ড, ইস্যুকারী দেশ, কারেন্সি, পরিমাণ — কোনো black box নয়। পেমেন্ট কোন রুট নিয়েছে, পেমেন্টের একই স্ক্রিনেই তা দেখা যায়।
soft decline হলে গ্রাহক ব্যর্থতা দেখার আগেই একই checkout session-এ বিকল্প রুটে আবার চেষ্টা করা হয়। উদ্ধার হওয়া বেশিরভাগ পেমেন্টের ক্ষেত্রে গ্রাহক টেরই পান না যে ঝুঁকি ছিল।
ইস্যুকারীর কাঁচা কোড অনুবাদ হয় এমন কারণে, যার ওপর অপারেটর পদক্ষেপ নিতে পারেন — কার্ডের মেয়াদ শেষ, ব্যালেন্স অপর্যাপ্ত, issuer risk — এবং সেগুলো গ্রুপ করা থাকে, যাতে অনেক পেমেন্টজুড়ে একটি প্যাটার্ন প্যাটার্ন হিসেবেই চোখে পড়ে।
বেশিরভাগ পেমেন্ট শুধু ডিভাইস ও আচরণগত সংকেতেই পাস হয়; policy চাইলে তবেই step-up challenge আসে। policy আপনি ঠিক করেন — সবসময়, ঝুঁকিভিত্তিক, কিংবা নিয়ম অনুমতি দিলে exempt — আর ফ্লো চালায় hosted পেজ।
Checkout, রসিদ ও settlement — সবকিছুতে একই অর্ডার রেফারেন্স। 9F21-0716 মেলালে পাবেন একটিই €49.00 এন্ট্রি — এক সিস্টেমে কার্ড রেকর্ড আর অন্যটিতে ক্রিপ্টো রেকর্ড, এমন নয়।
Settlement যেখানে কনফিগার করেন সেখানেই স্পষ্ট লেখা থাকে: EUR-এ auto-convert, RO49 •••• 0421-এ settle, প্রতিদিন ২৩:০০-এ payout। কাল হিসাবরক্ষক যে অঙ্ক দেখবেন, মার্চেন্ট আজই একটি স্ক্রিনে তা পড়ে নিতে পারেন।
প্রতিটি payout খুললে দেখা যায় কোন অর্ডার থেকে তা এসেছে, ফি-সহ আইটেম ধরে ধরে। ব্যাংক লাইন মিলে যায় এক্সপোর্ট করা তালিকার সঙ্গে, ফলে মাসশেষ হয়ে ওঠে সাধারণ একটি লুকআপ, কোনো তদন্ত নয়।
Refund-এর পরিমাণ মূল চার্জ পর্যন্ত বদলানো যায় — drawer সর্বোচ্চ অঙ্কটি দেখায় এবং তার কম হলেই সেটিকে আংশিক ধরে। একটি অর্ডারে দশটি আংশিক refund হলেও সব মিলে একটি রেফারেন্সেই রিকনসাইল হয়।
প্রতিটি refund-এ একটি বাধ্যতামূলক কারণ ও একটি ঐচ্ছিক নোট থাকে, আর নোটটি সঙ্গে সঙ্গে চলে: এক্সপোর্টে এবং গ্রাহকের রসিদে দেখা যায়। ছয় মাস পরে অর্ডার 9F21-0716 কেন সম্পূর্ণ ফেরত হয়েছিল, কাউকে তা মনে রাখতে হয় না।
রসিদ গ্রাহকের ই-মেইলে যায় এবং সঙ্গে সঙ্গে ডাউনলোডও করা যায়; refund-এর রসিদও একই পথে যায়। মার্চেন্টকে কখনও রসিদের টেমপ্লেট বানাতে হয় না।
দিনের batch-এর আগে বাতিল করলে authorization hold ছেড়ে দেওয়া হয় এবং কোনো অর্থ নড়ে না — refund নেই, ফি নেই, গ্রাহকের স্টেটমেন্টে ব্যাখ্যা করার মতো কিছুই নেই।
কার্ড পেমেন্ট চলে 3-D Secure-এর মাধ্যমে, আপনার পড়ে বোঝা যায় এমন routing policy-র অধীনে। Wallet পেমেন্টে থাকে ডিভাইসের নিজস্ব authentication, আর webhook ইভেন্ট বিশ্বাস করার আগে signature যাচাই করা হয়।
স্ক্রিনিং নিয়ম বাক্যের মতো করে পড়া যায় — নতুন কার্ডে Y দেশ থেকে X-এর বেশি পরিমাণ — আর সেই অনুযায়ী কাজ করে: allow, challenge বা block। বিশ্বস্ত ও ব্লক করা কার্ড, ই-মেইল ও ঠিকানার তালিকা থাকে একই স্ক্রিনে।
একই কার্ড, ডিভাইস বা ঠিকানা থেকে বারবার চেষ্টা ধরা পড়ে rate rule-এর মাধ্যমে, কেউ পরে খেয়াল করার অপেক্ষায় থাকতে হয় না। সংকেতগুলো পেমেন্টের ওপরেই দেখানো হয়, কোনো স্কোরের ভেতরে লুকানো থাকে না।
Chargeback খোলে তার পেছনের অর্ডার নিয়েই: authorization ফলাফল, 3-D Secure-এর ফল, রসিদ, ডেলিভারি, refund-এর ইতিহাস। সেই স্ক্রিন থেকেই জবাব দিন; প্রমাণ-প্যাক তৈরি হয় রেকর্ড থেকে, স্মৃতি থেকে নয়।
কার্ডের তথ্য নেওয়া পেজটি আমাদের — PCI-scoped ও hosted। গ্রাহক আমাদের ডোমেইনে, আপনার ডোমেইনে বা আপনার অ্যাপের ভেতরে, যেখানেই পেমেন্ট করুন, আপনার সার্ভার দেখে শুধু একটি token ও একটি অর্ডার রেফারেন্স — কার্ড নম্বর নয়।
পেমেন্ট ডেটা at rest এনক্রিপ্টেড এবং EU-তেই প্রসেস হয়। একজন ইউরোপীয় মার্চেন্টের কাছে ডেটা কোথায় থাকে, সেটি একটি উত্তর, পাদটীকা নয়।
Refund, পদ্ধতি পরিবর্তন, ব্র্যান্ডিং পরিবর্তন, key rotation — প্রতিটি audit trail-এ লেখা হয় অপারেটর, সময় ও কারণসহ। বিশেষ অধিকারের কাজ চালানোর আগে কারণ দিতে হয়।
Finance দেখে payout, support দেখে অর্ডার ও refund দেয়, ডেভেলপাররা দেখে key ও লগ। অ্যাক্সেস role অনুযায়ী দেওয়া হয়, একটি লগইন শেয়ার করে নয়।
পেয়াররা জমা হয় একটি customers ভিউতে — কে পেমেন্ট করেছেন, কতবার, কোন পদ্ধতিতে — ফলে নিয়মিত গ্রাহক একটি রেকর্ড, এক্সপোর্টে মিলে যাওয়া ই-মেইলের কাকতালীয় ব্যাপার নয়।
সার্চ বক্স থেকে লিংক বা রেফারেন্স দিয়ে পেমেন্ট খুঁজে নিন; হিসাবের খাতার দরকার হলে বর্তমান ভিউ CSV-তে এক্সপোর্ট করুন। Back office ধরেই নেয় যে কোনো একজন হিসাবরক্ষক চাইবেন।
আপনার বেছে নেওয়া সময়ের ভলিউম, approval rate, refund ও পদ্ধতির মিশ্রণ। অর্থ কোথায় গেল আর কোন পদ্ধতি প্রচারের যোগ্য, তা জানতে যথেষ্ট — কিছু এক্সপোর্ট না করেই।
Gateway যুক্ত হয় Protocore Center-এর সঙ্গে: সেখানকার payment-links back office প্রতিটি লিংককে তার settlement transfer-সহ দেখায় এবং পূর্ণ ট্রেসের জন্য open-in-Tracer লিংক দেয়। আপনার ops টিম checkout থেকে ledger পর্যন্ত স্বচ্ছভাবে দেখতে পায়।
ডেমো checkout-টি Arc Studio SRL-এর: তাদের নাম, তাদের মার্ক, তাদের অর্ডার। powered-by-Protocore ফুটার রেখে চালান বা পুরোপুরি whitelabel করে — যেভাবেই হোক, পেজটি আপনারই মনে হবে।
FAQ
কার্ড পেমেন্ট দুই ধাপে চলে: authorization কেনাকাটার সময় অর্থ আটকে রাখে, settlement তা সরিয়ে নেয়। Gateway স্বয়ংক্রিয়ভাবে capture করে, দিনের অর্ডারগুলো একটি ব্যাচে বন্ধ করে, এবং সেটিংসে ঠিক করা দৈনিক payout সময়ে আপনার নির্ধারিত অ্যাকাউন্টে EUR-এ পাঠিয়ে দেয়।
সময়। settlement-এর আগে বাতিল করলে authorization hold ছেড়ে দেওয়া হয়, কোনো অর্থ নড়ে না। settlement-এর পরে সেটি refund — অর্ডারের বিপরীতে, পূর্ণ বা আংশিক, কারণ নথিভুক্ত করে মূল পেমেন্ট পদ্ধতিতেই ফেরত যায়।
নীতি হিসেবে, ডিফল্ট বাধা হিসেবে নয়। বেশিরভাগ ফ্লো শুধু ডিভাইস ও আচরণগত ডেটাতেই পাস করে; routing policy চাইলে তবেই step-up challenge আসে। নীতি আপনি ঠিক করেন — ফ্লো বহন করে hosted page।
ইউরো। গ্রাহক নিশ্চিত করার আগেই পেজে USDC-র অঙ্ক নির্ধারিত হয়, ঘোষিত রেটে EUR-এ settle হয়, আর রসিদে রূপান্তর নথিভুক্ত থাকে। Checkout, রসিদ ও settlement একই অর্ডার রেফারেন্স ভাগ করে — টোকেন পজিশন আপনাকে কখনো রাখতে হয় না।
অর্ডারটিই আপনার প্রমাণের ফাইল। Authorization ফলাফল, রসিদ, refund ইতিহাস ও webhook ডেলিভারি — সবই একটি রেফারেন্সে বাঁধা। একটি লুকআপেই dispute-এর উত্তর মেলে, আর একই স্ক্রিন থেকে refund দেওয়াই প্রায়ই দ্রুততর সমাধান।
না। অর্ডার idempotency key দিয়ে তৈরি হয়, তাই পুনরায় পাঠানো অনুরোধ দ্বিতীয় চার্জ না করে মূল ফলাফলই ফেরত দেয় — আর ফেরার পথে webhook রিপ্লে সুরক্ষাসহ signed থাকে।
কার্ডের তথ্য নেওয়া পেজটি আমাদের — আমাদের দিকে hosted ও PCI-স্কোপে। আপনার সার্ভার পায় একটি টোকেন ও অর্ডার রেফারেন্স, কার্ড নম্বর নয়। গ্রাহক আমাদের ডোমেইনে, আপনার ডোমেইনে, আপনার অ্যাপে, বা আপনার নিজের লেআউটে এমবেড করা পেমেন্ট ফিল্ডে — যেভাবেই পে করুন, এটি একইভাবে প্রযোজ্য।
হ্যাঁ। sandbox-এর সঙ্গে দেওয়া checkout host-এ, নিজের ডোমেইনে, বা hosted payment field দিয়ে আপনার পেজে এমবেড করে চালাতে পারেন। ব্র্যান্ডিং — লোগো, রং, টাইপফেস, কোণ — লাইভ প্রিভিউসহ একটি সেটিংস স্ক্রিন, আর ফুটারে powered-by থাকবে নাকি পুরোপুরি whitelabel, তা আপনার পছন্দ।
কার্ড আমাদের দিকে network token হিসেবে vault করা থাকে; আপনার সিস্টেম রাখে শুধু একটি রেফারেন্স। সাবস্ক্রিপশন আপনার ঠিক করা সময়সূচিতে সেই টোকেনে চার্জ করে, নিজের soft decline নিজেই রিট্রাই করে, এবং কার্ড রিইস্যু হলেও কার্ডধারীকে অনুসরণ করে। প্রতিটি চক্র নিজস্ব অর্ডার ও রসিদ তৈরি করে, তাই সাবস্ক্রিপশন লাইন ধরে ধরে reconcile হয়।
নিজের মুদ্রায় অঙ্ক, নিশ্চিত করার আগে রূপান্তর স্পষ্টভাবে উল্লেখ করা, আর তাঁর ভাষায় checkout। আপনি এখনও EUR-এ settle পান। USDC-র মতোই নীতি: গ্রাহকের দিক মানিয়ে নেয়, আপনার খতিয়ান থাকে এক মুদ্রায়।
আপনার দিকে এটি একটি ইউরো প্রাপ্য মাত্র। ক্রিপ্টো অংশ — মূল্য নির্ধারণ, অন-চেইন পেমেন্ট ও রূপান্তর — Gateway সামলায়, আর আপনার অ্যাকাউন্টে পৌঁছায় নিয়ন্ত্রিত settlement পথ থেকে আসা EUR, প্রযোজ্য রেটসহ রসিদে নথিভুক্ত। আপনি টোকেন custody করছেন না, wallet চালাচ্ছেন না, পজিশনও ধরে রাখছেন না, কারণ রূপান্তর হয় settlement-এর পরে নয়, আগে।
অ্যাকাউন্ট পাওয়ার দিনই পেমেন্ট লিংক কাজ করে। API ইন্টিগ্রেশন মানে একটি order endpoint, একটি রিডাইরেক্ট ও একটি signed webhook — বেশিরভাগ টিম একই সপ্তাহে টেস্টে চালু করে ফেলে, আর শুরু থেকে শেষ পর্যন্ত একটি টেস্ট পেমেন্ট নেওয়ার পর লাইভে যায়। স্টোর প্লাগইনে ডেভেলপমেন্টই লাগে না।
হ্যাঁ — দুটোই চালান। নতুন অর্ডার Gateway-তে পাঠান, আর পুরোনো প্রোভাইডার নিজের অর্ডারের settlement ও refund শেষ করুক, কারণ refund সবসময় যে rail-এ পেমেন্ট এসেছে সেটি ধরেই ফেরত যায়। সংরক্ষিত কার্ড টোকেন হিসেবে মাইগ্রেট হয়, তাই আপনার সাবস্ক্রাইবারদের আবার কার্ডের তথ্য দিতে হয় না।
অর্ডার কল আর webhook হ্যান্ডলার। পেমেন্ট পেজ, পদ্ধতির লজিক, wallet শিট, 3-D Secure, রসিদ, এবং পরে যোগ হওয়া প্রতিটি নতুন পদ্ধতি হালনাগাদ রাখার দায়িত্ব আমাদের — hosted checkout-এর মূল উদ্দেশ্যই এটি।
প্রাইসিং
কোনো প্ল্যাটফর্ম ফি ছাড়াই লাইভ হন — Gateway আয় করে প্রসেস করা পেমেন্ট থেকে, তাই খরচ checkout দিয়ে যাওয়া ভলিউমের সঙ্গে চলে।
আপনার নিজের ব্র্যান্ডে checkout চালান, এমন লাইসেন্সে যার পরিধি নির্ধারিত হয় আপনার চালু করা রেল ও পরিকল্পিত থ্রুপুট অনুযায়ী।
পেমেন্ট পেজে আপনার ব্র্যান্ড, নিচে আমাদের রেল, আপনার হয়ে আমরাই পরিচালনা করি — পরিধি নির্ভর করে আপনি কোন পেমেন্ট মেথড চালু করেন তার ওপর।
খরচ নির্ভর করে checkout দিয়ে যাওয়া ভলিউম ও আপনার চালু করা রেলের ওপর — কার্ড, ওয়ালেট ও USDC সেটেলমেন্ট। স্ট্যান্ডঅ্যালোন নিন, বা পুরোপুরি whitelabel।
যাচাই করুন
আমরা আপনার সঙ্গে ওয়ার্কড উদাহরণটি চালাই — Arc Studio SRL, অর্ডার 9F21-0716 — কার্ড, ওয়ালেট ও USDC দিয়ে পেমেন্ট করে, এবং এর পেছনের মার্চেন্ট ব্যাক অফিসও দেখাই।
API key-সহ একটি টেস্ট মার্চেন্ট, যাতে আপনার টিম অর্ডার তৈরি করতে, হোস্টেড checkout চালাতে এবং সাইন করা ফলাফল শুরু থেকে শেষ পর্যন্ত পেতে পারে।
অর্ডার API, order.paid webhook ও ইন্টিগ্রেশন গাইড — checkout নিজে বানানোর বদলে Gateway-তে যুক্ত করতে যা যা দরকার, সবই।
আপনার লোগো, রং ও টাইপে হোস্টেড পেজ, যাতে লাইভ হওয়ার আগেই নিজের checkout দেখে নিতে পারেন।
আরও পড়ুন
স্ট্যান্ডঅ্যালোন বা whitelabel চলে — checkout-এ আপনার ব্র্যান্ড, নিচে আমাদের রেল।
PoS কাউন্টারে Gateway-র অর্ডার মডেলই ব্যবহার করে, vIBAN তার ব্যাংক-ট্রান্সফার অর্ডারকে স্বয়ংসনাক্তকারী রেফারেন্স দেয়, Chain তার USDC পেমেন্ট EUR-এ settle করে, Center হলো checkout-এর পেছনের অপারেটর কনসোল, আর Agents একই অর্ডার মডেল প্রয়োগ করে মানুষের নীতির অধীনে সফটওয়্যারের শুরু করা পেমেন্টে।
উপরের সবকিছু প্রোডাকশন ডেমোতে চলছে, যা আমরা আপনাকে ঘুরিয়ে দেখাতে পারি: স্ট্যান্ডঅ্যালোন, whitelabel বা একটি পূর্ণ প্ল্যাটফর্ম হিসেবে। কী বানাচ্ছেন বলুন, আমরা সবচেয়ে ছোট পথটি দেখিয়ে দেব।
