JustForFans Clone Script: Selling Tickets to a Live Stream

What does selling access to a live stream actually mean?

A founder who says “I want paid live streams” is usually describing one of two products that share almost nothing underneath. The first is a private session between a creator and one fan, billed by elapsed time: a metered utility. The second is an event, with one creator, one room, many paying attendees and a fixed price at the door: a box office.

This post is about the box office, because that is the one founders consistently underestimate. The metered private session is a different surface with its own billing model, covered separately in our write-up on paid calls on a fan monetization platform. If you want the commercial package rather than the engineering, the JustForFans clone hub covers scope and pricing. What follows is what only shows up in the schema: what a ticket actually is, and what it is not.

The distinction matters because a one-to-many event inverts the economics. In a metered session, revenue and cost scale with the same variable, so margin is stable. In a ticketed room, revenue scales with who bought and cost scales with who watched, for as long as they watch. Those are two different numbers, and a free viewer admitted by mistake costs money while earning nothing. So the useful questions are not about video quality but about entitlement, attribution and failure.

Which live video provider does the documentation actually name?

Worth checking rather than assuming, because it determines cost model, latency and whether recording exists at all. Across the documentation the named providers are consistent: Agora as the primary live streaming integration, Zego as the alternative or fallback, and Mux named separately for video-on-demand. The platform stack line names the Agora and Zego SDKs, the integration catalog marks Agora primary and ZegoCloud fallback, and the API notes list both as providing token and session management.

Two details are easy to misread. This is a hosted SDK integration, not a media server you operate. One architecture document does sketch a generic RTMP ingest, transcode, HLS packaging and CDN pipeline alongside a comparison of five candidate providers including Mux, Cloudflare Stream, Livepeer and AWS IVS, but that is an architecture discussion rather than a statement of what is wired up. The requirements document is specific that the system allocates the Agora or Zego token from admin settings at stream start, and central token allocation is the signature of an SDK integration.

The same comparison notes Agora offers sub-second latency but limited HLS support and recording at extra cost, while Mux and Cloudflare Stream trade several seconds of delay for native HLS. That tradeoff is a product decision. A ticketed watch-party absorbs five seconds happily and benefits from cheap HLS fan-out; an interactive paid question-and-answer room where attendees expect live reactions to chat cannot. The documented concurrency target is a thousand or more viewers per stream, attributed to the providers’ own scalability rather than to a measured result, and it should be read that way.

Who pays for the viewer minutes?

The operator does, and the documentation states it plainly. The white-label section says every integrated service uses the operator’s own credentials, then enumerates the consequence: payment revenue flows to the operator’s gateway, streaming costs are billed to the operator’s provider account, AI usage to the operator’s AI account, SMS to the operator’s messaging account. The stated intent is that the vendor is not a middle layer on provider costs.

That is a good arrangement at scale and also the most commonly missed line item in a ticketed business case. You are not buying streaming; you are buying the business logic in front of it, then opening your own provider account and carrying that bill. The cost planning section lists the live provider as an ongoing operator cost and offers a usage-based range of roughly a tenth of a cent to half a cent per viewer-minute as its own planning estimate. Treat that as the documentation’s figure and confirm current rates with the provider.

Run the arithmetic before pricing a ticket. A one-to-many event multiplies viewer-minutes by headcount while the ticket price stays fixed, so a long event with a cheap ticket is the dangerous shape. The documented net formula acknowledges this by subtracting streaming infrastructure costs, processing fees and commission from gross live revenue. One consequence for scoping: because no maximum duration is documented on the stream record, duration policy is a monetization control that lives in operator policy or in code you add.

Is a ticket a real record in the data model?

No, and this is the most important finding here, because almost every downstream surprise traces back to it. The live domain is documented as eight models: the session table, live comments, live likes, live online users, live history, video calls, audio calls and private stream requests. The entity catalog agrees and adds nothing. There is no ticket table, no ticket purchase table and no attendee entitlement table.

The session table carries twelve columns: identifier, broadcaster, title, description, thumbnail, a current viewer count, a private flag, a private price, a status, the RTMP stream key, and start and end timestamps. Note the absences. No ticket price column. No access-mode enum separating a ticketed room from a subscriber-only or free one. The only priced column is the private price, and it belongs to the invite-style booking flow governed by the separate private request table and its four-state status enum. The creator settings follow the same pattern: a toggle permitting private live streaming and a price for it, with no ticketed equivalent.

