پرش به محتوا
یکپارچه‌سازی

پول دست سامانه‌های شما می‌ماند. حساب‌وکتاب دست ما.

پلتفرم یک محاسبه است و یک سابقه. آنچه در سامانه‌های شما رخ داده را می‌گیرد، حساب می‌کند چه مبلغی بدهکارید و دستور را برمی‌گرداند. هرگز در مسیر پول نمی‌نشیند.

مرز نگهداری دارایینقشه‌ای از سامانه که با یک خط ضخیم به دو نیم تقسیم شده است. در سمت اپراتور: حساب Stripe او، حساب NOWPayments او، بانک او، کیف‌پول او و بک‌اند خودش. در سمت پلتفرم: دفتر کل، اجراها، فرمان‌ها، درخواست‌های برداشت و صندوق خروجی. چهار خط از مرز عبور می‌کنند و یک فرمان، یک رسید، یک دستور و یک رویداد را حمل می‌کنند. هیچ‌کدام پول حمل نمی‌کند، و دفتر کل و اجراها اصلاً از مرز عبور نمی‌کنند.اپراتورXEXفرمانرسیددستوررویدادمرز نگهداری داراییحساب Stripeحساب NOWPaymentsبانککیف پولبک‌اند شمادفتراجراهافرمان‌هابرداشت‌هاصندوق خروجیهیچ خطی در اینجا پول جابه‌جا نمی‌کند. XEX دستور می‌فرستد؛ پول را اپراتور جابه‌جا می‌کند.دفتر و اجراها از هیچ مرزی عبور نمی‌کنند
چهار چیز از مرز عبور می‌کند: یک رسید، یک فرمان، یک دستور و یک رویداد. هیچ‌کدام پول نیست.
قرارداد

یک مستند منتشرشده، و دو کلاینت که بر اساس آن نوشته شده‌اند.

یک سند OpenAPI در مخزن، یک کلاینت TypeScript و یک کلاینت Dart. مهندس شما می‌تواند پیش از آنکه کسی جلسه بگذارد، کل سطح API را بخواند.

OpenAPI

کل سطح عمومی در یک سند: اندپوینت‌های عضو، اندپوینت‌های مدیریتی، API فرمان و فهرست رویدادها.

api/openapi.yaml

کلاینت TypeScript

برای سرویس‌های وب و Node شما. تایپ‌شده بر اساس همان سند.

sdk/typescript

کلاینت Dart

برای اپلیکیشن Flutter، چون یک برنامهٔ رو به اعضا معمولاً یکی دارد و دست‌ساز نوشتن یک لایهٔ HTTP دوم همان جایی است که این دو از هم فاصله می‌گیرند.

sdk/dart

خروجی

رویدادهایی که می‌توانید به رسیدنشان تکیه کنید.

یازده نوع رویداد، که در همان تراکنشی صف می‌شوند که تغییر وضعیتِ سازندهٔ آن‌ها در آن رخ داده است.

  1. 01

    یک صندوق خروج تراکنشی، نه یک POST بفرست-و-فراموش‌کن

    رویداد در همان تراکنشی نوشته می‌شود که باعثش شده و بعد از یک صف اجاره‌ای فرستاده می‌شود. هیچ پنجره‌ای وجود ندارد که در آن به سامانهٔ شما چیزی گفته شده باشد که دفتر کل بعداً برش گردانده، و هیچ پنجره‌ای که در آن دفتر کل ثبت کرده باشد و به کسی گفته نشده باشد.

    internal/outbox

  2. 02

    امضاشده، با شناسهٔ کلید قابل چرخش

    هر تحویل یک امضای HMAC-SHA256 با شناسهٔ کلید و مهر زمانی دارد. چرخش هم‌پوشانی دارد: کلید قدیمی تا وقتی جابه‌جا شوید معتبر می‌ماند، پس چرخاندن یک کلید قطعی‌ای نیست که مجبور باشید برایش زمان‌بندی کنید.

    internal/outbox/sign.go

  3. 03

    رویدادهای تسویه اول می‌روند

    دستور برداشت پشت انبوهی از اعلان‌ها صف نمی‌کشد. کلاس‌های تحویل، خطوط جداگانه‌اند و تسویه همان خطی است که دستور پولی را می‌برد.

    internal/events

  4. 04

    شناسه‌های قطعی، پس اجرای دوباره بی‌اثر است

    اجرای دوبارهٔ یک هندلر همان شناسهٔ رویداد را دوباره در صف می‌گذارد و صندوق خروج تکراری را حذف می‌کند. تحویلِ دست‌کم-یک‌بار که واقعاً می‌شود دوباره فرستادش، نه تحویلِ دست‌کم-یک‌باری که باید مواظبش باشید.

    internal/events · internal/outbox

  5. 05

    یک نگهبان خروج روی نشانی شما

    مقصد را اپراتور تنظیم می‌کند، و همین آن را ذاتاً به یک مسیر حملهٔ SSRF تبدیل می‌کند. توزیع‌کننده نشانی را پیش از ارسال درخواست بررسی می‌کند و نشانی‌هایی را که انتظار دارید مسدود می‌کند.

    internal/outbox/ssrf.go

  6. 06

    عقب‌نشینی، پارک‌کردن و یک مغایرت‌گیر

    خطاها با فاصلهٔ فزاینده تکرار و در نهایت پارک می‌شوند، به‌جای اینکه مقصدی را که از کار افتاده بکوبند. یک مغایرت‌گیر بین‌سامانه‌ای رویدادی را که واقعاً گم شده پیدا می‌کند، به‌جای آنکه به بی‌نقص‌بودن صف اعتماد شود.

    internal/outbox · internal/reconciler

