Როგორ მუშაობს API მსუბუქი თამაშების პლატფორმასთან დაკავშირება

1) კომპონენტების ზოგადი არქიტექტურა და როლი

ოპერატორის პლატფორმა (Casino Platform): ანგარიშები, საფულე, ბონუს ძრავა, ლიმიტები, KYC/AML, გარიგების ჟურნალი.

ცოცხალი თამაშების პროვაიდერი (სტუდია/Provider): სტუდიები, დილერები, ვიდეო ნაკადები (WebRTC/Low-Latency HLS), რაუნდის თამაშის სერვერი.

აგრეგატორი (ზოგჯერ): ერთი API ათეულობით პროვაიდერთან, ვალუტის/ლიმიტის/მოვლენების გაერთიანება.

კლიენტის ფრონტი: ვებ/მობილური კლიენტი UI განაკვეთებით, ვიდეო ოპერატორი, ჩატი, ადგილობრივი რჩევები.

დამხმარე სერვისები: Risk/Anti-fraud, ლოგიკა, ანალიტიკა, შეტყობინებების სტრიქონები (Kafka/RabbitMQ), მონიტორინგი.

ტიპიური ტოპოლოგია: CDN (JWT) კლიენტი - server-server პლატფორმა - პროვაიდერი, ხოლო კლიენტი იღებს ვიდეო ნაკადს CDN/მედია შემქმნელთა აუზიდან.

2) მოთამაშისა და სესიების სასიცოცხლო ციკლი

2. 1. ლოგინი და „თამაშის ნიშანი“

1. მოთამაშე უფლებამოსილია პლატფორმაზე.

2. პლატფორმა იწვევს CreateGameSession პროვაიდერს (S2S), გადასცემს 'player _ id', 'currency', 'country', 'bet _ limits', საპასუხისმგებლო თამაშის დროშებს.

3. პროვაიდერი უბრუნდება ერთჯერადი game _ token და launch _ url.

4. კლიენტი ხსნის 'launch _ ur' iframe/ახალ ჩანართში, დაამატეთ' game _ token '(ან იღებს 302 თამაშის საბოლოო URL- ს).

S2S შეკითხვის მაგალითი:

http
POST /api/v1/sessions
Content-Type: application/json
Authorization: Bearer <platform_api_key>

{
"player_id": "u-918273",  "session_id": "sess-5f3b2",  "currency": "EUR",  "country": "DE",  "lang": "de",  "bet_limits": {"min": 0. 5, "max": 2000},  "responsible_gaming": {"self_excluded": false, "deposit_limit_left": 150},  "callback_urls": {
"balance": "https://platform. example. com/wallet/balance",   "debit":  "https://platform. example. com/wallet/debit",   "credit": "https://platform. example. com/wallet/credit",   "rollback":"https://platform. example. com/wallet/rollback",   "events": "https://platform. example. com/game/events"
}
}

პროვაიდერის პასუხი:

json
{
"game_token": "gtkn_7f0...e2a",  "launch_url": "https://live. provider. com/launch/roulette",  "expires_in": 900
}

2. 2. ავთენტიფიკაცია ფრონტზე

თამაში იტვირთება, ლიდერობს 'game _ token' მისი ბეკენდის საშუალებით.

WebSocket დამონტაჟებულია თამაშის სერვერზე განაკვეთები/მოვლენებისთვის.

ვიდეო ნაკადი გადის WebRTC- ზე (დაბალი შეფერხება 0. 5-2 ს) ან LL-HLS (2-5 ს).

3) ფული და განაკვეთები: Wallet API და idempotence

3. 1. ბალანსი და დებიუტი/სესხი

პროვაიდერი არ ინახავს მოთამაშის „ფულს“ - ის იწვევს პლატფორმის Wallet API- ს:

