Pricing architecture
SaaS subscriptions vs transaction fees: choosing a marketplace revenue model
Subscriptions monetize ongoing access and capability. Transaction fees monetize completed economic activity. They imply different architecture, different incentives and different failure modes.
This is usually framed as a pricing debate, and it is really a question about what the platform is being paid for. One model charges for the capability to operate; the other charges for an exchange that completed. The architecture, the incentives and the awkward cases all follow from that difference.
Two models, two definitions of value
Recurring access vs completed activity
How SaaS subscriptions work
A business selects a plan; the platform grants a set of entitlements; billing recurs until someone stops it. The visible part is the pricing table. The substantial part is everything that happens when the arrangement changes: upgrades, downgrades, proration, failed payments, retries, cancellation, reactivation, and what a business can still see after it stops paying.
The entitlement layer is the piece most often underestimated. If features check plan names directly in a dozen places, every pricing change becomes a code change and every edge case becomes a bug report.
How transaction fees work
A fee is applied when an exchange completes: a booking confirmed, an order paid, a job accepted. It can be a percentage, a fixed amount, or a mix, taken from one side or split. The platform is now in the payments business, which means payouts, holds, reversals and reconciliation between what was charged, what was paid out and what was reported.
What subscriptions do well
- Predictability — revenue is a function of accounts and churn, not of a quiet month.
- Packaged capability — value is described in features a buyer can evaluate before paying.
- No conflict with off-platform activity — the business is not penalised for repeat customers.
- Simpler accounting — no payouts, splits, refund logic or settlement timing.
- A cleaner relationship — the platform is a supplier of tools, not a party to each sale.
What transaction fees do well
- Alignment — the platform only earns when the business does.
- Low barrier — supply joins without a commitment, which helps coverage.
- Automatic scaling — revenue grows with marketplace activity, without a pricing change.
- Fairness across sizes — a small operator is not paying the same as a large one.
- Evidence of value — the fee is attached to something the business can point at.
The trade-offs
| Dimension | Subscription | Transaction fee |
|---|---|---|
| Revenue predictability | High — known in advance | Variable — follows activity |
| Barrier to joining | Higher — payment before value | Lower — payment after value |
| Incentive risk | Businesses under-use and then churn | Both sides move repeat business off-platform |
| Billing complexity | Plans, proration, dunning, entitlements | Splits, payouts, refunds, chargebacks |
| Support load | Plan changes and access questions | Money disputes, which are harder |
| Scales with | Number of paying accounts | Volume and value of transactions |
| Hardest case | A downgrade mid-cycle | A refund after payout |
When subscriptions fit better
- The business uses platform tools regardless of whether a transaction occurs.
- The exchange completes off-platform and cannot be reliably observed.
- Transaction values are low, so per-event fees are noise against payment costs.
- Relationships are long-running, so a per-event fee feels like a tax on loyalty.
- The platform needs predictable revenue to fund its own roadmap.
When transaction fees fit better
- The platform actually carries the booking, order or payment.
- Activity is infrequent or seasonal, making a monthly plan hard to justify.
- Transaction values are high enough that a fee is meaningful and acceptable.
- Supply is fragmented and price-sensitive, so a low barrier matters more than predictability.
- The platform adds visible value at the moment of exchange — trust, guarantees, dispute handling.
Hybrid models
Base plan + activity fee
Two shapes recur. A base plan with a reduced activity fee rewards committed sellers and steadies revenue. Free entry with a fee on completed activity maximises supply and defers revenue until value is proven. Both are defensible; both double the billing surface.
Architecture implications
Whichever model is chosen, the same subsystems have to exist and agree with each other.
- Billing — the source of truth for what is owed and what was collected.
- Subscriptions — plan state, renewal dates, cancellation and reactivation.
- Entitlements — one place that answers whether this account can do this thing today.
- Payment events — recorded so a fee can be traced back to the exchange that produced it.
- Refunds and reversals — with an explicit rule for what happens to the platform's cut.
- Invoicing — one document a business can reconcile against its own records.
- Reporting — figures that match between platform, payment provider and accounts.
Reconciliation is where this most often breaks: the platform, the payment provider and the accounting system each hold part of the truth. That is the same integration problem described in integrating disconnected business systems.
Choose on value creation, not fashion
Marketplace pricing follows trends, and the trend is a poor guide because it reflects other people's transaction values and cost structures. The durable test is simpler: name what the business receives, name when it receives it, and charge in that shape.
We model pricing alongside the billing and entitlement architecture, because the two decisions are the same decision. See hybrid marketplace and SaaS platform development.
Frequently asked questions
- Is subscription revenue better than transaction fees?
Neither is better in general. Subscriptions are more predictable and suit platforms businesses operate inside daily. Transaction fees align with activity and suit platforms that genuinely carry the exchange. The wrong question is which is superior; the right one is which value you are actually charging for.
- What percentage should a marketplace charge?
There is no universal correct percentage. Rates that work in one category are unworkable in another because average transaction value, margin, frequency and cost to serve all differ. Model it against your own numbers rather than borrowing a figure from an unrelated platform.
- Can a marketplace use both models?
Yes — a base plan with a lower activity fee, or free entry with a fee on completed transactions, are both common. The cost is operational: two billing paths that must appear as one account, one invoice and one dispute process.
- What does SaaS pricing require technically?
Plans, an entitlement layer that grants and revokes capability, proration for mid-cycle changes, retry handling for failed payments, invoices, tax treatment and reporting. Most of the work sits in the transitions rather than in the happy path.
- Are transaction fees easier for sellers to accept?
Usually at the start, because nothing is owed until they earn. Sentiment can reverse at volume, when the annual total of fees exceeds what a plan would have cost — which is exactly why tiered hybrids exist.
- What happens when a transaction is refunded?
The platform has to decide whether its fee is returned, retained or partially retained, then implement that consistently across payouts, invoices, tax records and reporting. Publishing the rule before launch prevents most of the disputes.
- Which model creates recurring revenue?
Subscriptions, by definition. Transaction fees can be steady in aggregate, but each unit of revenue depends on an event happening again rather than on an agreement continuing.