工作室和平臺之間的API集成如何工作

工作室（遊戲提供商）與平臺/聚合器的集成是圍繞會話，錢包，旋轉結果和事件遙測的同步和異步呼叫鏈。下面是一張簡短但實用的地圖，說明了開發人員和合規人員如何無縫地連接所有內容。

---

1）手掌上的建築

演員：

• Studio RGS（遠程遊戲服務器）是遊戲，RNG，獎金，頭獎的邏輯。
• 平臺/聚合器-路由，計費，促銷和合規性。
• 操作員是玩家的錢包，KYC/RG，展示櫃。
• 客戶端-Web/mobile遊戲容器（iframe/webview/native）。

主要輪胎：

• Sync API：會話,錢包,outcome。
• Async/Event Bus：旋轉事件，獎金，頭獎，RG，技術錯誤。
• 元數據/目錄：遊戲，市場構建，RTP配置文件，本地。

---

2）協議和基本解決方案

運輸：HTTPS/JSON（有時用於Event Bus/錢包的 gRPC）。

轉化：'接受：application/vnd。rgs.v1+json'或 '/v1/……'；兼容性降級-僅通過新版本。

標識：「game_id」、「build_hash」、「operator_id」、「session_id」、「round_id」、「spin_id」。

時間：嚴格的UTC，ISO-8601毫秒。

貨幣：ISO-4217+精度（小單位）。FX-操作員/聚合器側。

---

3）認證和授權

Server-to-server: OAuth2 Client Credentials или HMAC-подпись (`X-Signature: HMAC_SHA256(payload, shared_key)`).

玩家會議：短暫的JWT（簽名平臺）c'sub'，'geo'，'rg_flags'，'exp'，'aud=studio'。

訪問列表：用於prod路徑的IP allowlist+mTLS。

---

4）錢包模型： debit/credit vs transfer

A) Debit/Credit (on-the-fly):

1.該平臺調用RGS：「SpinRequest（stake）」→ RGS計算結果→返回「贏」。

2.同時，平臺在運營商中進行「debit（stake）」和「credit（win）」。

優點：簡單的會計。缺點：更多網絡呼叫,強硬的等效性要求。

B) Transfer (session balance):

1.在會話開始時，該平臺在RGS上進行「轉移（amount）」。

2.在RGS旋轉期間，它本身負責會議的平衡。完成時-「transferOut（remaining）」。

優點：錢包聊天較少。缺點：考慮到「RGS一側的錢」，額外的風險和回收。

建議：

• 對於插槽，通常使用具有等效鍵的debit/credit。

---

5）相同性和一致性

每個貨幣步驟都必須具有唯一的「idempotency_key」（例如「round_id」或「spin_id」）。

重復（「HTTP409/425」）返回相同的結果而不是「已執行錯誤」。

Exactly-once很難實現，因此我們建立了at-least-once+等效性。

我們擴展到：「debit」，「credit」，「jackpot_contribution」，「bonus_award」。

---

6）關鍵查詢方案（縮寫）

6.1.會議開始

json
POST /rgs/v1/sessions
{
"session_id": "s-…",  "operator_id": "op-…",  "player_id": "p-…",  "game_id": "g-BookOf…",  "build_hash": "sha256:…",  "jwt": "eyJhbGci…",  "geo": "DE",  "currency": "EUR",  "rg_flags": {"self_excluded": false, "time_limit_min": 60}
}

6.2.旋轉（debit/credit）

json
POST /rgs/v1/spins
{
"spin_id": "spin-…",  "round_id": "rnd-…",  "session_id": "s-…",  "stake": {"amount": 1.00, "currency": "EUR"},  "spin_type": "cash",  "idempotency_key": "spin-…"
}

答案是：

json
{
"spin_id": "spin-…",  "outcome": {
"win": {"amount": 3.40, "currency": "EUR"},   "features": [{"type":"bonus_trigger","name":"FreeSpins","count":10}],   "symbols": "opaque-or-omitted"
},  "rgs_txns": [
{"type":"jackpot_contribution","amount":0.01}
],  "telemetry_ref": "evt-…"
}

6.3.活動日誌（活動巴士，蹦床格式）

json
POST /rgs/v1/events/batch
{
"events":[
{
"type":"spin_finished",    "ts":"2025-10-20T11:22:33.123Z",    "spin_id":"spin-…",    "round_id":"rnd-…",    "stake":1.00,"win":3.40,"currency":"EUR",    "game_id":"g-…","build_hash":"sha256:…",    "player_id":"p-…","operator_id":"op-…",    "spin_type":"cash"
}
]
}

---

7）票據和市場建設

「build_hash」 （SHA-256）是每個事件的必修課。

全球vs市場建設：語言，警告，投註限制，RTP配置文件。

該平臺驗證： 「現在是否正在播放符合給定國家證書的法案。」

矩陣：'game_id × country × rtp_profile × build_hash'。

---

8）RNG，數學和反射

RNG居住在RGS上；商業邏輯不會改變「即時」的機會。

對於forenzika： 「seed/nonce」 to round/旋轉+版本的力學。

Replay：通過「spin_id」/「seed」 RGS復制結果並給出審計跟蹤。

---

9） Responsible Gaming （RG）和Complaence-hooks

時間/限量曲線：Event Bus中的「session_time_ms」，「提醒」，timeouts；「rg_event」。

