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.

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 Failure Handling

In certain situations (as described in the errors section above), it is necessary for transactions to be cancelled or put into a Pending state.

NOTE: ThrillPots will only cancel Debit transaction

Debit transactions

In the case of a failed Debit transaction, ThrillPots will send a cancellation request for the Debit transaction using the Debit transaction ID.

Credit transactions

A credit transaction will never be cancelled. If it fails after a certain number of retries, ThrillGate will make the transaction as pending and will continue to retry sending the transaction to the operator's wallet. This will continue for a fairly long period of time (configurable). If the transaction fails after all the configured attempts, it will be marked as Withheld and will require manual reconciliation by the operator via the Backoffice.

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 Failures

Since Transaction Batches are only applicable to Credit transactions, the same retry -> pending failure flow as described above is applied.

There is another limited set of errors that require Transaction Batches to be retried as Pending transactions.

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 marked as pending and continue to be retried in the background.