So where does a paid public ticket live? The requirements answer it in the live stream journey: for paid streams the fan pays by pay-per-view or by subscription. The API surface agrees, offering exactly one payment route for live, a pay-to-view access endpoint, and the central ledger supports a pay-per-view transaction type. A ticket is therefore a one-time purchase row in the general ledger that happened to be triggered by a stream, with the door being an entitlement check against that purchase.

That design is defensible and reuses machinery that works. It has one sharp consequence. The documented ledger carries relational columns for a related subscription, withdrawal and purchase, but no live stream column. The tip side of the same event does carry one, because tips and gifts during a stream are recorded as gift-flagged rows on the live comments table, which is keyed to the stream. Stated plainly: in the documented model the tips from an event are attributable to that event and the ticket sales are not. The table below separates what the feature list advertises from what the schema and API show, because the gap is where build time goes.

Live capability	What the feature list says	What the schema or API shows	Implication for a ticketed build
Paid public access	Included, configured as ticket or subscription	One pay-to-view endpoint; ledger supports a pay-per-view transaction type	Works, but as a purchase, not a ticket object
Ticket price per event	Ticket pricing listed as an operator control	No ticket price column on the session table; only a private price	Price source must be defined by the operator
Access mode as data	Public, paid, subscribers-only and private described as modes	Only a private boolean; no access-mode enum	Subscriber-only and ticketed modes need modeling
Per-attendee attribution	Formula multiplies ticket price by attendees	No live stream foreign key on the ledger; stream earnings stored as one decimal	Per-ticket reporting is an addition
Private one-to-one booking	Included, invite-only	Private request table with a four-state status enum, plus private price columns	The best-backed paid live path in the docs
Attendee cap	Not claimed	No capacity or maximum viewer column	Cap must be enforced in application logic
Recording and replay	Recording and stream backup listed as included	No recording table in the schema or entity catalog	Verify before promising replay access
In-room ejection	Not claimed as a live control	No eject, kick or mute endpoint in the live routes	Live moderation tooling is an addition
Tip goals during a stream	Tip goals listed as included	Only the crowdfunding campaign table carries a goal column	Confirm whether this is live-scoped at all
Multi-guest, screen share, simulcast	Listed as included or supported	No columns, enums or endpoints in the documented live surface	Treat as provider capability to confirm

None of this makes the live module weak. Chat, presence, likes, history and private booking are genuinely backed by tables and endpoints. The point is narrower: the ticketed public event is assembled from general-purpose parts rather than shipped as a dedicated subsystem, and a founder should budget for the assembly.

Does the documented earnings formula survive the schema?

The documentation states live revenue as ticket price multiplied by number of attendees, plus tips during the stream, with net arriving after streaming costs, processing fees and commission. As a description of where money comes from, that is accurate and it is the right model for pricing an event.

As a description of what the database computes, it needs qualification. The live history table records, per stream, a peak viewer count, a duration in seconds and a single earnings decimal. That is a rollup: it says what a stream made, not how it decomposes or who paid. The presence table records joins and leaves but carries no paid flag, so it tells you who was in the room, not who bought a seat. The tip half is reconstructable from gift-flagged live comments because those rows are keyed to the stream; the ticket half is not.

This matters commercially because the questions creators ask after a paid event are exactly the ones needing that decomposition: how many bought and did not show, what converted from announcement to purchase, which price point sold better. Each needs a purchase row that knows its stream. There is also a reconciliation point following from operator-owned provider accounts: door revenue sits in your ledger, delivery cost sits in your provider invoice, and nothing documented joins them.

Can a ticket be refunded, transferred, or honored if the stream never starts?

These three have one answer: not as a live-stream operation. On refunds, the capability exists at ledger level. The transaction type set includes a refund value, the status set includes a refunded state, and the admin tooling describes manual refund initiation with a reason plus dispute and chargeback management. There is no refund endpoint in the live routes, so refunding a ticket is an administrative action against a transaction, not self-service against an event. For a handful of tickets that is fine; for a cancelled event with several hundred buyers, the batch path is something to confirm or build.

