UnitMarket

Pay for the article you came for. Buy just the article you need. Pay once, no subscription.

Comment

Inspiration

A reader who wants one article is told to buy a whole subscription. An AI agent that needs one answer hits the same wall. Very little content is sold in small units, because the payment can cost more than the thing being paid for.

The arithmetic is simple. A single card payment at a standard published rate costs a percentage plus a fixed fee:

$$ \text{fee}(p) = 0.0349\,p + \$0.49 $$

For a 7 cent article, \( \text{fee}(0.07) \approx \$0.49 \). The fee is seven times the price. At that point a small sale does not make sense for the buyer, the seller or the payment network.

We noticed that ride sharing solved a similar problem. One driver and one rider are inefficient. A platform that pools riders and drivers and matches them at volume makes each trip cheap. We asked what the same idea looks like for payments, with PayPal as the settlement layer underneath.

That gave us three pillars:

  1. Buyer consolidation. Many buyers who want the same unit share one payment and a volume price.
  2. Seller consolidation. Small publishers pool their supply so they can fill orders none of them could fill alone.
  3. Trades at volume. AI agents buy in 5 to 10 cent pieces, and a ledger nets thousands of trades into far fewer payment movements. In our simulation, under the pricing assumptions stated below, that volume brings the fee per trade under one cent.

What it does

Scope, said up front. PayPal runs in the sandbox only, with test money. Real sandbox payments run today for purchases a person approves. In the sandbox, an agent's purchase stops at a UnitMarket page for the buyer to approve; the fully automatic agent path runs in the dry run. The micro-ledger, netting, buyer pools, seller pools, matching and payouts are simulated in code and are not yet connected to PayPal. Every figure below that comes from the simulation is labelled as one, and simulation results prove the modelled cases only, not PayPal compatibility.

Try it at https://unitmarket.live (the judge passcode is in the testing instructions). Real sandbox payments were made on 29 Oct 2026 (a pack from two publishers, paid as two separate payments) and on 7 Nov 2026 on the hosted app.

UnitMarket is a marketplace for small units of value, starting with content, for people and for AI agents.

A person buys. The buyer says what they need and what they will pay. UnitMarket proposes a pack. Nothing is charged until the buyer approves, and the price and terms are frozen at that moment. A pack from two publishers is paid as two separate PayPal sandbox payments. Each one is approved, captured and read back before access opens. The buyer then gets a library entry and a receipt.

An agent buys. The buyer gives an agent a cap: a money limit, a purchase count, a per-purchase maximum and an expiry. The agent searches, proposes and buys through six MCP tools and a public API. It can never create, widen or revoke its own cap. When we fire twenty buys at once on a five-purchase cap, exactly five orders are created. In the sandbox, each agent purchase still waits for the buyer's approval.

Everything is traceable. Every money, delivery, cap and control change is written to one append-only, hash-chained journal in the same database transaction. A verify command finds an edited row and names it.

Operators stay in control. They get health lights, alerts that raise and resolve on their own, an order timeline with an evidence pack, transaction search, business rules with history, per-unit refunds behind a second factor, and switches that turn any API group or MCP tool off without a deploy.

The three pillars at scale (simulation). A deterministic simulation runs 10,000 agent trades of 5 to 10 cents ($758 of content). It prices every PayPal movement at PayPal's published US rates as we read them in October 2026 (PayPal merchant fees). Whether UnitMarket would qualify for the micropayments rate, which needs PayPal's approval, is not yet validated.

  • Each trade paid on its own: 10,000 checkout payments at the standard rate (3.49% plus $0.49) cost $4,926.47 in fees.
  • Through the UnitMarket ledger: 198 movements cost $83.40. They are 100 wallet top-ups of $10 at the micropayments rate (4.99% plus $0.09), which is $58.90, and 98 batched payout items at $0.25 each, which is $24.50. Trades between top-up and payout net inside the ledger and touch no payment network.

Pools are measured separately on the same run. Without pools, each of the 10,000 single-unit orders is its own payment to a publisher. With buyer and seller pools, agents that want the same unit share one payment, so those 10,000 payments become 233, and their fees at the micropayments rate fall from $900.00 to $61.46. The pool model rounds each fee to whole cents per payment, so on a 5 to 10 cent payment the 4.99% part rounds to zero and only the $0.09 fixed fee is left: $900.00 is 10,000 times $0.09. Without that rounding, the same 10,000 payments cost $937.85 at the micropayments rate. Per-payment rounding is an assumption of our simulation; we have not validated that PayPal applies fees this way. That 233 counts payments to publishers. The 198 above counts ledger top-ups and payouts. They are two different measures. Thirty-three bundle requests that no single publisher could fill are all filled by pooled publishers. Publisher income after fees moves from minus $141.53 to plus $632.96.

