Payload

Posted on Oct 4

What happens after an x402 payment?

#x402 #api #ai #webdev

An AI agent finds your API, pays $0.10 in USDC through x402, gets its response. Clean. Done.

But then what?

Who gets that $0.10? The developer who built the endpoint? The platform hosting it? The person whose data trained the model behind it? The referrer who brought the agent there in the first place?

x402 solved how software pays. It did not solve what happens economically after the payment lands. That gap is where most API monetization quietly breaks.

The payment is the easy part

Here's what a typical x402 flow looks like from the seller's side:

# Agent discovers your endpoint, gets a 402 with payment requirements
curl https://your-api.example.com/v1/diagnose

# HTTP 402: payment required
# {
#   "x402Version": 2,
#   "accepts": [{
#     "scheme": "exact",
#     "network": "eip155:8453",
#     "asset": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
#     "amount": "100000",          # $0.10 in USDC atomic units
#     "payTo": "0xYourAddress..."
#   }]
# }

The agent pays. You get $0.10 in your wallet. The protocol worked exactly as designed.

Now multiply that by ten thousand calls a day, split across three contributors, with a platform fee, a referral agreement, and a recoupment schedule from when you paid a contractor to build the thing.

Your x402 integration doesn't know about any of that. It shouldn't. Payment and economics are different problems.

What breaks in practice

Hard-coded splits. The most common approach: a few lines of code that divide revenue 70/30. It works until the 30% person leaves, until you add a second contributor, until someone asks "what about the referral fee we agreed on?" Then it's a rewrite.

Spreadsheets. Surprisingly common even at real scale. Someone exports the transaction log monthly, applies formulas, sends payouts manually. It works until it doesn't, and when it breaks there's no audit trail.

Payment-provider logic. Splits implemented in Stripe Connect or a smart contract. Now your economic rules are locked to a specific rail. Change providers, rewrite everything. The economics should outlive the payment method.

Lost attribution. A user found you through a partner's integration six months ago. Every call since then should credit that partner. But the payment system sees anonymous wallet addresses, not customer relationships.

Recoupment math. You paid a developer $5,000 upfront against future revenue. They get 70% until that's recouped, then 40%. Try expressing that in a static split. Now try it across 50,000 microtransactions where the crossover happens mid-day on a Tuesday.

Separating the two problems

The clean architecture looks like this:

AGENT PAYS ($0.10 USDC)
    |
    v
x402 SETTLEMENT (payment rail)
    |
    v
ECONOMIC EVENT (normalized: who paid, how much, when, for what)
    |
    v
REVENUE RULES ENGINE (persistent rules applied to the event)
    |
    v
ENTITLEMENTS (developer $0.06, platform $0.02, referrer $0.01, contributor $0.01)
    |
    v
AUDITABLE LEDGER (every decision recorded, replayable)

The payment rail moves the money. A separate layer decides who participates economically. The rules persist across transactions, so recoupment, waterfalls, and attribution work automatically.

This is what I built RevRule to do. It's a programmable revenue rules engine: you define a Revenue Graph once (participants + rules), send it economic events, and it returns computed entitlements with a full audit trail.

A concrete example

Say you run an API that three people have a stake in. You define the economics once:

curl -X POST https://payload-rail.fly.dev/v1/graphs \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "my-api-economics",
    "participants": [
      {"id": "developer", "type": "person"},
      {"id": "platform", "type": "platform"},
      {"id": "referrer", "type": "person"}
    ],
    "rules": [
      {"id": "platform-fee", "type": "percentage", "value": 20, "payee": "platform"},
      {"id": "referral", "type": "percentage", "value": 10, "payee": "referrer"},
      {"id": "dev-remainder", "type": "remainder", "payee": "developer"}
    ]
  }'

Then every x402 payment becomes an economic event:

curl -X POST https://payload-rail.fly.dev/v1/graphs/my-api-economics/events \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "event": {
      "eventId": "evt-001",
      "graphId": "my-api-economics",
      "amountMicros": 100000,
      "currency": "USD",
      "occurredAt": "2026-10-04T12:00:00Z"
    }
  }'

Response:

{
  "eventId": "evt-001",
  "entitlements": [
    {"participantId": "platform", "amountMicros": 20000},
    {"participantId": "referrer", "amountMicros": 10000},
    {"participantId": "developer", "amountMicros": 70000}
  ]
}

$0.10 in, three entitlements out. The rules persist. The ten-thousandth payment follows the same rules as the first. If you need to simulate a rule change before applying it, there's a dry-run endpoint that computes without writing anything.

Why this matters for agent commerce

The x402 ecosystem is growing fast. Agents are paying for APIs, data, compute, and services. Every one of those payments creates an economic question: who participated in creating the value, and what are they owed?

If you're building a paid API for agents, you're already halfway there. You have the payment flow. The missing piece is the economics layer that turns raw payments into correct, auditable distributions.

A few things worth noting about the design:

No custody. RevRule never holds funds or executes payouts. It computes entitlements. Your wallet, Stripe account, or smart contract moves the money.
Rail-independent. The same rules apply whether the payment came through x402, Stripe, or anything else. Change your payment provider without rewriting your economics.
Idempotent. Events are keyed by ID. Replays return the original result. Safe to retry.
Auditable. Every computation writes to a hash-chained ledger you can verify independently.

Try it

Sandbox (free, no signup): https://payloadhq.github.io/flow-try.html
API docs: https://payloadhq.github.io/revrule-api.html
Source (MIT): https://github.com/Payloadhq/payload-flow
Machine discovery: https://payload-rail.fly.dev/.well-known/x402

The sandbox runs three scenarios in your browser: a $0.10 agent payment split, a $1,000 recoupment waterfall, and a $100,000 marketplace distribution. No API key needed to explore.

x402 answered how software pays. The next question is what happens economically after it pays. That's a rules problem, not a payments problem, and it deserves its own layer.

DEV Community