ورودی

فرمان‌هایی که دقیقاً یک بار اجرا می‌شوند، با کلید شناسه‌های خودِ شما.

شما به پلتفرم می‌گویید خریدی انجام شد، بازپرداختی انجام شد، عضوی احراز هویت شد. تکرار کردن رایگان است، چون کلید مال خودتان است.

هر فرمان ورودی به ازای هر فضای کاری و هر شناسه چندباره‌پذیر است و پاسخش کش می‌شود. همان خرید را دو بار بفرستید و فراخوان دوم پاسخ فراخوان اول را برمی‌گرداند — خرید دومی نمی‌سازد و دور دوم پورسانت روی خرید اول پرداخت نمی‌کند.

قرارداد خطا صریح است، چون «دوباره بفرستم یا نه» همان پرسشی است که یک یکپارچه‌سازی واقعاً باید پاسخش را بداند. خطای برگشتی رسید را آزاد می‌کند و می‌توانید دوباره بفرستید. رد شدن با کد ۴xx نهایی است و کش می‌شود: فرمان بر اساس محتوایش رد شده و فرستادن دوباره‌اش باز هم رد می‌شود.

internal/commands · internal/command

پول خروجی

همان‌طور تسویه کنید که همیشه می‌کنید.

پلتفرم دقیقاً همان سطرهای دفتر کل را رزرو و دستور را صادر می‌کند. آنچه پرداخت را اجرا می‌کند مال شماست.

اگر سامانهٔ تسویه دارید، دستور برداشت را به‌عنوان رویدادی از کلاس تسویه دریافت می‌کند و برای تسویه یا شکست پاسخ می‌دهد. اگر ندارید، کنسول پرداخت‌ها فهرست بدهی را نشان می‌دهد، شما از کیف‌پول خودتان پرداخت می‌کنید و قیمت اجراشده و شناسهٔ تراکنش خودتان را ثبت می‌کنید. پرداختی که بدون شناسه ثبت شود رد می‌شود — هرگز نمی‌شد آن را با کیف‌پول شما مغایرت‌گیری کرد، پس پذیرفتنش فقط یعنی مغایرت‌گیری دیرتر و دورتر شکست می‌خورد.

internal/claims · internal/httpapi/payouts.go

برند شما

دامنهٔ خودتان، اثبات‌شده پیش از راه‌اندازی.

نام میزبان را ثبت کنید، رکورد TXT‌ای را که پلتفرم می‌سازد منتشر کنید، و به‌محض اینکه رکورد پاسخ داد، راه‌اندازی انجام می‌شود.

ترتیب کار مهم است و اصلاً نکته همین است. اتصال یک نام میزبان — یا افزودن یک دامنه به فهرست مجاز ارائه‌دهندهٔ هویت — پیش از اثبات مالکیت، به کسی که واقعاً صاحب آن نام است اجازه می‌دهد ورودهایی را که برای شما بوده دریافت کند. پس تا وقتی رکورد پاسخ ندهد نه چیزی راه‌اندازی می‌شود و نه چیزی به فهرست مجاز ورود اضافه می‌شود. یک سرویس پس‌زمینه ظرف کمتر از یک دقیقه آن را برمی‌دارد.

internal/domains

قدم بعد

یک محیط آزمایشی بردارید و به سامانهٔ استیجینگ وصلش کنید.

روی هر پلن رایگان است، با همان سطح API، همان رویدادها و همان امضاهای محیط عملیاتی.