Bot-to-bot commerce with real carts and payment challenges

The live test: from discovery to boundary

The test was intentionally practical. Read the public discovery files, pick a real item or paid endpoint, attempt the least risky action, and stop before account creation, shipping, payment, wallet signature, or order submission.

buying_bot_probe:
  input:
    goal: "buy clothes under $50" | "buy tech under $500" | "call a paid API"
    policy: "do not complete purchase without delegated authority"
  discover:
    ucp: /.well-known/ucp
    catalog: /products.json
    api: /openapi.json | /.well-known/x402 | /.well-known/agent.json
  attempt:
    retail: add to cart, read cart total, request checkout handoff
    api: call without payment, inspect 402 or auth response
  stop_at:
    login | bot_mitigation | payment_required | human_token_required | shipping_required

Example 1: a bot has $50 and wants clothes

The user policy is narrow: find wearable clothing under $50, prefer in-stock variants, do not buy without approval. That is enough for a bot to act like a useful shopping assistant without pretending it owns the card.

The compelling part is not that the bot finished checkout. It did not. The compelling part is that the bot can return a specific approval packet: product title, variant, price, cart status, checkout URL or failure state, and the reason human authority is required.

approval_packet:
  merchant: "www.reebok.com"
  item: "Men's Lawn Club Shorts"
  variant: "Vector Navy / S"
  price: "$50.00"
  cart_total: "$50.00"
  boundary: "checkout_forbidden"
  next_step: "open merchant checkout in approved browser session"

Example 2: a bot has $500 and wants tech

The higher budget makes the buying work more interesting and more sensitive. A$499 plug-in bundle, a $299.92 smart-home bundle, or a$500 font license can be discovered by a bot, but the final authority differs by category.

The same budget behaves differently depending on what is being bought. A digital audio bundle needs account and license handling. A camera bundle needs shipping approval and probably a stronger policy because it is home-security hardware. A font license needs a precise license choice and the store-specific cart contract.

The API version is cleaner

Wallet-native API commerce looks less like a store and more like a priced HTTP action. The bot asks for the thing. The server either returns the result, returns402 Payment Required, or explains what authorization is missing.

paid_api_loop:
  request: POST /api/send
  response: 402 Payment Required
  price: "$0.02"
  payment_rail: x402 | MPP
  bot_policy_check:
    daily_email_budget_remaining: true
    recipient_allowed: true
    wallet_authorized: true
  retry:
    attach_payment_proof: X-PAYMENT
    record_receipt: true

This is why x402 and similar payment flows feel ahead for agent commerce. The product is usually a request, a result, a file, an email send, or an RPC call. There is no shipping address, size preference, card issuer challenge, or checkout page to interpret.

The real bot-to-bot contract

The useful contract is not "trust the bot." It is a sequence of small, inspectable permissions. Browse is not buy. Cart is not checkout. Checkout is not payment. Payment is not fulfillment. Each step should produce a state the next bot can understand.

What the buyer bot should return

1. The item or endpoint it selected, including variant ID, method, path, or SKU.
2. The price, currency, discounts, and whether taxes or shipping are still unknown.
3. The exact action attempted and the HTTP result.
4. The authority boundary: login, checkout, bot verification, human token, payment challenge, or shipping requirement.
5. The next safe action: ask for approval, open browser checkout, attach wallet payment proof, or stop as out of policy.

What merchants should expose

The retail probes failed at predictable places because the machine contract was incomplete. The API probes were easier to reason about because price, auth, and payment were closer to the HTTP response. DialtoneApp should push merchants toward that level of clarity without forcing every sale into the same payment rail.

Bot-to-bot commerce becomes compelling when the seller can say exactly what a bot may do, what it costs, which proof of authority is required, and where a human must take over. The probes show that the internet already has the pieces. The missing part is the consistent handoff between catalog, cart, checkout, payment, and policy.