A plan per creator
Pay a percentage, a fixed amount or both. Add a waiting period so refunds settle first, and a minimum so small balances roll forward to the next statement.
Creator commissions
Creator commissions calculated from real orders, and approved by a person
You set a commission plan for each creator, and the ledger builds itself from the orders their codes brought in. Refunds are netted out, referrals to themselves are flagged, and each statement waits for a person to approve it. You pay the creator your usual way and record the reference. Nothing here moves money.
Part of an add-on that is not on sale yet
Commissions belong to Creator Operations, which our team can switch on for a workspace while its price is being decided. Paying through the system is a test mode that moves no money. Statements record payments you made elsewhere.
- 2 parts
- a plan can pay a percentage, a fixed amount per order, or both
- 1 person
- must approve each statement, bound to the version they read
- 0 transfers
- the system makes: it calculates and records, and you pay the creator
- PlanA percentage, a fixed amount, a waiting period
- OrdersCounted from the codes each creator uses
- LedgerLines earned, held and clawed back
- StatementA person approves the exact version
- PaidYou pay, then record the reference
What does commission tracking cover?
The work that usually lives in a spreadsheet nobody fully trusts, with a record of who decided what.
A ledger from real orders
Lines are calculated from the orders that a creator's codes brought in, from your connected store. Each line points to its order, so a dispute starts from a fact.
Refunds taken back
When an order is refunded, its commission is taken back on the ledger, including after a statement closed. The next statement carries the correction.
Self-referrals flagged
An order that looks like a creator buying through their own code is flagged for a person to review, so it does not earn commission in silence.
Statements bound to a version
A statement is approved as a specific version with its digest. If the numbers change, the approval no longer applies and someone has to read it again.
Costs stay private
Commissions are a cost of the business, so a role that cannot see costs sees none of this, in the screen and through the API alike.
Who can do what with a commission?
Software and assistants may prepare and propose. Everything that commits your money belongs to a signed-in person.
| Action | A person on screen | An API key or AI agent |
|---|---|---|
| Read plans and ledger | Yes, if the role sees costs | Yes, with permission |
| Propose a plan | Yes | Yes, as a draft |
| Activate a plan | Yes | No |
| Approve a statement | Yes | No |
| Record a payment | Yes, with its reference | No |
| Void a statement | Yes | No |
How do you pay a creator from a statement?
Set the plan
Write the terms for the creator and activate them. An assistant can draft the plan for you, and a person makes it active.
Let orders build the ledger
Orders from the creator's codes become lines. The waiting period holds them until refunds have had time to arrive.
Approve the statement
Read the statement and approve that version. Anything that changes after this point needs a fresh approval.
Pay, then record it
Pay the creator through your bank or provider, and record the payment with its reference. The statement says paid only then.
Why the system never marks a statement as paid by itself
A statement that says paid is a claim someone can rely on: a creator, an accountant, an auditor. So it can only become true when a person records a real payment with a reference that can be checked. A test run, a scheduled job or an assistant cannot produce that state, and that is enforced in the code rather than written in a policy.
A payout mode exists, and it is a test mode. It walks the real steps: the service switch, the workspace owner's consent, a person, the exact statement version, and one attempt at a time. It records a simulated result and moves no money. Paying people for real needs a licensed payment provider, payee details and tax documents, which is a commercial and legal decision that has not been taken. No bank details are stored.
The ledger is built this way because creator disputes are about trust. When each line points to an order, when a refund shows up as its own correction, and when the approval shows who read which version, a disagreement becomes a five-minute check rather than an argument about whose spreadsheet is right.
When is this not what you are looking for?
This tracks and documents commissions. It does not replace a payment or an affiliate network.
You want payouts handled for you
There is no live payment rail. You pay creators yourself and record it. If you need the platform to pay, collect tax forms and hold payee details, use a licensed payout provider.
You need affiliate links and click tracking
Commissions are counted from the codes and store orders already recorded, not from a link-tracking network. If your program runs on tracked links across many sites, this is not that system.
You do not have a connected store
The ledger reads orders from the codes your connected store reports. With no store connection there are no orders to calculate from, and a manual process will serve you better.
Clear answers
Creator commissions: common questions
Replace the commission spreadsheet
Tell us how many creators you work with and which store you use. We will tell you whether this fits.