Acceptance Testing

Acceptance testing lets you certify your wallet integration on your own, before go-live. It replays the real signed wallet callbacks (/balance, /bet, /win, /rollback) against your staging wallet and returns a pass/fail report — so you can confirm everything works end-to-end without waiting on a coordinated test.

Run it yourself

You drive the run with two calls:

1. POST /acceptance/run — kicks off the suite and returns the full report in the response body when it finishes (a run takes up to ~90s).
2. GET /acceptance/run/{runId} — re-fetches a stored run by its runId (handy to re-read or share a result; you can only fetch your own runs).

POST https://acceptance.stagingmarbles.io/acceptance/run
GET  https://acceptance.stagingmarbles.io/acceptance/run/{runId}

Authentication

Authentication is by source IP — call from one of the IP addresses you whitelisted with us when your integration was set up. There is no token or signature to manage; we resolve which integration you are from the calling IP, so you do not send an integrationId (any integrationId in the body is ignored for operator calls). A request from a non-whitelisted IP is rejected with 401.

Request

Field names are PascalCase under testPlayer (they map directly to the harness' TestPlayer fields):

POST /acceptance/run HTTP/1.1
Host: acceptance.stagingmarbles.io
Content-Type: application/json

{
  "operatorId": "your-operator-id",
  "partnerId": "your-partner-id",
  "testPlayer": {
    "ClientPlayerID": "a funded standing test player",
    "ClientSessionID": "that player's last real session id",
    "Currency": "USD",
    "GameID": "a gameId whitelisted for you (GameAccessRules)"
  }
}

Omit checks to run all applicable checks. To run a subset, add a checks array of check ids (e.g. "checks": ["balance_read"]); ["all"] is the same as omitting it.

Request fields

Where do these values come from?

These are the same identifiers you already send us when you launch a game via POST /game/url — there's nothing new to generate:

• ClientPlayerID — your own unique id for the player. Use a real, funded test player on your staging wallet (the money-moving checks place small real bets, so it needs a balance). Tip: launch a game once as that player and copy the clientPlayerId / clientSessionId from your own /game/url request — those are exactly the values to use.
• ClientSessionID — your session id for that player. Use a recent/live one your wallet recognises (the same value you'd pass in /game/url).
• GameID — any game whitelisted for you (the game_whitelisted check below confirms it is). You can list your games with POST /game/games.
• operatorId / partnerId — the same values you send in every /game/url call.

Try it with curl

Start a run from a whitelisted integration IP:

curl -sS -X POST https://acceptance.stagingmarbles.io/acceptance/run \
  -H "Content-Type: application/json" \
  -d '{
    "operatorId": "your-operator-id",
    "partnerId": "your-partner-id",
    "testPlayer": {
      "ClientPlayerID": "your-funded-test-player",
      "ClientSessionID": "that-players-session-id",
      "Currency": "USD",
      "GameID": "a-whitelisted-game-id"
    }
  }'

The POST returns the full report. To re-fetch it later by its runId:

curl -sS https://acceptance.stagingmarbles.io/acceptance/run/run_327b8db7-0da9-448c-80cb-b78d09a5ce91

The checks

The suite runs in four phases. Phase 1 is reachability/auth, Phase 2 confirms the game is launchable, Phase 3 exercises the full wallet lifecycle, and Phase 4 verifies amount precision. Advisory checks warn rather than fail — a not-met advisory never blocks go-live.

Phase 1 — Reachability & auth (read-only)

Phase 2 — Launch (read-only)

This check needs both operatorId and partnerId; it is skipped if either is missing.

Phase 3 — Wallet lifecycle

Phase 4 — Precision

The report

The POST (and the GET) return the full report — HTTP 200 even when the run failed; the verdict is in the top-level status. Each check carries its own status, a human-readable reason, the same operator-facing description from the table above, and evidence (balances before/after, HTTP status, etc) — so a failed check tells you exactly what to fix.

{
  "runId": "run_327b8db7-0da9-448c-80cb-b78d09a5ce91",
  "integrationId": "your-integration",
  "environment": "staging",
  "status": "passed_with_warnings",
  "checks": [
    {
      "id": "signature_accepted",
      "phase": 1,
      "title": "Our signature is accepted",
      "status": "pass",
      "reason": "correctly-signed /balance accepted",
      "evidence": { "httpStatus": 200 }
    },
    {
      "id": "signature_rejected",
      "phase": 1,
      "title": "A bad signature is rejected",
      "status": "warn",
      "reason": "operator ACCEPTED a request signed with a wrong key (HTTP 200) — it is not verifying signatures"
    },
    {
      "id": "balance_read",
      "phase": 3,
      "title": "Balance reads for the test player",
      "status": "pass",
      "reason": "balance read",
      "evidence": { "balance": 3564378000 }
    },
    {
      "id": "rollback_zero",
      "phase": 3,
      "title": "Rollback nets to zero",
      "status": "pass",
      "reason": "rollback returns to start (catches re-debit operators)",
      "evidence": { "before": 3564378000, "after": 3564378000, "expectedDelta": 0, "actualDelta": 0 }
    }
  ]
}

Run status

Per-check status

Caveats

Error statuses

For the wallet-callback error statuses your endpoint returns (e.g. INSUFFICIENT_BALANCE), see Error Codes.