賭場如何通過橋梁連接直播提供商

什麼是現場賭場背景下的橋梁

Bridge是運營商平臺與實時提供商（Evolution，Pragmatic Live，Ezugi，TVBet等）之間的分層，可使API，事件，拼寫和財務計算正常化。簡而言之，橋使十幾種不同的「視圖」集成相同：單個投註合同，單個回合狀態方案，單個webhooks和報告性。

為什麼需要它

數十家提供商的單一合同（減少平臺更改）。

相似性和雙打防守（網絡後衛，玩家重新偵察）。

目錄正常化（表、限制、邊框、位置）。

單一現金和風險規則（限制，AML/KYT，RG）。

跨供應商監視QoS流和SLA。

組件鏈

1.賭場平臺（主機）：帳戶，KYC/RG，獎金，錢包，前線。

2.橋：提供商適配器，事件總線，桌子/極限布局，結算，拼寫，webhooks。

3.實時提供者：流（通常是WebRTC/HLS），遊戲引擎，計算結果，經銷商。

4.錢包：Seamless（資產負債表由運營商持有）或Transfer（由提供商存入遊戲銀行）。

5.可觀察性：流度度量（FPS，RTT，緩沖區），業務度量（Bet，GGR，Hold）。

網絡協議和會議

視頻：

WebRTC-低延遲（100-500毫秒），需要ICE/STUN/TURN。
HLS/LL-HLS-延遲較高，但比CDN更簡單。
費率和事件：WebSocket/HTTP-SSE/REST。
代幣：短壽命的JWT/opaque（TTL 3-10分鐘），根據提供商的要求輪換。

錢包模型

1） Seamless wallet（推薦）

利率/付款通過橋梁進入運營商的錢包。

優點：單一平衡,即時限制控制,簡化RG。

缺點：嚴格的錢包可用性（SLA）要求。

2) Transfer wallet

玩家將資金從提供商轉移到「桌子銀行」。

優點：峰值期間操作員錢包的負荷較小。

缺點：更難回收、回收和AML控制,在UX中摩擦。

會話生命周期（seamless）

1./createSession → bridge創建「sessionId」，返回「streamUrl」，「betSocketUrl」。

2.前端打開播放器（WebRTC/HLS）和事件連接。

3.玩家在橋上押註「placeBet」（「idempotencyKey」，「roundId」，「selection」，「stake」）。

4.Bridge授權錢包中的金額（保留）→確認提供商。

5.提供商宣布「bettingClosed」 → spin/deal → 「roundResult」。

6.Bridge計算付款，註銷/退回hold，生成「transactionId」。

7.Bridge將webhook平臺放下（「roundId」，「result」，「payout」，「balanceAfter」），寫信給ledger。

8.完成/重新連接-通過「sessionId」（平均）。

事件合同（示例）

橋梁→率（WS/REST）：

json
{
"type": "bet.place",  "idempotencyKey": "c0a4-77f…",  "sessionId": "sess_abc123",  "roundId": "R-2025-10-17-18:45:03-Table23",  "selection": [{"market":"roulette_straight","value":"17"}],  "stake": {"amount":"5.00","currency":"EUR"},  "limitsProfile":"VIP_A"
}

橋梁答案：

json
{
"status":"accepted",  "balanceHold":"-5.00",  "betId":"bet_9f2…",  "effectiveLimits":{"maxBet":"5000.00"}
}

回合結果→平臺（webhook）：

json
{
"event":"round.settle",  "roundId":"R-2025-10-17-18:45:03-Table23",  "bets":[
{"betId":"bet_9f2…","stake":"5.00","payout":"180.00","outcome":"WIN"}
],  "transactions":[
{"id":"trn_bet_9f2…","type":"DEBIT","amount":"5.00"},   {"id":"trn_pay_9f2…","type":"CREDIT","amount":"180.00"}
],  "balanceAfter":"1320.40"
}

關鍵規則：

相似性：所有查詢「idempotencyKey」。
明確的結果類型：「WIN/LOSE/PUSH/VOID/RETRY」。
穩定標識符：「roundId」是全局唯一的（表+時間+shard）。

目錄和限制

Discovery： '/providers/： id/tables'-桌子列表、限制、邊框、語言、時間表。

限制池：「DEFAULT」，「VIP_A」，「VIP_B」，「Ultra」。

