Subscription Billing and Entitlement: the SVOD Engine

Why this matters

If you are a founder, product manager, or first-time streaming CTO, subscription billing is the part of the platform that looks trivial in a demo and turns into a swamp in production. The demo shows a price and a "Subscribe" button; production has to handle a card that declines on renewal, a viewer who upgrades mid-month, an Apple subscription that was cancelled in iOS Settings without telling your server, a finance team that needs revenue recognized correctly for an audit, and a contractually protected title that must never play for someone whose payment lapsed. Get entitlement wrong in the permissive direction and you give away content you are licensed to protect; get it wrong in the strict direction and you lock out paying customers and manufacture cancellations. This is the SVOD engine room, and it is the companion build-guide to the OTT monetization map, which shows where this engine sits among all the ways a platform earns.

The one idea: entitlement is the hard part, not the paywall

Subscription Video on Demand (SVOD) — charging a recurring fee for access to a library — is one of the business models that decide a platform's architecture, and it sounds like a solved problem. Stripe takes the card, the viewer gets in, done. That framing is why so many teams under-budget the work and discover the real system only when it breaks.

Here is the distinction that organizes everything else. Billing is the money-collection machine: it stores the plan a viewer chose, charges their card on a schedule, handles upgrades and refunds, and retries failed payments. Entitlement is the access-decision machine: it answers one question, "is this viewer allowed to watch this title, on this device, in this place, right now?", and it answers it on every play. Billing runs on a monthly cadence; entitlement runs thousands of times a second. The paywall — the screen that shows plans and collects a card — is just the front door to billing. It is the part you can design in an afternoon, and it is the part that matters least.

The reason entitlement is the hard part is that it is stateful, always-consulted, and never allowed to be wrong. Think of it as the cash register and the bouncer fused into one service: the bouncer checks every person at the door every time they enter, and the register has to know, instantly, whether this person's membership is paid, what it covers, and how many friends they are already streaming with on other screens. A false "no" locks out someone who is paying you. A false "yes" streams a studio's film to someone who stopped paying — a contract breach, not just lost revenue. Entitlement also reaches beyond billing: it carries the same per-title, per-territory, per-window rules a license policy encodes, and the viewing data it generates is regulated under privacy law (VPPA, GDPR, CCPA). The rest of this article builds both engines and, more importantly, the wiring that keeps them in sync.

Figure 1. The entitlement check that runs on every play. The paywall is the front door; this decision is the machine behind it, consulted thousands of times a second and never allowed to be wrong.

What the billing engine actually does: four mechanics

Strip a subscription billing system down and it is four mechanics working on top of a stored payment method. None of them is the paywall UI; all of them are where production bugs and lost revenue hide.

Plans and tiers

A plan is the unit a viewer subscribes to: a price, a billing interval (monthly or yearly), and a bundle of what it grants — which catalog, what video quality, how many simultaneous streams, ad-free or ad-supported. The plan is also the input to entitlement; when the bouncer checks the door, the plan is the rulebook it reads. Designing the tiers and bundles themselves is its own decision, covered in pricing, packaging, and the monetization decision; here we care about how a chosen plan is enforced. A clean design keeps the plan's grants (resolution cap, stream count, catalog scope) as structured data the entitlement service can read directly, not as prose buried in a pricing page. Yearly plans matter for cash flow — they collect twelve months up front — but, as the revenue-recognition section explains, collecting the cash is not the same as earning it.

Trials

A free trial lets a viewer watch before the first charge, which lifts sign-ups and, handled badly, invites abuse and surprise-cancellation complaints. Two engineering points matter. First, a trial is an entitlement state, not a billing state: during the trial the viewer is fully entitled, but no money has changed hands, so the system must convert cleanly to a paid charge on the trial's last day — and handle the decline gracefully if the card fails at that exact moment. Second, the trial earns no revenue until it converts; in accounting terms the trial period is recognized at zero, a point finance will check.

Proration

Proration is the arithmetic of mid-cycle change: when a viewer upgrades, downgrades, or cancels partway through a paid period, they should pay or be credited for exactly the days they had each plan. The formula is the same everywhere:

prorated charge = plan price × (days remaining ÷ days in billing period)

Walk a concrete upgrade. A viewer on a \$100-a-year-equivalent plan — use round numbers — sits on a \$100/month tier and upgrades to a \$200/month tier on day 10 of a 30-day cycle, with 20 days remaining:

