Agent Payment State Is Not Purchase State

When an agent pays for a resource, payment success is only one fact about the purchase.

The surrounding system still depends on purchase permission, duplicate payment checks, delivery status, and a way to interpret failed responses.

Here, state means facts required to determine what happened after the agent acted.

Payment state means whether payment was verified or settled.

Purchase state means whether the buyer’s purchase intent completed correctly: permitted buyer, paid once, delivered resource, and enough evidence to resolve failure.

For this experiment, those facts include who paid, purchase permission, duplicate payment checks, delivery status, and evidence used to resolve a disagreement.

This builds on the thesis that agent failures become infrastructure problems when model output crosses into tools, credentials, and side effects. Payments make that boundary easier to inspect because side effects are concrete: money either moved or it did not.

x402 is the test case here because it gives HTTP services a payment path. A seller can return 402 Payment Required, a buyer agent can submit a signed payment, and the seller can verify and settle through a facilitator.

The experiment did not evaluate x402 as a complete product, it tested scenarios around a minimal x402-style flow to see which facts the payment rail resolved, and which facts remained outside it.

Assumption tested was simple:

If payment succeeds, an agent purchase action can be treated as complete.

The experiment did not support that assumption.

Experiment code and observations are at agent-control-lab/001-x402-payment-state.

Required System Facts

In this experiment, a buyer agent means a client program that holds a buyer wallet and makes the paid HTTP request. Seller means the service protecting the resource. Facilitator means the service verifying and settling payment.

The relevant system facts are:

• authorization: was the buyer agent permitted to make the purchase?
• duplicate payment: has this purchase already been paid for?
• settlement: did payment settle?
• delivery: did the seller deliver the resource?
• resolution: if parties disagree, what evidence resolves it?

x402 settles one part of this state. Completing the buyer’s purchase intent depends on the rest.

Test Harness

The experiment used a minimal x402-style payment flow:

• Express seller using @x402/express
• Python buyer agent handling the 402 -> pay -> retry flow
• Base Sepolia USDC
• public x402 facilitator for successful settlement
• local mock and proxy facilitators for failure scenarios

Protected resource: GET /resource.

Price: $0.001 USDC.

The experiment tested three scenarios:

1. unauthorized purchase
2. crash and retry
3. settlement confirmation loss

Each scenario starts from the same question: after the payment rail has done its part, what facts are still unresolved?

Scenario 1: Was the Buyer Agent Permitted to Make the Purchase?

In the first run, a buyer agent requested a protected resource. Seller returned 402 Payment Required, the buyer agent paid, and seller returned the resource.

Payment flow succeeded, but one fact was needed before payment:

Was the buyer agent permitted to make this purchase?

The flow proved that the buyer agent could pay from the wallet. It did not prove that the buyer agent had permission to make that purchase.

For a human buyer, this context often lives outside the payment protocol. The human knows what they meant to buy, whose money they are using, and why they are proceeding. A buyer agent may only see a payable HTTP response and a signing tool.

Observed pattern:

paid request without purchase permission

The payment rail can be correct while the permission decision lives somewhere else.

Scenario 2: Was This a Retry or a New Purchase?

A buyer agent paid once and received the resource. Then the test simulated a crash before the buyer agent saved a local receipt.

After restart, the buyer agent requested the same resource again. Seller returned another 402. The buyer agent paid again, seller delivered again.

Both payments were valid, but retry state was unresolved.

From the rail’s view, two valid payment authorizations arrived. From the buyer agent’s view, this was one intended purchase retried after a crash.

Missing fact:

Is this a new purchase, or a retry of an existing purchase?

A purchase ID is a stable identifier for the resource purchase the buyer agent is trying to complete. With a purchase ID, the system can check whether a retry belongs to an existing purchase before it signs another payment.

Observed pattern:

crash retry becomes second payment

Without a duplicate-payment guard, retry logic can spend twice.

Scenario 3: Did Settlement Lead to Delivery?

The third scenario placed a proxy facilitator between seller and real facilitator.

Proxy forwarded verification and settlement upstream. Upstream settlement succeeded, then the proxy withheld the successful settlement response and returned a failure to seller.

Result was split system state:

• real facilitator: settlement succeeded
• chain: payment moved
• seller: settlement confirmation failed
• buyer agent: paid request failed
• resource: not delivered

The payment rail moved value, but delivery and resolution did not converge.

Missing facts:

• did the seller receive enough confirmation to deliver?
• did the buyer agent receive enough evidence to stop retrying?
• if settlement happened upstream, where can the buyer agent retrieve that proof?

Observed pattern:

settled payment without delivery resolution

If buyer agent, seller, facilitator, and chain do not expose a resolution path, retry behavior depends on local policy rather than a shared settlement fact.

Failure Class

Failure Class: payment state treated as purchase state

This class appears when a system treats successful payment as enough to complete an agent purchase.

In the tested flow, x402 resolved payment state: a buyer agent submitted payment, the seller verified or settled it, and the protected resource could be released.

The remaining purchase facts lived outside the rail:

• was the buyer agent permitted to make the purchase?
• has this purchase already been paid for?
• was the resource delivered after payment?
• if settlement succeeded but confirmation failed, which fact should the buyer agent trust?

The failure condition is narrow: payment succeeds or settles, but the surrounding system cannot prove the purchase was permitted, paid once, delivered, and resolved.

Observed forms:

1. paid request without purchase permission
2. crash retry becomes second payment
3. settled payment without delivery resolution

Design implication: when payment is embedded directly into an agent request path, the system still needs a purchase-state layer around the rail.

A Minimum Purchase State Model

The experiment points to a small state model around agent purchases.

The payment rail resolves payment state, completing the buyer’s purchase intent still depends on at least four other facts:

• authorization: whether the buyer agent was permitted to make the purchase
• duplicate payment: whether this purchase has already been paid for
• delivery: whether the paid resource was delivered
• resolution: how the buyer agent resolves disagreement after a failed response

The payment rail does not have to own these facts, but an agent payment system has to account for them somewhere.

A minimal implementation would include:

1. permission check
2. purchase record
3. duplicate-payment guard
4. durable receipt
5. delivery record
6. resolution path
7. audit evidence

The boundary is narrow but important: settlement closes payment state, not full purchase state.

References

x402 open standard: x402: An Open Standard for Internet-Native Payments

x402 repository: x402-foundation/x402

Circle testnet faucet: faucet.circle.com

Experiment reproduction: agent-control-lab/001-x402-payment-state