Mapping規則：國家/貨幣/KYC狀態→允許的桌子和限制配置文件。

熱極限變化：事件極限。更新"而不重新啟動桌面。

流的可觀察性和質量（QoS）

玩家指標：

投註信號的RTT（目標<150 ms WebRTC）。
Dropped frames / buffer events.
Bitrate/Resolution改編。
投註窗口（在「bettingOpen」和實際投註之間的時間）。

提供商/桌子上的指標：

桌子的上限，簡易的回合，後期設置，「VOID」頻率。
博彩結束後平均計時。
QoS alerta：FPS降解，「retry」爆發。

合規與安全

KYT/AML：存款來源分析、「高風險」標誌→現場投註禁令。

RG（負責任的遊戲）：超時，限制，自我體驗-在「placeBet」之前應用。

數據駐留：邏輯和PII存儲在操作員中；橋僅存儲技術。雜誌和單位。

運輸安全：mTLS/IP-whitelist到提供商,HMAC請求簽名,短令牌的TTL。

審計：leder不可變（WORM/僅append-only），通過「roundId」/「sessionId」導出。

計算、重新計算和退款

飛行設置：每個結果的即時借記/信用。

Batch reconcile：提供商報告（hourly/daily）與bridge ledger （P&L,傭金）核對。

VOID/REFUND腳本：流失、經銷商錯誤、爭議-部分/完全退貨,有明確的原因代碼。

Dispute center：「roundId」捆綁包↔錄制視頻映射（超時代碼）,以便支持快速解決提卡問題。

性能和容錯能力

標量：提供商的靜態適配器+Kafka/NATS作為事件總線。

存儲：用於會話/限制的熱（Redis），用於ledger的熱（Postgres），用於日誌的冷（S3）。

Folbacks：如果錢包沒有響應-帶有後退的「SOFT_DECLINE」；如果提供商不可用-關閉大廳中的桌子/隱藏。

難得的回程：通過網絡時間表重復「placeBet」/「settle」是安全的。

UX： 前端模式

時鐘同步：使用橋上的「serverTime」進行「通過關閉博彩……」計時器。

本地化：經銷商語言≠接口語言；顯示字幕/術語表。

流播放器：網絡較差時自動倒置WebRTC → LL-HLS。

錯誤UI：易懂的代碼（"LBRG-401 TOKEN_EXPIRED'，"LBRG-429 LIMIT_EXCEEDED'，"LBRG-503 PROVIDER_DOWN')。

多重性：快速刷桌而不會打斷會話（reuse 'sessionId'）。

反模式

將長壽令牌存儲在客戶端上。

在「bettingClosed」之後接受賭註，因為經銷商-爭議得到保證。

沒有「idempotencyKey」 →回避時被淘汰。

在「roundId」和報告中混合時間區。

在沒有配置文件和KYC狀態的情況下設置「眼睛」限制。

忽略流的QoS是移動網絡上的高教堂。

逐步實施計劃（支票單）

體系結構和合同

記錄單個事件合同：'bet。place`, `bet.accepted`, `bet.rejected`, `round.settle`, `limits.update`, `session.close`, `provider.error`.
定義idempotency和「roundId」、「betId」、「transactionId」格式。
選擇一個錢包模型（優先無塞姆）。

安全性

mTLS給提供商,HMAC簽名網絡手冊,TTL令牌≤ 10分鐘。
RG/AML/KYT的利率準入政策，審核日誌。

目錄和限制

限額表和配置文件的導入,按國家/貨幣/CUS排列。
桌子極限和狀態的熱更新。

弗龍滕德

WebRTC播放器帶有LL-HLS後衛，定時時鐘，穩定投註計時器。
錯誤代碼和人文信息。

測試計劃

High-latency/packet-loss腳本,reconnection,不損失賭註。
雙重投註點擊→一次借記（平均水平）。
VOID/REFUND,有爭議的回合,報告差異。

可觀察性

[] Дашборд QoS: RTT, dropped frames, aborted rounds, time-to-settle.

Alerta通過提供商的SLA，reconcile報告。

Bridge將實時集成的「動物園」轉換為托管系統：單一投註，單一計算，可預測的UX和透明的流質量控制。通過正確設計的橋梁，運營商可以更快地連接新的實時提供商，降低技術風險，並通過等效性，嚴格的限制和可觀察性來保護P＆L。