Menu
← FIELD NOTESPAYMENTS 2026.08.08 · 13 min

The agent pays first, and the API can keep the money without doing the work.

x402 settles on-chain before the service is delivered, and crypto's irreversibility deletes the chargeback that backstopped pay-first commerce. 'Take the money, skip the work' is not a vendor risk you screen for — it is the default the protocol's happy path permits.

Here is the sequence almost nobody on a team adopting x402 says out loud, because the demo never makes them. The agent hits a priced endpoint, gets back HTTP 402, signs a payment, the payment settles on-chain, and then the resource server does the work and returns the result. Read that ordering once more: the money finalizes on the blockchain in a step that comes before the service is delivered. The agent has paid, irreversibly, for something it has not yet received and has no protocol-level guarantee it ever will. In the demo this is invisible, because the server in the demo is honest and the network is healthy. The ordering only becomes the whole story the first time the server is neither.

Call it what it is. Pay-first commerce existed for humans long before agents — you tap a card before the goods ship all the time — but it worked because a thick layer of recourse sat underneath it. If the goods never came, you filed a chargeback, the card network clawed the money back, and the merchant who took your payment and shipped nothing ate a reversal. That backstop is invisible precisely because it almost never has to fire; its existence is what makes paying first safe. x402 keeps the pay-first shape and removes the backstop: settlement is on-chain, on-chain settlement is final, and a final payment has no chargeback. What is left is pay-first commerce with the one mechanism that made it survivable quietly deleted.

This post is about that deletion and why it is structural, not incidental. “Take the payment, withhold the service” is not an edge case a careful provider screens out — it is the default the protocol’s ordering permits, on the happy path, with every cryptographic check passing. And the fix is not “use a more honest provider” or “add a flag”: it is an atomic exchange that binds payment to delivery so the money finalizes if and only if the result is delivered — a mechanism the shipping rails do not have.

The builders confirm the ordering — it is a feature, not a bug report

The cleanest way to establish that this is real and not a strawman is to read what the people building x402 rails say the ordering is. They do not hide it; they present settle-before-deliver as a feature, because from inside the payment layer it is one.

Towards Multi-Agent Economies: Enhancing the A2A Protocol with Ledger-Anchored Identities and x402 Micropayments for AI Agents (arXiv 2507.19550) is a primary source from builders extending Google’s Agent2Agent protocol with x402, and it states the sequencing plainly. By using EIP-3009, it writes, the architecture lets agents delegate payment execution to the recipient or a third party, ensuring “trustless, verifiable, and efficient micropayment settlement before service delivery.” The end-to-end flow is more explicit still: the payment is settled via the facilitator, which submits the transaction to the blockchain and pays the fees, and “finally, the resource server processes the A2A request and responds with the requested data or service.” Validation, then on-chain settlement, then delivery. The money lands first; everything after depends on the server choosing to deliver, and the protocol has nothing to say about that choice.

Why “take the money, skip the work” is the default, not a risk you screen for

The reason this is structural — a property of the shape, not of bad actors — is that the blockchain, the thing making the payment trustless, cannot referee the part of the deal that matters. A402: Binding Cryptocurrency Payments to Service Execution for Agentic Commerce (arXiv 2603.01179) states this post’s thesis as its own motivating problem. Its limitation L2: “x402 enforces a payment-first workflow in which on-chain payment confirmation precedes result delivery. As a result, a malicious or failed service provider can withhold service responses after receiving payment. This violates fair exchange of payment and service response.” That is the take-the-money-skip-the-work outcome named as a direct consequence of the ordering — not a bug in one implementation, but a property of the workflow.

And the reason the chain cannot fix it from underneath is specific. A402 walks the payment-channel version: if the client co-signs an updated balance state before receiving the service result, a malicious server can immediately close on that state to finalize the payment on-chain while aborting execution. The point to carry: “in both cases, the blockchain cannot enforce fairness because channel settlement lacks verifiable evidence of off-chain execution.” Settlement records that value moved; it carries no proof the service ran. The chain sees the payment and is blind to the delivery, so it finalizes what it can see and leaves what matters unverified. That blindness is why withholding-after-pay is not behavior the protocol resists — it cannot distinguish it from the honest case.

