Quick answer
Choose the primary pricing model that matches the value event: subscriptions or tiered memberships for continuing access, pay-per-view or bundles for defined purchases, and tips for voluntary support. This approach fits platforms with a clear audience promise and operable access, payout, and reversal rules; it does not fit offers that rely on viral spikes or models whose entitlements and financial states remain ambiguous. Treat commissions as platform revenue and free trials as acquisition mechanics, not core audience purchases. First, select one primary model, permit at most one secondary model with a separate job, and document the assumptions and operational states before scoping the build.
Which pricing architecture matches what the audience is actually buying?
Choose the architecture whose charge occurs at the same moment as the promised value. Ongoing availability points to a recurring mechanism; a self-contained deliverable or experience points to a one-time purchase; support given without required access points to a tip. For this decision, treat commission as the platform’s way of earning from an underlying transaction and a free trial as an entry route into an already-defined paid offer. Neither answers what the audience is buying. Read the matrix as seven proposed designs: every cell must agree with the offer’s promise, and any blank or contradictory cell is a reason to narrow the release rather than improvise policy after launch. A secondary mechanism earns a place only if its purpose is separate enough to explain in one sentence.
Test that rule against a hypothetical offer: a creator promises members a continuing library plus regular access to new analysis, while occasionally selling a standalone live workshop. The recurring promise makes subscription the primary candidate. Pay-per-view could remain as the sole secondary candidate because the workshop is separately described and purchased; it should not quietly become a subscriber benefit as well. Now apply the ordinary-month test. If the subscription still presents a coherent exchange when no workshop, launch spike, or exceptional promotion occurs, it can support the base architecture. If it needs those events to appear viable, then it has not passed as the primary offer. A trial may later test entry into the subscription, and commission may monetize completed purchases, but adding either does not repair an unclear core promise.
| Candidate | Best-matched value event | Purchase trigger and cadence | Entitlement duration | Intended metric hypothesis | Distinct role and first-release decision points |
|---|---|---|---|---|---|
| Subscription | Continuing access to content, community, expertise, or recurring service | Audience starts a recurring payment; price is normally presented per billing interval | While the subscription remains in an entitled state, subject to defined cancellation, failure, and expiry rules | Test paid conversion, recurring gross ARPU, renewal, and cohort retention | Primary candidate when value recurs predictably. Define renewal, grace-period, cancellation, refund, access, ledger, and payout behavior. Exclude if ordinary monthly value is unclear or entitlement states cannot be operated. |
| Tiered membership | Continuing access with meaningfully different benefit levels | Audience selects a recurring level based on access or service differences | While the selected tier remains entitled; upgrades and downgrades require explicit effective-date rules | Test tier mix, upgrade rate, recurring gross ARPU, and retention by tier | Primary candidate only when tiers represent distinct value rather than cosmetic price anchors. Defer if benefit boundaries, migrations, proration, creator allocation, or support explanations are unresolved. |
| Pay-per-view | A defined item, session, message, stream, download, or experience | Audience pays once when it wants the specified item or interaction | Permanent, time-limited, consumption-based, or event-bound as explicitly configured | Test buyer conversion, order value, purchase frequency, and transactional gross ARPU | Primary candidate for discrete value events; possible secondary mechanism alongside recurring access when it sells a clearly separate premium event. Define fulfilment, expiry, replay, cancellation, and refund effects. |
| Bundle | A defined collection whose combined purchase is the value | Audience makes a one-time purchase of multiple specified items or access rights | Determined by the component rules or one explicit bundle-level term | Test bundle conversion, average order value, attach rate, and component substitution | Primary candidate for curated collections or secondary merchandising. Defer when component entitlements, partial refunds, creator splits, ownership changes, or overlap with subscriptions cannot be explained consistently. |
| Tip | Voluntary support not required to receive the core entitlement | Audience chooses an amount at a moment of appreciation or interaction; normally transactional | No additional access unless a separate, explicit benefit is attached | Test tip participation, average tip, repeat tipping, and creator earnings contribution | Primary candidate only when voluntary support is itself the audience behavior. More often a secondary mechanism. Keep it distinct from purchases, donations, paid messages, and promised access. |
| Commission | Platform participation in creator transaction value | A configured share is calculated when an eligible transaction reaches a defined state | Not an audience entitlement; it follows the qualifying financial record and adjustment policy | Test platform revenue, effective take rate, creator net earnings, and contribution after modeled costs | Platform monetization layer, not the audience’s core purchase. Define the transaction-value base, exclusions, rounding, refunds, disputes, taxes, fees, payout timing, and creator reporting before implementation. |
| Free trial | Temporary acquisition path into a paid recurring offer | An eligible audience member starts limited free access before conversion or expiry | For the configured trial period, with explicit start, end, conversion, cancellation, and reuse rules | Test trial start, trial-to-paid conversion, early retention, and acquisition quality | Acquisition mechanic, not a standalone pricing model. Use only when the paid offer is already clear. Defer if eligibility, payment authorization, reminders, abuse controls, conversion timing, or post-trial access are undefined. |
For the first release, exclude tiered membership, bundles, and tips from this hypothetical design. More levels would introduce benefit-boundary and change-of-level decisions before a single recurring offer is proven; bundles would require a consistent account of overlapping rights and adjustments; tips would add another payment meaning without strengthening the chosen promise. Also defer the workshop if its access period, refund treatment, financial adjustments, creator earnings, or customer explanation cannot be stated without contradiction. This is a scope rule, not a claim that the excluded candidates perform poorly: niche results, substitution between offers, and the best combination remain unknown. Choose one primary mechanism, at most one non-overlapping secondary mechanism, and any acquisition mechanic; defer the rest.
Which assumptions must be fixed before the economics can be compared?
Make the model testable by fixing its boundaries before entering values: one analysis period, one eligible-audience definition, one active-user denominator, the transaction states included, and the deductions applied. For this decision, treat any change to those boundaries as a new scenario, not an innocent spreadsheet edit. Create a metric dictionary for the worksheet: GMV is the stated value of included transactions before the listed deductions; gross ARPU is that GMV divided by the defined active-user population; platform revenue is the modeled fees and commissions assigned to the platform; creator earnings are the modeled amount assigned to creators after specified deductions; take rate is modeled commission revenue divided by its stated transaction-value base; and simple period retention is the beginning cohort less defined customer losses, divided by that same beginning cohort. These are working definitions, not accounting conclusions.
Label every conversion, price, purchase-frequency, loss, fee, and take-rate input either “internal data” or “assumption,” with an owner and date. Then keep recurring and transactional mechanics on separate lines. In a hypothetical case, paid customers equal eligible audience multiplied by assumed conversion; recurring GMV equals active subscribers multiplied by assumed recurring price; transactional GMV equals buyers multiplied by assumed orders per buyer and assumed order value; and modeled commission revenue equals the declared transaction-value base multiplied by assumed take rate. Model total monthly cost separately as the monthly fee, plus revenue-based transaction fees, plus transaction-count-based flat fees, plus payment-processing fees. This separation makes the economic question legible: if a result moves, the team can see whether the change came from audience qualification, customer behavior, price, transaction volume, or deductions.
Compare low, base, and high cases rather than presenting a forecast. Hold the period, denominators, transaction states, and deduction rules constant, then vary one material assumption at a time—for example, conversion—while leaving the other inputs unchanged. Read the spread as sensitivity: if the architecture works only under the high case, then its economics remain conditional on that input; if all three cases use different definitions, the comparison says little beyond proving that spreadsheets are highly cooperative. No supplied material establishes an industry benchmark or authoritative accounting treatment, so refund timing, taxes, processor charges, payout timing, and revenue recognition need approved definitions before the output is used beyond this decision test. Complete the metric dictionary and assumption register, including period, denominator, transaction states, deductions, source, and low, base, and high value for every input.
What must happen from payment attempt through access, payout, and reversal?
Walk one customer’s purchase of the selected offer from the checkout attempt to its final creator and customer outcomes. At attempt, payments owns the trigger and stores an order plus a provider reference; the customer sees “processing,” the creator sees no earnings, and support waits for a terminal event. A decline stores a failed attempt, grants nothing, creates no balance entries, and gives support a retry-or-alternate-payment decision. Mark this branch provider-dependent. On confirmation, billing stores an immutable successful transaction and the event identifier. The customer sees completion, while the creator sees a pending sale. A delayed confirmation must remain processing until the same identifier arrives; a repeated event must return the existing result rather than create a second purchase. Treat idempotent event handling as supported only if that behavior has been demonstrated; otherwise mark it to be built.
After confirmation, access owns the entitlement record, finance owns paired creator-balance and platform-share entries, and the customer receives the purchased access. The creator sees the sale, deductions defined for this model, and the amount not yet available for payout; support compares the transaction, entitlement, and ledger references before changing anything. If this is a recurring offer, renewal repeats the attempt under a new billing-period record, while cancellation stops the next attempt without silently removing already-paid access; an unpaid renewal or configured expiry ends access at the recorded boundary. Mark renewal and cancellation according to demonstrated behavior, expiry rules as to be built until encoded, and any unselected charge type as excluded. The first incomplete state is the earliest missing record or customer-visible change—for example, a successful transaction with no matching entitlement. Test that transition directly; do not guess why it failed or repair downstream records by hand.
A refund or dispute creates a reversal linked to the original transaction, adjusts access under the approved policy, posts offsetting creator and platform entries, and shows the customer the resulting status. The creator sees the reversal and its effect on available or future balance. If payout has already occurred, finance records the adjustment against the defined subsequent-settlement treatment; support does not invent a balance correction. When access and ledger records disagree, freeze further automated movement for that purchase, identify the first absent or contradictory transition, and reconcile from stored references. Label refund timing and dispute outcomes provider-dependent until verified, post-payout adjustments to be built until finance can demonstrate them, and unexplained manual rescue as a release blocker. This is an implementation-scope test, not legal, tax, KYC, KYB, AML, or accounting advice; provider behavior, regional availability, and jurisdictional requirements require current first-party verification. Approve the walkthrough only when product, engineering, support, and finance can explain every customer, creator, balance, and reversal outcome.
What should the team specify before billing implementation begins?
Build a versioned pre-build specification for the selected endpoint before writing production logic. For the running scenario, represent the chosen offer as `offer_creator_access_v1`, priced in a named currency on the approved cadence, with explicit purchase qualification and precise rules for when access becomes visible and ceases to be valid. Add the acquisition configuration, the creator and platform allocation logic, the allowed lifecycle labels, named emitted events, required analytical attributes, responsible parties, exclusions, verification markers, approval tests, and executable fixtures. This document becomes the shared implementation reference for billing, access control, creator reporting, financial records, analytics, support tools, and launch measurement.
For each allowed lifecycle label, create one fixture that starts from stored input and ends in an assertion. A successful-payment fixture, for example, should state what the customer can see, what appears in the creator view, which financial entries must exist, which measurement signal is emitted, who investigates a mismatch, and what makes the test pass. Apply the same structure to every other accepted label, including any reversal-related label the release permits. Keep three columns of truth: approved product behaviour, proposed setup awaiting approval, and behaviour dependent on a provider. If an expected result cannot be placed in one of those columns, it is not ready to become code—ambiguity is not a particularly useful runtime dependency manager. Use this guide’s test: the first missing expected output is the implementation boundary, and the fixture should fail there without guessing why.
- Decision header: record a specification version, owner, review date, selected primary mechanism, permitted secondary mechanism, acquisition mechanic, excluded models, ordinary-month rationale, and unresolved provider dependencies.
- Offer definition: assign an immutable offer identifier; display name; creator or catalog scope; amount and currency; billing interval or one-time flag; eligibility rules; purchase limits; price-presentation rules; and supported regions or a
- Access contract: define access start, end, renewal, expiry, cancellation, upgrade, downgrade, grace-period, refund, dispute, and revocation behavior, including which system is authoritative when billing and access disagree.
- Acquisition settings: specify trial or promotional eligibility, duration, authorization requirement, conversion timing, reminders, cancellation behavior, reuse restrictions, analytics properties, and abuse-handling owner; mark unused fields
- Allocation rules: define the transaction-value base, creator allocation, platform allocation, rounding, deductions, adjustment order, negative-balance policy, payout effect, and creator-visible explanation. Flag tax, fee, and accounting
- Metric dictionary: use one period and define eligible audience, active user, buyer, paid customer, GMV, gross ARPU, platform revenue, creator earnings, take rate, retention, included transaction states, excluded states, and deduction policy
- Assumption register: label every conversion, price, purchase frequency, loss rate, fee, and take rate as internal data or assumption; record its source, period, denominator, low/base/high values, and approval owner. Compare scenarios, not
- Scenario formulas: calculate paid customers as eligible audience × assumed conversion; recurring GMV as active subscribers × assumed recurring price; transactional GMV as buyers × assumed orders per buyer × assumed order value; modeled
- State map: trace attempt, pending or delayed confirmation, success, failure, access grant, creator-balance entry, platform-share entry, renewal or expiry, cancellation, refund or dispute, access adjustment, balance adjustment, payout effect
- Transition ownership: for every state change, record the trigger, owning team or service, stored record, idempotency key, customer-visible result, creator-visible result, support decision, reconciliation treatment, and provider-verification
- Status and event contract: enumerate accepted status values and event names; specify valid transitions, event ordering expectations, duplicate handling, retry behavior, analytics properties, timestamps, correlation identifiers, and the
- Failure fixtures: test a declined attempt, delayed confirmation, duplicate event, interrupted fulfilment, cancellation before renewal, refund before payout, refund after payout, dispute, failed renewal, expired access, rounding difference,
The platform description supplied for Scrile Connect supports using the specification across subscriptions, tips, pay-per-view offers, private interactions, tailored payment paths, payout administration, analytics, and branded presentation. It does not establish tier structures, packaged offers, introductory free periods, allocation-engine details, reversal handling, provider charges, or geographic availability. Mark any reliance on those items as unverified until the relevant party confirms it, and keep it outside the approved build when confirmation is absent. Finance should approve monetary outputs, product should approve customer and creator presentation, engineering should approve state handling and testability, analytics should approve measurement fields, and support should approve the diagnostic information it will receive. Publish this specification as the first build artifact, and block implementation of every field or behaviour that lacks an owner, an acceptance criterion, or a verification status.
Frequently asked questions
What happens to existing customers when the offer’s price or terms change?
Treat the revised offer as a new version. Decide whether existing customers retain their current terms, move only after explicit acceptance, or lose eligibility at a defined endpoint. Record the applicable version for each purchase so access, charges, support, and reporting remain consistent.
How should complimentary or manually granted access be handled?
Represent it as a separate entitlement rather than a successful payment. Require a reason, authorizing owner, scope, and expiration rule, and exclude it from paid-user economics unless the analysis explicitly includes it.
What should happen if a creator leaves while customers still have valid access?
Choose the customer obligation before the offer launches. The platform must either preserve access through the promised endpoint, provide a defined replacement outcome, or prevent sales whose obligations cannot survive the creator’s departure. Creator offboarding should not silently erase customer rights or unsettled balances.
Builds SaaS platforms for content creators, agencies, and entrepreneurs. Writes about the business mechanics behind creator-economy products and how custom software actually ships.