自我判斷/障礙：在旗幟下-立刻'403 RG_BLOCKED'。

UI不變性：平臺檢查客戶顯示市場構建的警告/年齡標簽。

---

10）錯誤，撤退和SLA

編碼：'400'（驗證），'401/403'（身份驗證/RG），'409'（冪等性沖突），'422'（業務錯誤），'429'（限制率），'5xx'（時間）。

Retrais Policy：指數，在接收器上具有偶數鍵和重復數據消除功能。

SLA： API可用性≥99。9%，「spin」的p95 latency ≤200-300 ms（區域），Event Bus-near-real-time <60 s。

---

11）可觀察性和審計

Logs：帶有「trace_id」語句的未剪切服務器日誌。

度量標準：p95/p99 latency，方法錯誤率，RTP/獎金頻率偏差，「eligible spins」份額。

Alerts：根據SLA,關於數學異常,關於錢包故障的增長。

審計：WORM存儲費率/結果事件；按需出口。

---

12）安全性

mTLS + TLS 1.2+、HSTS、嚴格CORS在客戶機上。

Kay輪換，TTL代幣短，JTI/非測試。

針對客戶的反垃圾箱：asset簽名,完整性檢查,debagger防護。

秘密-僅在秘密管理者中；沒有「遊戲中的鑰匙」。

---

13）測試環境和認證

Sandbox：虛擬錢包，確定性的RNG（固定種子），自動失敗的RG腳本。

Staging：一個沒有真錢的prod-infra副本。

實驗室包：GDD/數學，RNG檔案，log方案，可重復構建和散列。

---

14） API中的促銷和頭獎

Free Spins：包傳輸：「grant_free_spins（計數，bet_size，rtp_profile?）」；事件在RGS中花費和計算。

比賽：「spin_type=tournament」屬性+Event Bus中的單個單元。

頭獎：「jackpot_contribution」和「jackpot_win」作為單獨的交易；通過偶數和「簽名」事件的一致性。

---

15）報告和計費

Блоки выгрузок: `spins_total`, `eligible_spins`, `turnover`, `ggr`, `netwin`, `jackpot_contrib`, `bonus_cost`, `royalty_due`.

Per-spin/turnover-fee：通過「eligible_spins」或「Σ stake × rate」得分。

Rev-share：「瀑布」保留後的「NetWin」；FX/異常的季度真值。

---

16）類型序列（言語圖）

Spin (debit/credit):

• Client → Platform: StartRound → Platform → RGS: Spin → RGS → Platform: Outcome → Platform → Wallet: Debit → Platform → Wallet: Credit → Platform → Client: Result → Platform → EventBus: spin_finished.

Free Spins:

• Platform → RGS: GrantFreeSpins → Client: Start → RGS: Consume/Log each → EventBus: spin_finished (spin_type=free).

---

17）變更管理和互操作性

合同第一（合同第一）：OpenAPI/Protobuf是電路的單一來源。

SemVer：僅添加字段；刪除/更改-在/v2中。

功能標誌：包含選項（Bonus Buy/Ante）-僅通過認證配置文件。

Deprecation： announce → grace period →在非活動區域關閉。

---

18）支票單

工作室→平臺

• OpenAPI/gRPC spacks和近似的pailoads。
• 「spin/debit/credit/jackpot」。
• 「build_hash」和市場建設登記冊。
• RNG反饋和審核日誌。
• RG-hooki和錯誤'403 RG_BLOCKED'。
• 帶有假種子、測試錢包和汽車價格標簽的Sandbox。

平臺→工作室

• 帶有短TTL、allowlist IP、mTLS的JWT簽名。
• 市場建設驗證器和證書。
• Event Bus和dashbords （latency/error/RTP drift）。
• 配額和等級限制，帶有誠實的反饋「429-Retry-After」。
• SLA/事件/通信渠道 24 × 7。

---

19） 30-60-90啟動計劃

0-30天

協調API合同和事件模式,選擇錢包模型.

提高sandbox：固定種子RNG，測試錢包，自動等效性測試。

「build_hash」註冊表和市場構建的主要矩陣。

31-60天

錢包和旋轉集成；啟用Event Bus和dashbords。

負載測試（p95/p99），retrai/等效性，網絡混沌場景。

合規性：RG-hooks，localis，年齡標簽；一個包裹到實驗室。

61-90天

飛行員有1-2名操作員，A/B參加促銷活動（免費旋轉/錦標賽）。

輸入true-up/報告，alerta RTP 漂移/bonus-freq。

準備v2改進：戰鬥事件，gRPC用於錢包，geo-routing。

---

20）簡短的FAQ

RTP/版本在哪裏驗證?在平臺上：「build_hash」 ↔證書↔國家/地區。

RTP可以動態更改嗎?沒有。僅通過預先認證的配置文件,並且僅通過切換市場來構建。

如何解決「雙重辯論」？等效密鑰+交易狀態存儲；重播-返回結果。

需要gRPC嗎?對於高容量的錢包/活體很有用；REST仍用於元數據/管理。

---

穩定集成是合同+相等性+可觀察性。透明的事件方案，法案/市場控制，RG鉤和版本紀律在開始時消除了90％的風險。接下來是促銷和報告自動化，強硬的SLA和精益的API開發而不必進行「中斷」更改。