checkout.succeeded
- a payment was successfulcheckout.failed
- a payment failedcheckout.hold
- during withdrawal, we ask you to place a hold on the available balance to prevent double spending and verify balance is sufficient.checkout.release_hold
- a withdrawal failed after you placed a hold.checkout.returned
- a payment was returnedcheckout.pending
- a checkout session has entered a pending statecheckout.terminally_failed
- a checkout failed due to geo, kyc, or other fraud checks.checkout.expired
- a checkout expired (for security purposes all checkouts expire)
Verifying Webhook Signatures
In order to prevent mailicious actors, we include a signature in the webhook event as a headerSOAP-WEBHOOK-SIGNATURE
. This signature was generated using your webhook signing secret that you can access in your dashboard in the Developers sections.
The SOAP-WEBHOOK-SIGNATURE
header has the following format:
t
is the timestamp when the signature was generated and should be used to prevent replay attacks.
v1
is the signature itself, generated using HMAC-SHA256.
In order to verify the signature, you will use the event payload and recreate the signature using your webhook signing secret, and compare it to the signature you received.
Updating Player’s Balance
It really depends on how you implement your accouting system. In this example we are only using credits and debits and updating the player’s balance accordingly.Other
- We retry webhooks 4 times after the first attempt with the exception of
checkout.hold
. - There is a 10 second timeout.
- Each webhook comes with
event_id
— use this as your idempotency key to not reprocess events.