DEV Community: Bryant rudolph

Preventing Autonomous Agent Double-Purchasing

Bryant rudolph — Sat, 24 Oct 2026 19:47:37 +0000

An agent retries a tool call. The tool call was a purchase. The merchant receives two valid orders. The agent's ledger records one transaction. The buyer's bank statement shows two.

This failure mode is a known hazard in agentic commerce, and it isn't a bug in any single component. It's the predictable result of three design decisions that were each reasonable on their own:

Agents retry. Reliable agent design requires retry logic. Network calls fail, timeouts happen, models hallucinate transient errors. The standard remedy is to retry until the call succeeds.

Purchases are non-idempotent by default. A POST to create an order creates an order. A second POST creates a second order. Nothing in the merchant's API distinguishes "this is a retry of the same intent" from "this is a new purchase."

Settlement is asynchronous. The agent's tool call returns when the order is acknowledged, not when the payment settles. Between acknowledgment and settlement, the agent has no signal that the purchase is already in flight.

The combination is a race condition. Retry logic fires before the settlement confirmation arrives. The agent sees no successful response to the first attempt. It retries. The merchant processes both.

Retries are bounded, and unknown outcomes must be reconciled. A retry loop is not infinite: a well-designed agent retries a bounded number of times, with backoff, and then stops and escalates. The hard case is the request whose outcome is genuinely unknown — the call timed out, or the response was lost in transit. The agent cannot safely assume the first attempt failed. It must reconcile the uncertain outcome before retrying: check the merchant's order state, the agent's own ledger, or the commitment record for evidence that the purchase already happened. Retrying on an absent response alone is how double-purchases get created.

Why this is different from consumer double-charges
Consumer double-charges are typically a payment-processor bug — the same authorization submitted twice by accident. The consumer notices on their statement and calls the bank. The card network has a straightforward remedy: reverse the duplicate.

Agent double-purchases are structural, not accidental. The agent was designed to retry. The merchant was designed to accept valid requests. The payment rail was designed to settle what it receives. Everyone behaved correctly within their own boundary. The failure lives in the gap between them — the missing record of what the agent was actually trying to commit to.

The partial fixes that don't fully work
Idempotency keys. The standard remedy for non-idempotent APIs. The client sends a unique key with the request; the server treats duplicate keys as the same request. Durable idempotency keys do work for agents — provided the key is persisted and reused across retries, session restarts, and process boundaries, so the same intent always carries the same key. The failure mode is a regenerated key: if the agent loses the key or creates a fresh one on retry, the server sees a brand-new request. And when the agent cannot tell whether the first request ever arrived, it still needs a reconciliation step, not just a key.

Nonce-based authorization. Payment protocols like EIP-3009 require a unique nonce per authorization. The chain rejects a second settlement with the same nonce. This prevents double-settlement. It does not prevent double-order — the merchant may have already accepted both orders before either authorization reaches the chain.

Spend limits. A cap on total spend per agent per period. This bounds the damage but doesn't prevent the double-purchase itself. It also fails when the double-purchase is within the limit.

Tool-call deduplication. The agent runtime refuses to execute the same tool call twice within a short window. This works when the runtime has a stable view of what "the same tool call" means. It fails when the retry happens across process boundaries, session restarts, or model context resets.

Each of these addresses part of the problem. None addresses the record that makes the duplicate detectable and enforceable in the first place.

What's actually missing
The missing piece is a commitment identifier that is generated before the purchase attempt and that both the agent and the merchant treat as authoritative.

This is different from an idempotency key. An idempotency key is generated by the client and honored by the server. A commitment identifier is generated as part of the commitment itself — before the agent attempts the purchase, before the merchant receives the request, before either party has committed to anything.

The commitment record binds:

The specific intent (what the agent is trying to buy)
The authority (what the agent is allowed to buy, under what limits)
The terms (price, deliverable, deadline, acceptance criteria)
The unique commitment identifier that ties the retry to the original intent

When the agent retries, the retry carries the same commitment identifier. When the merchant receives the second request, it recognizes it as the same commitment. But a commitment ID does not prevent a duplicate by itself — it only makes one detectable. Prevention requires enforcement: the merchant's execution path must perform durable deduplication keyed on that ID before processing, and the payment rail must reject a second settlement of the same authorization. Where the outcome of an attempt is unknown, recovery must reconcile against on-chain state and the commitment record rather than assuming a retry is safe from an absent response.

