Subscriptions
Plans priced in BDT with five billing intervals, free trials, coupons and redemption tracking. Running in production today.
Five ways to charge for it, and what each one costs you to run
A platform you own is only worth owning if it can take money. This is every revenue model the platform supports, how far each one actually goes today, and — because it is the part that decides a deal — whose merchant account the money lands in.
The part most platform vendors leave to a sales call
Every OTT platform claims to support subscriptions, advertising and pay-per-view. The question that decides whether you can launch is narrower: which of them is code that runs today, which is a credential away, and which is a project. Those three answers are on every card below, and none of them is softened.
The second question, and the one a CFO asks first, is where the money goes. On a hosted platform the vendor is usually in the payment path and takes a share of it. Here the merchant account at the gateway is yours: the settlement lands in your account, and there is no platform cut on a transaction we never touch.
One consequence worth stating before you read on. Subscriptions, trials, coupons, one-off purchases and event tickets are all running code, billed in taka. Server-side ad insertion, carrier billing and cohort revenue analytics are not built at all. A vendor who blurs those two lists costs you a quarter; we would rather lose the deal at the page than at the go-live.
The five models
Each one links to what it does, what it does not do yet, and the code behind the claim.
Running more than one at once
Nothing in the entitlement model assumes a single revenue source — a subscription and a one-off purchase are two independent grants, and either one opens a title.
Who charges for it this way
The revenue model that fits is usually decided by who the audience is and how they already pay for things, not by which features a platform lists.
- Broadcasters
- A back catalogue and a linear channel usually monetise differently: subscriptions carry the catalogue, and a match or a premiere is sold once as a ticket.
- Telcos and ISPs
- Bundling the service into a data pack is the model that converts, and it is the one that needs building — carrier billing is scoped here rather than claimed.
- OTT platforms
- Operators already charging subscribers, moving off a rented platform without losing the plans, the coupons or the payment relationship.
- Enterprise and education
- Often no consumer charging at all — entitlement without a gateway, where the value is access control rather than revenue.
Where the money lands, and who is in the path
The gateway merchant account is registered to you. SSLCommerz settles to that account directly, and the platform's role in the transaction is to name a price and to record what happened — it never holds funds. There is no revenue share to negotiate because there is no mechanism for one.
The price is always resolved server-side. A checkout request names an item and what is being bought; the amount and the access window are looked up from the service that owns that item immediately before the payment session is created. A client that posts its own price changes nothing, which is the difference between a checkout and a suggestion.
Settlement is idempotent under a row lock, so one validated payment settles at most one transaction. That is not a design intention — it is asserted by a verification playbook that reads the deployed source and fails if the lock is missing.
What ships, at a glance
The same statuses used across this site. Read the linked page before quoting any row of it.
| Capability | Status | What that means here |
|---|---|---|
| Subscription plans, BDT-priced | Shipping | Running in production, five billing intervals |
| Free trials | Shipping | Per-plan trial length; seeded at 7 days |
| Coupons and redemption | Shipping | Own service, with a key-gated admin route |
| Rentals, purchases, event tickets | Built — commissioned at deployment | Complete path; one database migration outstanding |
| SSLCommerz, and bKash / Nagad / cards through it | Connected at onboarding | Integration built; your merchant credentials configured |
| Client-side pre-roll advertising | Connected at onboarding | One platform-wide VAST tag, pre-roll only |
| Server-side ad insertion, mid-roll, frequency capping | Not built | No code anywhere |
| Carrier billing, zero-rating, MSISDN sign-in | Not built | Engagement work, scoped rather than claimed |
| MRR and monthly revenue series | Shipping | Real figures out of billing |
| Churn, LTV, cohort retention | Not built | No subscription state-transition history exists yet |
Questions
Do you take a percentage of subscription or transaction revenue?
No, and there is no mechanism for it. The merchant account at the gateway is yours and settlement goes to it directly. The platform names a price and records the outcome; it never holds funds.
Can I run subscriptions and pay-per-view at the same time?
Yes. A subscription entitlement and a one-off purchase entitlement are separate grants, and playback authorisation asks both — either one opens the title. There is no configuration that makes them exclusive.
Can I charge in taka?
Taka is the primary currency in the schema rather than a conversion applied at the edge. `price_bdt` is the non-null column on a plan and USD is the optional one, which is the reverse of how most platforms built elsewhere treat it.
What is genuinely missing today?
Server-side ad insertion, mid-roll and any ad rule beyond one platform-wide pre-roll tag. Carrier billing, operator bundles, zero-rating and MSISDN sign-in. Churn, lifetime value and cohort retention analytics. Those are builds inside an engagement, and each has its own page saying so.
Which mix fits your catalogue?
Tell us what you are charging for today and who your audience is. What comes back is which of these five you actually need, and which of them is a build rather than a setting.