The gap cuts both ways, which is the tell that the binding is missing rather than one party being malicious. A402’s limitation L1 names the server’s exposure: “service providers must execute requests optimistically before payment finalization, exposing them to non-payment risks. Moreover, facilitators broadcast payments without verifying that execution has been actually carried out. All these situations violate the atomic binding of execution and payment.” Withhold-after-pay and free-ride-after-deliver are two faces of one absent link: whichever side moves second is fully exposed to the other’s choice to defect, because nothing ties the two events together.

The missing chargeback, in protocol terms

The human intuition that pay-first is fine rests entirely on reversibility, and the security analysis of x402 is where reversibility’s absence becomes concrete failure modes.

Five Attacks on x402 Agentic Payment Protocol (arXiv 2605.11781) formally analyzes the protocol and reports that all five attacks it presents are practical and “can cause either unpaid service or paid-but-denied outcomes” — exactly the two failure modes of a broken pay-first exchange: you pay and get nothing, or you get the service without paying. The root is in the settlement path, which “may fail to bind the on-chain caller, facilitator, resource, and service decision into one atomic object.” Payment and delivery are separate events, and nothing welds them.

The chargeback point lands hardest in the paper’s words on rollback: “after the server releases the resource, later settlement failure or cache reuse cannot be naturally rolled back.” That is the missing chargeback in protocol terms — once the resource is out, a later failure cannot be reversed: no clawback, no network to appeal to, no analogue to the card dispute that backstops human pay-first commerce. The reversibility that made paying first survivable has no counterpart here, and you cannot paper over its absence with reputation between two agents that met at runtime and will never transact again.

The attacks make the asymmetry measurable. Attack I-B, “settlement preemption,” is the take-the-money-skip-the-work case made concrete — a caller-unbound settle yields payment without service. Its mirror, Attack I-A “revert-grant,” produces unpaid service after a settlement failure, and the exposure scales with trust in the facilitator: revert-grant probability reaches up to 5.18% with honest facilitators, and 100% under a Byzantine facilitator. A facilitator that turns malicious does not merely raise the odds of a bad outcome — it makes it certain. The pay-first shape, with no reversal underneath it, hands that much leverage to the party between caller and chain.

The fix has a name, and it is older than x402

The encouraging half is that “bind payment to delivery” is not an open research problem. It is a named property with known constructions, which makes the absence in x402 a design choice rather than a hard limit — the hard part was solved; the shipping rail simply did not adopt it.

A402’s own answer states the target property exactly: it designs “an atomic exchange protocol that combines TEE-based enforcement with adaptor signatures, which guarantees that a payment is finalized if and only if the request is correctly executed and the corresponding result is delivered, thereby enforcing the atomicity across execution, payment, and delivery.” Read the shape, not the cryptographic parts list. It re-couples the two events x402 separated, so “money finalized” and “result delivered” become one indivisible thing — no “after the payment but before the delivery” window remains for a server to settle and abort.

The same if and only if predates the agent-payment scramble entirely. Atomic and Fair Data Exchange via Blockchain (published at ACM CCS 2024) builds a fair data exchange where “the client receives the file if and only if the server receives an agreed-upon payment,” via verifiable encryption that lets the client check the delivered data against an agreed commitment before any payment unlocks the decrypting key. And it is cheap: trust-minimized, with constant-sized on-chain communication — “specifically 3 signatures, 1 verification key, and 1 secret key, with most of the data stored and communicated off-chain.” That is the load-bearing fact. x402’s missing binding is not missing because binding is impossible or expensive; it was left out.

Content delivery has its own constant-cost construction. FairRelay: Fair and Cost-Efficient Peer-to-Peer Content Delivery through Payment Channel Networks (arXiv 2405.02973) introduces an Enforceable Accumulative Hashed TimeLock Contract “designed to guarantee payment atomicity — ensuring all participants receive their payments upon successful content delivery.” Payment is conditioned on delivery, not a prior settlement, and the cost retires the objection that fairness is a luxury: zero on-chain cost on the optimistic honest path, and even contested disputes are constant — 24,902 gas for relayers (0.01 USD on Optimism L2) and 290,797 gas for customers (0.07 USD), under 1.5% overhead on a 10-hop path. Its fairness is “proved using the Universal Composability (UC) framework” — a provable property, no party able to profit by defecting, not a vibe.

Between these, the field has both the property and the proof that it costs almost nothing on the optimistic path. The atomic exchange A402 reaches for is the answer FairRelay and the CCS data-exchange work already built in their own domains. x402 is the outlier for not having one.

Why the missing chargeback bites harder than it looks