`GET /wallet/balance? player _ id 'მიმდინარე ხელმისაწვდომია.
'POST/wallet/debit' არის განაკვეთის ჩამოწერა.
'POST/wallet/credit' არის მოგების/დაბრუნების ჩარიცხვა.
'POST/wallet/rollback' რაუნდის გაუქმებისას გარიგების გამოტოვება.

მნიშვნელოვანი: ყველა ფულადი ოპერაცია idempotention _ id '/' round _ id '. იგივე მოთხოვნის გამეორება არ ცვლის შედეგს.

დებეტის მაგალითი (კურსი):

http
POST /wallet/debit
Idempotency-Key: trx-7a2df-001
Content-Type: application/json

{
"player_id": "u-918273",  "round_id": "r-2025-10-18-12:30:15Z-001",  "transaction_id": "trx-7a2df-001",  "amount": 25. 00,  "currency": "EUR",  "bet_type": "roulette_straight",  "meta": {"table_id":"ru-11", "selection":"17", "odds":35}
}

3. 2. დრო და ფსონის სტატუსი

WINDOW_OPEN → WINDOW_CLOSING → WINDOW_CLOSED. 'WINDOW _ CLOSED' შემდეგ, პროვაიდერი კრძალავს ახალ დებატებს.

მოგვიანებით განაკვეთები უარყოფილია კოდი 'LATE _ BET ".

კომუნიკაციის გაწყვეტისას, კლიენტს შეუძლია ხელახლა გაგზავნოს კურსი - სერვერმა უნდა შეძლოს განასხვავოს დუბლიკატი Idempotency-Key- ის მიხედვით.

გარიგების სტატუსები: 'PENDING', 'SETTLED', 'ROLLED _ BACK', 'REJECTED'.

4) რაუნდის მოვლენები: მოდელი და რიგითი

4. 1. WebSocket მოვლენების სქემა

`round. started ', მოდის' round _ id ', განაკვეთების ტაიმერი.

`bet. accepted/rejected '- დადასტურება თითოეული კურსისთვის.

`round. closed '- ის განაკვეთები აღარ მიიღება.

`round. result '- შედეგი (რულეტის/რუქების/ძვლების სექტორი).

`payout. created '- მოთამაშის მოგების ოდენობა.

`round. settled '- საბოლოო სტატუსი, საკონტროლო თანხა.

შედეგის მოვლენის მაგალითი:

json
{
"type": "round. result",  "round_id": "r-2025-10-18-12:30:15Z-001",  "table_id": "ru-11",  "payload": {
"roulette": {"number":17, "color":"black"},   "hash": "sha256:8a7b...d1c",   "video_ts": "2025-10-18T12:30:23. 450Z"
}
}

4. 2. თანმიმდევრულობა და მაკონტროლებელი თანხები

თითოეული ღონისძიება აღჭურვილია 'seq' და 'signature' (mTLS + მოთხოვნის სხეულის ხელმოწერა).

რეკონსტრუქციისთვის მითითებულია 'payout _ checksum' - ყველა 'round _ id' სესხის ოდენობა უნდა შეთანხმდეს.

5) ვიდეო ნაკადი და შეფერხება

WebRTC განაკვეთებისთვის „ცოცხალი ხელით“ (blackjeck/backar/rulet) არის მკაცრი შეფერხების ბიუჯეტი <2 c კლიენტამდე.

LL-HLS/DASH აუდიტორიისთვის/მასშტაბისთვის, საშუალებას აძლევს 2-5 წმ.

დროის სინქრონიზაცია: NTP/chrony, payload- ში - 'video _ ts' რეპლიკებისა და დავებისთვის.

Folback: WebRTC- ის დეგრადაციის დროს, მანქანის შეცვლა LL-HLS- ზე გვიანდელი განაკვეთების ბლოკირებით.

6) შეცდომები, რეტრაები, ტაიმაუტები

ზოგადი წესები:

ყველა S2S გამოწვევა 800-1500 ms ტაიმაუტით, ექსპონენციალური პაუზით და Jitter- ით, მაგრამ ფულის ხელახლა ჩამოწერის გარეშე (idempotence).

საფულის შეცდომების კოდი:

`INSUFFICIENT_FUNDS`, `LIMIT_EXCEEDED`, `ACCOUNT_LOCKED`, `DUPLICATE_TRANSACTION`, `LATE_BET`, `CURRENCY_MISMATCH`.

შეცდომის ფორმატი:

json
{
"error": "INSUFFICIENT_FUNDS",  "message": "Balance 18. 00 < required 25. 00",  "transaction_id": "trx-7a2df-001"
}

7) პრემიები, ფრისპინები, დაზღვევა

"ფულადი" საფულის პარალელურად, შეიძლება იყოს ბონუსის ბალანსი: "წყაროს: CASH	BONUS`.
მსუბუქი თამაშებისთვის, დაზღვევა/გვერდითი ბეტი (მაგალითად, ბლექჯეკში) ხშირია - ეს არის ცალკეული გარიგებები საკუთარი ლიმიტით და კოეფიციენტებით.
დამრგვალების წესები: საბანკო (half-to-even) ან მოთამაშის/ოპერატორის სასარგებლოდ - უნდა იყოს ჩაწერილი ინტეგრაციის კონფისკაციაში.

