Managing Subscriptions
View and filter every subscription in your project, inspect payment history, and cancel active or trialing subscriptions.
By the end of this page, you'll know where to find every subscription in your project, how to read its status, and which actions are available.
A subscription is the record created when a member signs up to one of your plans. It tracks which plan was chosen, which payment method was used, the current payment status, the amount paid, and which subscriber it belongs to.
Navigating to Subscriptions. Select a project first (top-left picker), then open Subscriptions from the sidebar. The Subscriptions page is separate from Members — one member can have multiple subscription records over time (original trial, upgrade, re-subscribe after churn).
Filters
The Subscriptions page has URL-routed filter tabs at the top:
Every subscription, regardless of status — active, expired, pending, cancelled.
An additional Pending filter exists on the global All Project Subscriptions route — it surfaces subscriptions whose payments are still being confirmed by the gateway.
Dropdown filters
Below the tabs, a row of dropdown filters narrows the list further. These appear on both a single project's Subscriptions page and the global All Project Subscriptions view:
- Filter by Plan — limit to subscriptions on a specific plan.
- Filter by Payment Method — limit to a specific configured provider and mode (Live / Test).
- Filter by Status — limit to one of the 13 statuses below.
- Per page — choose 15, 25, 50, or 100 rows per page.
On the global All Project Subscriptions view, an extra Filter by Project selector appears first. Pick a project to scope the list to it; doing so also populates the Plan and Payment Method dropdowns with that project's options. Reset Filters clears every dropdown back to its default.
The 13 subscription statuses
Subscriby tracks subscription state using a thirteen-option enum. Each status has its own badge colour so you can scan the list quickly:
| Status | Colour | Meaning |
|---|---|---|
| Active | green | Currently running and paid up. |
| Trialing | yellow | Inside a trial period of the plan. |
| Pending | blue | Payment submitted, awaiting confirmation. |
| Processing | blue | Gateway is processing the payment. |
| Capturable | blue | Payment is authorized but not yet captured. |
| Succeeded | green | Payment completed successfully. |
| Incomplete | orange | Payment hasn't completed in time — manual intervention may be needed. |
| Past Due | red | Renewal payment failed; retry window open. |
| Unpaid | red | Payment failed and retries exhausted. |
| Failed | red | Payment outright failed. |
| Expired | red | Billing period ended and access has stopped. |
| Canceled | zinc | Subscriber or creator cancelled. Access usually continues until the current period ends, then the subscription becomes Expired. |
| Paused | yellow | Temporarily paused by you or the payment provider. |
See Status reference for how these map to member-visible states like "your subscription is paused" or "payment failed".
List columns
Each row on the Subscriptions page shows:
| Column | Content |
|---|---|
| Plan | The plan's name, with the bot avatar and the project name beneath. |
| Payment Method | Provider (Stripe, PayPal, etc.) and its mode (Live / Test), plus the gateway's transaction ID. |
| Status | Colour-coded status badge (one of the 13 above). |
| Amount | Price paid, formatted in the subscription's currency. |
| Subscriber | The member's name and Telegram chat ID. If the subscription hasn't been claimed by a user yet — e.g. an unredeemed access-code-activated record — this reads "Unclaimed Subscription". |
Click a column header to sort by that field (ascending/descending toggle).
Time-limited passes in the list
A pass is a subscription record like any other, so it appears in this list — but two columns carry extra information, because the payment status alone describes a pass poorly. A pass reads Active from the moment it is paid for, which says nothing about whether its window has run.
- Plan adds the access window the customer bought, as a time range in the plan's timezone. A purchase not yet bound to a window reads "Awaiting window assignment".
- Status stacks a second badge for the pass's own state: Awaiting Window before it opens, Access Granted while it runs, Access Ended once it has closed, and Never Joined for a window that passed without the holder being admitted.
- Status adds a third badge while a pass is still awaiting its window: Queue Joined or Not Queued. That is the one thing on the row you can act on — a queued holder is admitted automatically at the start time, an unqueued one has to be at their phone.
Pass series in the list
A series is one row covering many dates, so it is read differently again. Its Status column carries how far through the slate the holder is — "6 passes left of 10" — plus N missed once dates start going by without them, in place of the single-window badges above.
Those badges would describe whichever date happens to be next and read as the state of the whole purchase, which on a thirty-date season is wrong about twenty-nine of them.
View Details splits the same way: a Season block with the span, progress, timezone and attended / missed counts, then a Next pass block naming that date and whether its queue has been joined.
Badges that override the pass state
Three situations mean the window no longer matters, and they replace the state badge rather than sit beside it:
| Badge | What it means |
|---|---|
| Cancelled | The subscription was cancelled. On a pass or a series it stands alone, with no lifecycle badge beside it: the holder will not be admitted, so Active would promise access that cannot arrive. On an ordinary membership Active stays, because access really does run to the end of the paid period. |
| Will Not Open | The pass ended before its window ran — refunded, expired, or otherwise closed out. It cannot open, whatever the countdown once said. |
| Refunded | Shown in place of Expired when a refund is what ended it. The lifecycle state is genuinely expired; this names the reason, which lives on the payment rows. |
The View Details flyout shows the same window and state, plus a flag when the holder has not tapped their invite link yet — see Customers who haven't joined the queue. It replaces Subscription Ends At with the window, because on a pass that timestamp is the close of a bought window rather than the end of a paid period.
Cancelling does not notify the customer
Cancelling a subscription from this screen removes access and stops billing, but sends the customer no message. On a pass that is worth knowing: they keep a working-looking invite link and only discover the change when they are not admitted. Until that changes, tell them yourself — or issue a refund instead, which does message them.
Per-row actions
Each row has an ellipsis (⋯) dropdown with these actions:
- View Details — opens a flyout with the subscription's full metadata.
- View Payments — opens a separate flyout listing every individual payment attached to this subscription, with its own pagination (10 per page).
- Cancel — opens the cancellation confirmation modal. Only available for Active or Trialing subscriptions that aren't already cancelled.
- Activity — opens the timeline view showing every tracked event for this subscription.
- Suspend Access — removes the member from this project's linked resources without cancelling. Shown for Active and Trialing subscriptions.
- Restore Access — puts a suspended member back, with fresh invite links. Shown only for Paused subscriptions.
- Reactivate — calls off a scheduled cancellation. Shown only for cancelled subscriptions paid through Stripe.
Cancelling a subscription
Find a cancellable subscription
Find the subscription in the list. If it's not Active or Trialing, cancellation isn't applicable (you'll see an error toast if you try).
Choose Cancel
Click the ellipsis dropdown and choose Cancel.
Confirm in the modal
A confirmation modal explains the impact. Confirm.
Subscriby runs CancelSubscriptionJob
Subscriby queues a CancelSubscriptionJob — a background job that:
- Marks the subscription as cancelled.
- Stops future automatic renewals (for recurring plans).
- Lets current paid access continue until the cycle ends, then flips the record to Expired and removes the member from Telegram resources.
You'll see a toast: "Subscription cancellation queued. The subscription cancellation has been queued and will be processed shortly."
Cancellation doesn't automatically issue a refund. Refunds are handled through your payment provider's own dashboard (Stripe, PayPal, Razorpay, etc.). Decide your refund policy up front and communicate it to subscribers.
Suspending access
Suspend Access removes a member from every linked Telegram resource on this project and marks the subscription Paused. Restore Access puts them back with newly generated invite links — the old ones were revoked and cannot be reinstated.
Suspending does not stop billing. The member keeps being charged by their payment provider on the normal schedule while they have no access. If you leave someone suspended for a month, they pay for that month and get nothing — so tell them, or cancel instead.
Subscriby settles through seven payment providers and only some can hold a recurring charge at all. A suspension that meant "stop billing" would work on some of your members and silently not on others, which is worse than a rule that is the same for everyone. Access is the part Subscriby controls directly, so it behaves identically no matter how the member pays.
Use it for a moderation timeout, a dispute you are investigating, or a member who asked for a short break and agreed to keep paying. For anything longer, cancelling is the honest option.
Reactivating a cancelled subscription
Reactivate calls off a cancellation that has not yet taken effect, putting the subscription back on its original billing schedule — the win-back path when someone changes their mind.
Stripe only. On every other provider, cancelling ends the agreement with the provider outright, so there is nothing left to resume and the member has to subscribe again. The action is hidden for those subscriptions rather than shown and then refused.
A subscription whose period has already expired cannot be reactivated on any provider.
The View Payments flyout
Each subscription can have multiple payments — the first checkout, any subsequent renewals, and any adjustments. View Payments opens a paginated list of those, including:
- Payment method used
- Amount and currency
- Payment status (from the same 13-status enum)
- Gateway-side identifiers for looking up the transaction in Stripe/PayPal/etc.
Use it when a subscriber asks "was my last renewal charged?" or when reconciling with your gateway dashboard.
Refunds
Subscriby doesn't process refunds directly — you issue them in your provider's dashboard, and Subscriby reacts to the webhook.
A full refund revokes access. When the provider reports the whole payment back, Subscriby
removes the member from every Telegram resource on that plan, marks the subscription
Refunded, records a refund row in the payment history, and emits subscription.refunded
and payment.refunded to your webhook subscribers. For a
time-limited pass whose window hasn't run yet, that
means the holder is not admitted when it opens — the window sweep only admits subscriptions
that are still live.
A partial refund leaves access alone. Sending a few pounds back doesn't evict a paying member, so the subscription continues untouched and only the payment history records it.
The customer is told. A refunded buyer receives a message naming the plan, the amount refunded, and — on a pass — the access window they no longer hold, plus a note that refunds usually reach their payment method within 5–10 business days. They are explicitly told their invite link no longer works, so a refunded pass holder doesn't sit waiting for a window that will never open for them.
A refunded series holder gets the same message written for a season: it names the plan and the amount, and says every remaining pass has been withdrawn rather than naming a single date. One date out of thirty would be the wrong thing to tell someone whose whole season just ended.
Stripe: charge.refunded must be enabled per mode
Stripe's enabled-event list is configured per endpoint and per mode, so a refund in live
mode produces nothing if only the test endpoint subscribes to charge.refunded — and vice
versa. Nothing in Subscriby can detect the difference between "no refund happened" and "we
were never told", so a refund can appear to be ignored entirely while the money is already
back with the customer.
If a refund isn't reflected within a minute or two, check the endpoint's enabled events before anything else.
- Crypto providers — refunds must be coordinated manually.
- Access codes — no refund applicable (no money changed hands). Cancel the subscription to revoke access.
Finding subscriptions activated via access codes
Subscriptions created by redeeming an access code are listed like any other — the only giveaway is the provider column: they'll show "Access Codes" instead of Stripe/PayPal/etc. The gateway transaction ID column will typically be empty for these.
Open the detail flyout to see the original access code string that activated the subscription — useful for tracing which campaign or influencer batch the signup came from.
Filter recipes
Frequently asked
Related
- Managing members — the subscribers behind the subscriptions.
- Subscription plans — the plans these subscriptions are instances of.
- Status reference — every status explained in plain language.
- Dashboard analytics — aggregated revenue and retention metrics.
How is this guide?