Debit & Credit Users
Last updated
Last updated
To receive messages on when to deduct and credit user balances based on the outcomes of matches, you should implement the following endpoints.
Method: POST /thndr/pay
Description: When you receive this post request from us:
Deduct the bet amount from the user's balance.
Associate the depositId
with the amount
in your database to allow for potential refunds.
Use depositId
as the idempotency key to ensure the same payment is not processed twice.
Body:
Note: You must pass "isClientSafe": true
in the response for it to be passed to the client.
Example 4XX response:
Method: POST /thndr/results
Description: Upon receiving this POST request from us, take the appropriate action based on the match outcome:
WIN or DRAW: Credit the user's balance by amount
.
LOSE: No action required.
REFUND: Retrieve the amount
from your database and refund the user.
NOTE: Use depositId
as the idempotency key to ensure the same result is not processed twice.
Body (WIN or DRAW):
Body (LOSE):
Body (REFUND):
To ensure the integrity and authenticity of API requests, our system signs each request payload using an HMAC (Hash-based Message Authentication Code) with the SHA-256 algorithm. Integrators must verify the signature to authenticate requests and prevent tampering.
To verify the request's authenticity, the integrator should:
Recompute the signature using the shared secret and the received payload.
Compare the computed signature with the x-server-authorization
header value.
Reject the request if the signatures do not match.
The SERVER_SECRET
is a pre-shared secret key known only to THNDR server and the integrator.
If you need to notify your client about any payment errors, such as "Insufficient Balance", you can return errors in the response with a status code 4XX. These errors will be sent to the client sdk via the callback for your front end to handle.