How SAAX handles this
SAAX Protocol treats the commitment as the primary artifact of the purchase. The commitment is created before execution begins, and it carries an identifier that survives retries, session restarts, and process boundaries.

A SAAX commitment includes:

A unique commitment ID, generated at commitment time
The authority reference (who authorized this commitment and under what scope)
The terms (what the commitment obligates the parties to)
The evidence requirements (what counts as fulfillment)
The recovery policy (what happens if fulfillment fails)

When the same intent is retried, the retry references the same commitment ID. The merchant, the agent, and the settlement rail all work from the same record.

The commitment schema, the lifecycle states, and the evidence interface are documented in the commitment lifecycle specification. The conformance suite pins down the standard's tested behavior. For how the same commitment ID is carried in real payments, see the integration guide.

Originally published on SAAX Protocol.

SAAX runs immediate payments live on Base mainnet, with escrow flows on testnet only — see the current status page before relying on any flow.

Find SAAX on x402scan: SAAX Router on x402scan.

Agentic Commerce Protocols Explained: AP2, x402, ACP, and UCP

Bryant rudolph — Mon, 12 Oct 2026 20:16:15 +0000

The infrastructure for agentic commerce is being built at an unprecedented pace. Four major protocols are competing to define how agents authorize, pay for, and complete transactions. Here is what each one does, what it doesn't, and where the gaps remain.

AP2 (Agent Payments Protocol)

Google's protocol, launched with 60+ partners including Mastercard, PayPal, American Express, and Coinbase. AP2 introduces Verifiable Credentials — Intent Mandates, Cart Mandates, and Payment Mandates — that cryptographically capture user authorization and intent. The goal is to solve the "crisis of trust" inherent in autonomous agent payments.

What it handles: Authorization.

What it doesn't: It does not record what the agent actually committed to, what counts as fulfillment, or what happens when the deliverable doesn't match the agreement.

x402

Coinbase's protocol, released four months before AP2 appeared. It revives HTTP status code 402 ("Payment Required") and makes payment a native HTTP operation. Request a paid resource, receive a 402 response with payment terms, send payment, get the resource. By October 2025, x402 processed 500,000 weekly transactions.

What it handles: Settlement.

What it doesn't: It does not verify whether the deliverable matched the agreed terms. It proves payment moved, not that fulfillment occurred.

ACP (Agentic Commerce Protocol)

OpenAI and Stripe's protocol, currently in beta. It defines the Agentic Checkout Specification (ACS) as a REST API contract for agents to complete purchases. The merchant remains the system of record — same principle as UCP, but more focused on the checkout flow.

What it handles: Checkout.

What it doesn't: It does not provide a structured commitment record that survives the transaction. The checkout completes; the record of what was agreed is held by the merchant, not by a neutral artifact both parties can reference.

UCP (Universal Commerce Protocol)

Google's broader commerce protocol, co-developed with Shopify, Etsy, Wayfair, Target, and Walmart. UCP lets merchants declare their capabilities (product listing, cart management, checkout, returns) through a standardized profile, and agents discover those capabilities dynamically.

What it handles: Capability discovery.

What it doesn't: It does not bind the terms of a specific transaction. Discovery is the first step; commitment is the record of what was actually agreed.

The gap none of them close

Each protocol handles a different piece of the agent commerce stack. AP2 handles authorization. x402 handles settlement. ACP handles checkout. UCP handles capability discovery.

None of them handle the commitment layer — the structured record of what the agent actually agreed to, what counts as fulfillment, and what happens when fulfillment fails.

This is the gap that matters when something goes wrong. A signed payment mandate proves the transaction was permitted. It does not prove the deliverable matched the agreement. When an agent buys wrong, there's no structured record to resolve the dispute against.

What a commitment layer adds

A commitment layer records the authority, terms, acceptance criteria, evidence requirements, and recovery policy before execution begins. It survives the transaction. It is the artifact both parties work from if something goes wrong.