8) პასუხისმგებელი თამაში და შეზღუდვები

სხდომის დროშები: 'self _ excluded', 'cooldown _ until', 'loss _ limit _ left', 'time _ limit _ left'.

ყოველი დებიუტის წინ პროვაიდერს შეუძლია მოითხოვოს 'validate _ limits ".

პლატფორმას შეუძლია დაიწყოს force _ close _ session: მოთამაშემ გამორიცხა/გადააჭარბა ზღვარს - პროვაიდერი დახურავს განაკვეთების ფანჯარას და აურზაურს უწყვეტი განაკვეთებით.

9) უსაფრთხოება და შესაბამისობა

mTLS S2S, HSTS, მკაცრი IP ალოვლისტი.

JWT/JWS მოკლე TTL წინა ხაზების, აუდიტის/issuer- ის შემოწმებისთვის.

Webhook's პროვაიდერის ხელმოწერა (HMAC-SHA256 სხეულზე).

დილერების მოქმედებების ლოგოები, რაუნდი, უცვლელი აუდიტი (WORM საცავი).

პერსონალური მონაცემების შენახვა - PII- ის მინიმიზაცია, 'player _ id' ტოქსიკაცია, იურისდიქციის შენახვის ვადა (GDPR და ანალოგები).

Geo დაბლოკვა და იურისდიქციის აკრძალვები CreateGameSession დონეზე.

10) რეკონსტრუქცია და ფინანსები

10. 1. საათობრივი/ყოველდღიური მოხსენებები

პროვაიდერი აწვდის მოხსენებას 'round _ id' total _ bets, total _ wins, fees '. პლატფორმა აერთიანებს:

დებატების ჯამი = განაკვეთები, სესხების ჯამი = მოგება + გადახდა, დელტა = GGR (ბონუსების/ჯეკპოტების/კომისიების გათვალისწინებით).

ანგარიშის ფორმატი:

json
{
"date": "2025-10-18",  "currency": "EUR",  "tables": [{
"table_id": "ru-11",   "rounds": 1260,   "total_bets": "45230. 00",   "total_payouts": "43012. 50",   "jackpot_contrib": "302. 00",   "provider_fee": "2. 5%"
}]
}

10. 2. Rollback სცენარები

ვიდეო/სცენარის მარცხი. cancelled: პროვაიდერი მართავს 'rollback' ყველა კურსს.

დებეტის ორმაგი დამუშავება, რომელიც დაიჭირეს პლატფორმაზე „DUPLICATE _ TRANSACTION“ და 200 OK იგივე შედეგით.

11) ჩატი, UI მოდერაცია და მოვლენები

ჩატის მოვლენები გადის ცალკეულ არხზე (WebSocket No. 2), ფილტრებით, გაჩერებული სიტყვებით.

სისტემური განცხადებები (close bets, winner list) - მხოლოდ პროვაიდერის სანდო წყაროდან, გაფორმებულია/დროულად.

12) ტესტირება და სერტიფიკაცია

Sandbox პროვაიდერი: ფიქსირებული შედეგები, იძულების შესაძლებლობა. result`.

QA კონტური: ტესტის მაგიდა შემცირებული განაკვეთების ფანჯრებით (5-8 გ) და დაჩქარებული ფლეშ.

დატვირთვა: 5-10 ათასი ერთდროული მოთამაშის იმიტაცია, წამში პიკის დებატები (TPS) - დაგეგმილი × 1. 5.

ინტეგრაციის სერთიფიკატი: ჩეკის ფურცლები impotence, ვალუტები, დამრგვალება, გამორთვა დამუშავება, ლიმიტების შესაბამისობა და სელფის ექსპოზიცია.

13) მეტრიკა და SLO

ისინი: median/95p latency 'debit/credit', WebSocket round-trip, დროის სინქრონიზაციის შეცდომა, drop-rate WebRTC.

Продукт: bet acceptance rate, late-bet rate, dispute rate, chargeback rate, session duration, retention, ARPU/LTV.

SLO მაგალითები:

99. 5% `debit` ≤ 1. 2 გვ, 99. 9% მიწოდება 'round. Result '300 ms ფიქსაციის შემდეგ, ვიდეო მხარდაჭერა - 2. 5 გვ 95p WebRTC- სთვის.

14) მულტივალუტა, გადასახადები, ლოკალიზაცია

კონვერტაცია - პროვაიდერის გარეთ: თამაში მუშაობს მკაცრად სესიის ვალუტაში.

გადასახადები/შეკავება - პლატფორმის მხარეს „კრედიტში“ (ველი 'witholding').

ლოკალიზაცია: 'lang', რიცხვების/ვალუტის ფორმატი, ტაიმერების დროის ზონა და მოხსენებები.

15) ინტეგრაციის ვარიანტები

1. პირდაპირი გადაცემა: მაქსიმალური კონტროლი და დარტყმა, მაგრამ ინდივიდუალური კონტრაქტები/სერთიფიკატი.

2. აგრეგატორის საშუალებით: პროვაიდერების მიერ სწრაფი საფარი, ერთიანი სქემები, ზოგჯერ ნაკლები მოქნილობა.

3. ჰიბრიდი: ტოპ მაგიდები პირდაპირ, დანარჩენი აგრეგატორის საშუალებით.

16) მინი სპეციფიკაცია (ჯამში)

16. 1. WebSocket შედის (კლიენტიდან პროვაიდერში)

json
{ "type":"bet. place", "bet":{
"amount": 25, "selection":"17", "table_id":"ru-11"
}, "idempotency_key":"c3a2-...-001" }

16. 2. WebSocket გამომდინარეობს (პროვაიდერიდან კლიენტამდე)

json
{ "type":"bet. accepted", "bet_id":"b-8821", "seq":12031 }
{ "type":"round. closed", "round_id":"r-...001", "seq":12050 }
{ "type":"round. result", "result":{"number":17,"color":"black"}, "seq":12070 }
{ "type":"payout. created", "amount":875, "currency":"EUR", "seq":12075 }

16. 3. Wallet S2S (პლატფორმა - პროვაიდერი)

'POST/wallet/debit' (იდემპოტენტურად)

'POST/wallet/credit' (idempotent)
'POST/wallet/rollback' (იდემპოტენტურად)

ხელმოწერა HMAC, 'Timestamp', 'Nonce', გამეორებისგან დაცვა (TTL-60 გ).

17) რეგიონალური საქმეები და როგორ დავხუროთ ისინი

მოთამაშეს აქვს კავშირის უფსკრული: კურსი გაიგზავნა, დადასტურება არ არსებობს, განმეორება იგივე 'Idempotency-Key'; სერვერი უპასუხებს წინა სტატუსს.

რაუნდში დილერის/გემბანის შეცვლა: ავტომატური გაუქმება და სრული 'rollback'.

ვალუტის შეუსაბამობა: 'CURRENCY _ MISMATCH' + ღონისძიების ჟურნალი; თამაში დაბლოკილია სხდომის ხელახლა გამოსვლამდე.

Self-exclusion თამაშის დროს: დაუყოვნებლივი 'force _ close _ session', დაუმუშავებელი დაბრუნება.

ვიდეოს ხარისხის შეცვლა: მხოლოდ კლიენტი, ტაიმერების/განაკვეთების გავლენის გარეშე.

Re Handshake WebSocket: წესრიგის დაკარგვის გარეშე - მოვლენების ხაზი „seq“, გამოტოვებული „დაჭერა“.

18) წარმოების ჩეკის სია

უსაფრთხოება

mTLS + pinning სერტიფიკატი, IP-allowlist.
ყველა webhook- ის ხელმოწერა და შემოწმება 'Timestamp '/' Nonce'.
მინი-PII: მხოლოდ 'player _ id' (ტოკნიზირებული).

საიმედოობა

ყველა ფულადი ოპერაციის Idempotence.
რაუნდი და უცვლელი აუდიტი.
WebRTC-LL-HLS მანქანების ფოლკლორი.

პროდუქტი

ლიმიტები/საპასუხისმგებლო თამაში გამოიყენება რეალურ დროში.
მშობლიური რჩევები განაკვეთის დროს.
დაშბორდები SLO + ალერტები 24/7.

ლაივ თამაშების ინტეგრაციის API არის დაბალი დონის ნაკადის, ღონისძიების საბურავის და იდემპოტენტური საფულის კავშირი, რომელსაც აქვს მკაცრი მოთხოვნები შეტყობინებების, ტაიმინგებისა და უსაფრთხოების შეკვეთისთვის. წარმატებული განხორციელება ემყარება: ფსონებისა და რაუნდის მკაცრი სასიცოცხლო ციკლი, დადასტურებული თანმიმდევრულობა (reconciliation), მონაცემთა დაცვა და საპასუხისმგებლო თამაშის შეზღუდვები - და „ლამაზი მაუწყებლობა“ გადააქცევს საიმედო, დამოწმებულ ფინანსურ პროდუქტს.