On transfers there is nothing at all: no endpoint, no column, no concept of a ticket changing hands. Because the entitlement is a purchase attached to a buyer rather than a bearer token attached to a seat, transferability would be designed from scratch. If gifting or reassigning a seat matters, scope it as net new work.

The third case will actually happen to you. Documented stream statuses are offline, live, ended and cancelled. A cancelled state exists; what is not documented is what it does to people who already paid. There is no reconciliation job, no automatic reversal and no entitlement expiry against that status, and the same holds for a creator who never goes live or a room that drops and does not return. This is where ticketed differs most from metered: an interrupted metered session simply stops billing, but in a ticketed room the money has already moved, so failure is a policy question with a payment processor watching. The documentation supports the direction, listing admin-configurable refund policies with visible terms and noting that terms and refund policies are the operator’s responsibility alongside legal counsel. The mechanism for publishing a policy exists; the automation that honors it for a dead stream is yours.

Does recording or replay exist?

This needs care, because a founder will put it on a sales page and it is not cleanly backed. The feature catalog lists recording as included with the note “save stream”, lists stream backup as included, and elsewhere lists cloud recording of live streams as included. The solution overview lists recording and video-on-demand access settings among operator controls. One architecture document goes further, showing a recording service that creates a recording record, enables recording at the provider with an object storage bucket and HLS output, then finalizes and moves the asset to a CDN.

Against that, two facts. The recording model in that code sample does not appear in the schema reference’s live domain, which lists eight models and not that one, nor in the entity catalog. And the same document’s provider comparison marks recording as an extra cost on Agora with limited HLS support, while listing it as included on Mux and optional on Cloudflare Stream. The honest reading: recording is a provider capability the architecture anticipates and the primary provider charges separately for, illustrated by sample code rather than evidenced by a documented table or endpoint.

Practically: confirm recording against the build you are buying rather than the feature list, expect to pay the provider for it, and recognize that a recording introduces a second entitlement question the ticket model does not answer. Does a ticket buy the live room, or the room plus the replay, and can someone who did not attend buy the replay afterwards? That is a separate access check.

Are attendee caps, in-room moderation and ejection documented?

Attendee caps: no. There is no capacity, maximum viewer or viewer limit column anywhere in the documented live surface. The session table holds a current viewer count, which is a counter rather than a ceiling. If your product needs a limited-capacity room, whether for scarcity pricing or predictable provider spend, that ceiling is application logic enforced at the pay-to-view gate.

In-room moderation and ejection: also no. The documented moderation is substantial but administrative and after the fact: an admin queue spanning posts, comments, replies, messages, reels and stories, with live stream moderation named among admin review surfaces, plus automated image and video moderation through a third-party service with a signed callback. What does not exist in the live routes is any endpoint to remove a viewer, mute a participant or ban someone for a stream’s duration. The live routes touching viewers are a creator-only viewer list and a creator-only statistics read; chat comment deletion sits in the general comment routes under an owner or moderated scope.

For a live event that is a real gap, because live is the one surface where a problem must be handled in seconds rather than reviewed in a queue. Ending the stream is documented as an owner-only delete, but that is a blunt instrument when several hundred people paid to be in the room. If you will run ticketed events with strangers present, in-room moderation belongs in build scope, and it should be scoped alongside the refund policy, because ejecting a paying attendee is a refund decision.

The pre-sale gate, by contrast, is well backed and underused. Country blocking is a real column on the user record with a settings endpoint behind it, applied per creator and platform-wide, and the API guidance explicitly instructs clients to respect privacy and geoblocking when showing streams and paid content. Age and identity verification run through named third-party providers with a verification callback, and verification status gates creator workflows. For an adult-adjacent ticketed event, controlling who can reach the purchase is more effective than controlling the room afterwards, and it is the part the platform actually models. The policy and legal obligations on top of those controls remain the operator’s, with their own counsel.

Which endpoints does a ticketed stream actually run on?

