Skip to content

Monetization · SVOD

Subscriptions, priced in taka and running today

Plans, intervals, trials, coupons and the entitlement check that decides whether a viewer may press play. This is the part of the platform with paying users on it, so the description is of code rather than of a roadmap.

A plan is a row, not a hard-coded tier

Plans live in the database and are edited from the admin console. Each carries a name, a price in taka, an optional price in dollars, a billing interval, a duration in days, a trial length, an active flag and a sort order. Adding a plan is adding a row; it is not a deployment and it does not involve us.

Taka is the primary currency and that is a schema fact rather than a positioning line: `price_bdt` is the non-null column and `price_usd` was added afterwards as nullable. A platform built for another market treats this the other way round, and the difference shows up as rounding on every invoice.

The seeded plans a new estate starts with are 90 taka monthly, 300 quarterly and 900 yearly, each with a seven-day trial. They are a starting point to be replaced with yours, not a price list we recommend.

Specification

What a plan can say

The columns that exist on a plan, and what each one controls.

FieldWhat it holdsNotes
Price in BDTDecimal, requiredThe primary currency; not a conversion
Price in USDDecimal, optionalAdded after BDT and nullable, deliberately
Billing intervaldaily · weekly · monthly · quarterly · yearlyFive, from the schema enum
Duration in daysInteger, default 30What the entitlement window is measured in
Trial lengthInteger days, default 0Seeded at 7 on the sample plans
Recurring flagBooleanMarks the plan as a recurring product — see the renewal note below
Active flag and sort orderBoolean, integerControls whether and where it appears
Read from the deployed billing schema. A subscription then carries one of five states: trialing, active, past due, cancelled or expired.

How entitlement is decided

Playback does not trust the client. When a viewer presses play, the platform asks billing whether that account currently holds a subscription that has not ended, and separately whether it holds a one-off purchase for that title. Either answer opens the title; neither answer closes it politely.

The check is a comparison against the period end rather than a flag somebody remembered to clear. A subscription that has run out is expired because the date says so, which means there is no state where a cancelled account keeps working because a job did not run.

Two things this page will not claim

Automatic renewal is not implemented. A subscription has a recurring flag and an interval, and entitlement lapses at the end of the period; there is no scheduler in the billing service that re-charges a card, and no dunning retry ladder behind the past-due state. Separately, per-plan concurrent stream limits do not exist: the device limit is one service-wide value, and a slot is a registered device rather than a playing stream. Both are honest builds inside an engagement, and neither may be sold as a plan feature.

Detail

What ships with it

Shipping

Free trials

Trial length is a per-plan column and a trialing subscription is a first-class state, not a coupon with a short expiry.

Shipping

Coupons and redemption

A separate coupon service with its own deployment. Redemptions are readable per coupon, and the admin create route sits behind a key gate proven by a verification playbook.

Shipping

Transaction history

Every payment attempt is a row with a state — pending, success, failed or cancelled — readable per user and in aggregate from the console.

Shipping

MRR and revenue series

Monthly recurring revenue in taka, a monthly revenue series and subscriber counts by current status. Real figures, out of billing.

Not built

Churn, LTV and cohorts

Nothing yet distinguishes a cancellation today from one in March, because no subscription state-transition history is recorded. Churn is the prerequisite for lifetime value, so it is two builds rather than one.

Not built

Trial-to-paid funnel

What exists is a snapshot ratio of accounts trialing now against paid now. Nobody is followed from trial to decision over time, which makes it a ratio rather than a funnel.

Questions

Questions

How many concurrent streams can I sell per plan?

None, today, and this is worth reading rather than skipping. The device limit is a single service-wide value with a default of 3, identical on every plan, and a slot is a registered device rather than a playing stream — so two streams on one device count once. Selling '1 stream' on a basic plan and '2 streams' on a premium one would be a promise the code does not keep. Making the limit per-plan and counting streams is a scoped build.

Does a subscription renew automatically?

Not today. The plan carries a recurring flag and an interval, and entitlement lapses when the period ends. There is no scheduler in the billing service that initiates the next charge, and no retry ladder behind the past-due state. Recurring collection is a build inside an engagement.

Can I change prices without a deployment?

Yes. Plans are database rows edited from the admin console — price, interval, trial length, whether the plan is visible and where it sorts. No release is involved and we are not in the loop.

What currency are subscribers charged in?

Taka. `price_bdt` is the required column on a plan and the gateway settles in BDT; the USD column exists and is optional. This is the schema's shape, not a display preference.

Bring your plan structure and we will map it

Most catalogues need three or four plans and one trial length. Send yours and we will tell you what maps onto what runs today and what needs building.