Stop hand-rolling revenue splits — 3 copy-paste Revenue Graphs that conserve to the micro-unit

Every marketplace, API business, and creator collab eventually hand-rolls the same code: take a payment, carve off the platform cut, pay the referrer, pay the contributor, hope the math adds up. It never quite does, and there is no audit trail when someone asks where their money went.

RevRule's answer is the Revenue Graph: a versioned, stateful rule graph that turns economic events into auditable entitlements. Last week I published three production-ready blueprints. Each one is a JSON graph spec you can load into the live Flow API in one curl call, and each is validated to conserve the pool exactly.

1. API revenue share

The pattern behind every API business with contributors: operator takes the remainder, a contributor gets a fixed percentage, referrers get their cut from attribution data.

{
  "id": "bp_api_revenue_share",
  "rules": [
    {"id": "r_payload_fee", "type": "payload_fee", "priority": 1, "params": {"licenseTier": "free"}},
    {"id": "r_referral", "type": "referral", "priority": 2, "params": {"rateBps": 1000}},
    {"id": "r_contributor", "type": "percentage", "priority": 3, "params": {"rateBps": 2000, "subjectParticipantId": "contributor"}},
    {"id": "r_operator_remainder", "type": "remainder", "priority": 4, "params": {"subjectParticipantId": "operator"}}
  ]
}

Rules consume from the pool in priority order. The referral rule resolves its subject from event.attribution.referrerId and skips cleanly when there is none. The remainder rule is validated to be last and takes exactly what is left, so the pool always conserves.

2. Marketplace split

Seller, platform, affiliate. The platform's take is a first-class platform_fee rule, separate from the infrastructure fee, so your economics and the rail's economics never get tangled:

• 5% affiliate referral
• 10% platform fee
• Remainder to seller

On a $100 sale ($3.30 processing cost), that is $4.79 to the affiliate, $9.09 to the platform, $81.85 to the seller, verified to the micro-unit.

3. Creator recoupment

The one that is genuinely hard to hand-roll: a label advances an artist $10,000, and the advance is worked down from the artist's share across many events, surviving restarts, before the post-recoupment split kicks in.

{"id": "r_recoup", "type": "recoupment", "priority": 2, "params": {
  "subjectParticipantId": "artist",
  "advanceMicros": 10000000000,
  "recoupRateBps": 10000,
  "postRateBps": 5000
}}

The recoupment balance is stateful. If an event completes the advance partway, the same event steps down to the post rate mid-stream. The ledger records the cumulative recouped amount per event, so both sides can audit it.

Try one in 60 seconds

Get a free API key, load a blueprint, activate it, and run a simulated event first (simulation is a dry run with zero side effects):

KEY=$(curl -s -X POST https://payload-rail.fly.dev/v1/access-keys \
  -H 'Content-Type: application/json' -d '{"label":"blueprint-test"}' | python3 -c "import sys,json; print(json.load(sys.stdin)['key'])")
BASE=https://payload-rail.fly.dev
curl -s -X POST $BASE/v1/graphs -H "Authorization: Bearer $KEY" \
  -H 'Content-Type: application/json' \
  --data @blueprints/marketplace-split.json

Every distribution the API returns is labeled proposed. The Rail never holds funds or moves money; your Stripe Connect account or facilitator executes the payouts. The graph owns the economics; the rail just moves the money.

Blueprints: github.com/Payloadhq/payload-flow/tree/main/blueprints
Live API quickstart: payloadhq.github.io/flow-rail.html
No-key browser sandbox: payloadhq.github.io/flow-sandbox.html

If you run a marketplace, an API business, or anything with revenue shares, try replacing your split code with a graph and tell me where the model breaks. That feedback is the roadmap.