charge for the new tier   = $200 × (20 ÷ 30) = $133.33
credit for the old tier   = $100 × (20 ÷ 30) =  $66.67
net charged immediately   = $133.33 − $66.67 =  $66.66

So the viewer pays \$66.66 now for the upgrade and the full \$200 at the next renewal. The near-universal convention is to prorate upgrades immediately (the viewer wants the better plan now) but apply downgrades at the next cycle (let them use what they already paid for, and avoid issuing awkward credits). Proration is one of the trickier corners of billing because every one of these events creates an accounting consequence that has to reconcile — which is the whole reason teams reach for a billing platform rather than hand-rolling it.

Dunning

Dunning is the automated retry-and-remind sequence that runs when a renewal payment fails. It is the least glamorous mechanic and the one that protects the most revenue, because most subscription losses are not viewers deciding to leave — they are cards quietly failing. We give dunning its own section below because the numbers are large enough to change your business.

The subscription lifecycle: one state machine, many edge cases

Every subscription moves through a small set of states, and writing them down explicitly is the single best defense against entitlement bugs. A subscription is trialing, then active, and on a failed renewal it enters a past-due / grace state where the platform retries the card while — crucially — usually keeping the viewer entitled so a transient decline does not interrupt a paying customer mid-season. From grace it either recovers back to active or, after the retries are exhausted, lapses to canceled and then expired, at which point entitlement is finally withdrawn. A separate win-back path tries to bring expired viewers back.

The reason to model this as one explicit state machine is that entitlement is a function of the state, not of the last payment. "Has a valid payment" is the wrong question; "is in a state that grants access" is the right one, because grace periods, trials, and refunds all decouple access from the most recent charge. Teams that treat entitlement as a simple boolean — paid or not — are the ones who either cut off customers during a routine retry or keep streaming to people who churned weeks ago.

Figure 2. The subscription lifecycle as one state machine. Access is granted by the state, not by the last payment — the grace state keeps a paying viewer watching while a transient card decline is retried.

Where the money is collected: app-store billing vs direct billing

Now the decision that quietly sets your margin — and margin, alongside delivery and encoding, is what the OTT cost model turns into a runway. If a viewer subscribes inside your iOS or Android app, the platform store processes the payment and takes a cut. If they subscribe on your website (direct billing), you process the card through your own payment provider and keep far more of the dollar. This is not a billing-team detail; it is an architecture decision you cannot retrofit cleanly, because the two paths produce different money, different data, and different sources of truth.

Start with the cut, because it is large. As of mid-2026, Apple's App Store charges 30% on an auto-renewing subscription's first year and 15% from the second year onward, with a 15% Small Business Program rate for developers under \$1 million a year (Apple Developer, 2026 — vendor policy, re-check). Google Play charges 15% on subscriptions today, and under its 2026 Epic settlement is moving to 10% on subscriptions (and 20% on other in-app purchases) in the US, UK, and EEA from 30 June 2026, rolling out globally by 2027 (Google Play / Epic settlement, 2026 — dated, re-verify). Both regimes are in motion in 2026 after the Epic v. Apple and Epic v. Google outcomes, so treat every number here as dated and confirm it before you model on it.

Put the cut into a build decision with arithmetic. Take 100,000 subscribers at \$9.99/month:

gross billings            = 100,000 × $9.99            = $999,000 / month
in-app, Apple 30% year 1  = $999,000 × 0.70            = $699,300 / month
direct web, ~3% card fee  = $999,000 × 0.97            = $969,030 / month
difference                = $969,030 − $699,300        ≈ $269,730 / month

That gap is about \$3.2 million a year, on the same 100,000 subscribers, decided entirely by where the subscription was sold. This is why serious SVOD platforms route sign-ups deliberately. The lever streaming has that a game does not is the "reader app" carve-out: Apple's guidelines classify video services among "reader" apps, which may let viewers create and manage their account — and pay — on the web, then simply sign in on the app, without forcing in-app purchase (App Store Review Guidelines §3.1.3(a), 2026 — re-check). Netflix and Spotify famously use this: there is no "subscribe" button in the iOS app at all. In the US, the April 2025 Epic v. Apple injunction further loosened external-link rules; that area is still being litigated, so treat it as live.

The cost of direct billing is that you now own the things the store used to handle for you: card processing and its PCI-DSS compliance boundary (the Payment Card Industry Data Security Standard that governs handling card data — covered with the transactional flows in TVOD: rent, buy, PPV), fraud, tax, refunds, and dunning. Most teams keep card data out of scope by tokenizing through a payment provider, but the responsibility is now yours. The table below is the trade-off as a coverage map.

