跳轉到

無縫錢包

允許 Game Provider 與 Licensee 的錢包系統進行整合，使 Game Provider 可以直接向 Licensee 的錢包發送交易請求。

在Seamless Wallet 模式中，玩家的餘額由營運商持有並管理。Game Provider 不儲存或維護玩家餘額。

所有與資金相關的操作（例如下注或派彩）都必須透過Licensee的錢包進行處理。

實作對象

在無縫錢包的模式下，將由 Licensee 提供 Wallet API， Game Provider 根據玩家的遊戲階段發起錢包交易請求。

Licensee 須知

對於所有發送至 Licensee 的請求，Game Provider 都將附加上 API_KEY，API_KEY 是 Licensee 提供給 Game Provider 的存取金鑰。

Game Provider 遵照以下通訊協定與技術規範：

  • 採用 RESTful 協定
  • 預期回應時間低於 300 毫秒
  • 請求與回應使用 JSON 格式：使用 content-type: application/json 標頭
  • 預期持久化連線：Response Header 包含 connection: keep-alive
  • 僅支援 HTTPS 站點
  • 身份驗證處理
    1. 於 Request Header 添加 authorization: ECDSA-SHA256 <API_KEY> 1
    2. 於 Request Header 添加 authorization: HMAC-SHA256 <API_KEY> 1
    3. 於 Request Header 添加 authorization: bearer <API_KEY>
    4. 於 Request Header 添加 api-key: <API_KEY> 2
    5. 於 Query String 添加 api_key=<API_KEY> (不建議)
  • API_KEY 規範
    1. 由 Licensee 提供
    2. 建議長度在 8 至 22 個字元
    3. A-Z, a-z, 0-9, ., - 僅由這些字元組成 3
  • API 站點要求
    1. 網域必須擁有 https 證書
    2. 使用固定的 Public IP；或者固定的 DNS 紀錄
    3. 不接受臨時通道服務、短網址

其他實作建議

考慮到 Game Provider 與 Licensee 之間的請求效率，我們強烈建議啟用 connection: keep-alive 來建立 HTTP 長連線。
若 Licensee 支援 HTTP/2 協定，Game Provider 也能夠協助調用 HTTP2 Client 發出請求。

結算類型

區分為逐筆結算模式 (Mixed)與回合結算模式 (Gamewise)

逐筆結算模式 (Mixed)

對應每一個 Debit Request，都會有一個單獨的 Credit Request 或是 Cancel Request。

倘若發出了 3 次 Debit，則 Licensee 理想下會收到 3 次 Credit Request；也可能收到 Cancel Request。

對於 Game Provider，每筆交易存在以下狀態：

  • COMMIT：發出 Debit Request，但是尚未發出 Credit Request 或 Cancel Request
  • COMPLETE：發出 Debit Request，且發出 Credit Request 並收到成功回覆
  • CANCELED：發出 Debit Request，且發出 Cancel Request 並收到成功回覆
  • PENDING：發出 Debit Request，且發出 Cancel 或 Credit ，但是沒有收成功到回覆
    1. 收到失敗、逾期請求都會進入 PENDING 請求
    2. 在這之後，將 Credit 或 Cancel 排入重送佇列

合併提交

在此模式下，依照 Licensee 需求，可以進行合併提交：將 Debit 與 Credit 在一次請求同時送出。
由於此種下注模式多用於 Slot Machine、快速型 RNG 遊戲，當玩家下注的瞬間便能夠知道結算分數，Game Provider 內部會嘗試將兩次請求合併提交。

若您有此需求，請聯繫 Game Provider 協助處理。

回合結算模式 (Gamewise)

在單局遊戲中，允許 Player 發出多個 Debit Request，並在最後發出一個 Credit Request，將該局的總金額轉入 Player 錢包中。

典型的遊戲類型對應多回合結算與撲克類型的遊戲：

  • 百家樂可在閒、莊、和等多個位置同時下多筆籌碼
  • 輪盤可以在不同號碼或區域下注
  • Live 遊戲可以在封盤前連續加注

每一次的 Debit Request，都可以視作等價於「加注」或是「放置籌碼」的遊戲邏輯。

結算階段失敗

考慮 Gamewise 的下注模式或是Mixed拆分兩次請求，若 Game Provider 在下注時 Debit Request 通過，則預設 Credit Request 即使 Licensee 回應失敗，也會回傳給 Player 結果。
對遊戲來說，玩家在遊戲中進行了下注，並且該下注被認為是合法的。對玩家來說就應該取得一筆 Credit。

若 Licensee 有可能發生 Debit 通過但是 Credit 拒絕的情境，應該通知 Game Provider 處理方式

  1. HMAC-SHA256 ↩↩

  2. api-keys ↩

  3. RFC5890 ↩