On the market page a visitor sees a 402 quote and a retry-with-a-payment-header. On the agents page the same visitor sees an invoice, an exact amount, and a separate collect. With nobody to explain it, those look like two unrelated products. They are not. They are the same track, entered through two different doors.
The confusion is worth heading off precisely because it's so easy to have. So here is the whole thing in one frame: one settlement track, two ways to ask.
One settlement track
The settlement layer is single. A facilitator that verifies and settles, one chain, dUSD as the unit, and keys that carry a boundary — a spend cap, an expiry, an instant revoke. That layer is dfmi. Everything above it is only how you open the conversation. Both doors below settle through the exact same facilitator on the exact same chain.
Two ways to ask
A handshake where paying is delivery
The buyer reaches for the goods, gets a 402 with a quote, and retries with a payment header. The server settles and delivers in the same HTTP round-trip. Stateless, one and done. Like tapping a card for a coffee.
Bill, pay, collect — with a ledger
The buyer asks for an invoice first and gets an id and an exact amount. Paying is an on-chain transfer; collecting is a separate call that can come seconds or days later. Stateful — open, paid, overdue — with a ledger to query and chase. Like placing an order, wiring the money, then picking up against the receipt.
Side by side
| x402 · 402 handshake | invoice · paykit / buykit | |
|---|---|---|
| Start | Buyer reaches for the goods, is refused, and gets a quote. | Buyer asks for a bill first, and gets an id and the exact amount. |
| Pay & deliver | Same HTTP round-trip: retry with a payment header, the server settles and delivers on the spot. | Two separate steps: paying is an on-chain transfer, collecting is another call — seconds or days apart. |
| Who verifies | The server hands the payment header to the facilitator to verify and settle, and trusts its reply. | The seller reads the chain itself and checks the exact amount arrived — trusting no one's reply. |
| Matching | This one request is bound to this one payment. | A unique decimal tail (0.020287) binds the payment to the bill id. |
| State | Stateless — one and done. | Stateful: open / paid / overdue — queryable, chaseable, reconcilable. |
| After a failure | Retry, and it's a brand-new charge. | The same bill can retry payment; paid once, never charged twice (idempotent). |
| Fits | One-off API calls, per-call metered services, a human tapping to buy. | Agent-to-agent business, deals that need terms and records, asynchronous flows. |
| Directory | bazaar knows it natively: probe the 402 quote and it's alive. | bazaar can't see it — unless the seller also opens a 402 endpoint. |
When to use which
Reach for x402 for one-off API calls, per-call metered services, and human-taps-to-buy. Reach for an invoice for agent-to-agent business, for anything that needs terms and a record, and for asynchronous flows where paying and collecting are pulled apart in time.
It was never two payment systems. It's one settlement track with two front doors.
x402 is a handshake where paying is delivery. An invoice is bill, pay, collect — three steps with a ledger in between. One is tapping a card for a coffee; the other is order, transfer, then pick up against the receipt. On dfmi the two coexist, and both settle on the same facilitator and the same chain.
Read the field notes:
Drawn from the dfmi implementation and standard x402 / EIP-3009 practice. Both flows settle through the same public facilitator on chain 112172. dUSD is a meter, not an asset.