تعادل و کیف پول: معماری چند کیف پول

1) چرا چند کیف پول و اهداف

یک ورودی «balance = number» واقعیت iGaming را پوشش نمی دهد. کیف پول/حساب های جداگانه مورد نیاز است: پول واقعی (پول نقد)، صندوق پاداش، استخر شرط بندی، freespins، امتیاز کامپیوتر، گاهی اوقات کیف پول ارز (EUR/USD/BRL).

اهداف معماری عبارتند از:

دقت پول (دو ورودی، حسابرسی).
سیاست های لغو (به عنوان مثال، اولین پاداش/vager، و سپس پول نقد).
سرعت (API p95 ≤ 250-400 میلی ثانیه، شرط/حل و فصل در زمان واقعی).
ایمنی و انطباق (KYC/AML، محدودیت های بازی مسئول، تنظیم کننده ها).
مقیاس: قله → ده ها هزار نفر از عملیات/ثانیه، میلیاردها پست/ماه.

2) مدل داده: «Ledger + Subwallets»

نهادهای حداقل

حساب: بازیکن/نام تجاری/بازار.

کیف پول: {نوع: نقدی	پاداش ها	شرط بندی	FS	امتیاز، ارز، وضعیت
LedgerEntry (двойная запись): 'debit _ account', 'credit _ account', 'amount', 'currency', 'operation _ id', 'category', 'created _ at'.
ارسال: عملیات کسب و کار اتمی، ترکیبی از 2 + LedgerEntry.
نگه دارید/رزرو: مسدود کردن موقت وجوه برای شرط/برداشت.
سیاست: قوانین اولویت نوشتن/اعتبار.
FXRate: قوانین دوره/دقت/گرد کردن.
محدودیت: روز/ماه/بازی مسئول.

مثال از جداول (ساده شده)

SQL
- ترازنامه برای دو ورودی (از جمله کسب و کار)
حساب ها (شناسه، owner_user_id، نوع، ارز، وضعیت،...)

- ارسال (دو ورودی، اشاره به معامله کسب و کار)
 (id, , , currency, category, )

- دارای (ذخایر)
دارای (شناسه، account_id، amount_minor، ارز، دلیل، expires_at، دولت، operation_id، created_at)

- سیاست های نوشتن (اولویت ها)
spend_policies (شناسه، بازار، wallet_priority jsonb، updated_at)

- نرخ ارز متقابل fx_rates (ccy_from، ccy_to، نرخ، دقت، valid_from)

قانون: حقیقت در مجله معامله ('ledger _ entries') زندگی می کند. تعادل فعلی یا یک مجموع (عکس فوری تحقق یافته) است، یا از یک مجله محاسبه می شود (گران است، اما فقط درست است).

3) انواع کیف پول و رفتار آنها

کیف پول	از سوی دیگر	می توانید بالا	می تواند نوشته شود	قوانین ویژه
پول نقد	پول واقعی	PSP/اقلام تعهدی دستی/بازده	پیشنهادات, خرید, برداشت	بر AML/KYC تاثیر می گذارد ؛ معاملات ثبت می شوند
پاداش ها	پول جایزه	تبلیغات/کمپین ها	نرخ ها (بر اساس قوانین)	به طور مستقیم نمایش داده نمی, تبدیل به پول نقد زمانی که vager اعدام است
شرط بندی	حسابداری برای پاداش «منجمد»	خودکار از پاداش شرط	نوشتن آف به نفع ارائه دهنده بازی	حل و فصل/لغو قانون انتشار
FS (FreeSpins)	بسته های چرخشی	کمپین ها	بازپرداخت در اسلات	معادل نقدی در T&C ثابت است
امتیاز ها	وفاداری/شرکت ها	فعالیت ها	فروشگاه/وضعیت	نه پول ؛ در گزارش های AML گنجانده نشده است

4) سیاست های لغو و ترتیب اولویت

به وضوح الگوریتم برای منبع بودجه را رسمی کنید: مثال (اسلات/کازینو):

1. اول، نوشتن از شرط بندی (اگر شرط فعال است).

