Creator Platform / Revenue Share
Status: partly available. Subscriber-side billing (plans, products, prices, subscriptions, refunds, credit notes, FX) is available through the public API. Automatic revenue-share settlements on subscription revenue (Settlements) and cron-style payout runs (Recurring Schedules) are not part of the public API; this page shows how to attribute and report creator revenue with what exists, and where the marketplace payout flow fits.
The creator economy pricing pattern: subscribers pay the platform a monthly fee for access to a creator's content; the platform retains a percentage as its commission and any payment-processing costs; the remainder is paid out to the creator on a fixed cadence. Each creator runs their own pricing tiers; each subscriber subscribes individually to a creator. The platform's relationship is two-sided - it's customer-facing on subscriber subscriptions and partner-facing on creator payouts.
Real-world examples. Substack (creators set tier prices, Stripe processes, platform takes 10%, pays out monthly), Patreon (multiple tiers per creator, platform takes 5-12% depending on plan, pays out monthly), Twitch (subscriber tiers, Twitch takes 50%, monthly payouts), OnlyFans (creator-set prices, platform takes 20%, weekly payouts), Buy Me a Coffee, Ko-fi. Common shape: creator defines 1-3 subscription tiers at price points they pick; subscribers subscribe individually; platform commission ranges 5-50% depending on the platform; payout is monthly via direct deposit or PayPal.
The shape of the problem
Creator platforms are marketplaces with extra characteristics:
- Per-creator pricing tiers. Each creator defines their own price points. The platform doesn't dictate pricing - it just collects.
- Subscriber-creator subscriptions, not subscriber-platform. A subscriber on Patreon supporting 3 creators has 3 separate subscriptions. Each with its own price, billing cycle, lifecycle.
- Net-of-cost commission math. Most creator platforms quote commission as net of payment processing - "we keep 10%, but Stripe also takes 2.9% + 30c per charge." The payout has to net both correctly.
- Tax complications. When a US-based platform pays out to an EU-based creator, tax withholding rules apply. When the creator is the merchant of record vs the platform is, VAT treatment differs. This is a real operational concern, not a theoretical one.
- Cancellation flow asymmetry. A subscriber cancelling means: the creator still keeps what they earned through the cancellation date; platform commission is final on those past charges. There's no "claw back paid commissions on cancellation."
- Refund policy. Some platforms allow refunds on the latest month's charge; the corresponding commission gets clawed back from the creator's next payout.
Kontier blueprint
| Concern | Kontier primitive |
|---|---|
| Per-creator tiers | One plan per creator and cadence, one product per tier |
| Subscriber-creator subscriptions | Standard subscriptions whose line is drawn from the creator's plan; the creator is the subscription's plan_id |
| Revenue attribution | GET /v1/subscriptions?plan_id=… and GET /v1/invoices?subscription_id=…&status=paid per creator |
| Tier upgrades and downgrades | Cut the live revision, write the draft with a new phase on the new tier's product, publish |
| Refund clawback | POST /v1/invoices/{id}/refund writes a credit note; deduct it from the creator's next payout |
| Platform commission and creator payout statements | Not available through the public API (Settlements). Compute the share in your system from paid invoices, or sell one-off items through the marketplace API, which prices a commission and pays out on statements |
| Per-jurisdiction tax withholding | Not modelled; handle outside Kontier |
Build it
IDs in the examples are placeholders: use the id each create call returns.
1. Onboard a creator
There is no counterparty object in the public API. A creator is represented by their own plan (step 2); keep the creator's payout details, tax forms and handle in your own system, or as metadata on the plan. If the creator also sells one-off items, make them a customer with the seller role as in the marketplace blueprint, which records a payout account and a VAT posture.
2. Creator defines subscription tiers
Each creator gets a plan; cadence is a property of the plan (price_cadence_unit), so a monthly and an annual offer are two plans.
Code
Attach both products to the plan with POST /v1/plans/{id}/products, then price them on the plan. plan_version: 0 stages the price on a never-published plan's working draft:
Code
For annual prepay, create a second plan "Anna Writes Things - Annual" with "price_cadence_unit": "year", attach the same products and price the standard tier at "50.00" (saves 17%).
Publish the products and the plans; nothing is sellable before. Publishing is a change with the operation catalog.publish_version:
Code
(Use "subject_kind": "product" with each product's id for the products, before the plans.) A plan's first publish is its version 1.
3. Subscriber subscribes to the creator
A subscription is created empty, its deal is written as a revision of phases, then it is started:
Code
Code
Code
The subscription bills on its plan's cadence: to sell the annual tier instead, draw the line from the annual plan. Its plan_id is the creator's plan, which is what you attribute revenue by. then: "open" means the membership runs on until it is cancelled.
4. Attribute and report creator revenue
At the end of each payout period, collect what each creator earned:
Code
From each paid invoice (total, tax_total, amount_paid) and each credit note issued against one, compute the creator's share net of your commission and processing cost. To react as money arrives instead of polling, subscribe to the invoice.payment_recorded webhook.
Automatic per-creator settlement statements with commission and withholding rules, and a cron that generates them, are not available through the public API (Settlements, Recurring Schedules). The payout statement and the bank transfer are yours to produce.
5. Handle refunds and cancellations
A refund on the latest month's charge goes through the invoice; it writes a credit note and moves the money back:
Code
Deduct the refunded amount's creator share from the creator's next payout. A refund can be parked by an approval checkpoint (the response is 202 with state: approval_pending); the outcome then arrives as an approval.* webhook.
A subscriber who leaves keeps access until the end of the period they paid for:
Code
Past charges stay billed, so the creator keeps what they earned through the cancellation date.
Variations
- Tip / one-time donation or paid download. A one-off purchase from a creator fits the marketplace flow: make the creator a seller, agree a sale with the subscriber as buyer, charge and complete it. The marketplace prices your commission, rolls the creator's sales into weekly or monthly statements and prepares the payouts. Subscription revenue does not flow into those statements.
- Pay-what-you-want pricing. The subscriber picks a monthly amount above the creator's minimum. Enforce the minimum in your checkout, then state the chosen amount as an agreed price on the line:
"price": { "kind": "stated", "price": { "kind": "agreed", "amount": "8.00" } }. - Multi-currency subscribers. Add EUR and GBP prices for the same products and plans; each subscription bills in its own
currency, fixed when it is created. Converting earnings into the creator's payout currency is part of your payout computation; see Exchange Rates and Currency Policy for the rates Kontier applies. - Creator-of-creators (collectives). A publication with co-authors is one plan; splitting its revenue among collaborators is part of your payout computation.
- Tier upgrades and downgrades. Cut the live revision (
POST /v1/subscriptions/{id}/revisions/cut), write the whole draft with a new last phase whose line is the new tier's product (PUT /v1/subscriptions/{id}/revisions/draft) and publish (POST /v1/subscriptions/{id}/revisions/draft/publish). The cut is a billing boundary the invoice pipeline prorates across, and publishing emitssubscription.revision_published. See SaaS per-seat for the full sequence. - Free tier with paid upgrades. A free member's line states a free price:
"price": { "kind": "stated", "price": { "kind": "free" } }. It bills nothing; upgrade it with a cut that states"price": { "kind": "reset" }on the paid phase.
What you don't have to build
- Per-creator tiers, prices and cadences (plans, products, prices, published as versions)
- Subscription lifecycle, renewals, upgrades with proration, and end-of-period cancellation
- Refunds with credit notes
- Per-creator revenue lookups (filter subscriptions by
plan_id, invoices bysubscription_id,statusandpaid_at) - Commission, statements and payouts for one-off creator sales (the marketplace API)
Next steps
- Subscriptions - subscriber-creator subscription lifecycle
- Marketplace - seller payouts and statements for one-off sales
- Credit Notes - refund documents
- Settlements - revenue-share statements (not in the public API)