Payload

RevRule by Payload

Your payment system moves the money.
RevRule decides who earns what.

Set the rules once. Whenever your product, API, marketplace, agent, or project earns money, RevRule calculates who participates.

Royalties Revenue shares Commissions Referrals Recoupment Waterfalls Platform fees Contributor payouts

Interactive demo

Understand it in ten seconds

One API payment. Four participants. Move the sliders and watch the economics change. This is what RevRule computes on every event, automatically.

$1.00 API PAYMENT

Drag to change the rules. The split recomputes instantly.

NEXT PAYMENT → the same rules execute automatically. And the next. And the next.

Try the full engine with recoupment and waterfalls in the live sandbox. No sign-up, no credit card.

Use cases

Oh, I could use this for…

One engine. Every situation below runs on the same Revenue Graph model.

API / AI Agents

An API earns $1

RevRule distributes the economics across developer, platform, referrer, and contributor.

SaaS

Reward everyone who helped

Developer, salesperson, partner, or referrer gets their share automatically on every subscription.

Marketplaces

Program the whole split

Seller, platform, referral, and contributor economics in one persistent rule set.

Creators / Media

Royalties that stick

Keep royalties and residuals attached to qualifying revenue across every future event.

Agencies

Commissions without spreadsheets

Partner shares, commissions, and recoupment rules that execute themselves.

Licensing

Continuing participation

Apply ongoing economic participation across every qualifying sale of licensed work.

The big idea

Most payment systems answer one question

Most payment systems answer:
HOW DOES MONEY MOVE?

RevRule answers:
WHO PARTICIPATES IN THE MONEY, UNDER WHAT RULES, AND HOW DO THOSE RULES CHANGE OVER TIME?

Under the hood, RevRule is built on a small set of durable concepts:

Revenue GraphThe persistent rule set for an economic relationship
Economic EventsRevenue moments the rules respond to
Persistent EntitlementsWho is owed what, remembered across transactions
RecoupmentAdvances paid back before splits change
AttributionWhich revenue qualifies for which participant
StateThe engine remembers where every rule stands
AuditabilityEvery computation leaves a verifiable trail

Why this is different

This is not a basic splitter

A splitter divides one payment. RevRule governs an economic relationship over time.

Normal splitter

70% → A
30% → B

Done. Nothing persists. Nothing changes. The next payment is a blank slate.

RevRule

70% → A until $50,000 is recouped, then 55%
10% → B only on attributable customers
5% → C for qualifying revenue
3% → platform, always
Rules persist across every future economic event. The engine remembers.

Persistence

The rule belongs to the relationship

Not to the individual payment. Change the rail. The economics stay.

Stripe payment→ REVRULE
x402 payment→ REVRULE
Another supported rail→ REVRULE

The rail can change. The economics can persist.

Machine commerce

Built for the age of agents

What happens after an x402 payment

AI agent finds API→ Pays through x402→ RevRule receives event→ Rules execute→ Participants earn→ Ledger updates→ Next call repeats

MACHINE PAYS. REVRULE RUNS THE ECONOMICS.

Proof, not promises

Verify it yourself

Developers trust what they can inspect. Everything below is live and real.

Is this you?

If any of these sound familiar

  • IF YOU RUN AN API — and more than one party should earn when it gets called…
  • IF YOU OPERATE A MARKETPLACE — and seller, platform, and referral economics live in scattered code…
  • IF YOU BUILT A SAAS PRODUCT — and partners, affiliates, or contributors deserve a cut…
  • IF MULTIPLE PEOPLE SHOULD PARTICIPATE WHEN YOU EARN — automatically, every time…
  • IF SOMEONE SHOULD KEEP EARNING AFTER THEIR ORIGINAL CONTRIBUTION — royalties, residuals, recoupment…
  • IF YOU HAVE BEEN MANAGING REVENUE RULES IN SPREADSHEETS OR CUSTOM CODE — and it keeps breaking…

Before / after

What changes

Before RevRule

  • Custom payout logic in every service
  • Spreadsheets and manual calculations
  • Hard-coded percentages nobody dares touch
  • Lost attribution across events
  • Payment-provider-specific logic
  • Recoupment tracked by hand
  • Poor auditability when questions come

With RevRule

  • One economic rules engine
  • Persistent rules across transactions
  • Automatic calculations on every event
  • Stateful entitlements the engine remembers
  • Rail-independent economics
  • Recoupment and waterfalls built in
  • Clean, verifiable audit trail

Questions

What RevRule is not

Does RevRule hold my money?
No. RevRule never holds funds and never executes payouts. It computes who is entitled to what. Your payment system moves the money. RevRule decides who earns what.
Do I need crypto?
No. RevRule works with ordinary payment rails. Crypto and x402 are supported where they fit, never required.
Can I use it with normal software?
Yes. If your product can call an API when revenue happens, RevRule can program the economics.
Is it only for royalties?
No. Royalties are one use case. Revenue shares, referrals, commissions, recoupment, waterfalls, platform fees, and contributor payouts all run on the same engine.
Is it only for x402?
No. x402 is one way economic events enter RevRule. Any revenue event works.
Is it only for large companies?
No. A solo API builder with one referrer gets the same engine as a marketplace.
Do I have to replace my payment provider?
No. Keep Stripe, keep your rail. RevRule sits beside it and programs the economics on top.

Pricing

Simple on purpose

RevRule by Payload

$99 one-time

Try free in the sandbox. No credit card, no trial clock.
Buy once for $99 when you are ready for production.

Free evaluation: limited test Revenue Graphs, simulations, sample rules, and blueprints. Run the full engine in the RevRule sandbox or get a free API key from the console.
$99 unlocks production graphs, live events, integrations, and persistent production state.

Your payment rail moves money.
RevRule decides who earns.

Support: Support