Time-Limited Passes

An ordinary subscription starts the moment someone pays. A time-limited pass doesn't — it grants access during a window you schedule. Someone can buy your Sunday pass on Wednesday, be admitted Sunday morning, and be removed Sunday night, without you touching anything on the day.

One purchase buys one window. To attend another window, the customer buys another pass — or you bundle a whole slate of windows into a Pass Series and sell it as a season ticket.

When to use one

Passes fit anything sold by the occasion rather than by the month:

• A sports handicapper selling per-slate access — Thursday, Saturday, Sunday, Monday
• A trader running a London-session or market-open room
• An educator selling a seat in a scheduled class or cohort
• An analyst opening a channel on the day a report drops

If your product is an ongoing membership, use an ordinary subscription plan instead. If a buyer should get a whole set of dates from one payment — a season, a course, a cohort — build the pass plans first and then bundle them into a Pass Series.

The three kinds of plan

Every plan starts with one choice, and it is the choice that decides which half of the form you see next.

This page is the middle one. The distinction that matters against the third: a pass plan owns its own dates and generates them from a schedule, while a series owns none — it points at dates that already exist on pass plans like this one. Build these first, and a Pass Series can then bundle them.

Both scheduled kinds are unlocked by the same capability and neither carries an extra transaction fee.

Creating one

Creating one from the Telegram bot

The plan wizard on the Subscriby bot builds pass schedules too, so a slate can go on sale from your phone.

Start Add Plan on your project as usual. After the price, the bot asks how customers should get access — choose Time-Limited Pass and it takes over from there:

• Timezone — your account timezone is offered as a button, alongside a short list of common zones. Anything else you type is accepted, so Europe/Madrid and GMT both work. Older names are resolved to their modern equivalent rather than rejected, so Asia/Calcutta is stored as Asia/Kolkata and US/Eastern as America/New_York.
• Repeats — Daily, Weekly or Monthly, the same three patterns as the dashboard.
• Access windows — send one per message as day, start time and length: Sunday 19:00 3h on a weekly plan, 15 19:00 3h on a monthly one, or 19:00 3h when it repeats daily. Day names work in English or in your bot's language, times take 19:00 or 7pm, and lengths take m, h or d. Tap Done when the slate is complete, or Remove Last to drop the window you just added.
• Stop selling — send a number of minutes, or tap Skip to sell right up to each window opening. Any number above zero then asks whether it counts back from when a window starts or when it ends, the same choice as the dashboard.

Choosing a pass skips the billing cycle, trial and renewal questions — a pass has no cycle to bill and nothing to renew — and goes straight to linked resources. The plan is created inactive, exactly as the dashboard leaves it, and the bot reports how many windows went on sale.

Adding a date by hand

Manage Access Windows has an Add a Window form at the bottom: pick a Date and a Starts time, set how long it Lasts, and add it.

This is how a fixed-dates plan gets every one of its windows. On a repeating plan it's for the exception — a rescheduled match, a bonus session — because a hand-placed window is never removed when you edit the schedule. Only generated windows are rebuilt.

Times are wall-clock in the plan's timezone, exactly like the slot times above, so 14:00 means 14:00 where your audience is rather than wherever you happen to be.

Four things are refused, with the reason shown:

• a start time in the past
• a window shorter or longer than the configured limits
• a start time this plan already has a window for
• on a plan set to before a window ends, a window no longer than its own cutoff — it would close its sales before it ever opened

That last one matters most on a fixed-date plan. Those have no repeating slots, so there is no schedule for the checks above to measure and this is the only place the length is checked against the cutoff.

To remove a hand-placed date, cancel it like any other window — holders get moved to the next one or told to ask you for a refund, which is why there's no plain delete.

Cancelling one customer's pass

Open Subscriptions, find the purchase and choose Cancel Subscription. Cancelling a pass does two things: the customer is not admitted when the window opens, and that date goes back on sale for them, so they can rebook it or pick a different one.

That second part is what makes cancelling the right tool for clearing up test purchases. A date stays reserved for whoever holds it, so a live pass keeps its window off their list — but a cancelled one releases it.

Cancelling does not remove anyone already inside the channel. If the window is running and you want them out now, cancel the pass and then remove them from the channel in Telegram.

A cancelled pass reads Cancelled on its own, with no lifecycle badge beside it. An ordinary membership cancelled with time still on it stays Active, because access genuinely runs to the end of the period already paid for — but a pass has no such period. The window sweep admits only holders who have not cancelled, so "Active" there would promise access that cannot arrive.

What your customer sees

1. They pick a date at checkout — the next one is preselected, and dates they already hold are hidden. On a plan that sells through its windows, one already running is marked On now and leads the list, because it is the one they get into immediately.
2. After paying, the bot names the window they bought — plan, start, end and how long until it opens — and their invite links follow in the next message. The portal's confirmation screen states the same window, so the date is visible without leaving the browser.
3. Tapping the link puts them in a queue. The bot confirms this straight away and states when access opens, when it ends, and how long they'll have.
4. When the window opens they are admitted automatically, whether or not they are at their phone — and the bot says so, with a Join button for every channel or group the pass covers and a countdown to when access ends. That message replaces the generic resource list at this moment, so what they get is unmistakably about the window they were waiting for rather than a repeat of their purchase receipt.
5. When it closes the pass ends and they are removed — unless another pass of theirs, or an ordinary subscription, still grants that same channel. Removal is decided per channel, so a customer who holds a Sunday pass and a monthly membership keeps their seat when Sunday's window closes.