Responsibility	In-app store billing	Direct (web) billing	Billing aggregator (e.g. RevenueCat, Adapty)
Who collects the money	Store (Apple / Google)	You (your PSP)	You, via the aggregator's wrapper
Platform cut	15–30% (see dates)	~2–3% PSP fee only	PSP fee + aggregator fee
PCI-DSS scope	Store owns it	You own it (tokenize to reduce)	You own it, aggregator assists
Card retries / dunning	Store-controlled	You build it	Aggregator assists
Entitlement source of truth	Store notifications	Your billing DB	Aggregator's unified entitlement
Cross-platform account	Hard (store-siloed)	Native	Native (its main value)
Refund control	Store-controlled	You control it	You control it

Table 1. Where each billing path puts the work. "You own it" cells are the responsibilities direct billing transfers from the store to your team — the price of keeping the larger share of the dollar.

Figure 3. The two billing paths. In-app billing trades a 15–30% cut for the store handling payment and compliance; direct billing keeps the dollar but hands you the work — and both must feed the same entitlement record.

Keeping billing and entitlement in sync: the source-of-truth problem

Here is the bug that defines real subscription systems. When a viewer subscribes through Apple or Google, the store, not your server, owns the billing relationship. They can renew, cancel, refund, upgrade, or enter billing retry entirely inside the store — in iOS Settings, say — and your platform finds out only if you are listening. If you treat the app's local "I bought it" signal as truth, you will keep streaming to people who cancelled and cut off people whose renewal just succeeded on Apple's side.

The fix is a server-side source of truth fed by the stores' own webhooks. Apple sends App Store Server Notifications V2 and Google Play sends Real-Time Developer Notifications (RTDN) over Google Cloud Pub/Sub; both push a message to your backend whenever a subscription's state changes — renewed, cancelled, refunded, entered grace, expired (Apple and Google developer documentation, 2026). The disciplined pipeline is always the same four steps: verify the notification's signature so it provably comes from the store; call the store's server API to fetch the authoritative current state (the notification is a doorbell, not the full message); deduplicate on the notification ID because webhooks are delivered at-least-once and will arrive twice; then update your entitlement record, which is the one place every client and the paywall ask for the truth. Build this and a cancellation in iOS Settings reaches your entitlement service in seconds; skip it and your access decisions drift away from reality.

This is also why cross-platform streaming services so often adopt a billing aggregator (RevenueCat, Adapty, and similar) or build the equivalent: a single entitlement layer that normalizes Apple, Google, and web billing into one answer to "what can this account watch?", so a subscription bought on an iPhone unlocks the same account on a smart TV. The aggregator is not collecting the money differently; it is unifying the entitlement across stores, which is the hard part.

Figure 4. The reference wiring. Three billing sources (App Store, Google Play, web PSP) feed verified webhooks into one entitlement service — the single source of truth that the player, paywall, analytics, and finance all read.

Revenue recognition: collecting cash is not earning revenue

Finance will hold the billing system to a rule that surprises engineers: the money you collect is not the revenue you report. Under the controlling accounting standards — ASC 606 in US GAAP and the equivalent IFRS 15 internationally — subscription revenue is recognized as the service is delivered, spread evenly across the period the viewer is entitled, not when the card is charged (FASB ASC 606; IFRS 15).

The case that bites is the annual plan. A viewer pays \$120 up front for a year. On the day the card clears you have \$120 in cash but \$0 in earned revenue; the \$120 sits as a liability called deferred revenue, and you recognize \$10 of revenue each month as you deliver the service. Free trials follow the same logic — zero revenue during the trial, recognition beginning at conversion — and refunds and proration adjust what has been earned. The reason this matters to the build, not just the finance team, is that your entitlement and billing records are the audit trail for revenue. If the system cannot say precisely what each viewer was entitled to and what they were charged across every upgrade, refund, and grace period, the company cannot recognize revenue cleanly or pass an audit. Designing billing events as an immutable, queryable ledger from day one is far cheaper than reconstructing it later.

Involuntary churn: the silent revenue leak you fix with engineering

Most people picture churn as a viewer deciding to cancel. In subscriptions, a large share of churn is nothing of the kind — it is involuntary churn, where the viewer wants to stay but the renewal payment fails: an expired card, a hit credit limit, a bank's fraud filter, a network timeout. Across the subscription economy, involuntary churn accounts for roughly 20–40% of total churn, and streaming services see a median involuntary-churn rate around 2.1% of subscribers per month (Slicker, 2025). Up to 9% of recurring card payments fail on first attempt (Slicker, 2025). This is revenue walking out the door from people who never chose to leave — and it is recovered with engineering, not marketing.

