ゲーム会社が増えてもパートナー側のコードはそのままです。その約束を守るために GG Labs がどう構成されているか、検証できることだけを書きました。
シームレス方式が前提です。パートナーのプラットフォームは GG Labs 一つだけを相手にし、ゲーム会社ごとの差は中間の層が吸収します。
トランスファー方式ではベット段階のコールバックがありません。ユーザーがゲームに入るときに残高をゲーム会社のウォレットへ移し、出るときに戻します。どちらであっても、パートナーが実装する仕様は GG Labs のもの一つです。
どちらを選ぶかはパートナーのウォレット構成が決めます。運用中に変更してもゲーム会社を繋ぎ直しません。
| Seamless | Transfer | |
|---|---|---|
| ユーザー残高がある場所 | パートナープラットフォームのウォレット。GG Labs は中継のみです。 | プレイ中はゲーム会社のウォレット。入退場時に移動します。 |
| パートナーが実装するもの | 残高照会・減算・加算のコールバック3種 | 入金・出金の API 2種 |
| 残高への反映 | ベットごとにリアルタイム | 移動の時点 |
| 適する場合 | 複数のゲーム会社を同時に運用し、ユーザー残高を一か所で管理したいとき | 既存のウォレット構成を変えにくい、または早く開きたいとき |
| 方式の切替 | 運用中に切替可能です。パートナー側のコールバックを追加・削除するだけで、ゲーム会社の連携はそのままです。 | |
パートナーの開発チームが最初の打ち合わせ前に知りたいことです。
| プロトコル | REST(JSON)によるリクエスト・レスポンス、WebSocket でゲーム・トランザクションのイベントを受信 |
|---|---|
| 認証 | パートナーごとの API キーとリクエスト署名(HMAC)。本番環境では IP 許可リストが必須 |
| 環境 | Sandbox と Production を分離。仕様は同一でキーのみ異なります |
| ドキュメント | OpenAPI 仕様、コールバック例、テストシナリオ。契約前に閲覧可能 |
| イベント | ベット確定、精算、ゲーム状態の変更を Webhook で送信 |
| 通貨 | KRW、USD、JPY、PHP、THB、VND。ゲーム会社の対応範囲により異なります |
| 精算データ | 日次のレポートファイルと API 照会。ゲーム会社ごとのフォーマットを単一スキーマに変換 |
| モニタリング | ゲーム会社ごとの応答時間・エラー率を常時観測。閾値を超えた場合はパートナーへ先んじて通知 |
認証バッジの代わりに、実際に行っていることを書きました。
ゲーム会社ごとの応答時間とエラー率を常時観測します。閾値を超えれば、パートナーが気づく前にお知らせします。
原因、影響範囲、復旧見込み時点を受付と同時に共有し、収束後に報告書を残します。
ベットと精算の単位で監査ログを保管します。紛争が起きれば、パートナーとゲーム会社が同じ記録を見ます。
すべての区間は TLS、保存データは暗号化します。鍵はサービスと分離して管理します。
コンソール・API・運用システムの権限を役割ごとに分離し、すべてのアクセスを記録します。
定期的なバックアップと復旧リハーサルを行います。目標復旧時間は契約書に数字で記載します。