技術與整合
RGS 技術與錢包整合
營運商透過 AKI電子的轉帳錢包 API 串接 HTML5 老虎機與 RGS。這裡說明從建立玩家、轉入與啟動遊戲，到轉出、查單及拉取注單的流程，也說明逾時或連線中斷時如何確認交易結果。
整合
整合長什麼樣子
從拿到憑證到玩家回到大廳，中間是四段。
取得憑證
我們發給你一組 API 金鑰與簽章密鑰，以及一個沙盒環境。同一時間可以有多組金鑰同時有效：我方發新的一組，你們切換之後再撤銷舊的，不必停機。
建立玩家、轉入
玩家第一次進遊戲館時呼叫 player/create（已經建過會回 created: false，再叫一次無妨）。開遊戲前，先從玩家的錢包扣錢，再呼叫 transfer/in 把錢轉進遊戲。
開遊戲
你的後端呼叫 launch，帶玩家識別碼、幣別與遊戲代碼，取得遊戲網址與有時效的 session token，把 gameUrl 交給瀏覽器。純 HTML5，不需外掛，桌機與行動裝置共用。要用 iframe 嵌進大廳的話，先把每一層父頁的 Origin 給我方加進遊戲主機的白名單 —— 開通時問得到，沒開通的來源瀏覽器會直接拒絕顯示。
轉出、拉注單
玩家回到大廳時呼叫 transfer/out（不帶金額＝全額），把轉出的金額加回玩家的錢包；每幾分鐘呼叫 bets 拉注單。我方從不呼叫你們，錢什麼時候轉回，由你們的大廳決定。
上新遊戲你那側一行程式碼都不用改 —— launch 時換一個遊戲代碼就好。
轉帳錢包：只有你們呼叫我們
這是市場上最常見的串接方式，娛樂城接老虎機遊戲商幾乎都是這一種。你們不用架設任何讓我方呼叫的端點，也不用開放任何連入的網址或防火牆。
Transfer · API v3
轉帳錢包
玩家的錢由你們轉進遊戲，再由你們轉回。我方從不呼叫你們 —— 下注與派彩都記在我方的遊戲餘額上，錢會一直留在那裡，直到你們呼叫轉出。
- 從玩家的錢包扣錢 → 呼叫
transfer/in - 呼叫
launch開遊戲 —— 下注與派彩都記在遊戲餘額上，不會呼叫你們 - 玩家回到大廳 → 呼叫
transfer/out（不帶金額＝全額） - 把轉出的金額加回玩家的錢包；每幾分鐘呼叫
bets拉注單
- 你們要架的端點
- 沒有 —— 我方從不呼叫你們
- 你們會呼叫
pinggamesplayer/createplayer/balanceplayer/logoutlaunchtransfer/intransfer/outtransfer/querybets- 玩家餘額在哪
- 轉入之後在我方的遊戲餘額，直到你們轉出
- 錢什麼時候轉回
- 你們呼叫 transfer/out 的時候，我方不會自己轉回
每一個請求都帶 X-Api-Key、X-Timestamp（毫秒）、X-Signature-Version: 2 與 X-Signature：用 Secret 對「v2＋換行＋時間戳＋換行＋POST＋換行＋路徑＋換行＋原始本文」算 HMAC-SHA256（未帶 X-Signature-Version 的第 1 版簽章於過渡期仍接受）。開通時登記你們伺服器的出口 IP（可以是網段），登記之後其他來源一律拒絕。金額一律用元、最多兩位小數；時間用 ISO 8601，一定要帶時區。
轉帳：三種結果，不是兩種
整合金流最常被寫錯的地方，是把「不知道」歸進「失敗」。你們呼叫我方的每一筆轉帳，回應只會是下面三種之一。
ok明確成功
HTTP 200 且 status 為 ok。轉入之後錢已經在遊戲餘額裡；轉出之後，把回應裡的 amount 加回玩家的錢包。
rejected明確拒絕
4xx 且帶 error.code，例如遊戲餘額不足、局還沒跑完（免費遊戲或重轉進行中）。這一次請求沒有動錢；若是重送或 transaction_conflict，先查明原交易，不能據此認定先前未成立而退款。新的轉入明確被拒時才退回玩家錢包；轉出遇到局還沒跑完，稍後用同一個編號再送。判斷請看 code，不要看 message。
unknown結果未知
逾時、連線中斷、5xx。錢可能已經轉了，也可能沒有。用同一個交易編號重送，或呼叫 transfer/query，先核對原交易的玩家、方向、幣別與金額，再檢查 found 與交易 status：success 已成立、failed 未成立、processing 尚待確認、reversed 已沖銷須核帳。在編號保存期內，found: false 才表示未成立且編號已作廢；查單 5xx 或明細已歸檔時不能直接退款。
千萬不要換一個新的交易編號重送 —— 那是唯一一種會讓同一筆錢轉兩次的做法。在交易編號保存期內，transfer/query 回 found: false 會把編號標記作廢；原請求晚到也會被拒（409 transaction_voided）。查單回 5xx（包含明細已歸檔）仍須查明，不能直接退款。
一局的生命週期
「結算中」與「進行中」分開處理：進行中的局可接續剩下的特色轉數（免費遊戲、重轉等）；結算中的局只確認或補送派彩，依重試規則處理，不再發牌。
冪等與重試
- 遊戲端以同一個回合識別碼重送時，回放原本的結果，不會重複扣款（這一段由我方的遊戲前端處理，你們不必送回合識別碼）。
- 一局裡的每一轉（免費遊戲、重轉等）依轉數序號推進：重送已經產生的那一轉會回放原結果，跳號的請求會被拒 —— 斷線續玩不會跳轉也不會重複。
- 每一筆轉帳用一個新的交易編號（transactionId），而且永遠不重複 —— 用你們自己的轉帳單號最好。
- 同一筆錢重送時用同一個編號：已經成立的編號會回放原本的結果（duplicate: true），錢不會再動一次。同一個編號換了玩家、方向或金額，回 409 transaction_conflict，這一次不會執行。
錢在遊戲裡的那段時間
玩家轉進來、還沒轉出去的錢，記在我方帳上的遊戲餘額裡 —— 那是我方對你們的一筆負債。它會一直留在那裡，直到你們呼叫 transfer/out：我方不會在開遊戲時自動轉入，也不會自己把錢轉回去。
什麼時候轉回，你們說了算
常見做法是玩家回到大廳、切換遊戲館或登出時全額轉出 —— transfer/out 不帶金額就是全額。玩家可以同時開好幾款遊戲，共用同一個遊戲餘額。
局還開著的時候不准轉出
特色（免費遊戲、重轉、BONUS）跑到一半把錢抽走，剩下的轉數就派不出彩。這時我方回 409 round_in_progress —— 那不是錯誤，是「現在還不能轉」，稍後用同一個交易編號再送就好。玩家直接關掉遊戲的話，我方會在背景把那一局跑完，派彩記進遊戲餘額。
同一位玩家的轉帳會排隊
每一筆轉帳在我方的一個資料庫交易裡完成，中間沒有任何網路呼叫 —— 資金變動完整提交或不入帳。失敗交易仍可能保留查單紀錄，須看 status。同一位玩家同時送來的轉入、轉出與下注會一筆一筆處理，餘額不會被扣成負的；不同玩家可並行處理；相同交易編號仍須依序核對。
看得見那筆錢
player/balance 隨時查得到玩家留在遊戲裡的錢，也就是全額轉出會轉出的金額。要確保玩家轉出之前不會再下注（例如凍結帳號），先呼叫 player/logout 關掉他還開著的遊戲。
帳務上只有一條等式：玩家沒有打到一半的局時，遊戲餘額 ＝ 轉入 − 轉出 ＋ 注單輸贏（winLoss）的加總。上線前的測試清單就有這一項；日結以台北時間切日，兩邊的日報表對得起來。
營運商拿得到什麼
營運後台
注單查詢、玩家報表、單局回放、每日對帳報表。營運商帳號只看得到自己那一家 —— 租戶隔離在資料庫層強制，不是靠查詢語句自律。
每日對帳
我方每天自動跑日結，並先檢查帳務的前提：未定案的交易與不平衡的分錄都必須是 0 —— 任何一項不是 0，那一天的數字就先不拿去對帳。日結以台北時間切日，報表頁可以下載每日對帳檔；你們也可以用 bets 依結算時間拉注單，自己對一次。
單局回放
客服收到玩家申訴時，用注單編號就能把那一局重算一遍，看到每一轉的盤面。
沙盒環境
我方開一個沙盒商戶給你們（測試用的商戶代碼與金鑰），跟正式帳完全分開。上線前的測試清單逐項跑過 —— 重送同一個編號、模擬逾時後查單、特色進行中轉出 —— 全部通過再申請正式商戶。
資料與保存
5 年保存
注單與分錄保存 5 年，線上熱資料窗 1 個月（任何時候都查得到至少最近 1 個月）。超過熱資料窗且符合歸檔條件的資料，通過完整性檢查後歸檔為壓縮檔；歸檔後的逐筆明細須另行調閱，歷史彙總報表與彙總對帳檔仍可在後台查詢。試玩與轉帳錢包的資料亦可依條件歸檔；須先確認結算、日彙總及餘額結轉完整，維持玩家餘額與報表可核對。未定案或檢查未通過的資料保留在線上。
歸檔會驗
分離分區後匯出壓縮檔，再讀回核對列數與雜湊，驗證通過才刪除原分區。匯出或驗證失敗時會嘗試接回分區；若程序中斷，後續歸檔流程會處理未完成狀態。
備份會還原
備份每週真的還原到一個專用的驗證資料庫，檢查帳務不變式。沒還原過的備份等於沒有備份。
租戶隔離
資料列層級安全性（RLS）在資料庫層強制，應用程式的資料庫角色沒有繞過權限。
部署
機房
目前部署於東京。實際延遲依玩家與營運商伺服器的所在地及網路路由而異。
遊戲前端
純 HTML5，無外掛，桌機與行動裝置同一份，玩家端走 CDN。
營運商 API
獨立網域，不經過 CDN，只做 server-to-server。
營運後台
獨立網域，與遊戲不同源，後台寫入操作另外驗證請求來源。
完整文件
已開通商戶可在營運後台閱讀完整的串接文件，並下載 Markdown 原檔。尚未開通者可聯絡我們索取文件與沙盒憑證。所有 API 都是 POST、本文是 JSON，網址開頭是 /operator/v3/；金額一律用元，最多兩位小數。