প্ল্যাটফর্ম আর্কিটেকচার

একটি কোর, অনেক সারফেস — প্ল্যাটফর্ম আসলে যেভাবে কাজ করে।

লেজার থেকে শুরু করে পুরো প্ল্যাটফর্মের একটি ভ্রমণ: একই ডাবল-এন্ট্রি কোর শেয়ার করা অ্যাকাউন্ট, KYC, কার্ড ও ক্রিপ্টো; একটি পেমেন্ট কীভাবে create থেকে reconcile পর্যন্ত যায়; এবং অ্যাপ লেয়ার, অপারেটর কনসোল ও রেগুলেটেড লাইন কোথায় অবস্থান করে।

আমাদের সাথে কথা বলুন প্রোডাক্টগুলো দেখুন

কোর

সবকিছুর নিচে একটিই লেজার।

প্ল্যাটফর্মের কেন্দ্রে রয়েছে একটিমাত্র অ্যাকাউন্ট লেজার। প্রতিটি অ্যাকাউন্ট — কাস্টমার ওয়ালেট, মার্চেন্ট ব্যালেন্স, ফি অ্যাকাউন্ট, সেটেলমেন্ট অ্যাকাউন্ট — এই লেজারের একটি নোড, এবং মূল্যের প্রতিটি স্থানান্তর একটি ডাবল-এন্ট্রি পোস্টিং: একটি অ্যাকাউন্ট ডেবিট, আরেকটি ক্রেডিট, দুই পক্ষ সব সময় সমান। লেজার append-only। এন্ট্রি কখনো এডিট বা ডিলিট হয় না; সংশোধন মানে একটি নতুন, বিপরীতমুখী এন্ট্রি, ফলে একটি ব্যালেন্স কীভাবে বর্তমান মানে পৌঁছাল তার পূর্ণ ইতিহাস সব সময় পুনর্গঠন করা যায়। অ্যাকাউন্ট, KYC স্টেট, ইস্যু করা কার্ড ও ক্রিপ্টো অ্যাড্রেস সবই একই অ্যাকাউন্ট মডেলে যুক্ত। তাই কার্ড অথোরাইজেশন, ব্যাংক ট্রান্সফার ও অন-চেইন ডিপোজিট আলাদা সিস্টেম জোড়া লাগানোর কোনো রিকনসিলিয়েশন লেয়ার ছাড়াই একই ব্যালেন্সে পোস্ট হতে পারে।

01ডাবল-এন্ট্রি: প্রতিটি পোস্টিং ব্যালেন্সড, ডেবিট ও ক্রেডিট সমান
02Append-only: সংশোধন মানে নতুন এন্ট্রি, কখনো এডিট নয়
03ফিয়াট, কার্ড ও ক্রিপ্টোর জন্য একটিই অ্যাকাউন্ট মডেল
04KYC স্টেট অ্যাকাউন্টের সঙ্গেই থাকে, আলাদা টেবিলে নয়

একটি পেমেন্ট, শুরু থেকে শেষ

একটি পেমেন্ট, create থেকে reconcile।

পেমেন্ট একটিমাত্র কল নয়, বরং একটি ছোট লাইফসাইকেল, এবং প্রতিটি ধাপ এমন একটি স্টেট যা লেজার ও আপনার সিস্টেম দুটিই দেখতে পায়। প্রতিটি স্টেট পরিবর্তনে একটি webhook যায়, এবং প্রতিটি রাইট idempotent — একই key একই ফলাফলে রিপ্লে হয়, তাই রিট্রাই করা রিকোয়েস্ট কখনো দুবার চার্জ করে না।

01
Create
একটি intent খোলা হয়: অ্যামাউন্ট, কারেন্সি, সংশ্লিষ্ট অ্যাকাউন্ট। এখনো কিছু সরেনি — লেজার একটি pending এন্ট্রি রেকর্ড করে।
02
Authorize
রেল ফান্ড ও ঝুঁকি যাচাই করে একটি হোল্ড বসায়। কার্ডের ক্ষেত্রে এটি অথোরাইজেশন; ট্রান্সফারের ক্ষেত্রে ডেবিট রিজার্ভ করা হয়।
03
Capture
হোল্ড করা অ্যামাউন্ট কমিট হয়। লেজার সেই ডাবল-এন্ট্রি পোস্ট করে, যা দুই অ্যাকাউন্টের মধ্যে প্রকৃতপক্ষে মূল্য সরায়।
04
Settle
অন্তর্নিহিত রেল — কার্ড স্কিম, ব্যাংক বা চেইন — জুড়ে ফান্ড ক্লিয়ার হয়, এবং সেটেলমেন্ট অ্যাকাউন্ট প্রকৃত অর্থের সঙ্গে reconcile হয়।
05
Reconcile
প্ল্যাটফর্ম নিজের পোস্টিংগুলোকে রেলের সেটেলমেন্ট রিপোর্টের সঙ্গে মেলায়; যা মেলে না তা ফ্ল্যাগ করা হয়, লুকানো হয় না।

