At Tickera, we always listen to our users. When a feature request keeps popping up, we take notice. One of the most common ones for years was time-based check-in limits – and as of Tickera 3.4.9.9, it’s built right into the core plugin.
On paper it sounds small. In practice it replaces a fair number of clunky workarounds, opens the door to membership-style ticketing, and quietly solves a few common fraud problems. Here’s what it is, what it’s good for, and how to put it to work.
How the feature works
If you’re running Tickera version 3.4.9.9 or newer, you’ll notice a new option when creating or editing a ticket type: Limit check-ins on time basis. When you set it to “Yes,” a new field appears where you can enter how many check-ins are allowed, and choose whether that limit applies per hour, day, week, or month.

That’s the whole interface – simple, but flexible enough to cover a surprising range of scenarios. You can still set a total check-in count alongside the time-based limit, so one ticket can allow, for example, five check-ins total with a cap of one per day. Both limits are enforced automatically at the scanner; nothing for the check-in staff to remember.
Multi-day festivals and conferences
This is the scenario the feature was designed for. Imagine a five-day festival where attendees can buy a two-day pass, a three-day pass, or a full five-day pass. Before, you had two options: create a separate ticket type for every day (and every combination), or set a total check-in count and rely on staff to spot duplicate scans in the same day.
Now the setup is clean. A three-day pass becomes one ticket type with a total of three check-ins and a limit of one per day. The attendee can enter on any three of the five days, but they can’t share the ticket with a friend who scans it later the same afternoon. If someone tries, the second scan is automatically rejected at the door.
Season tickets and recurring events
If your event repeats on a schedule – a sports season, a theatre subscription, a weekly comedy night, a monthly speaker series – you can now sell a proper season pass out of the box.
Set the ticket to allow one check-in per week (or per month, depending on the cadence), combine that with a start and end date for the check-in period, and you have full control over when the pass is valid. Once the last week of the season passes, the ticket automatically becomes inactive. No manual cleanup, no expired tickets sitting in the database with active QR codes.
Gym, yoga, and studio memberships
This is the use case that quietly changes the most for Tickera. In the past, running a gym or yoga studio on Tickera meant pairing it with WooCommerce via Bridge for WooCommerce plus WooCommerce Subscriptions – powerful, but complex, with recurring licensing costs and more moving parts to maintain.
With time-based check-in limits, a lot of membership use cases work natively, without any add-ons. A few examples:
- Unlimited monthly membership: a single ticket type with a validity period of 30 days and no per-day cap (or a very high one). The member checks in as many times as they want during the month.
- Three-visits-per-week membership: a ticket type with a cap of three check-ins per week, valid for a month or a quarter. Popular for yoga studios where “3x per week” is a classic plan.
- Class pack of ten: a total check-in count of ten with a limit of one per day, valid for 90 days. A staple of studio pricing.
- Quarterly or yearly pass: a long validity window, with or without a per-day cap. Pair with the appropriate check-in frequency rule for the type of facility.
Everything still works through Tickera alone. And if you do already run the Bridge + Subscriptions stack, the new check-in limits layer cleanly on top – so existing WooCommerce-based memberships can adopt this too.
Preventing ticket fraud and accidental double scans
There’s a second, quieter benefit. Time-based limits meaningfully reduce two headaches that every event organizer has lived through: counterfeit tickets and accidental double-scans of the same ticket by different staff members.
Even when a ticket legitimately allows multiple entries (for re-entry, for multi-day events, for re-admission after a meal break), setting a short per-day cap means a single ticket can’t be photographed, shared, and reused by a friend later the same evening. The second attempt bounces at the scanner with no human judgement required. For multi-day passes, re-entry tickets, and membership-style setups, this is a security layer that costs nothing to enable and catches an attack class that used to rely entirely on the door staff’s attention.
Combining it with the rest of Tickera
Time-based limits are one more lever, not a replacement for the existing ones. The combinations with other Tickera features are where the setup gets really expressive:
- Combine with ticket validity windows (start and end date) to build season passes that expire on a fixed calendar date.
- Combine with ticket quantity limits to build scarce season passes – “only 100 yearly memberships available.”
- Combine with tiered ticket types to offer a bronze/silver/gold ladder where the difference is frequency of access, not features.
- Combine with custom forms to capture per-check-in information when useful (for example, “which class are you attending today?” – though this is optional; most setups don’t need it).
- Combine with the Check-in apps for offline-tolerant scanning at the door or at the studio entrance; the check-in log and time-based rules sync back to the site as soon as the app goes online.
A few things to test before launch
If you’re rolling this out on a live event or a new membership product, take fifteen minutes to test the edge cases. The feature is robust, but human misconfiguration is always the bigger risk:
- Scan the same ticket twice in a row at the door – verify the second scan is rejected with a clear message for the check-in staff.
- Scan a multi-day ticket on day one, then again on day two – verify the second day scan is accepted.
- Scan a season ticket after the season’s end date – verify it’s rejected as expired.
- Check the attendee list in the Tickera admin and confirm the per-ticket check-in log matches reality.
- If you’re using the Check-in apps, test both online and offline scans to confirm the limits are enforced in both states.
The short version
Time-based check-in limits unlock multi-day festivals, season tickets, gym and studio memberships, and a quiet security upgrade against ticket fraud – all in one setting on the ticket type. Combine it with validity windows and per-ticket quantity caps and you’ve got a native alternative to most of what a subscription or membership plugin would give you, without a second stack of plugins to maintain.
If you’re already using this feature creatively or have an idea for how it could be improved, we’d love to hear from you. Drop us a message through the Tickera contact form and tell us how you’re using time-based check-ins.