x402 revenue splits: pay a referrer from the payment itself, not a spreadsheet

In x402, a server answers an unpaid request with HTTP 402 Payment Required ^[1]. The answer carries a PAYMENT-REQUIRED header that lists the price, the network and the destination address ^[1]. The buyer signs a payment to that address and retries the request.

x402 revenue splits change only one thing: the destination address. When a seller offers a referral share and a buyer arrives through a referral link, our server quotes a split contract as the address instead of the seller's own wallet. The buyer signs one ordinary payment, exactly as before. A stock x402 client cannot tell the difference, and it does not need to.

The split is a push split from 0xSplits. Its documentation describes each split as a smart contract wallet with a list of recipients and their shares, and says a push split sends funds directly to the recipients when it distributes ^[2]. So the money does not wait in an account we control. It moves from the contract to each wallet.

The contract's address is fixed before it exists. Our server works out the address from the recipients and their shares, and the buyer can pay it before the contract is deployed. The first distribution deploys it and pays everyone in the same step.

A split with an owner is a wallet that someone controls. The 0xSplits documentation says the owner has full execution access from the split's address, which lets the owner pause distributions and make arbitrary transactions ^[2]. That is useful for some teams. It is the wrong shape for a referral promise.

So every split we create has no owner. The documentation says that when the owner is the zero address, the split becomes immutable ^[2]. Nobody can add a recipient, change a share or pause a payout. That includes us. The terms a buyer pays into are the terms the contract will pay out, forever.

We also chose not to write our own splitting contract. 0xSplits publishes the same push split factory address on Base, Polygon and Arbitrum in its deployment files ^[3], and its V2 contracts went through an independent audit with a public report ^[4]. Using audited, widely used code is safer than inventing a new one for money that belongs to other people.

Everything starts on the seller side. In SpendTheBits, each resource a seller publishes has a Settings card, and Referral share is the first row. Our app offers a short list of choices, from off up to one fifth of each sale. Off is the default, so nothing changes until the seller turns it on.

Our server enforces a hard ceiling on top of the app, and it refuses any split in which the seller would not keep the majority of each sale. A referral program is meant to bring a seller more buyers, not to hand the business away.

Once a share is set, any SpendTheBits user can copy a referral link for that resource. The link is the normal resource address with a ref value naming their handle added to the end ^[7]. Sharing the link costs nothing, and the referrer does not need to ask the seller for permission.

The buyer sees no extra charge. The referral share comes out of the seller's price, not on top of it, so a buyer who arrives through a link pays the same as a buyer who does not.

Our server checks the referral before it builds the split, and every check fails safe. The handle must exist, it must not belong to the seller, and its owner must hold a USDC address on the same network as the seller. A seller cannot refer their own sales to a second account they control, because the handle has to belong to a different user. If any check fails, the quote simply pays the seller, so a bad link can never block a sale.

Splits apply to fixed price USDC payments on Base, Polygon and Arbitrum. Payments on Solana, on Circle Arc and metered payments still go straight to the seller, because the split contract is not available there yet. In those cases a referral link is ignored, and the sale works as it always did.

Anyone may trigger a distribution, and we do it from our own relayer so sellers never pay gas or think about it. The relayer can only start a payout to the recipients the contract already fixed. It cannot send a single cent anywhere else.

Sending a transaction for every one cent sale would waste gas, so payouts are batched. Our relayer distributes once a split holds about half a dollar, or a day after the oldest unpaid sale, whichever comes first ^[7].

Then comes the part that makes the books trustworthy. We do not record what we expected to pay. We read the mined transaction and book each party's income from the USDC transfers the chain actually made. If the chain moved it, it is in the books, and if it did not, it is not.

We do not call a feature live until real money has moved through it. In September, a buyer used the public example client to pay one cent for a SpendTheBits resource on Base through a referral link, and the payment went to the split contract, not to the seller ^[5].

About four minutes later ^[5], one distribution transaction from that contract paid three wallets at once: the seller, the referrer and our treasury ^[6]. The payment brought in 10,000 USDC base units ^[5], and the distribution sent 999 of them to the referrer ^[6]. That is just under the share our seller had set. The 0xSplits documentation warns that small shares can lose a little to rounding on small distributions, which is exactly what happened ^[2]. The seller kept the large majority, and our part was a small slice, well under one percent.

Every step is public on the Base explorer, and the example repository links the payment and the split ^[7]. Anyone can check the result without asking us.

x402 revenue splits fit any seller who wants other people to bring buyers: a data feed shared in agent builder groups, a risk score recommended by a newsletter, an API listed by a directory that wants a cut. The referrer gets paid without asking, and the seller never has to run payouts.

They also suit referrers who are wary of promises. A share that lives in an ownerless contract is not a promise at all. It is the only way the money can move.

To start, read our guide to getting paid by AI agents and the walkthrough on monetizing an API with x402. If regular buyers matter more to you than referrers, x402 subscriptions as passes covers the other side, and the agents page shows every setting sellers can switch on.