x402 and Machine Payments: What Actually Ships When an Agent Pays

HTTP 402, finally used

Status code 402 sat reserved in the HTTP spec for decades with no agreed semantics. x402 gives it one: a server responds 402 with payment requirements, the client settles, and retries with proof of payment attached.

The elegance is that it needs no new transport. Any HTTP client can implement it, the payment step is explicit rather than hidden in an out-of-band billing relationship, and there is no account provisioning before the first call. For agent-to-agent commerce that last property matters more than it sounds — an agent discovering a service at runtime cannot complete a signup flow.

What Stripe’s approach adds

Stripe’s Machine Payments Protocol comes at the same problem from the conventional rails: issued credentials, programmatic authorisation, and spend controls that a finance team can reason about.

The trade is legibility against openness. x402 is a protocol anyone can implement against any settlement mechanism. MPP is an implementation with a company behind it, existing compliance posture, and controls that already fit how businesses account for spend. Neither is strictly better — they suit different buyers.

The part both leave to you

Read either specification to its terminal state and you arrive at the same place: payment confirmed. Correct scope for a payment protocol, and also where the interesting problems start.

Once money has moved, four questions remain open, and none are addressed by either protocol:

• Did the work happen? Payment confirms transfer, not delivery.
• Was it the work described? Nothing binds the payment to a specific execution with specific inputs.
• Who adjudicates? At sub-penny values no dispute process can cost less than the transaction.
• How does the buyer check without asking the seller? Asking the paid party whether they delivered is not verification.

Designing the layer above

Whatever sits above these rails needs three properties, and they follow from the questions rather than from taste.

Bind payment to execution. The receipt must reference the specific task — its inputs, its outputs, its cost — not merely that an amount moved between parties.

Make it checkable offline. If verification requires calling the platform, the platform remains the authority and nothing has changed. Sign the execution and publish the key.

Charge before crediting. The ordering is not stylistic. Credit the seller first and any failure between the two steps creates earnings with no corresponding charge — a bug that silently destroys a marketplace’s books and is invisible until reconciliation.

Where to start

If you are building on these rails today, the practical sequence is: implement the payment protocol that matches your buyers, define what a receipt must contain before writing any settlement code, and make the receipt verifiable by a third party from the first version.

Retrofitting verification is considerably harder than designing for it, because the receipt format has to be right before there is any history to be compatible with.