Bet State Machine
All bets in the system are managed through a robust state machine, ensuring that every possible scenario—such as network issues, operator timeouts, or unexpected errors—is handled in a consistent and reliable manner. This state machine tracks each bet from creation through to completion, including successful payouts, refunds, cancellations, and even rollbacks when necessary.
By leveraging this state management approach, the system can automatically retry failed operations, provide clear audit trails, and support both automatic and manual resolution of complex cases. This ensures a seamless experience for both operators and players, even in the face of technical challenges or unforeseen circumstances.
Bet Status Enum
The system uses an enumerated type (BetStatus) to represent the current state of a bet. The possible values are:
| Value | Status | Description |
|---|---|---|
| 0 | UNSPECIFIED | Default/undefined state. |
| 1 | NEW | The bet has just been created and is awaiting processing. |
| 2 | FAILED | The bet failed to process (e.g., due to network or system error). |
| 3 | CANCELLING | The system is attempting to cancel the bet. |
| 4 | CANCELLED | The bet has been cancelled. |
| 5 | PROCESSING | The bet is currently being processed. |
| 6 | REFUNDING | The system is attempting to refund the bet. |
| 7 | PAYING_OUT | The system is attempting to pay out winnings for the bet. |
| 8 | SUCCESSFUL | The bet has been successfully processed and paid out. |
| 9 | ROLLING_BACK | The system is attempting to roll back the bet (undo the transaction). |
| 10 | ROLLED_BACK | The bet has been rolled back (transaction undone). |
Retry Mechanism
- Automatic Retries:
For all critical webhook calls (BETPAYOUTREFUNDCANCELROLLBACK), the system will automatically retry failed or timed-out requests every 10 minutes. - Retry Duration:
Retries continue for up to 2 days. If the operation does not succeed within this window, the bet will require manual intervention. - Manual Retry:
After 2 days, if the bet is still unresolved, a manual retry mechanism is available for administrators or back-office operators to handle the case.
Transaction Storage and Audit
- The system stores and updates the transaction state at every step.
- Additional information such as
tenant_id,tenant_tx_id, and other metadata is stored for auditing and troubleshooting. - This ensures that when a response is received from the operator, the system can accurately match and update the correct transaction.
State Machine Diagram
Below is a visual representation of the bet state machine, showing all possible states and transitions, including retry logic and webhook interactions:
