Technology

RGS technology & wallet integration

Operators integrate Akitsora HTML5 slots through our RGS transfer-wallet API. Follow player creation, transfers, game launch and bet reporting, including how to confirm a transaction after a timeout or interrupted connection.

Integration

What integration looks like

Four steps from credentials to the player's return to your lobby.

Get credentials

We issue an API key, a signing secret and a sandbox. Several keys can be valid at once: we issue a new one, you switch over, then the old one is revoked — no downtime.

Create the player, transfer in

Call player/create the first time a player enters your game hall (it returns created: false if the player already exists, so calling it again is harmless). Before opening a game, debit the player's wallet on your side and call transfer/in to move the money into the game.

Open the game

Your backend calls launch with the player id, currency and game code, receives a game URL and an expiring session token, and hands the gameUrl to the browser. Pure HTML5, no plugins, one build for desktop and mobile. If you embed the game in an iframe, send us the Origin of every parent frame first so we can allow it on the game host — we ask for it during onboarding, and the browser refuses to render an origin that is not on that list.

Transfer out, pull bets

When the player returns to your lobby, call transfer/out (no amount = everything) and credit the amount back to the player's wallet; pull bets with bets every few minutes. We never call you — your lobby decides when the money comes back.

Launching a new title needs no code change on your side — just a different game code at launch.

Transfer wallet: only you call us

This is the most common way casinos integrate game providers — almost every lobby already works this way. You host no endpoint for us to call, and you open no inbound URL or firewall rule.

Transfer · API v3

Transfer wallet

You move the player's money into the game and back out again. We never call you — stakes and wins are booked on the game balance on our side, and the money stays there until you transfer it out.

Debit the player's wallet → call transfer/in
Call launch to open the game — stakes and wins are booked on the game balance, with no calls to you
Player returns to your lobby → call transfer/out (no amount = everything)
Credit the amount back to the player's wallet; pull bets with bets every few minutes

Endpoints you host: none — we never call you
You call: ping games player/create player/balance player/logout launch transfer/in transfer/out transfer/query bets
Balance lives: in the game balance on our side, from transfer in until you transfer out
Money comes back: when you call transfer/out — never automatically

Every request carries X-Api-Key, X-Timestamp (milliseconds), X-Signature-Version: 2 and X-Signature: an HMAC-SHA256 of v2, a newline, the timestamp, a newline, POST, a newline, the request path, a newline and the raw body, keyed with your secret (v1 without X-Signature-Version remains accepted during the transition period). Register your servers' egress IPs (ranges welcome) at onboarding; once registered, any other source is refused. Amounts are in major currency units with up to two decimal places; times are ISO 8601 and must carry a time zone.

Transfers have three outcomes, not two

The most commonly mis-implemented part of any money integration is filing “don't know” under “failed.” Every transfer you send us ends in exactly one of these three.

ok

Confirmed success

HTTP 200 with status: ok. After a transfer in, the money is in the game balance; after a transfer out, credit the amount in the response back to the player's wallet.

rejected

Confirmed rejection

A 4xx with an error.code — insufficient game balance, or a round still running (free spins or respins), for example. This attempt moved no money. For a retry or transaction_conflict, check the original transaction before refunding; rejection does not prove an earlier transfer failed. Refund a new transfer in only when its rejection is confirmed; if a transfer out hit an unfinished round, send the same ID again later. Branch on code, never on message.

unknown

Outcome unknown

Timeouts, dropped connections and 5xx responses. The money may or may not have moved. Resend with the same ID or call transfer/query, verify its player, direction, currency and amount, then check found and transaction status: success took effect, failed did not, processing is unresolved, and reversed needs reconciliation. Within the ID retention period, found: false means it did not take effect and the ID is void. Do not refund on a 5xx query response or archived details.

Never resend under a new transaction ID — it is the one way to move the same money twice. Within the ID retention period, found: false from transfer/query marks the ID void; a late original request is rejected (409 transaction_voided). A 5xx query response, including archived details, still needs investigation before any refund.

The life of a round

Open and settling are handled separately. Open rounds can continue their remaining feature spins (free spins, respins and the like). Settling rounds only reconcile or retry the payout under the retry rules; no further symbols are dealt.

pendingCreated, not yet opened. Nothing is dealt in this state; if processing is interrupted, we check the debit and then either void the round or open it.

openDebit confirmed, round in progress — including unfinished free spins, respins and other features.

settlingPlay is over, the payout is not yet confirmed.

settledPayout confirmed, ledger balanced.