Where a holder can check their own pass

A pass is not an ongoing membership, so it deliberately does not take over the bot's home screen — otherwise buying Sunday would hide Thursday, and selling several slates is the whole point. Instead a Your passes block sits above the plan list, listing up to three of the soonest with a My pass button for each.

Opening one shows everything about it: what was paid, the exact window in your schedule's timezone, a countdown to when it opens or ends, whether their join request is in the queue, and what the plan includes. A pass they can no longer use is left out entirely rather than listed with "access ended" under a heading saying what they hold.

The web portal carries the same detail. The plan card shows their own window and countdown beside Manage — distinct from the strip at the top of the card, which counts down to the next window on sale and is rarely the one they bought — and My Memberships repeats it per membership.

They can put it in their calendar

The portal offers every pass holder Add to your calendar — a subscription URL that puts their window into Apple Calendar, Google Calendar or Outlook, with a reminder an hour before it opens.

This matters more on a single pass than it looks. A holder acts once, days early, and then has nothing to do until the window opens — which is exactly the situation where a date slips a mind. The reminder ladder chases them in Telegram; the calendar puts it where they plan the rest of their week.

Nothing to configure. The link is minted the first time a holder opens their membership screen, so most purchases never carry one at all.

Every holder is reminded before the window opens

A holder who never taps their link isn't locked out — links are reissued when the window opens — but they then have to be at their phone to use them, and on a three-hour window noticing an hour late costs a third of what they paid for.

So the bot messages holders automatically: about a day before the window opens, and again about an hour before. Both name the plan, the window and an exact countdown to the opening. What the message asks of them depends on where they stand:

• Not in the queue — their invite link is attached as a button, so joining is one tap.
• Already queued — they're told there's nothing to do, that they'll be admitted automatically, and that the window goes ahead as scheduled unless you cancel it. No buttons, because a second tap would only produce a request Telegram refuses.

Someone who queued a fortnight ago has forgotten it exists, and a dated window is worth raising before they plan their evening around something else — which is why the reminder goes out either way rather than only to the people with something left to do.

A milestone that had already passed at purchase is skipped rather than fired late, so a customer buying two hours ahead gets the hour reminder only. You don't configure or trigger any of this.

You're reminded too, with the roll call

A window is a live event you have to be ready for, so the bot tells you about it three times:

The first two name the project, the plan, the window and the countdown, then give you the numbers that matter:

The last two are the point. Not in the queue is the only figure you can still change before the doors open, so when it is above zero the notice points you at Send Reminders in Manage Access Windows; when it is zero it says so plainly, which saves you opening the panel to check.

There is a third case, and it is the one worth reading carefully: if every pass sold has since been refunded or cancelled, the notice says nobody is due to arrive rather than telling you everything is in order. An empty queue and an empty window look identical in the numbers alone.

Nudging them yourself, from the window panel

Two rungs a day apart cannot cover every reason you might want to reach these buyers. A venue changed, the slate went up late, or a window was bought long enough ago that both milestones have already passed — and there is nothing scheduled between now and the window opening.

Open Manage Access Windows, and any window with an amber N not in queue badge gets a Send Reminders button beside Cancel Window. Confirm, and everyone in that count is messaged with their own invite link attached. The button reports back — "7 purchases have been notified." — and the number is what Telegram actually accepted, not what was attempted, so a buyer who has blocked your bot is excluded from it rather than counted as reached.

The message is headed Reminder from your project name and says outright that you sent it by hand, so a nudge landing outside the usual times doesn't read as the bot misfiring. It names the plan, the window and an exact countdown — to the opening, or to the close if the window is already running — and carries one button per linked resource with that customer's own invite link, so joining is one tap and they never have to go looking for a message from days ago.

The button only reaches buyers who are still out of the queue, and only on a window that can still be entered — a cancelled or finished window has nothing to nudge anyone about, so it gets neither the badge nor the button. Anyone who joins the queue between the panel being drawn and the button being pressed is skipped.

Sending a reminder counts as that window's most recent one, so the automatic ladder will not follow it minutes later with the same thing. A later milestone still fires normally: nudge someone two days out and they still get the one-hour reminder.

Nudging one customer

When a single buyer has written in to say they cannot find their link, the whole window is the wrong instrument. Open that subscriber from Users, and their pass card carries a Queue status badge — Join request not sent, In the queue or Admitted — a Last reminded line, and a Send Reminder button when there is something to remind them about.

It sends exactly the message above, to exactly that person.

Saying something else to them

Send Reminders sends one fixed message: your invite link is waiting, here it is. When you need to tell holders something else — a venue change, a kick-off delay, a thank-you after the final whistle — use a broadcast instead.