The live and calls section of the API collection is compact, and reading it calibrates expectations fast. For streams it provides a list of active streams, a create restricted to verified creators, lookups by identifier and by username, a metadata read, a details read, an owner-only end, a comment post, a like post, a creator-only viewer list, a creator-only statistics read, and a single pay-to-view access post. For scheduled events it provides an event create, an event list and a start, all creator-scoped.

Three observations matter. Scheduling exists as a first-class flow with its own routes, which is genuinely useful for a box office because an announced event is what people buy against. The entire monetization funnels through one payment route, so the pay-to-view handler is the single place where price, entitlement, capacity, geographic eligibility and verification all have to be enforced, which is convenient to secure and easy to under-implement. And there are two parallel route families for live, a primary set and a second documented as an alternate create and alternate CRUD. The platform’s own residual risk register names legacy route aliases as a medium risk, with the mitigation to inventory, document and test aliases for the same authorization posture. Take that seriously on a paid surface: two doors into the same room are two places to enforce the same check, and the second is the one that gets forgotten.

Read the security posture precisely. Rate limiting appears as guidance, presented as a suggested throttle posture by endpoint class and a table of recommended controls per flow, with incomplete rate limiting listed as a medium residual risk. Two-factor authentication is listed as supported, with a column on the user record and external providers for the SMS path. Login attempt logging and a financial audit log are listed as included features. The distinction for a build plan is that some of these are shipped behaviors and others are hardening recommendations the operator implements, and a payment endpoint for a ticketed event is exactly the kind of flow the documentation recommends throttling rather than one it certifies as throttled.

What does an operator configure before selling the first ticket?

The pre-launch list is mostly accounts and policy rather than code, which is the good news. Accounts first: a real-time provider account with Agora or Zego, billed to you, with token credentials in the platform’s central settings record, since the requirements describe token allocation from admin settings at stream start. Then a payment gateway from the documented set, with revenue flowing to your account. Then the verification providers, because verification status gates creator workflows.

Then the controls that already exist and should be set deliberately: country blocking at creator level and platform-wide, the platform fee percentage in global settings with any per-creator override, moderation thresholds and the automated moderation toggle, and a published refund policy with visible terms. Those are configuration, not development.

What remains is the real build work this post has identified: a ticket price source for public events, an access-mode distinction if you want more than private versus not, a stream reference on the purchase so attendance and revenue reconcile, a capacity ceiling enforced at the payment gate, a failure rule that honors or reverses entitlements when a stream is cancelled or never starts, in-room moderation if strangers will be present, and a decision about whether a ticket includes a replay. That is a focused list, and it is one you can only write after reading the schema.

Founder Decision Signals

Your creators already draw a crowd at a time. Ticketed events monetize simultaneity. If audiences consume on their own schedule, a scheduled room converts badly and a catalog or subscription will outperform it.

Your price clears delivery cost with room to spare. Because the operator carries the viewer-minute bill, a cheap ticket to a long event is the one shape that can lose money at scale. Shorten the event, raise the price, or reconsider the surface.

You can answer the cancellation question today. If you cannot state in one sentence what happens to four hundred buyers when a creator does not show, you are not ready to sell tickets. This is the question the documentation leaves to you and the one that generates chargebacks.

You need per-event reporting from day one. If creator trust depends on showing who bought and what an event earned, budget the stream reference on the purchase as initial build rather than a later report. Retrofitting attribution onto historical transactions is unpleasant.

Private bookings may be the faster start. The private request flow is the best-backed paid live path in the documentation, with its own table, status enum and price columns. If your creators prefer intimacy to audience, that path needs less assembly. It is a different product with different billing, worth considering before defaulting to events.

Common Ticketed Live Stream Mistakes to Avoid

Reading a feature list as a data model. A row saying recording, tip goals or multi-guest is included tells you the capability is anticipated, not that a table, column or endpoint exists. For anything a fan pays for, verify against the schema and API collection.

Assuming the ticket is an object. Teams design ticket lists, transfers, seat counts and ticket-level refunds assuming a ticket record exists. In the documented model it does not. Design against that, or add the object deliberately.

Forgetting the second route family. Two documented paths into live creation means two places the paid entitlement check must hold. The platform’s own risk register flags legacy route aliases for this reason. Test both, or retire one.

