اتوماسیون پرداخت و کنترل محدودیت

مقاله کامل

💡 18+. مواد مهندسی و کاربردی برای سیستم عامل ها و اپراتورهای iGaming. فراخوانی برای بازی نیست. منظور ما از «پرداخت»، پرداخت نقدی به بازیکنان در تمام کانالها است: کارت/بانک/کیف پول/کریپتو.

1) چرا پرداخت خودکار

سرعت و قابلیت پیش بینی: بازیکنان انتظار دارند که پول نقد سریع و شفاف دریافت کنند.

ریسک و انطباق: RG/AML/تحریم ها، سرعت و محدودیت های نام تجاری/بازیکن/کانال.

مقیاس: قله پس از مسابقات و «داغ» پخش - ده ها هزار نفر از برنامه های کاربردی.

هزینه: بهینه سازی کمیسیون و مانده خزانه در PSP/حساب/شبکه.

هدف اصلی پرداخت یک بار، قابل اثبات و قابل کنترل برای هر گونه قطع است.

2) مدل نقش اصلی پرداخت

پرداخت ارکستر یک ماشین وضعیت و sagas است: می پذیرد برنامه های کاربردی، چک محدودیت ها و قوانین، مسیرهای، retrait، ثبت نتیجه.

ریسک و انطباق - RG/AML/KYT، غربالگری سورتمه، «چهار چشم».

خزانه داری - ذخایر کانال، مدیریت تعادل، مصون سازی.

کیف پول/لجر منبع حقیقت تعادل است ؛ بدهی/جبران خسارت تنها از طریق آن.

PSP/بانک/Kastodi/رمزنگاری پردازنده - عملکرد نهایی.

3) دستگاه دولتی

1. درخواست → درخواست از جلو/CRM/API.

2. RG/AML: خود حذفی/از دست دادن/محدودیت زمانی, لیست آفتاب/PEP, KYT (برای رمزنگاری/کیف پول), وضعیت KYC.

3. محدودیت → چک کردن سرعت و محدودیت: در هر بازیکن/نام تجاری/منطقه/روش (روزانه/هفتگی/ماهانه).

4. کسر → idempoint 'wallet. debit "(или" hold "→" commit ") с" X-idempotency-key ".

5. مسیر → انتخاب کانال/بازرگان/شبکه (قوانین + هزینه + تبدیل + در دسترس بودن).

6. ارسال به PSP/بانک/سفارشی (امضای mTLS +).

7. await_settlement → انتظار برای تایید («حل و فصل »/« شکست خورده») توسط webhook یا چک کشیدن.

8. اطلاع → حوادث به اتوبوس/BI، بازیکن - وضعیت/ETA.

9. تطبیق → تطبیق PSP/بانک/گزارش های زنجیره ای با لجر.

10. → جبران اگر 'شکست خورده' - بازگشت به لجر (idempotent), انتخاب مجدد از کانال, تشدید.

تغییرناپذیر ها:

تعادل فقط از طریق Ledger تغییر می کند.
«پرداخت های از دست رفته/تکراری» = 0 - ارائه شده توسط idempotency و deduplication.
تمام انتقال ها به صورت اتمی ثبت و ردیابی می شوند ('trace _ id'، 'payout _ id').

4) محدودیت ها و سرعت: چگونه به درستی شمارش شود

4. 1 انواع محدودیت

تنظیم کننده/RG: محدودیت برداشت روزانه/هفتگی، خود حذفی، خنک کننده.

تقلب/سرعت: مقدار/تعداد معاملات، فرکانس برنامه ها، تغییر جزئیات، دستگاه ها/ASN/geo.

نقدی: محدودیت کانال/بازرگان/حساب/شبکه، مانده خزانه.

اتاق های عمل: آستانه «بررسی دستی» و «چهار چشم» (VIP/مبالغ زیاد).

4. 2 ذخیره سازی و پیاده سازی

شمارنده توزیع شده (Redis + TTL + Lua/atomic) برای پنجره های 1h/24h/7d.

پیش بینی در OLAP برای قوانین پیشرفته (پنجره های کشویی، الگوهای).

Idempotence شمارنده: افزایش تنها زمانی که برنامه به «ارسال» منتقل.

توضیح پذیری: برای هر خرابی - کد علت و «چه حد کار کرد».