How we built it

We are a small team, and we built UnitMarket with Claude as our engineering partner. The two repositories hold about 429,000 lines of TypeScript, tests included. The full test run of the sandbox repository on revision 34fa170 shows 13,621 passed, 0 failed, 51 skipped.

  • Stack. Next.js and React in TypeScript, PostgreSQL (PGlite offline, Cloud SQL when hosted), and Google Cloud Run with Secret Manager.
  • Domain packages for catalogue, discovery, approval, payments, entitlements, ledger, receipts, recovery, rules, trace, alerts and search.
  • PayPal. Orders v2 in the sandbox: token, create, get, capture and read back. All five calls go through one sealed transport package, the only code allowed to open a network connection.
  • Two-key safety. Reaching the sandbox needs a connect flag and an active approval with a scope, an amount cap and a call budget. An operator opens one from Operations Controls with an authenticator code, one sitting at a time, limited to $5 per order, 40 calls, $20 in total and 4 hours. There is no live mode in the code, and the build fails if a live PayPal host appears.
  • AI in the product. A Claude adapter turns a buyer's plain words into a search and proposes a pack. It uses read-only tools, never sees payment data, has a daily spend cap and a stop switch, and falls back to a scripted model. It is off on the hosted demo, where the scripted model composes packs.
  • How we worked. One written spec per task, tests written first, and a separate review before every merge. We have six test suites (unit, state, contract, integration, adversarial and golden), mutation testing on money paths, browser journeys and a secret scan over the full git history.
  • Simulation. A separate simulation repository models the micro-ledger, netting, buyer pools, seller pools, matching and payouts with a fixed seed, so the same inputs give the same numbers every time.

Challenges we ran into

  • Paying several publishers on one approval. One buyer approval has to become several PayPal payments, with a safe stop if one of them fails partway.
  • Testing against a real payment service safely. We designed the two-key approval, kill switches, call budgets and append-only approvals before the first sandbox call. When a secret was pasted by mistake, we rotated it within the hour and logged it.
  • Making the journal trustworthy. Our own verify check found 223 journal rows with no actor. The cause was two copies of the trace context in the production server. We fixed it, and unattributed rows are now zero.
  • Agents under concurrency. A cap that holds for one request can break under twenty parallel ones. We made the cap check and the order creation one transaction and proved it with an adversarial test.
  • Staying honest. It is tempting to blur the line between what runs in the sandbox and what runs in the simulation. We label every screen from stored data, never from a hard-coded string.

Accomplishments that we're proud of

  • Real PayPal sandbox payments, read back and verified before any access opens.
  • A payment path that fails closed: no approval row, no call.
  • An agent cap that holds exactly under parallel load.
  • Every money change traced in a journal that anyone can verify.
  • A simulation showing fees on 10,000 micro trades falling from $4,926 to $83 (about 59 times lower) when priced at PayPal's published rates, with rate eligibility still to be validated.
  • Pooled sellers filling every bundle that no single small publisher could fill.

What we learned

  • A payment agent is mostly a safety problem. The hard question is not how to make the call. It is what must be true before the call leaves the app, and how a person stops it.
  • A payment response is a claim. We read every capture back before trusting it.
  • Small payments are a volume problem, not a price problem. Per-trade fees stay flat however many trades you make. In our simulation, a ledger and pools make the cost per trade fall as volume grows:

$$ \text{cost per trade} = \frac{\text{fees on } N \text{ trades}}{N}: \quad \frac{\$4{,}926.47}{10{,}000} \approx 49\text{ cents alone}, \qquad \frac{\$83.40}{10{,}000} \approx 0.83\text{ cents with the ledger} $$

  • AI speeds up building only with discipline. Claude wrote and reviewed much of the code. What made that safe was a written spec per task, tests first, and an independent review before every merge.

What's next for UnitMarket

  • Bring buyer pools, seller pools and the netting ledger from the simulation into the product, settled through PayPal.
  • Pay each publisher directly into their own PayPal account.
  • Add compliance, disputes and payouts.
  • Agentic buyer search. Today an agent searches the UnitMarket catalogue through MCP tools and proposes a pack. Next, an agent will keep watching for new units that match a buyer's standing request, compare offers across publishers and buy within the buyer's cap without a fresh prompt.
  • Work with PayPal on pricing designed for automated micro trades.

Built With

Share this project:

Updates

Submission history