2. سپس از پاداش تا خسته شدن.

3. باقی مانده پول نقد است.

مثال (ورزش):

1. اولین CASH (تنظیم کننده/مالیات).

2. سپس BONUS (freebet)، ترجمه به شرط بندی.

«تصمیم سیاسی» را به عنوان یک ویژگی در Postings ذخیره کنید تا پشتیبانی و حسابرسی ببینند «چرا آنها آن را نوشتند».

5) چرخه عمر پول و عملیات

واریز وجه

1. 'POST/wallet/deposit' → یک ورودی معلق ایجاد کنید (صندوق ورودی سوسیس PSP).

2. Webhook PSP (امضای HMAC, idempotency by 'operation _ id') → اعتبار نقدی, category = 'سپرده'.

3. رویداد «wallet _ updated» را منتشر میکنیم.

نرخ گذاری

1. «POST/bet/place» → ایجاد یک نگه دارید (رزرو) در حساب منبع (نقدی/پاداش/شرط بندی).

2. هنگام تایید نرخ, انتقال → منبع بدهی, اعتبار سرویس «حل و فصل» حساب از ارائه دهنده است →.

3. پس از لغو - انتشار نگه دارید.

حل و فصل (نتیجه)

به دست آوردن: بدهی از حساب «حل و فصل» ارائه دهنده → اعتبار نقدی یا سیاست شرط → پاداش → نقدی.

از دست دادن: نزدیک «هزینه» ارائه دهنده با یک معامله → بدون اعتبار به بازیکن.

1. بررسی KYC/AML، محدودیت بازی مسئول.

2. مبلغ برداشت را نگه دارید.

3. موفقیت PSP → نقدی بدهی نهایی → حساب اعتباری «پرداخت».

4. خرابی در PSP → release hold.

6) idempotence و دقیقا یک بار «در درون معنی»

همه جا 'operation _ id' (UUID/ULID افزایش یافته) با یک شاخص منحصر به فرد. درخواست مجدد → وضعیت معامله گذشته.

PSP/ارائه دهنده بازی webhooks: جدول صندوق با dedupe توسط 'event _ id + signature'. پردازش - کارگر بی نظیر (الگوی خروجی).

Idempotency-Key در HTTP برای مشتری ؛ TTL را ≥ 24-72 ساعت ذخیره کنید.

7) نگهداری و نگهداری

نگه داشتن یک نوشتن نیست، بلکه «توقف» تعادل موجود است.

قوانین و مقررات:

زندگی را نگه دارید: ثانیه → دقیقه (نرخ) یا ساعت (خروجی).
نگه داشتن می تواند به طور جزئی یا به طور کامل خاموش (حل و فصل جزئی).
هنگامی که منقضی - انتشار خودکار و رویداد.
رابطه «hold _ id» ↔ «bet _ id/withdraw _ id» را حفظ کنید.

8) ارزها، FX و گرد کردن

مقادیر پولی - در واحد جزئی (سنت)، نوع - عدد صحیح.

گرد کردن بانک (دور نیمه به حتی) و یا توسط T&C.

FX: «CASH (EUR)» ↔ «CASH (USD)» بهتر است کیف پول را تقسیم کنید. تبدیل به عنوان یک عملیات جداگانه:

"debit EUR، FX_EURUSD' اعتباری و" debit FX_EURUSD، اعتبار USD "- شفاف برای حسابرسی.
ممنوع است که به طور خودکار «رسیدن» به دوره در اختلاف ؛ تمام قوانین در سیاست FX هستند.

9) بازی مسئولانه و محدودیت

سپرده/شرط/از دست دادن/محدودیت جلسه (روز/هفته/ماه), خنک کردن, خود حذفی.

اجرا به عنوان قبل از چک قبل از نگه داشتن/بدهی.

گزارش های خرابی - در یک گزارش حسابرسی جداگانه، در دسترس پشتیبانی و تنظیم کننده.

10) سیگنال های ضد تقلب در اطراف کیف پول