Webhook ও idempotency এই ফ্লো-র প্রতিটি প্রান্তে কাজ করে। পেমেন্ট সরেছে কি না তা আপনার সিস্টেম polling নয়, ইভেন্ট পেয়েই জানে, এবং টাইমআউটের পর আপনি যে রিকোয়েস্ট রিট্রাই করেন তা — idempotency key দিয়ে — একই ফলাফলে পৌঁছায়, ফলে পুনরাবৃত্তি কখনো দুবার চার্জ করে না। authorize ও capture চালায় যে সার্ভিস, সেটি হলো পেমেন্ট গেটওয়ে.

অ্যাপ লেয়ার

ওপরে whitelabel অ্যাপ, নিচে একটি প্ল্যাটফর্ম।

কোর ক্ষমতা সরবরাহ করে; অ্যাপ লেয়ার সেগুলোকে প্রোডাক্টে রূপ দেয়। কাস্টমার-মুখী প্রতিটি অ্যাপ — ওয়েব ও মোবাইল — একটি whitelabel ক্লায়েন্ট, যা একই অ্যাকাউন্ট, পেমেন্ট ও কার্ড নিজস্ব ব্র্যান্ডে দেখায়। থিমিং টোকেন-চালিত: রং, টাইপ, রেডিয়াস ও স্পেসিং আসে একটি ডিজাইন-টোকেন সিস্টেম (PDS) থেকে, তাই অপারেটর অ্যাপ ফর্ক না করে শুধু টোকেন বদলেই পুরো সারফেসের স্টাইল পাল্টাতে পারে। একই প্ল্যাটফর্মকে একেবারে ভিন্ন দিকে চালানো যায় — কনজিউমার neobank, মার্চেন্ট acquiring অ্যাপ, কার্ড-ইস্যুয়িং প্রোগ্রাম, ক্রিপ্টো on/off-ramp বা অভ্যন্তরীণ অপারেশনস টুল — পাঁচটি আলাদা প্রোডাক্ট না হয়েই। এটি একটি প্ল্যাটফর্ম, ভিন্ন ভিন্ন সাজে; প্রতিটি কনফিগার করা, নতুন করে তৈরি নয়।

01শেয়ার্ড API-তে whitelabel ওয়েব ও মোবাইল ক্লায়েন্ট
02টোকেন-চালিত থিমিং (PDS): কনফিগে রিস্টাইল, ফর্ক নয়
03পাঁচটি উদাহরণ দিক — neobank, acquiring, issuing, ramp, ops
04নতুন সারফেস কনফিগার করা হয়, নতুন করে তৈরি নয়

অপারেশনস

কনসোল থেকে চালান, কারণ রেকর্ডে রেখে।

প্রতিটি অ্যাপের পেছনে রয়েছে একটি অপারেটর কনসোল। এখানে সাপোর্ট এজেন্ট অ্যাকাউন্ট খুঁজে দেখেন, ঝুঁকি বিশ্লেষক কার্ড ফ্রিজ করেন, কিংবা অপারেশনস লিড একটি পোস্টিং রিভার্স করেন। রিড অ্যাক্সেস বিস্তৃত; privileged অ্যাকশন নয়। অর্থ স্থানান্তর, লিমিট পরিবর্তন বা কাস্টমারের ফান্ডে হাত দেওয়ার যেকোনো কাজ চালানোর আগে কারণ উল্লেখ করতে হয় এবং একটি immutable অডিট এন্ট্রি লেখা হয় — কে করলেন, কীসের ওপর, কখন ও কেন। অ্যাক্সেস least privilege মেনে চলে, তাই প্রতিটি অপারেটর শুধু নিজের রোল যা অনুমোদন করে তা-ই দেখতে ও করতে পারেন। এটি অপারেটর কনসোল Protocore Center-এর মডেল, এবং একই অবস্থান প্ল্যাটফর্মের প্রতিটি সিস্টেমে বিল্ট-ইন: সংবেদনশীল অ্যাকশন সুচিন্তিত, দায়বদ্ধ এবং পরে পর্যালোচনাযোগ্য।

01বিস্তৃত রিড, নিয়ন্ত্রিত রাইট — privileged অ্যাকশন ব্যতিক্রম
02ফান্ড-সংশ্লিষ্ট যেকোনো অ্যাকশনের আগে কারণ বাধ্যতামূলক
03Immutable অডিট ট্রেইল: কে, কী, কখন, কেন
04অপারেটর রোল অনুযায়ী least privilege

ক্রিপ্টো ব্রিজ

একই লেজারে ক্রিপ্টো ও ফিয়াট।

