Echilibru și portofele: arhitectură multi-portofel

1) De ce multi-portofel și ce obiective

O intrare „balance = number” nu acoperă realitatea iGaming. Sunt necesare portofele/subconturi separate: bani reali (cash), fonduri bonus, pool pariu, freespins, puncte de calculator, uneori portofele valutare (EUR/USD/BRL).

Obiectivele arhitecturii sunt:

Precizia banilor (intrare dublă, auditabilitate).
Politica de deconectare (de exemplu, primul bonus/vager, apoi numerar).
Viteza (p95 API ≤ 250-400 ms, pariu/decontare în timp real).
Siguranță și conformitate (KYC/AML, limite de joc responsabil, autorități de reglementare).
Scară: vârfuri → zeci de mii de operațiuni/sec, miliarde de posturi/lună.

2) Modelul de date: "Ledger + Subwallets'

Entități minime

Cont: jucător/marcă/piață.

Portofel: '{tip: CASH	BONUS	WAGER	FS	PUNCTE, valută, status} '.
LedgerEntry (двойная запись): 'debit _ account',' credit _ account', 'suma', 'valuta', 'operation _ id',' categorie ',' creat _ at '.
Postare: operațiune de afaceri atomice, combină 2 + LedgerEntry.
Hold/Rezervare: blocarea temporară a fondurilor pentru pariu/retragere.
Politică: reguli de reducere/prioritate a creditului.
FXRate: reguli de curs/precizie/rotunjire.
Limită: zi/lună/joc responsabil.

Exemplu de tabele (simplificat)

sql
-- Conturi bilanțiere pentru dublă intrare (inclusiv afaceri)
conturi (id, owner_user_id, tip, valută, stare,...)

- Postare (intrare dublă, referință la tranzacția de afaceri)
 (id, , , , valută, categorie, )

-- Deține (rezerve)
deține (id, , , valută, motiv, , stat, )

-- Politici de anulare (priorități)
spend_policies (id, market, wallet_priority jsonb, updated_at)

-- Ratele de schimb încrucișate fx_rates (ccy_from, ccy_to, rata, precizie, valid_from)

Regulă: Adevărul trăiește în jurnalul tranzacției ('ledger _ entries'). Soldul actual este fie un agregat (instantaneu materializat), fie este calculat dintr-un jurnal (scump, dar numai adevărat).

3) Tipuri de portofele și comportamentul lor

Pungă	Cur	Poate reîncărca	Poate fi eliminat	Reguli speciale
CASH	Bani reali	PSP/acumulări/returnări manuale	Oferte, achiziții, retrageri	Afectează AML/KYC; tranzacțiile sunt înregistrate
BONUS	Bani bonus	Promo/Campanii	Tarife (după reguli)	Nu este afișat direct, convertit în numerar atunci când vagerul este executat
WAGER	Contabilizarea bonusurilor „congelate”	Auto din bonusul de pariu	Reduceri în favoarea furnizorului de jocuri	Decontați/Anulați regula de eliberare
FS (FreeSpins)	Pachete de rotație	Campanii	Rambursarea în sloturi	Echivalentul în numerar este stabilit la T&C
PUNCTE	Loialitate/comps	Activitate	Magazin/statusuri	Nu bani; neincluse în rapoartele LMA

4) Politica de eliminare și ordinea prioritară

Formalizați în mod clar algoritmul pentru sursa de fonduri: Exemplu (sloturi/cazinouri):

1. În primul rând, scrieți de pe WAGER (în cazul în care pariul este activ).

2. Apoi de la BONUS până la epuizare.

3. Restul este de la CASH.

Exemplu (sport):

1. Primul CASH (regulator/taxă).

2. Apoi BONUS (freebet), traducerea la WAGER.

Salvați „decizia de politică” ca atribut în Postări, astfel încât suportul și auditul să vadă „de ce au scris-o”.

5) Ciclul de viață al banilor și operațiunilor

Depozit

1. „POST/PORTOFEL/depozit” → crea o intrare în așteptare (inbox de cârnați PSP).

2. Webhook PSP (semnătură HMAC, idempotență prin 'operation _ id') → credit CASH, categoria =' DEPOZIT '.

3. Publicăm evenimentul „wallet _ update”.

Rata

1. 'POST/bet/place' → creează o rezervă în contul sursă (CASH/BONUS/WAGER).

2. La confirmarea ratei, transferul sursei de deținere → debit, creditul contului de „decontare” al furnizorului este →.

3. După anulare - așteptare eliberare.