voidedThe wager is confirmed not effective; the round is voided and its record retained.

Idempotency and retries

When the game client re-sends the same round id, the original result is replayed and nothing is debited twice (our game client handles this — you never send a round id).
Every spin within a round (free spins, respins and the like) advances by spin index: re-sending a spin that already exists replays it, and a request that jumps ahead is refused — so a reconnect never skips or repeats a spin.
Every transfer gets a new transaction ID (transactionId) that is never reused — your own transfer reference is ideal.
Resend the same money with the same ID: an ID that already took effect replays its original result (duplicate: true), and the money does not move again. Reusing an ID for a different player, direction or amount returns 409 transaction_conflict, and nothing is executed.

While the money sits in the game

Money a player has transferred in and not yet transferred out sits in their game balance on our books — a liability we owe you. It stays there until you call transfer/out: we never transfer in automatically at launch, and we never send money back on our own.

You decide when money comes back

The usual pattern is a full transfer out whenever the player returns to the lobby, switches game hall or logs out — call transfer/out without an amount to move everything. A player can have several games open at once; they share one game balance.

No transfer out while a round is open

Pulling the money out mid-feature (free spins, respins, a bonus) would leave the remaining spins with nothing to pay. We answer 409 round_in_progress — that is not an error, it means "not right now". Send it again shortly with the same transaction ID. If the player simply closes the game, we finish the round in the background and pay the win into the game balance.

Transfers for one player queue up

Every transfer completes inside a single database transaction on our side, with no network call in the middle — the money movement commits in full or is not posted. A failed transaction may still have a queryable record; check its status. Transfers in, transfers out and stakes arriving at the same time for the same player are processed one at a time, so the balance never goes negative. Different players may be processed concurrently; matching transaction IDs are still checked in order.

You can see the money

player/balance returns what the player currently holds in the game — exactly what a full transfer out would move. To make sure a player cannot stake again before you transfer out (when freezing an account, for example), call player/logout first to close their open games.

The books come down to one equation: when a player has no unfinished round, their game balance equals transfers in, minus transfers out, plus the sum of winLoss on their bets. It is on the pre-launch test checklist, and daily figures on both sides are cut on Taipei time (UTC+8), so the daily reports line up.

What operators get

Back office

Round search, player reports, single-round replay, daily reconciliation reports. An operator account sees only its own data — tenant isolation is enforced at the database layer, not by careful queries.

Daily reconciliation

We run the daily close automatically and check its preconditions first: pending transactions and unbalanced entries must both be zero — if either is not, that day's figures are held back from reconciliation. Days are cut on Taipei time (UTC+8), the Reports page provides daily reconciliation exports, and you can pull bets by settlement time to reconcile on your side.

Round replay

Given a round id, support can recompute the round and see the board for every spin.

Sandbox

We open a sandbox merchant for you (a test merchant code and keys), kept completely separate from production. Work through the pre-launch checklist — resending the same ID, querying after a simulated timeout, transferring out during a feature — and apply for a production merchant once everything passes.

Data & retention

5-year retention

Rounds and ledger entries are kept for 5 years, and the online hot window is 1 month (at least the most recent month is always online). Eligible older data is archived to compressed files after integrity checks pass. Archived transaction details require retrieval, while historical summary reports and summary reconciliation exports remain available in the back office. Demo and transfer-wallet data can also be archived when eligible. Settlement, daily summaries and balance carry-forward must be complete so balances and reports remain reconcilable. Unresolved records and data that fails those checks remain online.

Archives are verified

After detaching a partition, we export a compressed file and read it back to verify row count and hash before dropping the original partition. Export or verification failures trigger a reattachment attempt; interrupted operations are handled by a subsequent archive run.

Backups are restored

Backups are restored every week to a dedicated verification database and checked against the accounting invariants. An untested backup is not a backup.

Tenant isolation

Row-level security is enforced by the database; the application's database role has no bypass privilege.

Deployment

Region

Currently deployed in Tokyo. Actual latency depends on where players and operator servers are located, and on network routing.

Game client

Pure HTML5, no plugins, one build for desktop and mobile. Player traffic served through a CDN.

Operator API

Its own domain, no CDN in front, server-to-server only.

Back office

Its own domain, separate from the game. Back-office write operations also validate the request origin.

Full documentation

Onboarded merchants can read the full integration document in the back office and download it as Markdown. Contact us for documentation and sandbox credentials if you are not yet onboarded. Every API is a POST with a JSON body under /operator/v3/, and amounts are in major currency units with up to two decimal places.

Request integration docs