Treating the provider bill as a rounding error. It is the one cost that grows with success here, and it lands on the operator’s account. Model it per event at your real headcount and duration before setting a price.

Launching without a dead-stream policy. The status enum has a cancelled value and no documented consequence for buyers. Write the rule, publish it on the event page, automate the simple case. Processors judge you on dispute rate, not intent.

Relying on post-hoc moderation for a live room. An admin queue is right for uploaded content and wrong for a room that is live now. Scope the in-room control, and decide whether ejection triggers a refund.

Promising a replay you have not confirmed. Replay is a separate entitlement from live access, and recording is a provider feature with its own cost. Implying a recording before confirming one exists is a support burden you create on purpose.

How a Ready-Made Foundation Fits a Ticketed Live Stream Build

Everything above argues for a particular starting point, not against starting from one. The genuinely hard parts of a ticketed live product are not the parts missing from the documentation. Identity and verification, a central ledger with an auditable transaction type set, a gateway abstraction with signed webhooks and idempotency discipline, creator payouts, subscription billing, geographic blocking, automated moderation with a callback, chat and presence, an admin control plane with configurable fees, and a working integration against a named real-time provider. That is years of work and it already exists.

What this post has mapped is a short, knowable delta on top: a ticket price source, an access-mode distinction, a stream reference on the purchase, a capacity ceiling at the payment gate, a failure rule for dead streams, in-room moderation, and a replay entitlement decision. Seven items, each nameable before a line of code is written. That is a very different project from building a creator platform, and it is the shape a ready-made foundation should produce: the generic ninety percent inherited, the opinionated ten percent built on purpose.

Miracuves works on exactly this basis. We start from the documented platform, read the schema with you rather than reciting a feature list, and scope the delta as named work with the absences stated plainly, including the ones above. Where a capability is a third-party account you open and pay for, we say so. Where something appears in a feature list without a table behind it, we say that too, because a founder who discovers it after launch has a worse problem than one who budgeted for it. Our broader work across the creator economy and our influencer platform solutions follows the same approach.

The compliance and policy obligations stay with you throughout, as they must. Which jurisdictions you sell events into, what your terms and refund policy say, how age verification is applied, and how you respond to a takedown are operator decisions taken with your own legal counsel. The platform provides controls, not a substitute for the judgment about how to use them.

Final Thoughts

Ticketed live streaming looks like the simplest monetization surface on a creator platform and is quietly one of the most demanding, because it is the only one where money moves before value is delivered and where cost scales with an audience you do not control. The video itself is solved, handled by a named third party on your account. The hard parts are the entitlement record, the attribution back to the event, and the rule for when the event does not happen.

The documentation behind a JustForFans clone script supports a ticketed room honestly, through a pay-to-view purchase against a central ledger, with real scheduling, real chat and presence, and a well-modeled private booking alternative. It does not model a ticket as an object, attribute a purchase to a stream, cap a room, document a refund or transfer at event level, or provide in-room moderation. Those are the seven decisions, and knowing them in advance turns an open-ended build into a bounded one.

If you are planning a ticketed live product, read the schema before the feature list, price the event against the provider bill rather than the ticket alone, and write the cancellation policy on day one. Then build the seven things. That is the whole job, and it is a good deal smaller than it looks from the outside.

FAQs

