معماری پلتفرم
یک هسته، چندین رابط — پلتفرم در عمل چگونه کار می‌کند.
مروری بر پلتفرم از دفتر کل به بالا: حساب‌ها، KYC، کارت‌ها و رمزارز که روی یک هسته‌ی دوطرفه‌نویسی مشترک‌اند، مسیر یک پرداخت از ایجاد تا تطبیق، و جایگاه لایه‌ی اپلیکیشن، کنسول اپراتور و مرز تحت مجوز.
هسته
یک دفتر کل زیر همه‌چیز.
در مرکز پلتفرم، یک دفتر کل حساب‌ها قرار دارد. هر حساب — کیف پول مشتری، موجودی پذیرنده، حساب کارمزد، حساب تسویه — یک گره روی این دفتر کل است و هر جابه‌جایی ارزش یک ثبت دوطرفه است: یک حساب بدهکار و حساب دیگر بستانکار می‌شود و دو طرف همیشه برابرند. دفتر کل فقط‌افزودنی (append-only) است. ورودی‌ها هرگز ویرایش یا حذف نمی‌شوند؛ اصلاح یعنی یک ورودی جدید و معکوس، بنابراین مسیر رسیدن هر موجودی به مقدار فعلی همیشه قابل بازسازی است. حساب‌ها، وضعیت KYC، کارت‌های صادرشده و آدرس‌های رمزارزی همگی به همان مدل حساب وصل می‌شوند؛ برای همین تأیید تراکنش کارتی، انتقال بانکی و واریز on-chain می‌توانند روی یک موجودی ثبت شوند، بی‌آنکه لایه‌ی تطبیقی سیستم‌های جداگانه را به هم بدوزد.
- 01دوطرفه‌نویسی: هر ثبت متوازن است و بدهکار با بستانکار برابر است
- 02فقط‌افزودنی: اصلاح یعنی ورودی جدید، نه ویرایش
- 03یک مدل حساب برای ارز فیات، کارت و رمزارز
- 04وضعیت KYC همراه حساب است، نه در یک جدول جانبی
یک پرداخت، سرتاسر
یک پرداخت، از ایجاد تا تطبیق.
پرداخت یک فراخوانی نیست، یک چرخه‌ی عمر کوتاه است و هر مرحله وضعیتی است که هم دفتر کل و هم سیستم‌های شما می‌بینند. هر تغییر وضعیت یک webhook ارسال می‌کند و هر نوشتن idempotent است — همان کلید همیشه به همان نتیجه می‌رسد، پس درخواست تکراری هرگز دوبار شارژ نمی‌کند.
- 01
ایجاد
یک intent باز می‌شود: مبلغ، ارز، حساب‌های درگیر. هنوز چیزی جابه‌جا نشده — دفتر کل یک ورودی در حال انتظار ثبت می‌کند.
- 02
تأیید
ریل موجودی و ریسک را بررسی می‌کند و مبلغ را بلوکه می‌کند. در کارت این همان authorization است؛ در انتقال، بدهکاری رزرو می‌شود.
- 03
برداشت
مبلغ بلوکه‌شده قطعی می‌شود. دفتر کل ثبت دوطرفه‌ای را انجام می‌دهد که ارزش را واقعاً بین دو حساب جابه‌جا می‌کند.
- 04
تسویه
وجوه روی ریل زیرساختی — شبکه‌ی کارتی، بانک یا زنجیره — پاک‌سازی می‌شوند و حساب‌های تسویه با پول واقعی تطبیق می‌یابند.
- 05
تطبیق
پلتفرم ثبت‌های خودش را با گزارش تسویه‌ی ریل مطابقت می‌دهد؛ هر چه نخواند، علامت می‌خورد و پنهان نمی‌شود.
webhook و idempotency در هر لبه‌ی این جریان حضور دارند. سیستم‌های شما با دریافت یک رویداد می‌فهمند پرداخت انجام شده، نه با پولینگ، و هر درخواستی که بعد از timeout دوباره بفرستید — از طریق idempotency key — به همان نتیجه می‌رسد، پس تکرار هرگز دوبار شارژ نمی‌کند. سرویسی که authorize و capture را اجرا می‌کند payment gateway.
لایه‌ی اپلیکیشن
اپلیکیشن‌های whitelabel در بالا، یک پلتفرم در زیر.
هسته قابلیت‌ها را ارائه می‌کند و لایه‌ی اپلیکیشن آن‌ها را به محصول تبدیل می‌کند. هر اپلیکیشن رو به مشتری — وب و موبایل — یک کلاینت whitelabel است که همان حساب‌ها، پرداخت‌ها و کارت‌ها را با برند خودش نمایش می‌دهد. تم‌بندی مبتنی بر توکن است: رنگ، فونت، گردی گوشه‌ها و فاصله‌گذاری از یک سیستم design token (PDS) می‌آید، پس اپراتور با تغییر توکن‌ها کل رابط را بازطراحی می‌کند، نه با فورک‌کردن اپلیکیشن. همین پلتفرم را می‌توان در مسیرهای کاملاً متفاوتی به کار گرفت — نئوبانک مصرف‌کننده، اپلیکیشن اکوایرینگ پذیرندگان، برنامه‌ی صدور کارت، on/off-ramp رمزارزی یا ابزار داخلی عملیات — بی‌آنکه به پنج محصول جدا تبدیل شود. یک پلتفرم است با ظاهرهای مختلف؛ هر کدام پیکربندی می‌شود، نه از نو ساخته.
- 01کلاینت‌های whitelabel وب و موبایل روی APIهای مشترک
- 02تم‌بندی مبتنی بر توکن (PDS): بازطراحی با پیکربندی، نه فورک
- 03پنج مسیر نمونه — نئوبانک، اکوایرینگ، صدور کارت، ramp، عملیات
- 04رابط‌های جدید پیکربندی می‌شوند، نه از نو ساخته
عملیات
از کنسول اجرا کنید، با دلیلی ثبت‌شده.
پشت هر اپلیکیشن یک کنسول اپراتور هست. جایی که کارشناس پشتیبانی یک حساب را بررسی می‌کند، تحلیلگر ریسک کارتی را مسدود می‌کند یا مسئول عملیات یک ثبت را معکوس می‌کند. دسترسی خواندن گسترده است؛ دسترسی به اقدامات حساس نه. هر کاری که پول را جابه‌جا کند، محدودیت‌ها را تغییر دهد یا به وجوه مشتری دست بزند، پیش از اجرا باید دلیل مشخصی داشته باشد و یک ورودی ممیزی تغییرناپذیر ثبت می‌کند — چه کسی، روی چه چیزی، کی و چرا. دسترسی بر اساس حداقل سطح دسترسی (least privilege) است، یعنی هر اپراتور فقط آنچه نقشش اجازه می‌دهد می‌بیند و انجام می‌دهد. این همان مدل Protocore Center، کنسول اپراتور، است و همین رویکرد در تمام سیستم‌های پلتفرم هم هست: اقدامات حساس آگاهانه‌اند، به فرد مشخصی منتسب می‌شوند و بعداً قابل بازبینی‌اند.
- 01خواندن گسترده، نوشتن کنترل‌شده — اقدامات حساس استثنا هستند
- 02ذکر دلیل پیش از هر اقدام مرتبط با وجوه الزامی است
- 03ردپای ممیزی تغییرناپذیر: چه کسی، چه چیزی، کی، چرا
- 04حداقل سطح دسترسی برای هر نقش اپراتور
پل رمزارز
رمزارز و فیات روی یک دفتر کل.
رمزارز در این پلتفرم یک سیلوی جداگانه نیست؛ آدرس رمزارزی فقط یک حساب دیگر روی همان دفتر کل است. on/off-ramp در لبه‌ی سیستم بین فیات و دارایی دیجیتال تبدیل می‌کند — مشتری با کارت یا انتقال بانکی موجودی را شارژ می‌کند و رمزارز می‌گیرد، یا رمزارز می‌فروشد و به حساب بانکی برداشت می‌کند. ارزش on-chain می‌تواند تا یک مسیر بانکی تسویه شود: پرداخت on-chain ورودی به حساب اعتبار داده می‌شود، تبدیل می‌شود و به یک IBAN پرداخت می‌شود، پس گیرنده پول معمولی را در حساب بانکی معمولی می‌بیند. چون هر دو سمت روی یک دفتر کل دوطرفه ثبت می‌شوند، جابه‌جایی‌ای که on-chain شروع شود و با انتقال بانکی تمام شود، یک تاریخچه‌ی تطبیق‌شده است، نه دو سیستمی که دستی با هم تطبیق داده شوند.
- 01آدرس رمزارزی یک حساب است مثل بقیه
- 02on/off-ramp: تبدیل فیات و دارایی دیجیتال در لبه
- 03تسویه‌ی on-chain تا پرداخت به IBAN
- 04یک تاریخچه‌ی تطبیق‌شده برای هر دو سمت
سطح توسعه
APIها، webhookها و یک sandbox برای توسعه.
هر کاری که اپلیکیشن‌ها انجام می‌دهند، از طریق یک API مستند انجام می‌دهند — ایجاد حساب، ثبت پرداخت، صدور کارت، شروع ramp. نمونه‌ی فراخوانی‌ها چیزی شبیه POST /v1/wallets یا POST /v1/payments است؛ ساختار REST است و روی هر نوشتن یک idempotency key دارد. تغییر وضعیت‌ها به شکل webhook ارسال می‌شوند، پس سیستم‌های شما به رویدادها واکنش نشان می‌دهند، نه اینکه مدام پولینگ کنند. توسعه روی یک tenant از نوع sandbox انجام می‌شود — نسخه‌ی ایزوله‌ی پلتفرم با ریل‌های آزمایشی، که می‌توانید کل جریان ایجاد تا تطبیق را بدون جابه‌جایی پول واقعی اجرا کنید. اینکه هر محصول چه چیزی را و در کدام سطح در اختیار شما می‌گذارد، با باند دسترسی آن مشخص می‌شود؛ صفحه‌ی هر محصول توضیح می‌دهد هر باند شامل چه چیزهایی است.
- 01REST API مستند، نوشتن idempotent
- 02webhook برای هر تغییر وضعیت — رویدادمحور، نه پولینگ
- 03tenant از نوع sandbox با ریل‌های آزمایشی، جدا از محیط production
- 04دامنه و محدودیت‌ها بر اساس باند دسترسی هر محصول
مرز صادقانه
Protocore نرم‌افزار می‌سازد. مجوز، مرز تحت نظارت را نگه می‌دارد.
یک محصول پرداخت از دو چیز به‌هم‌پیوسته تشکیل شده است: اجازه‌ی قانونی نگهداری و جابه‌جایی پول، و نرم‌افزاری که آن را فرمان می‌دهد، ثبت می‌کند و تطبیق می‌دهد. Protocore نرم‌افزار می‌سازد. فعالیت تحت نظارت — نگهداری وجوه مشتری، صدور حساب، جابه‌جایی پول روی یک شبکه‌ی کارتی — به مجوز خود اپراتور یا یک شریک دارای مجوز برمی‌گردد: بانک، EMI یا مؤسسه‌ی پرداخت. پلتفرم طوری ساخته شده که با هر ریل تحت نظارتی که شما بیاورید جور شود و داده‌ی کارت را روی همان ریل نگه دارد تا هرگز به سرورهای شما نرسد؛ اما جایگزین آن مجوز نیست، و هیچ نرم‌افزاری نیست. اینکه مرز تحت نظارت کجا قرار بگیرد، تصمیمی است که با شریک خود می‌گیرید و معماری طوری طراحی شده که در هر دو طرف آن درست بنشیند.
- 01یک لایه‌ی نرم‌افزاری، نه مجوز
- 02فعالیت تحت نظارت با اپراتور یا شریک دارای مجوز است
- 03داده‌ی کارت روی ریل می‌ماند، نه روی سرورهای شما
- 04ساخته‌شده برای سازگاری با ریل‌های تحت نظارتی که می‌آورید
ارتباط با بخش‌های دیگر
یک رشته را دنبال کنید.
هر مفهوم این صفحه جای کامل‌تری دارد — تعریف‌ها، محصولات و باندهای دسترسی که مشخص می‌کنند هر سطح شامل چه چیزی است.
idempotency، webhook، تسویه، IBAN مجازی، SCA — تعریف‌شده.
سرویسی که authorize و capture را اجرا می‌کند.
اقدامات حساس با ذکر دلیل الزامی و ممیزی‌شده.
ارزش on-chain که تا IBAN تسویه می‌شود.
تبدیل فیات و دارایی دیجیتال در لبه.
هر محصول شامل چه چیزی است، سطح به سطح.
معماری پروژه‌ی خودتان را می‌خواهید؟
بگویید چه می‌سازید. با یک طراحی سیستم و جایگاه مرز تحت نظارت برمی‌گردیم — نه با یک پیچ‌دک.