Paid video access

Video monetisation is an access problem before it is a payment problem

Taking the payment is the part your business already knows how to do. The part that breaks is everything afterwards: which viewer may now play which video, what happens when they stop paying, and whether the file itself is still downloadable by anyone who finds the URL.

Start free trialSee the API reference

Payment there, playback rights here

  • Paid video stops being a public file

    Encrypted on-demand delivery with playback keys restricted to the domains you allow.

  • Access follows your customer record

    Create members and attach plans from your own system when a payment succeeds.

  • One API, not a second product

    Members, plans, access and reporting are all addressable from your backend.

  • See what people paid for and watched

    Retention and completion per video, attributable to your own identifiers.

The control problem

Charging for video is easy. Revoking access is not

Most paid-video projects come apart at the same two points: a link that keeps working after the subscription lapses, and a file that was never protected in the first place.

Without control

Access by good intentions

A private page, an unlisted link, a member-only area whose protection stops at the page rather than the video.

  • The video URL works for anyone who has it, member or not
  • A cancelled customer keeps the link they were given
  • The embed plays anywhere it is pasted
  • No way to tell which account shared it

On your own terms

Access by decision

Playback depends on a key, the key depends on a rule, and the rule follows the member record your own system maintains.

  • Segments are encrypted, so a direct fetch returns ciphertext
  • Key requests follow the allowed-origin rules you configure
  • Links can expire and can be limited by view count
  • Member and plan state is changed by your backend when billing changes

Step one

Choose the access model inside your own product

Choose the commercial model that fits your product, then express each purchase or membership as clear access rules.

  1. 01

    Ongoing membership

    A member keeps access to a library while your own billing says they are current. Your system attaches a plan on payment and detaches it when payment stops.

  2. 02

    One-off purchase

    A viewer buys a single title or course. Your system grants that member access to the specific videos or channel they bought.

  3. 03

    Time-boxed access

    Access is granted for a defined window. Signed links carry an expiry, so the grant ends without anyone remembering to revoke it.

  4. 04

    Internal entitlement

    No money involved — a licence, a cohort or an employment record decides access. The mechanism is identical.

Step two

The membership and access primitives DynTube actually provides

Build the paid-viewing workflow from these verified membership, access, delivery and reporting capabilities.

MembersPer account
Create a member record that corresponds to a person in your own system, and read their current state and activity.
PlansPer account
Define plans that describe what a member may watch, and read the plans attached to a member.
Attach and detachPer member
Attach a plan to a member when your billing says they are entitled, and manage the lifecycle when that changes.
Encrypted deliveryOn-demand video
Paid video is delivered AES-128 encrypted with a key requested per playback, so the file is not simply downloadable from its URL.
Domain restrictions and signed linksPer project and per request
Playback keys follow the allowed-origin list you configure — an empty list or the account-level key exemption leaves them unrestricted — and links can be signed, time-limited and view-limited.

Step three

Connect your own billing through the API

The integration is short because the responsibilities are clean: your system owns the money, DynTube owns the access decision.

  1. 01

    Take the payment in your own product

    Your checkout, your payment provider, your customer record. Nothing about this step involves DynTube.

  2. 02

    Create or find the member

    On a successful payment, your backend creates a DynTube member for that person, or looks up the one it created earlier.

  3. 03

    Attach the plan that matches what they bought

    One API call. From that point the member may play what the plan allows, and nothing else.

  4. 04

    React when billing changes

    On cancellation, failure or refund, your backend manages the plan lifecycle for that member. Access follows your billing rather than drifting away from it.

  5. 05

    Authorise playback per request

    Issue a signed playback token from your server for the member in session, so a URL copied out of the page does not keep working elsewhere.

Step four

Protect and measure the video you charge for

Paid video attracts two questions the free kind does not: is it leaking, and is it worth what people paid.

Per-viewer watermarkingAvailability depends on your plan
Overlay identifying information on playback so a captured copy points back to the account that made it. Confirm current inclusions before relying on it.
DRM licence controlAvailability depends on your plan
For content valuable enough to need a device-level decision about whether playback may proceed.
Engagement reportingPer video
Retention and completion, unique viewers, geography and devices — so you can see which paid title held attention and which lost it.
Your own identifiersOptional
Pass your member identifier with a view and engagement is attributed to that member. Without one, viewers stay anonymous to us.

Questions

Questions about monetising video

Does DynTube take the payment?

No. DynTube does not operate a checkout, does not bill your viewers and does not run recurring billing. You take payment in your own product with your own provider, then tell DynTube who is entitled to access.

Is there a DynTube storefront or membership website?

No. DynTube provides video hosting, delivery, the player, channels, member and plan management, and an API. The website your customers buy from is yours to build and own.

Which payment processors work with this?

The integration is a call from your backend to the DynTube API after a payment succeeds, so it does not depend on a particular processor. We do not publish a compatibility list, and we will not claim a specific processor is supported without evidence — the integration code is yours.

What happens when someone stops paying?

Your system manages that member’s plan lifecycle through the API, so access ends when your billing says it should. Nothing expires automatically on our side, because only your system knows the payment state.

Can a paying member still copy the video?

Someone watching a video they are entitled to watch can record their own screen. Encryption and domain restrictions remove the easy routes; watermarking, where your plan includes it, makes a captured copy attributable. None of it is prevention, and we will not describe it that way.

Sell the access, keep the product

Your checkout and your customer record stay where they are. DynTube decides who may play what, and keeps the file itself out of reach.

Start free trialTalk to us about the integration