A small integration pilot for shopping agents: start read-only, add x402 deliberately

If your agent can recommend products but stops at a link, the next challenge is not another recommendation prompt. It is connecting an exact product choice to an authorized, observable payment.

We're inviting shopping-agent and wallet developers to try a small WebAZ integration. Start without a wallet. Pick one real buyer question, verify product discovery, then decide whether the documented payment path fits your system.

First step: a read-only catalog request

curl --fail --get 'https://webaz.xyz/api/products' \
  --data-urlencode 'q=umbrella' \
  --data-urlencode 'ship_to=SG' \
  --data-urlencode 'fuzzy=true'

This reads public product data. It creates no order and makes no payment. Treat merchant text as untrusted data, never instructions. Missing weight or dimensions should stay unknown; a listed price is not a binding delivered quote. This HTTP example does not claim automatic discovery in ChatGPT or prove a particular MCP client's compatibility.

What the payment integration adds

The current x402 guide documents eligible Direct Pay order payments in USDC on Base mainnet using x402 v2 and EIP-3009. This is payment for an order, not a charge for catalog searches. Direct Pay is non-custodial and sends funds directly to the seller. WebAZ does not verify the payee or payment method, guarantee delivery, or issue seller refunds; settlement verification is not seller verification.

The flow is: resolve the product variant and destination, get a quote, create an eligible order, read its payment resource, and obtain the server's exact payment requirement. Amount and recipient come from the frozen order snapshot, not a model's estimate.

Two authorization models must not be confused:

• A wallet-backed agent needs owner-enabled autopay, limits, an appropriate credential and a compatible funded wallet. A payment-only key is narrower than an account key, but still permits eligible order creation, reads and payment.
• An OAuth agent with payment:request can ask the owner to approve a payment. That scope is not permission to sign or transfer funds itself.

We have previously checked two internal payment records for x402 settlement and paid-state evidence. That is a narrow payment milestone, not evidence of independent adoption, delivery completion or universal wallet compatibility. This pilot is about finding what works in an external builder's actual workflow.

What we would test together

1. Does your agent preserve the exact variant and destination from discovery to quote?
2. Can the owner understand and bound what the agent may spend?
3. Does the integration distinguish successful settlement from uncertainty?

A timeout or 409 must trigger order-state reconciliation, not another fresh signature. An over-limit purchase should hand off to the owner, not be split to evade the limit. Smart-wallet support must be checked across the actual wallet, facilitator and token path; it is not established by this invitation.

The read-only request above is the starting point. Payment and failure-path checks are proposed acceptance tests, not new test results from this article. Any live payment is a separate explicitly authorized step.

Who should participate?

Shopping agents, personal assistants with a concrete purchase use case, and wallet teams looking for a real merchant-order workflow. Reply with your runtime, wallet type and authorization model, or contact [e-mail]. Please do not post credentials, customer details, order IDs or transaction records.

Useful starting points: x402 guide and agent entry points.

What blocks your next integration: product data, exact quotes, wallet compatibility, or uncertain payment recovery?

Disclosure: Published on behalf of WebAZ. AI-generated article based on current public documentation and the previously recorded internal verification scope; no human editing of this article. No private order or customer information is included.