If the agent retries and double-charges, the commitment ID prevents it. If the fulfillment doesn't match the agreement, the commitment record is the evidence. If a dispute arises, the recovery policy was set at commitment time, not negotiated after the fact.

The spec is at saax-protocol.com/spec. The conformance suite is at saax-protocol.com/conformance. The commitment lifecycle, the evidence interface, and the settlement-linkage model are documented there.

Building a revenue path for registered agents — looking for collaborators

Bryant rudolph — Sat, 10 Oct 2026 12:09:44 +0000

I've been building infrastructure for agent-to-agent commerce and I'm at the point where the technical foundation works but the demand side is empty. I'm looking for people who want to build revenue on top of it.

What SAAX does, in one line: it's a commitment layer that records what an agent agreed to, verifies fulfillment, and handles recovery if it fails. It sits between authorization (AP2, ACP) and settlement (x402, MPP, card networks).

What's live right now:

MCP endpoint at https://www.saax-protocol.com/mcp with 10 tools

Commitment lifecycle with persistent storage

Public spec, conformance suite, integration docs

Registry listing on the MCP Registry and Glama

Where I want to go with it:

Two directions I think are viable right now, and I don't have the bandwidth to pursue both:

Direction 1 — Registered agents selling services. An agent registers its capability (data retrieval, code review, translations, security scans, etc.), and SAAX routes demand to it. The agent gets paid per job. The routing and settlement already work. What's missing is agents that actually have services to sell.

Direction 2 — Businesses sending agents to purchase. A business has an agent that needs to buy something from a supplier. SAAX records the commitment, verifies the delivery, handles the payment, and writes the audit trail. The infrastructure exists. What's missing is businesses that have agents transacting at a volume where the commitment layer is worth using.

What I'm asking:

Is this useful to anyone here? If you're running an agent that has a service to sell, or you're building a system where agents transact with external suppliers, I'd like to hear where it breaks for you and what would need to exist to make it work.

If you're interested in building revenue on top of this — as an agent operator, a supplier, or a partner — I'm open to conversations. No token, no pitch deck. Just a working protocol looking for its first users.

Spec is at saax-protocol.com/spec. MCP endpoint is live and free to test. Reply here or reach out at support@saax-protocol.com.

SAAX Protocol: A Commitment Layer for Agentic Commerce

Bryant rudolph — Sat, 10 Oct 2026 11:53:37 +0000

When an AI agent buys something and the purchase goes wrong, the parties usually discover the same problem: there is no structured record of what was actually committed.

The authorization was valid. The credentials were real. The merchant fulfilled a legitimate order. The buyer is looking at a charge for something they never intended to purchase. Card networks were built for a two-party dispute. Stablecoin rails were built for instant, irreversible settlement. Neither was designed to answer the question that matters here: what did the agent actually commit to, and did the merchant deliver it?

I've been building a protocol layer for this problem. It's called SAAX Protocol — Solvent Applied Autonomous Exchange Protocol. A vendor-neutral commitment lifecycle for autonomous commerce.

The gap in the stack
Most agent commerce infrastructure handles two layers:

Authorization — proves that a party with valid credentials authorized a specific transfer of value. This is what AP2, ACP, and the card networks handle.

Settlement — moves the value on the specified rail. This is what x402, MPP, and payment processors handle.

Between them, there's a missing layer: the commitment. What the agent actually agreed to, what counts as fulfillment, what proves it, and what happens when it fails.

Without the commitment layer, the payment layer is trying to do work it was never given the terms for. It approves transactions it should not approve and disputes transactions it cannot evaluate.

What a SAAX commitment records
A commitment binds five things before execution begins:

Authority — who authorized the agent to act, under what scope, with what limits

Terms — what was agreed: price, deliverable, deadline, conditions

Acceptance criteria — what objectively counts as fulfillment

Evidence requirements — what proof must be submitted

Recovery policy — what happens if fulfillment fails

The commitment is issued before payment. Evidence is attached as references. Outcome and finality states are recorded against the same commitment.

The in-flight state
The hardest case is what happens when the agent's first attempt leaves the machine and never returns a response. The commitment ID is on the wire. Settlement may already be in flight. A naive retry with the same ID races the merchant's accept path.

The protocol rule: an unknown outcome is a status check, not another POST.

