Payment API & Webhooks for iGaming Platforms | Documented: The Endpoints, Events, and Signatures Your Engineering Team Will Build Against

A payment API and webhook surface for iGaming platforms is the most honest piece of documentation any payment vendor produces. Marketing pages can be polished; an API reference cannot hide. Either the endpoints make sense as a coherent resource model, the webhook payloads commit to stable shapes, the error responses look designed rather than improvised, and the documentation answers the questions engineers actually ask — or they don't. This page is a working tour of all four for the iGaming context.

Hand any working backend engineer the documentation of three payment platforms and they can tell you within twenty minutes which one is a serious product. Not from the marketing. From the shape of the API itself. The rest of this article is what that engineer would see when they open our docs.

The REST Resource Model

The API exposes a small, opinionated set of resources rather than a sprawling RPC surface. Every interaction maps to one of: a deposit, a withdrawal, a refund, an order, or a player. Endpoints follow conventional REST verbs, and the resource model is consistent enough that an engineer who learns one resource can predict the shape of the others.

Initiating a Deposit — Request and Response

The actual shape of a deposit request and response. The contract is deliberately small; the rail-specific routing and risk decisions are made server-side, not pushed onto the integrator.

{
  "amount": 1500,
  "currency": "INR",
  "player_id": "p_4827",
  "method": "upi",
  "reference": "player-deposit-1747553421",
  "metadata": {
    "vertical": "casino",
    "session_id": "sess_8cd2..."
  }
}

{
  "id": "d_9q3kp2",
  "status": "awaiting_method",
  "amount": 1500,
  "currency": "INR",
  "player_id": "p_4827",
  "method": "upi",
  "redirect_url": "https://pay.your-brand.com/d/9q3kp2",
  "deep_link": "upi://pay?pa=your-brand@...",
  "created_at": "2026-05-18T11:42:18Z",
  "expires_at": "2026-05-18T11:52:18Z"
}

Authentication and Webhook Signatures

Every request is authenticated with a per-tenant API key. Every webhook delivered to your platform carries a signature your platform verifies. Neither piece is optional. The flow:

Webhook Event Catalog

Webhook events are versioned, structured, and emit on every meaningful state transition. Your integration subscribes once; we deliver durably (retry on failure with exponential backoff, then queue for manual replay through the admin). The full event surface:

Idempotency — How Duplicate Submission Is Defeated

The single most important quality of a payment API is that an integrator can retry a network failure without accidentally creating a second deposit. Every state-changing endpoint accepts an idempotency key; identical requests with the same key produce identical results without re-running the side effects.

Structured Error Responses

Errors are not free-form strings; they're a stable JSON shape with an HTTP status, a machine-readable code, a human-readable message, and a documentation link. Every error code is referenced in this article and in our docs so a competent integrator can build error handling without guessing.

{
  "error": {
    "code": "player_limit_exceeded",
    "message": "Deposit exceeds the player's daily limit.",
    "http_status": 422,
    "docs_url": "https://docs.example/errors/player_limit_exceeded",
    "request_id": "req_8cd2..."
  }
}

The Error Code Table

Deposit State Machine — API View

The same state machine described on the player cashier side is exposed through the API. Every state is a string value on deposit.status; every transition emits a webhook; the audit trail records who or what triggered each move.

Sandbox & Production Environments

Every tenant gets a sandbox with full feature parity — same endpoints, same webhook signatures, same error codes. Sandbox transactions use simulated rails so your integration can be tested end-to-end before a single real player exists.

Versioning Policy

Where the API Sits in the Larger Picture

This API is the integration surface for the same managed gateway whose player cashier UI and merchant admin and order management back-end are described elsewhere on this site. The three surfaces are deliberate counterparts: the cashier is what the player sees, the admin is what the operations team uses, and this API is what your engineering team builds against. Same data model, same audit trail, three audiences. An integrator can ship against the API while operations works in the admin and players use the cashier — all reading the same source of truth.

Everything Else, Compressed

Integration-Specific Questions Engineers Actually Ask

The Next Step

A working payment API and webhook surface for iGaming platforms is, in the end, the most honest disclosure a vendor makes. Marketing copy describes intent; the API describes capability. The endpoints, event names, signature scheme, error model, and idempotency mechanism described on this page are the actual contract your engineering team will integrate against — there is no separate, prettier version that lives behind the sales process.

Tell us what your existing platform looks like, which API conventions your team already uses, and what your integration timeline looks like. We will walk through the spec against your specific stack — and your engineering team will form their own opinion of the API on its own merits, not from a marketing demo.