Skip to main content

Webhook Simulator

This simulator is the QA for your webhook integration. It tests the webhook receiver endpoints you built — deposits and withdrawals — against every scenario we require, building valid notifications, signing them exactly the way we do, and delivering them to your endpoint.

When every scenario passes, your integration is ready — there is no separate manual QA on our side. Run all four scenarios, confirm the ALL PASSED state, export the run as evidence, and send it to us as your sign-off before you launch the system.

How it works​

  • Your operator username (the API shared secret we deliver via OTP) signs the request locally in your browser using the Web Crypto API. It is never sent to our servers and never stored.
  • The signature is computed over the exact bytes we send — SHA256(operator_username + raw_body + operator_username), hex-encoded — and sent as Authorization: Bearer <signature>. See Signature for the formula and validation code.
  • The signed request is relayed by a small server-side proxy so it reaches your endpoint under real server-to-server conditions (no browser CORS). The proxy forwards the body verbatim and never logs it or the signature.
Runs on the deployed site

The relay is a serverless function, so the simulator works on the deployed docs site — not under a local npm start. Point it at an endpoint you can reach over https (the proxy rejects non-https and private/internal hosts).

What gets sent​

You provide the endpoint URLs, your point_of_sale.id, your operator username, and an optional amount. Everything else is generated fresh on each fire — a random player username (a 10-digit number), a unique transaction_number, the matching description, created_at, and currency_code — so each run looks like a real, distinct notification. amount is always sent as a JSON number (e.g. 100), never a quoted or 2-decimal string.

The scenarios​

  1. Happy path — a valid, correctly-signed notification. Your endpoint should accept it and return 201 Created.
  2. Tampered signature — a valid body with a corrupted signature. Your endpoint must reject it with a non-201 (401 / 403) and not process it.
  3. Invalid payload — the same request is sent repeatedly, each time omitting exactly one field, always with a valid signature (so this isolates content validation from signature validation). Each should return 400. Results are shown as a per-field table.
  4. Duplicate event — the same transaction_number is delivered twice. The first delivery should return 201 Created and the second must return 409 Conflict, proving your idempotency is keyed on transaction_number (see Idempotency). This scenario passes only when the duplicate returns 409.

What each scenario checks​

Every scenario validates the response body, not only the HTTP status. For a scenario to pass, the response must meet the full contract: the body must be valid JSON, status must be "success" (happy path) or "error" (the rejections), transaction_number must follow the echo rule (the value we sent, or null where you couldn't read it), and error responses must carry a non-empty message. A 201 with an empty or garbage body is a fail — so ALL PASSED means your endpoint meets the whole contract, not just the status codes.

Your operator username is used only here in your browser to sign the request; it is never sent to our servers and never stored.
Happy pathValid signature → expect 201.
Tampered signatureValid body, corrupted signature → expect 401 / 403.
Invalid payloadOmit one field at a time, valid signature → expect 400 each.
Duplicate eventSame transaction_number twice → expect 201, then 409.

Integration readiness

0/4
Happy pathValid signature → expect 201.Not run
Tampered signatureValid body, corrupted signature → expect 401 / 403.Not run
Invalid payloadOmit one field at a time, valid signature → expect 400 each.Not run
Duplicate eventSame transaction_number twice → expect 201, then 409.Not run
Run all four scenarios and get every check green. That ALL PASSED state is your sign-off — no separate manual QA on our side.
The export never includes your operator username or the request signature.

Inspection

Run a scenario to see the HTTP status, response body, headers and latency here.