Can you please consider adding a "time" cost payment structure vs Rake? Timed cash game play is very common in poker, especially the higher end stakes in private brick and mortar rooms, and having a software that supports this would be nice VS having to create timed functionality from the ground up using API functionality.
Thanks!
Feature Request: Add a "time" cost structure vs Rake
-
Kent Briggs
- Site Admin
- Posts: 6046
- Joined: Wed Mar 19, 2008 8:47 pm
Re: Feature Request: Add a "time" cost structure vs Rake
Timed rake is common in brick and mortar setups only because it's easier to implement. There's no reason to do it in online play where it's automated per hand. You would just get people trying to game the system by only playing hands in between the rake times.
Re: Feature Request: Add a "time" cost structure vs Rake
> There's no reason to do it in online play where it's automated per hand.
There are major reasons to do timed play VS rake. For example, rake is illegal in some areas whereas timed play is not. There are also business case scenarios whereas you want to do timed play instead of rake. In short, allowing for timed play is an extremely valuable option to have support for instead of just rake.
> You would just get people trying to game the system by only playing hands in between the rake times.
This is only the case if timed play was limited and incorrectly implemented. Instead, I would suggest allowing the site operator the option of tying timed play to one of these 2 options:
- Timed play table-wide (this means all players play time at the same time on a table-specific timed event (eg, every 30 minutes for the whole table)) or
- Timed play player-specific (players pay time upon posting their first hand at the table and timed event (eg, every 30 minutes for the specific player) happens to each player individually based on their specific time information.
Further, you could add another option of doing timed play agnostic of specific table sitting and whollistic of a particular player's play. For example, if a player sits and plays across 10 tables, on and off, for a total table-sit time of 120 minutes, then you have __ occurances of ___ timed events that remove ___ credits to that player. This makes time for that player tied to the player's sit-time and no tied to a player time. This is likely the best option as it essentially micro-collects player time in a better fashion as it does not tie time play to a single table or to a single full table time session.
Hopefully you can understand this and consider implementing it right away!
There are major reasons to do timed play VS rake. For example, rake is illegal in some areas whereas timed play is not. There are also business case scenarios whereas you want to do timed play instead of rake. In short, allowing for timed play is an extremely valuable option to have support for instead of just rake.
> You would just get people trying to game the system by only playing hands in between the rake times.
This is only the case if timed play was limited and incorrectly implemented. Instead, I would suggest allowing the site operator the option of tying timed play to one of these 2 options:
- Timed play table-wide (this means all players play time at the same time on a table-specific timed event (eg, every 30 minutes for the whole table)) or
- Timed play player-specific (players pay time upon posting their first hand at the table and timed event (eg, every 30 minutes for the specific player) happens to each player individually based on their specific time information.
Further, you could add another option of doing timed play agnostic of specific table sitting and whollistic of a particular player's play. For example, if a player sits and plays across 10 tables, on and off, for a total table-sit time of 120 minutes, then you have __ occurances of ___ timed events that remove ___ credits to that player. This makes time for that player tied to the player's sit-time and no tied to a player time. This is likely the best option as it essentially micro-collects player time in a better fashion as it does not tie time play to a single table or to a single full table time session.
Hopefully you can understand this and consider implementing it right away!
Re: Feature Request: Add a "time" cost structure vs Rake
BUMP!
Is there any update on potentially adding this?
Thanks!
Is there any update on potentially adding this?
Thanks!
-
Kent Briggs
- Site Admin
- Posts: 6046
- Joined: Wed Mar 19, 2008 8:47 pm
Re: Feature Request: Add a "time" cost structure vs Rake
Highly unlikely
-
Kent Briggs
- Site Admin
- Posts: 6046
- Joined: Wed Mar 19, 2008 8:47 pm
Re: Feature Request: Add a "time" cost structure vs Rake
That said, there's nothing stopping you from implementing your own system where you "rake" an account balance by time, which could be login time, or table seated time, or just a flat monthly subscription fee. Use the Callback Event system and API calls to implement whatever you need.
Re: Feature Request: Add a "time" cost structure vs Rake
Hello,Kent Briggs wrote: Fri Apr 10, 2026 3:17 pm That said, there's nothing stopping you from implementing your own system where you "rake" an account balance by time, which could be login time, or table seated time, or just a flat monthly subscription fee. Use the Callback Event system and API calls to implement whatever you need.
Yes, I have built a system which tracks players on tables and can do was you mentioned, however, it would be much smoother if there was something integrated to pull time VS building an external system to do the same, especially considering that this feature alone would likely open up the doors to a more legitimate offering of your software to the masses.
-
Kent Briggs
- Site Admin
- Posts: 6046
- Joined: Wed Mar 19, 2008 8:47 pm
Re: Feature Request: Add a "time" cost structure vs Rake
It would be more complex than it seems because there would be a hundred different ways to do it and would require lots of settings to satisfy everyone (if ever).
Re: Feature Request: Add a "time" cost structure vs Rake
I'm not sure this would be the case. Essentially you'd just need to support the typical timed deduction method that I would say 95% of cash games do in brick-and-mortar locations do. A simple "Enable Timed Deduction" with a few simple options such as the timed deduction amount, the time deduction interval style (on the hour, or every ___ minutes), allowing deduction from table balance and/or primary/secondary balance, etc. That alone would make this very functional.Kent Briggs wrote: Sat Apr 18, 2026 6:55 pm It would be more complex than it seems because there would be a hundred different ways to do it and would require lots of settings to satisfy everyone (if ever).
Right now your API does not allow for deduction from table balance, which is a major issue. If you could update your API to allow for deduction from ring/cash game balance, that would help things out considerably.
Re: Feature Request: Add a "time" cost structure vs Rake
Just to re-iterate the issue, your system does not allow you to rake a table balance, only a non-table balance. This makes your "nothing stopping you" option unable to work. For example, if you have $100 balance, and you sit on a table with $100, your balance is now $0, and the API deduction does not allow for removing from table balance, only non-sit balance, which would be $0.Kent Briggs wrote: Fri Apr 10, 2026 3:17 pm That said, there's nothing stopping you from implementing your own system where you "rake" an account balance by time,
Can you update the API AccountsDecBalance AccountsDecBalance2 to allow 2 new parameters, 1 would be a "DeductFromTable" and another would be the "TableID". This would enable us to use the API to deduct from a specific table balance.
Thanks