It would be comfortable to conclude “so just add an arbiter,” but the theory says the situation is worse than a missing convenience, and being precise keeps the fix honest.

On the Impossibility of Fair Exchange without a Trusted Third Party (Pagnia and Gaertner, TUD-BS-1999-02, 1999) formally defines strong fair exchange — the buyer pays if and only if it receives — and proves that “it is impossible to solve strong fair exchange without a trusted third party,” relating the problem to consensus via the Fischer–Lynch–Paterson impossibility result. Strip the chargeback out of pay-first commerce and add nothing in its place, and you have not landed on a riskier version of the same deal; you have landed on a problem with no goodwill-based solution at all. The impossibility is a theorem.

The same work establishes that “strong fair exchange is at least as hard as consensus,” which tells you what the fix has to be. Because the property is consensus-hard, you cannot retrofit it as a config option or a header field. It takes a real mechanism — escrow with deterministic release, a trusted execution environment, an adaptor-signature binding, an arbitration oracle — playing the role the theorem says you cannot do without. The thing x402 removed was load-bearing, and replacing it is at least as hard as agreement itself.

What this argument does not claim

Two qualifications, because the version of this that overstates loses the reader who actually ships on x402.

First, this is not the claim that x402 is broken in the sense of “does not move money,” or that the pay-first rails should not have been built. The rail does its job: it makes a web-native per-call micropayment ordinary, settling stablecoin value between parties with no human in the loop, and the x402 economy it opens up is real — the A2A-plus-x402 builders above treat these as working rails, not a thought experiment. The narrow claim is about one seam — settlement precedes delivery and nothing binds them — not the rail’s competence at what it was built to do. A team can adopt x402 and be right to; what it cannot do is read “the payment settled and the call returned in the demo” as “the exchange is fair when the server defects.”

Second, the fixes are proposals and constructions, not a finished standard you can drop into an x402 deployment tomorrow. A402 is a proposed design; the CCS data-exchange protocol and FairRelay are constructions proven in their own settings, not x402 modules. The honest status: the field has named the property and shown it is buildable cheaply, while x402 still ships without it. The gap is closable — mechanism shape known, cost objection answered — but “closable” is not “closed,” and a team on x402 today relies on a rail whose atomicity gap is still open. Binding payment to delivery, where the counterparty supports no atomic flow, falls to the application layer — an escrow of the kind escrow and dispute resolution for agent commerce describes, sized to what is at stake.

What to build or demand, given the gap is still open

Stop treating settlement as the end of the exchange; treat delivery as the condition the payment is bound to. When evaluating any agent-payment design, ask the one question x402’s happy path obscures: does the payment finalize if and only if the service is delivered? If the answer is “settlement happens first and delivery is the server’s choice,” you are buying a payment rail, not a fair exchange — price it, and bound it, as exactly that.

  • You can state, for your chosen rail, whether settlement precedes delivery or is bound to it — and you have not assumed binding the demo never showed.
  • Where the counterparty supports it, payment runs through an atomic or escrowed flow that finalizes only on verified delivery — an A402-style service channel or an escrow that releases on delivery and refunds otherwise.
  • Where only bare pay-first is available, the decoupling is a named, accepted risk with a per-call spend ceiling sized to a loss you can absorb without recourse.
  • The facilitator’s possible misbehavior is in the threat model — revert-grant exposure scales with its honesty — and the caller is bound into settlement so a caller-unbound settle cannot separate payment from service.
  • Nobody on the team believes a chargeback or clawback exists for a finalized on-chain payment — because it does not.

Reading list

The agent pays first because the protocol settles first, and the protocol settles first because the chain can see a payment and cannot see a delivery. That ordering would be survivable if a chargeback sat underneath it, the way one sits under every card you tap before the goods ship — but on-chain finality has no chargeback, so the mechanism that made pay-first commerce safe for humans is gone. What remains is not a vendor you screen out but a default the shape permits: take the money, skip the work, the buyer with no recourse and the chain no objection. The exit is the one fair exchange has always required — bind payment to delivery so the two finalize together or not at all. The constructions exist and the cost is small; the rail just does not have it yet, and until it does, that binding is yours to build.

NEW ENGAGEMENT · INTAKE

Tell us about it.

The more specific you are, the more useful our first reply.

SERVICE AREA
↩ ENCRYPTED IN TRANSIT
ASK THE FIELD NOTES BETA