List Timed-out Bets

⏱️ Description

Command 27 – List of Timed-Out Bets (Seamless Wallet Only)

This command returns a JSON list of transactions representing bets that timed out when sent to the Seamless Wallet URL. These bets were considered failed by the RGS-CWS system but may have been processed after timeout by your system.

You can use this list to reconcile any unintentional balance deductions and refund the players accordingly, based on uniqid.

NOTE: Transactions where your response was not valid (did not contain {"status":"1"} or {"status":"-1"} will be considered same as timed out transactions (failed to be processed) and will be returned as results for this command.

🧠 Use Case Example:

RGS-CWS sends a bet request at 15:33:22. The operator doesn’t respond within 30 seconds. RGS-CWS marks it as failed.
But your System processes it at 15:33:55, leading to a balance deduction.
The operator must refund this manually using the data returned by Command 27.

📜 Sample JSON Request (from your server to the RGS-CWS server)

{ "command": "27", "apiusername": "your_api_username", "apipass": "your_api_password", "sdate": "2020-01-01 00:00:00", "fdate": "2025-01-01 00:00:00", "complete": "0" }

📥 Input Parameters (from your server to the RGS-CWS server)

Parameter	Mandatory	Description	Type
`*command`	✅	Must be `"27"`	string
`*apiusername`	✅	API username	string
`*apipass`	✅	API password	string
`*sdate`	✅	Start date for filtering bets. Use `0` to include everything. Format: `Y-m-d H:i:s`	string
`*fdate`	✅	End date for filtering bets. Use `0` to include everything. Format: `Y-m-d H:i:s`	string
`complete`	❌	If `1`, all returned incomplete transactions will be marked as completed. Default: `0` (recommended first)	string

⚠️ Important: It is highly recommended to first run the request with complete=0 and process all returned results. Once fully synchronized, you may run it again with complete=1—but only if you're using a datetime filter for both start and finish date.
⚠️ Warning: Do not use complete=1 without a datetime filter. Doing so may mark newer/older transactions as completed, including those that were not part of your most recent sync. This can result in missed or unprocessed transactions.
✅The safer alternative to sending complete=1 is to mark each transaction as resolved by following the instructions indicated in the Resolve Timed-Out TX advanced endpoint.

📃 Sample JSON Response (returned by RGS-CWS)

[ { "uniqid": "TX0012345", "username": "u241_demo123", "date": "2025-07-04 15:33:22", "type": "bet", "amount": "-50.00", "gpid": "8473", "gameid": "5203", "response_status": "timeout" }, ... ]

📤 Output Parameters (returned by RGS-CWS)

Parameter	Required	Description	Type
`uniqid`	✅	Unique transaction ID. Use this to ensure no double refunds.	string
`username`	✅	Player's username	string
`date`	✅	Date/time when the transaction was initiated	string
`type`	✅	Transaction type (`bet`)	string
`amount`	✅	Transaction amount	string
`gpid`	✅	Game round ID	string
`gameid`	✅	Game ID	string
`response_status`	✅	Usually 0 for this type of events	string

✅ Operator Action Required:

Use this command to retrieve all timeout-flagged transactions.
Cross-reference with your internal logs to confirm whether they were processed.
Refund affected players manually if the transaction was processed after timeout.
Avoid double-refunding by checking uniqid.
Once confirmed, re-run with complete = 1 to mark records as synced. The safer alternative to sending complete=1 is to mark each transaction as resolved by following the instructions indicated in the Resolve Timed-Out TX advanced endpoint.