What is a timeout?

A timeout occurs when your server fails to respond within the allowed timeframe—5 seconds or when it fails to return a valid response. In such cases, our RGS-CWS server cancels the transaction or repeats it, as it cannot determine whether your system has processed it or not.

To ensure synchronization, the RGS-CWS will:

• Attempt to cancel the bet transaction using type=cancelbet if the original request was a bet.

• Repeat the win transaction using type=win if it was a win.

⚠️NOTE: transactions where your server response does not include {"status":"1"} or {"status":"-1"} will also be marked as timed-out meaning that they need to be reprocessed using the methods described below.
Bets must be cancelled/reversed if you processed them.
Wins must be granted (add the funds to player accounts) if you did not process them

Timed out bets - must reverse

Your system should check periodically for timed out bets and cancel them (reverse amount), if you did process them in the past, by setting up your own cronjob inside your own platform environment and retrieving the data as described at point “List Timed-Out Bets” (from advanced endpoints category) from this documentation.

OPTIONAL ALTERNATIVE: The RGS-CWS manager can set up a cronjob (script that runs every 5 minutes) which will send type=cancelbet to your balance_adj URL, in the same format as any win or bet. Cancelbet will usually be positive value or 0.

Note that instead of "type":"bet", the value will be "type":"cancelbet"

If the transaction was already processed by your system, in the past, then the response must contain status:1 and the balance and the transaction ID from your system. EG: {"status":"1","balance":"5221212.44","txid":"9174g01g123131"}

If the transaction was not processed in the past, but it was processed now, then the response must contain status:1 , the balance and the transaction ID from your system. EG: {"status":"1","balance":"5221212.44","txid":"9174g01g123131"}

Basically the response will be the same no matter if you processed it in the past or not.

IMPORTANT: If you do not return status as 1, the transaction will be retried until you do so, once every 5 minutes.

Timed out wins - must grant

Your system should check periodically for timed out wins and grant them to the players, if you did not process them in the past, by setting up your own cronjob inside your own platform environment and retrieving the data as described at point “List Timed-Out Wins” (from advanced endpoints category) from this documentation.

OPTIONAL ALTERNATIVE: The RGS-CWS manager can set up a cronjob (script that runs every 5 minutes) which will send type=win to your balance_adj URL, in the same format as any win.

If the transaction was already processed by your system, in the past, then the response must contain status:1 , the balance and the transaction ID from your system. EG: {"status":"1","balance":"22221212.44","txid":"9174g01g123131"}

If the transaction was not processed in the past, but it was processed now, then the response must contain status:1 , the balance and the transaction ID from your system. EG: {"status":"1","balance":"22221212.44","txid":"9174g01g123131"}

The response format remains the same whether or not you processed the transaction previously.

If you do not return status as 1, the transaction will be retried until you do so, once every 5 minutes.

In exceptional cases, some wins may need to be cancelled. In this case, our RGS-CWS API will send type=cancelwin to your balance_adj URL, in the same format as any win, but the amount will typically be negative.. NOTE: for every cancelwin, the uniqid parameter will contain this structure “cancel_”+transaction_id_to_cancel . Best practice is to str_replace “cancel_” with “”(nothing) for this event and to retrieve the ID of the transaction that you must cancel, for your internal tracking.

NOTE: for every cancelbet or cancelwin, the uniqid parameter will contain this structure “cancel_”+transaction_id_to_cancel

Best practice is to str_replace “cancel_” with “”(nothing) for this event and to retrieve the ID of the transaction that you must cancel, for your internal tracking.

NOTE: All these transactions will repeat every 5 minutes until they are resolved (you return "status":"1", up to maximum 20 retries. In the future this mechanism might be replaced with an incremental one (the retry interval may become incremental (e.g., after 5 minutes, 10, 20, 40, 80, 160, up to 1000 minutes before stopping).)