加密赌场

Torrent Gear

Live Games连接到平台的API如何工作

1）通用架构和组件角色

运营商平台（Casino Platform）：帐户，钱包，奖金引擎，限制，KYC/AML，交易日志。

实时游戏提供商（Studio/Provider）：工作室，经销商，视频流（WebRTC/Low-Latency HLS），回合游戏服务器。

聚合器（有时）：单个API到数十个提供商,统一货币/限制/事件。

客户端前端： Web/移动客户端与 UI投注,视频播放器,聊天,本地提示.

支持服务：Risk/Anti-fraud、拼写、分析、消息队列（Kafka/RabbitMQ）、监控。

类型拓扑：→客户端（JWT）→ →平台（服务器到服务器）→提供商，并行接收来自CDN/媒体服务器池的视频流。

2）玩家的生命周期和会议

2.1.Login和"游戏令牌"

1.玩家在平台上授权。

2.该平台从提供商（S2S）调用CreateGameSession，传递负责任的游戏标志"player_id"，"currency"，"country"，"bet_limits"。

3.提供商返回一次性game_token和launch_url。

4.客户端在iframe/新选项卡中打开 "launch_url"，方法是添加"game_token"（或在游戏的目的URL上接收302）。

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 （c）或LL-HLS （2-5 c）。

3）金钱和赌注： 钱包API和平均水平

3.1.资产负债表和借记/贷款

提供商不存储玩家的"金钱"-它调用Platform Wallet API：

`GET /wallet/balance?player_id' →当前可用。
"POST/wallet/debit" →注销费率。
"POST/wallet/credit" →记入奖金/退款。
"POST/wallet/rollback" →取消回合时回滚交易。

重要：所有货币交易都是通过"transaction_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.收到/回收"→每个费率的确认。

`round.closed '→不再接受赌注。

`round.结果"→结果（轮盘赌部门/地图/骨头）。

`payout.created '→玩家获胜的金额。

`round.定位"→最终状态,校验和。

结果事件的示例：

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+请求主体签名）。

对于reconciliation，指定"payout_checksum"-"round_id"上所有积分的总和必须收敛。

5）视频流和延迟

WebRTC的"活手投注"（二十一点/七叶树/轮盘）是对客户的严格延迟预算<2 c。

用于观众/比例的LL-HLS/DASH，允许2-5 c。

时间同步：NTP/chrony，在payload中-"video_ts"用于回放和争议。

后退：当WebRTC降级时，→自动切换到LL-HLS，并锁定后期投注。

6）错误，retrai，taymauts

一般规则：

所有带有800-1500毫秒时间的S2S呼叫，带有指数暂停和Jitter的转发，但没有重新注销（等效性）。

钱包错误代码：

`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）奖金,frispins,保险

与"现金"钱包平行时，可能会有奖金余额：付费注销来源"来源：CASH	BONUS`.
对于轻量级游戏，保险/边球（例如二十一点）是具有自身限制和赔率的单独交易。
四舍五入的规则：银行（半进制）或有利于玩家/运营商-必须记录在集成组合中。

8）负责任的游戏和限制

会话标志为"self_excluded"、"cooldown_until"、"loss_limit_left"、"time_limit_left"。

提供商可以在每次借记之前查询"validate_limits"。

平台可以启动force_close_session：玩家被排除/超过限制→提供商关闭下注窗口并以未下注的下注退款。

9）安全和合规性

mTLS用于S2S，HSTS，严格的IP allowlist。

JWT/JWS具有用于前端令牌的简短TTL，可听性/可听性检查。

提供商webhook的签名（HMAC-SHA256在身体上）。

经销商操作日志,回合中继,不变审核（WORM存储）。

个人数据存储-PII最小化，"player_id"标记化，司法管辖区保留时间（GDPR和类似物）。

根据CreateGameSession级别的司法管辖区进行地理锁定和禁令。

10）重新安置和财务

10.1.每小时/每日报告

提供商提供有关"round_id → total_bets total_wins，fees"的报告。该平台总结了：

借方总额=赌注Σ，贷款总额=Σ获胜+退款，Delta=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 c）和加速流量的测试表。

负载： 模拟5-10,000个同时玩家，峰值每秒借记（TPS）≥计划× 1。5.

集成认证：关于等效性、货币、四舍五入、停电处理、限额匹配和自我释放的支票单。

13）度量标准和SLO

这些：median/95 p latency for '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 c，99。9%送货回程。result '≤ 300毫秒固定后，视频支持≤ 2.5 s用于95p WebRTC。

14）多元货币、税收、本地化

转换-非提供商：游戏严格以会话货币运行。

税收/保留-在"信用"（"withholding"字段）的平台侧。

本地化："lang"，数字/货币格式，计时器和报告的时区。

15）集成选项

1.Direct-to-Provider：最大控制和视野,但单独的合同/认证。

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"（偶数）
"POST/wallet/rollback"（偶数）

HMAC标题"Timestamp"，"Nonce"，重复保护（TTL ≤ 60 c）。

17）边缘案例以及如何关闭它们

玩家的连接断裂：发出赌注，没有确认→使用相同的"Idempotency-Key"重播；服务器将响应以前的状态。

在回合中更换经销商/甲板：自动取消和完整的"rollback"。

货币不匹配："CURRENCY_MISMATCH"+事件日志；游戏被阻止直到会话过多。

游戏时的自我释放：即时"force_close_session"，返回未播放。

视频质量的变化：仅限客户,不影响计时器/投注。

Re-handshake WebSocket：在不失去订单的情况下-一队事件以"seq"、"追赶"错过。

18）生产启动支票清单

安全性

mTLS+pinning证书,IP allowlist。
所有webhook的签名和检查"Timestamp"/"Nonce"。
Mini-PII：只有"player_id"（标记）。

可靠性

所有现金交易的可持续性。
回合回合和不可改变的审计。
WebRTC → LL-HLS自动后退。

产品

限制/负责任的游戏实时应用。
投注时的本机提示。
SLO+Alerta Dashbords 24/7。

Live Games Integration API是一捆低支撑流、事件总线和偶数钱包，对消息顺序、时间和安全性有严格的要求。成功的实施依赖于以下因素：严格的投注和回合生命周期，可验证的一致性（reconciliation），数据保护和负责任的游戏限制-并将"美丽的广播"转变为可靠，可认证的金融产品。