Decontare (rezultat)

Câștig: debitul contului de „decontare” al furnizorului → credit CASH sau WAGER→BONUS→CASH poliței.

Pierdere: închideți „cheltuiala” furnizorului cu un → de tranzacție fără credite pentru jucător.

1. Verificarea KYC/AML, limitele jocului responsabil.

2. Stai pe suma de retragere.

3. Succesul PSP → debitul final CASH → „plata” contului de credit.

4. Suspendarea eliberării → PSP a eșuat.

6) Idempotența și exact o dată „în sens”

Oriunde 'operation _ id' (UUID/ULID îmbunătățit) cu un index unic. Re-solicita statutul → al tranzactiei anterioare.

Cârlige PSP/furnizor de jocuri: Tabel Inbox cu dedupe prin 'event _ id + signature'. Prelucrare - lucrător idempotent (model Outbox).

Idempotency-Key pe HTTP pentru client; A se păstra TTL ≥ 24-72 ore.

7) Rezerve și dețineri

Hold nu este o reducere, ci o „înghețare” a soldului disponibil.

Reguli:

Durata de viață: seconds→minutes (rată) sau ore (ieșire).
Cala poate fi stinsă parțial sau complet (decontare parțială).
Când expiră - eliberare automată și eveniment.
Păstrați relația 'hold _ id' ↔' bet _ id/retrage _ id'.

8) valute, FX și rotunjire

Sume monetare - în unități minore (cenți), tip - întreg.

Rotunjire bancară (rotundă de la jumătate la egal) sau prin T & C.

FX: „CASH (EUR)” ↔ „CASH (USD)” este mai bine să împărțiți portofelele. Conversia ca o operație separată:

"debit EUR, FX_EURUSD' de credit și" debit FX_EURUSD, credit USD "- transparent pentru audit.
Este interzis să „atingeți” automat cursul într-un litigiu; toate regulile sunt în politica FX.

9) Jocul responsabil și limitele

Depunere/Pariu/Pierdere/Limite de sesiune (zi/săptămână/lună), răcire, auto-excludere.

Implementat ca pre-verificare înainte de așteptare/debit.

Jurnalele de eșec - într-un jurnal de audit separat, disponibil pentru suport și regulator.

10) Semnale antifraudă în jurul portofelului

Clustere de dispozitive/ASN-uri, depozite mici frecvente → retrageri mari, modele de spălare.

Limite de viteză la „depozit/în interiorul” de BIN/țară/dispozitiv.

Liste de blocuri pentru destinatari (portofele/IBAN), lista de „catâri”.

Evenimente de portofel → în magazinul de caracteristici de notare (autentificare/depunere/rată).

11) Coerență și performanță

Adevărat vs cache

Adevărul este în registru. Pentru API-ul „get balance”, păstrați instantaneul materializat ('user _ id + wallet _ type → balance_minor, version').

Scrieți: o tranzacție în baza de date → invalida memoria cache.

În „heavy” flow (live), short-TTL 1-5 s + verificarea obligatorie a adevărului înainte de retragere/pariu mare este adecvat.

Opărire

Sharding by 'user _ id' (modul/clasament), piscine separate cioburi pentru CASH vs BONUS.

Tastele fierbinți (VIP/boți) - solicită coagularea prin 'user _ id'.

Agregări asincrone (compuneți „postare” → „actualizare-instantaneu” în fundal).

12) contracte API (pseudo)

Echilibru

