Phoenix Games
Guidelines

Testing & Validation

Validate your integration with the self-service tester

Self-Service Integration Tester

Phoenix provides an automated testing service that validates your webhook implementation. It runs 40 tests covering correctness, idempotency, concurrency, and security - the same checks Phoenix uses internally.

Endpoint

https://operators.staging.phoenixbet.io/tester/api/v1/test-run/sync

The tester runs against your staging webhook endpoints only. Make sure your operator's api_url points to your staging environment.

Authentication

Same as all Operator API calls: X-Operator-Id header + X-Signature header. Sign the JSON request body with your private key.

Request

{
  "player_id": "test_player_123",
  "test_amount_cents": 100
}
FieldTypeDescription
player_idstringA test player with sufficient balance (at least 10x the test amount)
test_amount_centsintegerAmount in cents to use for test transactions (default: 1000)
player_id_bstring (optional)Second player for cross-player isolation test

The tester will withdraw and deposit small amounts during testing. All test transactions are cleaned up (rolled back) after the run.

Response

Returns a JSON report with results for each test:

{
  "operator_name": "YourPlatform",
  "total": 40,
  "passed": 38,
  "failed": 2,
  "skipped": 0,
  "results": [
    {
      "id": "C-01",
      "name": "Basic withdraw",
      "passed": true,
      "checks": [...],
      "duration_ms": 245,
      "http_calls": 4
    }
  ]
}

Streaming Results

For real-time results as each test completes, use the SSE endpoint instead:

POST .../tester/api/v1/test-run

This returns a Server-Sent Events stream with each test result as it finishes.

What the Tester Checks

Correctness (C-01 to C-31)

  • Basic withdraw/deposit/rollback with balance verification
  • Insufficient balance handling
  • Zero amount rejection
  • Non-existent player handling
  • Idempotency (sequential and concurrent duplicate tx_id)
  • Full bet lifecycle flows (win, loss, cancel, mixed)
  • Balance precision (cent-level accuracy, no floating-point drift)
  • Concurrent request handling
  • Batch deposit (if enabled)

Security (S-01 to S-07)

  • Requests without signature are rejected
  • Requests with invalid signature are rejected
  • Tampered request body detected and rejected
  • Empty signature rejected
  • Signature from wrong key rejected
  • No internal details leaked in error responses
  • Signature verified against raw body bytes, not re-serialized JSON

Before Running

  1. Create a dedicated test player with at least 10x the test amount in balance
  2. Make sure your staging endpoints are reachable
  3. Verify your webhook endpoints handle the standard request format