خوشه های دستگاه/ASN ها، سپرده های مکرر کوچک → برداشت های بزرگ، الگوهای شستشو.

محدودیت سرعت در «سپرده/در» توسط BIN/کشور/دستگاه.

لیست های بلوک برای گیرندگان (کیف پول/IBAN)، لیست «قاطر».

رویدادهای کیف پول → در فروشگاه ویژگی های به ثمر رساند (ورود/سپرده/نرخ).

11) ثبات و عملکرد

درست در مقابل کش

حقیقت در لجر است. برای API «get balance»، عکس فوری تحقق یافته («user _ id + wallet _ type → balance_minor، version») را نگه دارید.

نوشتن: معامله در پایگاه داده → اعتبار کش.

در جریان «سنگین» (زنده), کوتاه TTL 1-5 S + بررسی حقیقت اجباری قبل از خروج/شرط بزرگ مناسب است.

پوسته پوسته شدن

Sharding توسط 'کاربر _ ID' (ماژول/رتبه بندی)، استخر شارد جداگانه برای نقدی در مقابل پاداش.

کلید های داغ (VIP/رباتها) - درخواست coalescing توسط 'user _ id'.

تجمع ناهمزمان (نوشتن «ارسال» → «snapshot-update» در پس زمینه).

12) قراردادهای API (شبه)

تعادل در تعادل

وب سایت
GET/v1/کیف پول ؟ انواع = نقدی، پاداش
→ 200 {«کیف پول»: [
{"نوع": "پول نقد"، "ارز": "EUR"، "در دسترس": 12050، "نگه دارید": 500، "نسخه": 1942}، {"نوع": "پاداش"، "ارز": "EUR"، "در دسترس": 3000 "،" wager _ req ": 15000}
]}

شرط (با نگه داشتن)

وب سایت
پست/v1/شرط/محل
{"bet _ id ": "b _ 123 ", "مقدار ": 500, "ارز ":" EUR"," source _ policy":" casino _ default", "idempotency_key":"ik_abc"}
→ 201 {«وضعیت «: «برگزار شد «, «HOLD _ ID «:» h _ 789»,» منقضی می شود _ در»: 30}

حل و فصل

وب سایت
پست/v1/شرط/حل و فصل
{«bet _ id «: «b _ 123 «، «نتیجه»:» WIN»،» پرداخت»: 1250}
→ 200 {«وضعیت «: «حل و فصل «،» نقدی _ دلتا»: + 1250}

وب سایت
پست/v1/برداشت
{"برداشت _ id ": "w _ 456 ", "مقدار ": 10000," ارز":" EUR"," روش":" sepa", "idempotency_key":"ik_def"}
→ 202 {«state «: «PENDING «, «next _ check _ sec «: 2, «status _ url»: »/v1/withdrawals/w _ 456»}

13) نمونه هایی از ارسال (دو ورودی)

سپرده €100 (هزینه PSP €1، کمیسیون. حساب - جداگانه)


بدهی: PSP_Settlements (EUR) 10000
اعتبار: کاربر. نقدی (یورو) 10000

بدهی: کاربر. نقدی (EUR) 100 (تغییر هزینه)
اعتبار: PSP_Fees (EUR) 100

شرط €5 از پاداش (انتقال به شرط بندی)


بدهی: کاربر. پاداش (EUR) 500
اعتبار: کاربر. شرط (EUR) 500 (حرکت به شرط بندی)
بدهی: کاربر. شرط بندی (EUR) 500
اعتبار: ارائه دهنده حل و فصل (EUR) 500 (نرخ نوشته شده است)

12 یورو برنده شوید 5 به صورت نقدی


بدهی: ارائه دهنده. حل و فصل (EUR) 1250
اعتبار: کاربر. نقدی (یورو) 1250

نگه داشتن خاموش (تحقق از طریق حساب سرویس HOLD)


بدهی: کاربر. نقدی (یورو) 500
اعتبار: کاربر. نگه دارید (EUR) 500 (ایجاد شده توسط نگه دارید)
- در حل و فصل
بدهی: کاربر. نگه دارید (یورو) 500
اعتبار: ارائه دهنده حل و فصل (EUR) 500
- در مورد لغو
بدهی: کاربر. نگه دارید (یورو) 500
اعتبار: کاربر. نقدی (یورو) 500