5) ارکستراسیون کانال (PSP/بانک ها/رمزنگاری)

5. 1 مسیریابی

قوانین جغرافیایی، ارز، مقدار، سرعت، هزینه، خطر، در دسترس بودن، اردوگاه های SLO.

آبشار: PSP1 → PSP2 در صورت شکست ؛ برای رمزنگاری - شبکه A → B.

رویکرد A/B و راهزن برای بهینه سازی تبدیل و قیمت.

5. 2 ویژگی های خاص کانال

کارت ها/بانک ها: ماشین های وضعیت «ارسال → پردازش → حل و فصل»، بازده/بازپرداخت با توجه به طرح (SEPA/SWIFT).

کیف پول الکترونیکی: محدودیت های فوری اما سخت و غربالگری سورتمه.

رمزنگاری: نهایی بودن در زنجیره (N تأیید)، KYT آدرس پذیر، قانون سفر بین VASP، لیست آدرس های سفید، MRS/multisig، مدیریت گاز.

6) ایمنی و انطباق

mTLS + OAuth2/signatures بر روی تمام S2S، در هر کلید نام تجاری/منطقه، نشانه کوتاه مدت و محدود به یک کانال.

CCR/CCR/Sank- غربالگری قبل از ارسال ؛ برای رمزنگاری - میزان ریسک آدرس/tx.

RBAC/ABAC و «چهار چشم» در اقدامات دستی/مبالغ آستانه.

ممیزی WORM: سیاهههای تغییرناپذیر تغییرات حد/قانون/آستانه و مداخلات دستی.

PII/اقامت: داده ها و سیاهههای مربوط - بر اساس منطقه، رمزگذاری در حالت استراحت/در حال حمل و نقل، RLS.

7) Idempotence و ساگاس (راه پول)

هر عملیات ضبط دارای یک 'X-Idempotency-Key' است. تکرار → همان نتیجه (200 با بدن قدیمی).

Сага «کسر → ارسال → حل و فصل»:

اگر "ارسال" سقوط کرد - جبران خسارت ("کیف پول. انتشار/اعتبار ").
اگر «حل و فصل» نیامد - retray/re-question، پدربزرگ توسط «پرداخت _ id».
بدون تنظیمات تعادل دستی - فقط رویدادهای جبران کننده.

8) قراردادهای API (قطعات مرجع)

ایجاد درخواست خرید


پست/v1/پرداخت
عنوان ها: X-Idempotency-Key: po_001، X-Trace-Id: tr_a1b2
{
«player_id":"p_123,» «مقدار «: {«مقدار»: 250. 00، «ارز»:» EUR»}، «روش «:» sepa»، «مقصد «: {» iban»:» DE89»...}، «ابرداده «: {«brand _ id»:» A»،» منطقه»:» EU»}
}
→ 202 {«پرداخت _ id «: «po _ 001 «، «وضعیت»:» درخواست شده»،» eta»:» 2025-10-23T18: 00: 00Z»}

Webhook از PSP/بانک/سفارشی


POST/webhooks/پرداخت
X-امضا: sha256 =...
{
«event_id":"uuid,» «payout_id":"po_001,» psp_ref":"psp_77, «وضعیت»: «حل و فصل»، «occurred_at":"2025-10-23T16:21:05Z»
}

حذف/جبران خسارت را نگه دارید


پست/ v1/payouts/po_001/compensate
هدر: X-idempotency-کلید: po_001_comp
→ 200 {«وضعیت «: «جبران»}

9) قابلیت مشاهده و SLO

SLO (نشانه ها):

تمام شد. درخواست → ارسال 'p95 120-300 ms (مسیر داخلی),' ارسال → حل و فصل 'p95: کارت/ewallet 5-30 دقیقه, بانک SEPA T + + 1, رمزنگاری 10 دقیقه (بر روی شبکه), «از دست رفته/پرداخت تکراری» = 0.

معیارها:

تاخیر p50/p95/p99 توسط مراحل, خطا نرخ (کسب و کار/4xx/5xx), طوفان سعی مجدد, صف/تاخیر DLQ, موفقیت نرخ کانال, هزینه در هر موفقیت, PSP/شکست کد بانکی, حد پاسخ (RG/AML/سرعت).
ردیابی: OpenTelemetry (لبه → محدودیت → کیف پول → روتر → PSP)، 'trace _ id' در webhooks.
هشدارها: نقض SLO، رشد IDEMPOTENCY _ MISMATCH، پرش «missing _ platform» در آشتی، افت میزان موفقیت در یک جغرافیایی/کانال خاص.