The broadcast composer offers the same populations as audience segments: Active Pass Holders and Active Pass Holders Not in Queue for one window you pick, and All Active Pass Holders / All Active Pass Holders Not in Queue across every upcoming window at once. The window picker there shows the holder count each option would reach, so you can see who a message lands on before writing it.

If a purchase produces no access

Provisioning can fail for reasons that have nothing to do with the payment — most often the bot no longer being an administrator with the Invite Users via Link right on the channel.

When a paid purchase produces no invite links at all, both sides are told: the customer gets a message saying their payment is safe and offering 🔄 Refresh Invite Links, and you get one naming the customer, the plan, and the likely cause. Fix the bot's permissions and the customer's refresh will then work — you do not need to re-issue anything yourself.

A plan whose resources are all manual is not a failure and stays silent: there are no links to issue, and the customer's confirmation screen says you will arrange access directly.

When a payment lands late

Buying and paying are not the same instant. A customer taps Pay at 10:59 for an 11:00 window, and the payment provider confirms it at 11:00, 11:01, or — on a card that needs 3-D Secure, or a crypto payment waiting on confirmations — considerably later. Subscriby only learns the payment succeeded when the provider's webhook arrives.

Three things can happen, and all three are handled without you intervening.

The window has not started yet

The normal case. The pass is bound to the window they chose and they are admitted when it opens, exactly as if they had paid a week earlier.

The window has already opened

They are bound to that window and admitted within about a minute, keeping whatever is left of it. Someone confirmed at 11:01 on an 11:00–14:00 window gets 2 hours 59 minutes.

This is worth understanding because the admission does not come from the window opening — that already happened. A separate catch-up runs every minute and admits anyone whose payment landed after their window opened, so late arrivals are never stranded waiting for an event that has passed.

If they tap their invite link before that catch-up runs, they are let straight in. Either route counts as attending; neither is recorded as a missed window.

The same machinery is what makes selling during a window work: on before a window ends this is not a late payment being rescued, it is the normal path. Set that anchor and the catch-up becomes the front door.

The window has already ended

They are not bound to a window that can no longer deliver anything. Subscriby moves them to the next available window on the same plan and their pass runs then instead, and messages them to say so — naming the window they missed, the one they now hold, and telling them to contact you if that date does not suit.

If the plan has no further window — a one-off, or a series that has finished — the purchase is left unbound and logged for you to resolve. The customer is told plainly that they were given no access and should contact you for a refund. Check Manage Access Windows after any schedule ends and refund through your payment provider.

Why moving them is safe: one price, every window

Every window on a plan sells for the same price, which is what makes this automatic move fair rather than presumptuous. Subscriby treats the windows on one plan as interchangeable — same price, so the same content and experience is assumed throughout.

If your windows are not interchangeable — Sunday's slate is worth more than Thursday's, a weekend intensive is not the same product as a weeknight Q&A — do not model them as one plan with several slots. Create a separate pass plan for each, priced and named on its own. Then nobody is ever moved between two things you consider different.

Use the sales cutoff to control this

Stop selling closes sales a set number of minutes before each window, at whichever end the anchor names. It exists precisely for this race.

On before a window starts — nothing is sold once a window is running:

On before a window ends — the window stays on sale while it runs:

The cutoff hides the window from checkout — it does not affect anyone who already bought it.

Changing a schedule

Editing slots rebuilds future dates — except any window a customer has already bought. Those keep their original times and are never moved or deleted, because someone paid for that occurrence.

So after a change a plan can legitimately show an old Saturday 12:00 that 47 people bought alongside a new Saturday 13:00 for future buyers. The windows panel marks the sold ones.

Cancelling a window

A postponed game is the one case where a sold window disappears, and it is never automatic. Cancel it from Manage Access Windows and every holder is either moved to the next available window on the same plan, or — if there is none — has their pass ended and is told to ask you for a refund. Everyone affected is messaged either way.

Postponing one properly

The order matters, because the replacement is chosen at the moment you cancel. Cancel first and you are gambling on whatever the schedule happens to offer next — which may be a fortnight away, or nothing at all.

What the customer receives

Everyone affected is messaged, and the wording differs by where they stood.

None of them invites the customer to buy again — an invitation to buy the next one is exactly wrong for somebody stranded because there is no next one.

The exact wording is on the subscriber page: If the organiser cancels your window.

A worked example

A Saturday football plan, weekly at 08:00, £15, 41 sold for Sat 29 Aug. The pitch floods on the Thursday.

Nobody is moved onto a date they already hold — a holder of both 29 Aug and 5 Sep skips to 12 Sep instead.

When to cancel a window — and when not to

Automating the fallout

A cancellation emits three kinds of webhook, so none of this has to be reconciled by hand:

pass.holder_stranded is the one worth wiring up: it carries the subscriber, the amount, the currency and the gateway payment reference, which is the only durable record of who you owe. Both are available as Zapier triggers and in the n8n trigger node.

Questions

Related

• Pass Series — bundle many of these windows into one season ticket
• Subscription Plans — ordinary recurring plans
• Managing Subscriptions — what a held pass looks like
• pass.* webhook events — automate around windows opening and closing