The engineering is dunning plus two supporting tactics. Dunning retries a failed charge on a schedule and emails the viewer to update their card; a transient decline often clears on the second or third attempt. A card-updater service (offered by Visa and Mastercard through your payment provider) automatically refreshes a card number that was reissued, recovering up to 20% of failures before a retry is even needed (Slicker, 2025). And a grace period keeps the viewer entitled and watching during the retry window, so you are not interrupting — and antagonizing — a customer you are about to recover. Put numbers on it for the same 100,000 subscribers at \$9.99:

failed renewals at 9%        = 9,000 / month
revenue at risk              = 9,000 × $9.99   ≈ $89,910 / month
recovered at industry-median 47.6% dunning   ≈ $42,797 / month
recovered at a strong ~70% program           ≈ $62,937 / month
extra revenue from doing dunning well        ≈ $20,140 / month  (~$242k / year)

The difference between a weak retry flow and a strong one — card updater, smart retry timing, grace periods, good update emails — is on the order of a quarter-million dollars a year at this modest scale, all of it from viewers who wanted to keep paying. There is also a compliance subtlety that bites EU billing: under PSD2 Strong Customer Authentication, the first charge at sign-up must be authenticated (typically 3-D Secure), but subsequent recurring charges qualify as merchant-initiated transactions that are exempt — provided you flag them correctly. Mislabel them and your renewals get declined for authentication you did not need, manufacturing involuntary churn out of a configuration mistake. The churn analytics that track all of this live in churn, retention, and subscription analytics.

A common mistake: building the paywall first and treating entitlement as a boolean

The recurring failure pattern is to ship the visible 10% and skip the structural 90%. A team builds a beautiful paywall, wires Stripe, flips a is_subscribed = true flag on the account, and ships. Then production arrives. A renewal fails and the boolean flips a paying customer to locked-out mid-episode, because there is no grace state. An iPhone cancellation never reaches the server, because nobody is consuming App Store Server Notifications, so the account streams for free for a month. A viewer upgrades and is double-charged, because proration was never built. Finance cannot close the books, because billing events were overwritten instead of logged. Each of these is the same root error: entitlement was modeled as a single boolean tied to the last payment, instead of as a state derived from a reconciled ledger. The fix is the order of work — model the lifecycle states and the store-notification sync first, treat the paywall as the last and easiest piece, and never let a client's local belief about a purchase be the source of truth.

Where Fora Soft fits in

Subscription billing is where streaming scale meets money, and the expensive failures are invisible until they compound: revenue leaking through involuntary churn, entitlement drifting out of sync with the app stores, an audit that cannot close because the billing ledger was never built to be one. Fora Soft has built video streaming and OTT/Internet-TV platforms since 2005, across 625+ shipped projects for 400+ clients, which means we have wired entitlement services that stay correct under concurrency, reconciled Apple App Store and Google Play billing against direct web billing through one source of truth, and built the dunning and grace-period flows that quietly recover the revenue most platforms lose. Our stance is scalability-first and vendor-neutral: we start from the scale you must serve and the margin you must protect, then build the billing-and-entitlement engine — direct, in-app, or unified across both — that your model actually requires.

What to read next

• The OTT monetization map: subscriptions, ads, transactions
• Paywalls, registration walls, and access control
• Churn, retention, and subscription analytics

For a shorter, product-level overview of in-app vs web monetization, see our video streaming app monetization guide; to commission a build, talk to our streaming team via the link above.

Call to action

• Talk to a streaming engineer — book a 30-minute scoping call to talk through your subscription billing plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Subscription Billing & Entitlement — One-Page Reference — The entitlement decision checklist, the subscription lifecycle state machine, the app-store-vs-direct billing routing decision, and the dunning / involuntary-churn playbook, on a single sheet.

References