http
GET/v1/portofele? Tipuri = CASH, BONUS
→ 200 {„portofele”: [
{"type": "CASH", "valută": "EUR", "available": 12050, "hold': 500," version ": 1942}, {" type ":" BONUS "," valută ":" EUR "," disponibil ": 3000," wager _ req ": 15000}
]}

Pariu (cu așteptare)

http
POST/v1/pariuri/loc
{„bet _ id':” b _ 123 „,” sumă „: 500”, monedă „:” EUR „,” source _ policy „:” casino _ default „,” idempotency_key":"ik_abc"}
→ 201 {„status”: „HOLD',” hold _ id': „h _ 789”, „expiră _ in”: 30}

Decontare

http
POST/v1/pariuri/soluționare
{"bet _ id':" b _ 123 "," rezultat ":" WIN "," payout ": 1250}
→ 200 {„status „: „SETTLED „,” cash _ delta”: + 1250}

http
POST/v1/retrageri
{„retragere _ id':” w _ 456 „,” sumă „: 10000”, monedă „:” EUR „,” metodă „:” sepa „,” idempotency_key":"ik_def"}
→ 202 {"state": "PENDING", "next _ check _ sec": 2 ", status _ url': "/v1/retrageri/w _ 456"}

13) Exemple de postări (dublu-intrare)

Depozit €100 (taxa PSP €1, commis. cont - separat)


Debit: PSP_Settlements (EUR) 10000
Credit: Utilizator. NUMERAR (EUR) 10000

Debit: Utilizator. CASH (EUR) 100 (schimb de taxe)
Credit: PSP_Fees (EUR) 100

Pariu €5 din BONUS (transfer în WAGER)


Debit: Utilizator. BONUS (EUR) 500
Credit: Utilizator. PARIU (EUR) 500 (trecere la pariu)
Debit: Utilizator. PARIU (EUR) 500
Credit: Furnizor. Decontare (EUR) 500 (rata anulată)

Câștigă €12. 5 → în numerar


Debit: Furnizor. Decontare (EUR) 1250
Credit: Utilizator. NUMERAR (EUR) 1250

Mențineți dezactivarea (realizare prin intermediul contului de service HOLD)


Debit: Utilizator. CASH (EUR) 500
Credit: Utilizator. HOLD (EUR) 500 (creat de hold)
-- la soluționare
Debit: Utilizator. HOLD (EUR) 500
Credit: Furnizor. Decontare (EUR) 500
-- la anulare
Debit: Utilizator. HOLD (EUR) 500
Credit: Utilizator. CASH (EUR) 500

14) Audit, imutabilitate și conformitate

WORM/imunitate pentru jurnal (depozit obiect/arhivă WAL).

Accesați meta-jurnalele: cine a citit/schimbat limitele, cine a făcut ajustări manuale (numai prin „ajustare-postare” cu justificare).

GDPR/autorități de reglementare: stocarea tranzacțiilor timp de 5-10 ani (în funcție de jurisdicție), transparența decontărilor pentru jucător (istoricul reducerilor/pariului).

15) Toleranța la erori și DR

Multi-AZ obligatoriu; Regiunea DR pentru portofel: replicarea sincronizării în zonă, async - în regiune; PITR este activat.

Promovarea standby - numai manual prin lista de verificare (exclude split-creier).

Restabiliți verificarea săptămânală (test-restaurare), reconcilierea cantității de rapoarte de control.

16) Observabilitate portofel

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

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

Alerte: Scăderea succesului PSP pe piață, creșterea 'hold _ expired _ rate', furnizorul de jocuri în afara sincronizării (fără confirmări> N min).

17) Testarea și controlul calității

Teste de contract cu furnizorii de PSP/jocuri (webhooks/semnături).

Teste de bani bazate pe proprietate: suma debitelor = = suma creditelor în fiecare Postare.

Fuzz/haos: întârzieri PSP/furnizor, repetări de cârlig web, flappies de rețea.

Încărcare: pariuri de spargere (60-120 s), înmuiere (4-8 h), control „coadă _ lag” și p99.

18) Lista de verificare a pregătirii pentru producție

Înregistrare dublă a registrului, toate operațiunile prin Postare cu 'operation _ id'.
Politici clare de cheltuieli și ordinea prioritară (persistă cu postarea).
Deține cu TTL/soluționare parțială/expirare, comunicare cu pariu/retragere.
Inbox/Outbox, carti web HMAC, idempotenta la toate frontierele.
Portofele individuale CASH/BONUS/WAGER/FS/POINTS; împărțite pe valute.
FX și rotunjire minoră; conversie - o operațiune separată.
Limite de joc responsabil pentru a deține/debit; audit de eșec.
Citiți memoria cache (scurt TTL) + verificarea adevărului necesar înainte de acțiunile critice.
PITR/backup-uri/scripturi DR; promovarea manuală, exerciții DR regulate.
Tablouri de bord/alerte SLI + tehnice; Jurnalele WORM și jurnalele de acces.
Teste de încărcare/haos; rapoarte de reconciliere cu PSP/furnizori.

Rezumat reluare

Arhitectura multi-portofel nu este „multe numere de echilibru”, ci un sistem financiar cu o intrare dublă, politici de cheltuieli, rezervare și un traseu transparent pentru audit și jucători. Păstrați adevărul în jurnal, utilizați deține și idempotence, portofele separate și valute, automatizați reconcilierea și DR. în acest fel portofelul va fi rapid pentru UX, precis pentru bani și rezistent la sarcini de vârf și verificări de reglementare.