10) خزانه داری و توازن

ذخایر توسط کانال ها/بازرگانان/شبکه ها، تعادل خودکار.

سیاست های آستانه: حداقل و حداکثر در حساب/کیف پول، «توقف پرداخت های جدید» زمانی که کمبود مالی.

مصون سازی ارز/رمزنگاری, حسابداری برای کمیسیون و تفاوت نرخ ارز.

ویترین مالی: طرح واقعیت، هزینه خروج از طریق کانال، پیری «حلق آویز» پرداخت.

11) آشتی

گزارش های روزانه PSP/بانک/سفارشی/زنجیره ای → عادی سازی → مقایسه با رجیستری «payouts» و سوابق Ledger.

Категории: 'match', 'timing', 'missing _ psp', 'missing _ platform', 'amount _ mismatch'.

قوانین خودکار برای «زمان بندی»، بلیط برای «عدم تطابق»، هشدار توسط آستانه.

برای رمزنگاری - نقشه برداری توسط «txid/network/confirmations».

12) شیوه های هرج و مرج و DR

PSP/بانک قطره: آبشار به جایگزین, 'مکث پرداخت جدید' حالت برای کانال.

تاخیر webhooks: pull-statuses دوره ای، dedup توسط 'event _ id'.

قطع منطقه ای: دارایی-بدهی/دارایی-دارایی (RPO ≤ 5 دقیقه، RTO ≤ 30 دقیقه).

Spiked gas/reorgs (رمزنگاری): هزینه پویا، تأیید اضافی، پرداخت های با اولویت پایین معوق.

13) چک لیست

پلت فرم/اپراتور

Idempotency در wallet. بدهی/اعتباری/جبران ',' X-Idempotency-کلید 'везде.
غربالگری سرعت/RG/AML/KYT/غرق شده قبل از «ارسال».
مسیریابی و کانال آبشار، کلید/گواهی در هر نام تجاری/منطقه است.
ممیزی WORM از محدودیت/قوانین/اقدامات دستی، چهار چشم در آستانه.
داشبورد SLO و هشدار، OpenTelemetry، DLQ برای webhooks.
آشتی روزانه T + 1، موارد عدم تطابق، تشدید.
آستانه خزانه داری و تعادل خودکار ؛ توقف مادها ('بدون پرداخت جدید').
تمرینات DR/xaoc: افت PSP/بانک/شبکه، تاخیر/تکراری از webhooks.

ارائه دهنده/PSP/بانک/سفارشی

امضا Webhooks (HMAC/EdDSA) + زمان بندی/nonce، تضمین تحویل مجدد 2xx.
کد خرابی نرمال، گزارش T + 1، یکپارچگی فایل (هش/PGP).
API های وضعیت موجود برای چک کردن کشش.

14) ضد الگوهای (پرچم قرمز)

تعادل بدهی/اعتبار توسط webhook بدون دستور صریح در Ledger.

فقدان idempotency → دو نوشتن آف/جبران.

کلید های به اشتراک گذاشته شده/گواهی برای مارک های مختلف/مناطق.

محدودیت های سرعت «در صورت درخواست» و نه در محموله های تایید شده در نظر گرفته می شود.

ویرایش دستی وضعیت پرداخت/تعادل در پایگاه داده.

هیچ DLQ/deduplication برای webhooks → وضعیت «چسبنده» وجود ندارد.

بدون آشتی T + 1 ؛ اکسل دستی پاره وقت.

استنتاج کریپتو بدون تاییدهای TAC/whitelisting/multifactorial

15) خط پایین

اتوماسیون پرداخت هماهنگ پول و خطرات است: محدودیت های سخت و سرعت، دستورات پول بی نظیر، مسیریابی کانال معقول، انطباق پیش فرض، مشاهده پذیری و آشتی روزانه. چنین خط لوله پرداختی به سرعت و یک بار پرداخت می شود، در برابر سقوط و قله مقاوم است، برای بازیکن، تنظیم کننده و گزارش مالی شفاف است - و در عین حال هزینه و خطرات خزانه را کنترل می کند.