1. FASB ASC 606 — Revenue from Contracts with Customers. Financial Accounting Standards Board. Tier 1. The controlling US GAAP standard; subscription revenue is recognized over the period the service is delivered, with prepaid amounts held as deferred revenue. https://asc.fasb.org/ — accessed 2026-06-17.
2. IFRS 15 — Revenue from Contracts with Customers. IFRS Foundation / IASB. Tier 1. The international equivalent of ASC 606; same five-step model and over-time recognition for subscriptions. https://www.ifrs.org/issued-standards/list-of-standards/ifrs-15-revenue-from-contracts-with-customers/ — accessed 2026-06-17.
3. PSD2 Regulatory Technical Standards on Strong Customer Authentication (Commission Delegated Regulation (EU) 2018/389). European Commission. Tier 1. Defines SCA and the merchant-initiated-transaction exemption that applies to recurring subscription charges after the authenticated first payment. https://eur-lex.europa.eu/eli/reg_del/2018/389/oj — accessed 2026-06-17.
4. PCI DSS v4.0.1 — Payment Card Industry Data Security Standard. PCI Security Standards Council. Tier 1. The compliance boundary that direct (web) card billing brings into scope; tokenization through a provider reduces but does not remove responsibility. https://www.pcisecuritystandards.org/document_library/ — accessed 2026-06-17.
5. App Store Server Notifications V2 and Auto-Renewable Subscriptions. Apple Developer Documentation. Tier 3 (first-party). Server-to-server notifications of subscription state changes; the basis for keeping a server-side entitlement record in sync with App Store billing. https://developer.apple.com/documentation/appstoreservernotifications — accessed 2026-06-17. Vendor docs — re-check.
6. App Store Review Guidelines §3.1.3(a) — "Reader" apps; and subscription commission / Small Business Program. Apple Developer. Tier 3. Video services qualify as reader apps and may manage accounts and payment on the web; 30% year-one / 15% subsequent-year and 15% Small Business subscription rates. https://developer.apple.com/app-store/review/guidelines/ — accessed 2026-06-17. Vendor/legal policy in flux post-Epic v. Apple (US injunction, Apr 2025) — re-verify at publish.
7. Real-Time Developer Notifications (RTDN) and Play Billing subscription lifecycle. Android Developers / Google Play. Tier 3 (first-party). Pub/Sub notifications of subscription state changes; the documented pattern is to call the Play Developer API for authoritative state after each notification. https://developer.android.com/google/play/billing/rtdn-reference — accessed 2026-06-17.
8. Google Play service fees and the 2026 Epic settlement. Google Play Console Help / Epic v. Google settlement coverage. Tier 3. 15% subscription fee today; moving to 10% on subscriptions / 20% on IAP in US/UK/EEA from 30 June 2026, global rollout by 2027. https://support.google.com/googleplay/android-developer/answer/112622 — accessed 2026-06-17. Rates changing 30 Jun 2026 — re-verify at publish.
9. Involuntary churn and failed-payment benchmarks, 2025. Slicker. Tier 5. Involuntary churn ~20–40% of total churn; streaming median ~2.1%/month; up to ~9% of recurring payments fail; dunning recovery median ~47.6%, card updaters recovering up to ~20% before retry. https://www.slickerhq.com/blog/involuntary-churn-benchmarks-2025-industry-numbers-ai-recovery-impact — accessed 2026-06-17. Estimates vary by methodology.
10. Antenna — Premium SVOD churn and ARPU, State of Subscriptions (2025). Antenna. Tier 5. Premium SVOD weighted-average monthly churn ~4.6% in 2025; <2.5% as a healthy benchmark — the backdrop against which involuntary churn is recovered. https://www.antenna.live/insights/a-grown-up-streaming-market — accessed 2026-06-17.
11. Subscription proration mechanics for SaaS and streaming. Recurly / industry billing references. Tier 6. The prorate-by-days-remaining formula; the upgrade-immediately, downgrade-next-cycle convention. https://recurly.com/blog/prorated-billing-101-what-it-is-and-how-it-works/ — accessed 2026-06-17.
12. Fora Soft — Video Streaming App Monetisation in 2026 (overview blog). Fora Soft. Tier 7. Product-level companion on SVOD/AVOD/TVOD and in-app vs web billing, including the reader-app carve-out; the shorter commercial-intent counterpart this educational article links to. https://www.forasoft.com/blog/article/video-streaming-app-monetization-strategies — accessed 2026-06-17.

Where sources disagreed, the controlling standard or first-party document was followed. ASC 606, IFRS 15, the PSD2 SCA RTS, and PCI DSS are cited from the issuing bodies; Apple and Google billing behavior is cited from their own developer documentation and dated, because store commissions and rules are actively changing in 2026 (the Google Play fee cut effective 30 June 2026 and the post-Epic v. Apple US external-link rules are both flagged for re-verification). Churn, payment-failure, and recovery figures are 2025 analyst benchmarks, cited as ranges, never as universal numbers.