Standard Wallet API: Transactions

Transactions

Once the player token has been authenticated, the ThrillPots system can start making transaction calls through ThrillGate.

In standard operation, the first transaction call will be a Debit transaction request to fetch funds from a player's wallet for the Jackpot Contribution bet. This call is also intended to open the game round for the jackpot contribution.

If successful, ThrillPots will process the jackpot contribution and determine if a win occurred.

The next transaction call that will be made will be a Credit transaction request. This call is intended to pay any winnings to the player account and to close the game round that was opened with the Debit transaction.

Transaction Errors

If an error occurs while executing transactions with the operator wallet, ThrillGate and ThrillPots cooperate to ensure that the transaction error is handled correctly.

When an error occurs, ThrillGate will attempt to retry the transaction request a set number of times. If all retries fail, the error will be sent to ThrillPots for further handling.

If there are certain wallet errors that you do not wish ThrillGate to perform its retry logic, you can configure that as part of the wallet configuration in ThrillGate.

Please see the ThrillGate section on Configuring Wallet Error Behaviour for more information on how to configure ThrillGate's wallet error handling.

Once an error has been sent back to ThrillPots, ThrillPots will decide whether a transaction needs to be cancelled or not. Transaction cancellation is discussed next.

#@ Transaction Cancellation

In certain situations (as described in the errors section above), it is necessary for transactions to be cancelled. In general, ThrillPots handles transaction cancellation logic as follows:

If the Debit transaction failed

ThrillPots will send a cancellation request for the Debit transaction using the Debit transaction ID.

If the Credit transaction failed

ThrillPots will first send a cancellation request for the Credit transaction and then a separate cancellation request for the Debit transaction. Both requests will be sent with the respective transaction IDs.

Transaction Batches (Credit only)

ThrillPots uses Transaction Batch requests to communicate payouts to multiple players.

These types of payouts are only relevant to jackpots that are either:

• Multi-player payouts (community payouts)
• Raffle jackpot payouts

In both situations, since multiple players are considered winners from a single jackpot win, ThrillPots needs a way to credit wins to multiple players. Since these players are not guaranteed to be online at the time of the win, ThrillPots will not have access to any session token information for all the winners.

Transaction Batches are used in these special situations to communicate a set of credit operations that need to be applied to multiple players accounts.

Although unlikely, it is possible that not all the specified player accounts will be able to be credited with the winnings. Such a situation may arise if, for example, the player account has been banned/blocked or is self-excluded at the time of the jackpot win.

In these cases, the operator wallet is expected to flag the player account as an exception and continue to pay the remaining players in the transaction batch.

It is not considered an error if a player account in a transaction batch cannot be paid. The operator wallet should simply indicate this exception in the response and attempt to pay all other players.

Transaction Batch Cancellation

We have discussed what Transaction Batch exceptions are and how they are handled.

There is another limited set of errors that require Transaction Batches to be cancelled.

These errors are typically (but not limited to) errors such as network errors and timeouts. When an error occurs that leads ThrillGate to not be sure whether the operator's wallet has handled the transaction batch request, the request will first be retried, but after failing a specific number of times, the transaction batch will be cancelled.

Each transaction batch request has a unique identifier, and this identifier will be sent as part of the transaction batch cancellation request.