List Timed-out Wins

⏱️ Description

Command 28 – List of Timed-Out Wins (Seamless Wallet Only)

This function returns a JSON list of transactions representing wins that timed out when sent to the Seamless Wallet URL. These wins 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 win request at 18:33:22. The operator doesn’t respond within 30 seconds. RGS-CWS marks it as failed.
But your System processes it at 18:33:55, leading to a balance increase.
The operator must refund this manually using the data returned by Command 28.

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

{ "command": "28", "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 `"28"`	string
`*apiusername`	✅	API username	string
`*apipass`	✅	API password	string
`*sdate`	✅	Start date for filtering wins. Use `0` to include everything. Format: `Y-m-d H:i:s`	string
`*fdate`	✅	End date for filtering wins. 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": "win", "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 (`win`)	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.