The agent queries the commitment state before retrying. not_found means safe to retry. in_flight means wait. fulfilled means stop. failed means retry with a fresh commitment ID.

On the merchant side, the rule is equally clear: write in_flight to durable storage before processing the request. The write is the lock. A second request with the same commitment ID returns in_flight — it isn't processed again.

Both sides need both rules. Neither alone closes the gap.

What's live
The protocol has a working reference implementation:

Spec: saax-protocol.com/spec

Conformance suite: saax-protocol.com/conformance — 61/61 vectors passing

Docs: saax-protocol.com/docs

MCP endpoint: https://www.saax-protocol.com/mcp — 10 tools, free to test, no signup

Registry listing: io.github.bryantrudy24/saax-protocol version 1.0.3

The protocol is vendor-neutral and open for comment. The Router is one implementation of it — the settlement layer uses x402 and MPP, but the Protocol itself doesn't require any specific rail.

Why I'm sharing this
I'm not pitching a token or a product. I built this because the commitment gap is real, and the infrastructure being built around agent commerce (AP2, x402, MPP, UCP, ACP) doesn't include it. If you're building agents that transact, I'd like to know whether a shared commitment layer is useful to your stack — and where the spec is thin or unclear.

The MCP endpoint is live. The conformance suite is public. The spec is open. If this solves a problem for you, I'd want to hear how. If it doesn't, I'd want to hear that too.

Preventing double-purchases in agentic commerce — the retry-storm problem

Bryant rudolph — Fri, 09 Oct 2026 21:59:31 +0000

An agent retries a tool call. The tool call was a purchase. The merchant receives two valid orders. The agent's ledger records one transaction. The buyer's statement shows two.

This is the most common failure mode in agentic commerce, and it isn't a bug in any single component. It's the predictable result of three design decisions that were each reasonable on their own.

Agents retry. Reliable agent design requires retry logic. Network calls fail, timeouts happen, models hallucinate transient errors. The standard remedy is to retry until the call succeeds.

Purchases are non-idempotent by default. A POST to create an order creates an order. A second POST creates a second order. Nothing distinguishes "this is a retry of the same intent" from "this is a new purchase."

The race condition: retry fires before the settlement confirmation arrives. The agent sees no successful response to the first attempt. It retries. The merchant processes both.

The partial fixes that don't fully work
Idempotency keys work when the client generates the key and has a stable identity for "the same intent." Agents often don't.

Nonce-based authorization (EIP-3009) prevents double-settlement. It doesn't prevent double-order — the merchant may have already accepted both orders before either authorization reaches the chain.

Spend limits bound the damage. They don't prevent the double-purchase.

Tool-call deduplication works in-process. It fails across session restarts, process boundaries, or model context resets.

Each of these addresses part of the problem. None addresses the record that makes the duplicate detectable in the first place.

What's actually missing
A commitment identifier generated before the purchase attempt that both the agent and the merchant treat as authoritative.

The commitment record binds:

The specific intent (what the agent is trying to buy)

The authority (what the agent is allowed to buy, under what limits)

The terms (price, deliverable, deadline, acceptance criteria)

The unique commitment identifier that ties the retry to the original intent

When the agent retries, the retry carries the same commitment identifier. When the merchant receives the second request, it recognizes it as the same commitment. When the payment rail receives the second authorization, the commitment record prevents the duplicate settlement — because the commitment is the unit of truth, not the individual purchase attempt.

How I'm building this
I've been building a protocol layer for this problem. It's called SAAX Protocol — Solvent Applied Autonomous Exchange Protocol. A vendor-neutral commitment lifecycle for autonomous commerce.

A SAAX commitment includes a unique commitment ID, the authority reference, the terms, the evidence requirements, and the recovery policy. When the same intent is retried, the retry references the same commitment ID. The merchant, the agent, and the settlement rail all work from the same record.

The spec is public at saax-protocol.com/spec. The conformance suite is at saax-protocol.com/conformance. There's a working MCP endpoint at https://www.saax-protocol.com/mcp that handles discovery, routing, and validation — free to test, no signup.

The protocol is vendor-neutral and open for comment. Would be interested in feedback from anyone working on this problem — especially where the spec is thin or unclear.

Curious how others are handling retry-safe agent purchases. What's your approach?