Skip to content
Last updated

Webhooks

Webhooks deliver real-time transaction status changes to your server. They are the single source of truth for final transaction outcomes — never rely on redirects or client-side events.

⚠️ Warning: Credit or debit a player balance only after a webhook (or the GET transaction endpoint) confirms the final status. Browser redirects and SDK events can be lost or spoofed.

Configure webhooks

  1. Log in to the OMNO Dashboard.
  2. Navigate to Developers → Webhooks.
  3. Click Create Webhook.
  4. Fill in the required fields:
    • Name — internal identifier.
    • Webhook URL — the endpoint that receives events.
  5. Select Hook Type: Transaction.
  6. Select which transaction events to receive.
  7. Choose an authorization method (optional).
  8. Click Create.

You can monitor delivery under Developers → Webhooks: full request payloads, your server's responses, and the delivery status of each attempt.

Which events trigger a webhook

You subscribe to the transaction events relevant to your integration, such as creation, processing updates, successful completion, failure/timeout, and refund updates. Each selected event fires a webhook when the transaction reaches that state.

[TBD: exact list of status changes that trigger a webhook]

Payload

OMNO sends an HTTP POST with a JSON body describing the transaction.

[TBD: PayIn webhook payload structure and example]

[TBD: Payout webhook payload structure and example]

[TBD: signature verification method]

Retry policy

If delivery fails, OMNO retries the request up to 10 times.

[TBD: retry interval / backoff schedule]

[TBD: what response counts as successful delivery — e.g. any 2xx]

[TBD: delivery timeout]

[TBD: behavior after the 10th failed retry]

Handling requirements

  • Respond quickly — do heavy processing asynchronously.
  • Process idempotently — the same transaction can arrive more than once.
  • Handle out-of-order statuses — never downgrade a final status (for example, do not overwrite SUCCESS with an earlier PENDING).
  • On any doubt, call the GET transaction endpoint to fetch the authoritative status.

Test transactions

Transactions processed by a fake PSP are identified by the fake PSP ID (merchantPspId / processorPspId on the transaction). See Testing in Production.

⚠️ Warning: Never credit or debit real player balances for transactions processed by a fake PSP.