প্ল্যাটফর্মে ক্রিপ্টো আলাদা কোনো সাইলো নয়; ক্রিপ্টো অ্যাড্রেস একই লেজারের আরেকটি অ্যাকাউন্ট মাত্র। on/off-ramp প্রান্তে ফিয়াট ও ডিজিটাল অ্যাসেটের মধ্যে রূপান্তর করে — কাস্টমার কার্ড বা ট্রান্সফার দিয়ে ব্যালেন্স ফান্ড করে ক্রিপ্টো পান, অথবা ক্রিপ্টো বিক্রি করে ব্যাংক অ্যাকাউন্টে উইথড্র করেন। অন-চেইন মূল্য ব্যাংক রেল পর্যন্ত সেটল হতে পারে: আগত অন-চেইন পেমেন্ট অ্যাকাউন্টে ক্রেডিট হয়, রূপান্তরিত হয় এবং IBAN-এ পেআউট হয়, ফলে প্রাপক সাধারণ ব্যাংক অ্যাকাউন্টে সাধারণ অর্থই দেখেন। দুটি লেগই যেহেতু একই ডাবল-এন্ট্রি লেজারে পোস্ট হয়, অন-চেইনে শুরু হয়ে ব্যাংক ট্রান্সফারে শেষ হওয়া একটি মুভমেন্ট একটিই reconciled ইতিহাস — হাতে মেলানো দুটি সিস্টেম নয়।

01ক্রিপ্টো অ্যাড্রেস অন্য যেকোনো অ্যাকাউন্টের মতোই একটি অ্যাকাউন্ট
02On/off-ramp: প্রান্তে ফিয়াট ও ডিজিটাল অ্যাসেটের রূপান্তর
03IBAN পেআউট পর্যন্ত অন-চেইন সেটলমেন্ট
04দুই লেগ জুড়ে একটিই reconciled ইতিহাস

বিল্ড সারফেস

API, webhook এবং বিল্ড করার জন্য একটি sandbox।

অ্যাপগুলো যা কিছু করে, সবই একটি ডকুমেন্টেড API-র মাধ্যমে — অ্যাকাউন্ট তৈরি, পেমেন্ট খোলা, কার্ড ইস্যু, ramp শুরু। উদাহরণস্বরূপ কলগুলো দেখতে এমন: POST /v1/wallets বা POST /v1/payments; গঠন REST, প্রতিটি রাইটে একটি idempotency key সহ। স্টেট পরিবর্তন webhook হিসেবে পাঠানো হয়, ফলে আপনার সিস্টেম polling না করে ইভেন্টে সাড়া দেয়। ডেভেলপমেন্ট হয় একটি sandbox tenant-এ — টেস্ট রেলসহ প্ল্যাটফর্মের একটি আলাদা কপি, যেখানে প্রকৃত অর্থ না সরিয়েই create থেকে reconcile পর্যন্ত পুরো ফ্লো চালানো যায়। প্রতিটি প্রোডাক্ট আপনাকে কী এবং কোন টিয়ারে দেয়, তা তার access band দিয়ে নির্ধারিত; প্রোডাক্ট পেজগুলোতে একটি band-এ কী কী আছে তা বিস্তারিত বলা আছে।

01ডকুমেন্টেড REST API, idempotent রাইট
02প্রতিটি স্টেট পরিবর্তনে webhook — ইভেন্ট-চালিত, polling নয়
03টেস্ট রেলসহ sandbox tenant, প্রোডাকশন থেকে বিচ্ছিন্ন
04পরিসর ও লিমিট নির্ধারিত হয় প্রোডাক্টভিত্তিক access band দিয়ে

স্পষ্ট সীমারেখা

Protocore সফটওয়্যার তৈরি করে। রেগুলেটেড লাইন থাকে লাইসেন্সের হাতে।

একটি পেমেন্ট প্রোডাক্ট দুটি জিনিসের মিলন: অর্থ ধারণ ও স্থানান্তরের রেগুলেটেড অনুমতি, এবং তা নির্দেশ, রেকর্ড ও reconcile করা সফটওয়্যার। Protocore সফটওয়্যার তৈরি করে। রেগুলেটেড কার্যক্রম — কাস্টমারের ফান্ড ধারণ, অ্যাকাউন্ট ইস্যু, স্কিমে অর্থ স্থানান্তর — থাকে অপারেটরের নিজস্ব লাইসেন্স বা একজন লাইসেন্সপ্রাপ্ত পার্টনারের কাছে: ব্যাংক, EMI বা পেমেন্ট ইনস্টিটিউশন। প্ল্যাটফর্মটি আপনার আনা যেকোনো রেগুলেটেড রেলে খাপ খাওয়ানোর জন্য এবং কার্ড ডেটা রেলেই রাখার জন্য তৈরি, যাতে তা আপনার সার্ভারে কখনো না আসে; এটি ওই অনুমতির বিকল্প নয়, এবং কোনো সফটওয়্যারই নয়। রেগুলেটেড লাইন কোথায় পড়বে তা আপনি আপনার পার্টনারের সঙ্গে ঠিক করেন, আর আর্কিটেকচার এমনভাবে ডিজাইন করা যাতে তা এর যেকোনো পাশে নির্বিঘ্নে বসে।