<!– wp:rank-math/faq-block {"questions":[{"id":"faq-question-17613401","title":"Which live video provider does a ticketed live stream actually use?","content":"

The documentation names Agora as the primary live streaming integration and Zego as the alternative or fallback, with Mux listed separately for video-on-demand. The platform stack, the integration catalog and the API notes agree, and the requirements describe the system allocating an Agora or Zego token from central admin settings at stream start. One architecture document also compares five candidate providers including Mux, Cloudflare Stream, Livepeer and AWS IVS, but that is an architecture discussion rather than what is wired up. Confirm the provider against your specific build, because latency, HLS support and recording cost differ sharply between them.

“,”visible”:true},{“id”:”faq-question-17613402″,”title”:”Does the operator pay for viewer minutes on a paid live stream?”,”content”:”

Yes. The documentation states that every integrated service uses the operator’s own credentials, and specifically that streaming costs are billed to the operator’s provider account. You open your own Agora or Zego account and carry that bill. The cost planning section lists the live provider as an ongoing operator cost and offers a usage-based range of roughly a tenth of a cent to half a cent per viewer-minute as its own planning estimate; treat that as the documentation’s figure and confirm current rates with the provider. This matters most for one-to-many events, because cost scales with headcount and duration while the ticket price stays fixed.

“,”visible”:true},{“id”:”faq-question-17613403″,”title”:”Is a live stream ticket stored as its own record in the database?”,”content”:”

No. The documented live domain contains eight models covering the session, comments, likes, online users, history, video calls, audio calls and private stream requests. There is no ticket table, no ticket purchase table and no attendee entitlement table. The session record carries twelve columns and none is a ticket price or an access-mode enum; the only priced column is a private price belonging to the invite-style booking flow. Paid public access runs through a single pay-to-view endpoint and is recorded as a one-time purchase in the central ledger, which supports a pay-per-view transaction type.

“,”visible”:true},{“id”:”faq-question-17613404″,”title”:”Can a fan get a refund if a paid live stream never starts?”,”content”:”

Not automatically, and this is the gap most worth planning around. The stream status values include a cancelled state, but no reconciliation job, automatic reversal or entitlement expiry is documented against it. Refunds exist at ledger level: the transaction type set includes a refund value, the status set includes a refunded state, and admin tooling supports manual refund initiation with a reason plus dispute and chargeback management. There is no refund endpoint in the live routes, so a ticket refund is an administrative action against a transaction. Publish a policy for cancelled and never-started events before launch, and automate at least the simple case.

“,”visible”:true},{“id”:”faq-question-17613405″,”title”:”Are live stream tickets transferable between fans?”,”content”:”

No. There is no transfer endpoint, no transfer column and no concept of a ticket changing hands anywhere in the documentation. Because the entitlement is a purchase attached to a specific buyer rather than a bearer token attached to a seat, transferability would have to be designed and built from scratch. If gifting a ticket or reassigning a seat is part of your product, scope it as net new work rather than assuming it comes with the platform.

“,”visible”:true},{“id”:”faq-question-17613406″,”title”:”Does a paid live stream get recorded for replay?”,”content”:”

Treat this as unconfirmed until you verify it against your build. The feature catalog lists recording, cloud recording and stream backup as included, and the solution overview lists recording and video-on-demand settings among operator controls. However, the recording model shown in one architecture document’s sample code does not appear in the schema reference’s live domain or in the entity catalog, and that document’s own provider comparison marks recording as an extra cost on the primary provider. Replay is also a separate entitlement: decide explicitly whether a ticket buys the live room only or the room plus the recording, and whether non-attendees can buy the replay afterwards.

“,”visible”:true},{“id”:”faq-question-17613407″,”title”:”Can a creator cap attendance or eject someone from a live room?”,”content”:”

Neither is documented. There is no capacity, maximum viewer or viewer limit column on the live stream record; the viewer count present is a counter, not a ceiling, so a cap must be enforced in application logic at the payment gate. The documented moderation is administrative and after the fact: an admin queue spanning posts, comments, messages, reels, stories and reported live streams, plus automated image and video moderation through a third-party service. The live routes offer a creator-only viewer list, a creator-only statistics read and an owner-only end-stream, but no eject, mute or ban action. In-room moderation is build scope, and ejecting a paying attendee is also a refund decision.

“,”visible”:true},{“id”:”faq-question-17613408″,”title”:”What does it cost to add ticketed live streams to a creator platform build?”,”content”:”

Scope it as the delta rather than the platform. The foundation that already exists includes identity and verification, the financial ledger, gateway abstraction, payouts, subscriptions, geographic blocking, automated moderation, chat and presence, an admin control plane, and a working real-time provider integration. The ticketed delta identified from the documentation is seven named items: a ticket price source, an access-mode distinction, a stream reference on the purchase for attribution, a capacity ceiling at the payment gate, a failure rule for cancelled or never-started streams, in-room moderation, and a replay entitlement decision. Miracuves scopes that delta explicitly, with third-party accounts and documentation gaps named up front. Share your event shape, expected headcount and price point and we will size it.

“,”visible”:true}]} –>