14) حسابرسی، تغییر ناپذیری و انطباق

WORM/immunity for log (ذخیره سازی شیء/آرشیو WAL).

دسترسی به متا سیاهههای مربوط: که خواندن/تغییر محدودیت، که ساخته شده تنظیمات دستی (تنها از طریق «تنظیم ارسال» با توجیه).

GDPR/تنظیم کننده ها: ذخیره سازی معاملات برای 5-10 سال (توسط صلاحیت)، شفافیت تسویه حساب برای بازیکن (تاریخ نوشتن/شرط بندی).

15) تحمل خطا و DR

چند AZ اجباری ؛ منطقه DR برای کیف پول: همگام سازی تکرار در منطقه، async - به منطقه ؛ PITR فعال است.

ترویج آماده به کار - فقط به صورت دستی توسط چک لیست (حذف تقسیم مغز).

بازگرداندن چک هفتگی (تست بازگرداندن)، آشتی از مقدار گزارش کنترل.

16) قابلیت مشاهده کیف پول

SLI: 'deposit _ success _ ratio', 'withdraw _ success _ ratio', 'bet _ hold _ latency _ p95', 'settlement _ latency _ p95'.

Тех: 'ledger _ postings _ rate', 'db _ connections _ saturation', 'queue _ lag _ seconds', 'hold _ expired _ rate'.

هشدارها: افت موفقیت PSP در بازار، رشد «hold _ expired _ rate»، ارائه دهنده بازی خارج از همگام سازی (بدون تأیید> N min).

17) تست و کنترل کیفیت

تست قرارداد با ارائه دهندگان PSP/بازی (webhooks/signatures).

آزمون های مبتنی بر اموال پول: مجموع بدهی = = مجموع اعتبارات در هر ارسال.

Fuzz/هرج و مرج: تاخیر PSP/ارائه دهنده، تکرار webhook، flappies شبکه.

بار: شرط پشت سر هم (60-120 ثانیه)، خیس (4-8 ساعت)، کنترل «صف _ تاخیر» و p99.

18) چک لیست آمادگی تولید

ورود دو دفتر، تمام عملیات از طریق ارسال با 'operation _ id'.
پاک کردن سیاست های هزینه و ترتیب اولویت (همچنان با ارسال).
دارای TTL/حل و فصل جزئی/انقضای, ارتباط با شرط/برداشت.
صندوق ورودی/خروجی، HMAC webhooks، idempotency در تمام مرزها.
نقدی فردی/پاداش/شرط بندی/FS/امتیاز کیف پول; تقسیم بر ارزها
FX و گرد کردن جزئی ؛ تبدیل - یک عملیات جداگانه.
محدودیت بازی مسئول برای نگه داشتن/بدهی ؛ حسابرسی شکست
خواندن حافظه پنهان (TTL کوتاه) + بررسی حقیقت مورد نیاز قبل از اقدامات بحرانی.
PITR/پشتیبان گیری/اسکریپت DR ؛ کتابچه راهنمای کاربر، تمرینات منظم DR.
داشبورد/هشدار SLI + فنی ؛ لاگ های WORM و لاگ های دسترسی
تست بار/هرج و مرج ؛ گزارش آشتی با PSP/ارائه دهندگان.

خلاصه رزومه

معماری چند کیف پول «بسیاری از اعداد تعادل» نیست، بلکه یک سیستم مالی با دو ورودی، سیاست های هزینه، رزرو و یک دنباله شفاف برای حسابرسی و بازیکنان است. نگه داشتن حقیقت در ورود به سیستم، استفاده از نگه می دارد و idempotence، کیف پول جداگانه و ارز، به طور خودکار آشتی و DR به این ترتیب کیف پول سریع برای UX، دقیق برای پول و مقاوم در برابر بارهای اوج و چک های قانونی خواهد بود.