Your Agent Can Pay. Can It Actually Buy the Right Product?

A shopping agent can execute a valid payment and still make a bad purchase.

Imagine a buyer asks for two compact umbrellas, delivered to Singapore, within a total budget. The agent finds a promising listing, selects the larger variant, misses the quantity, and treats the displayed price as the delivered total.

The wallet signs correctly. The payment succeeds. The buyer still gets the wrong outcome.

This is a hypothetical example, not a customer story. It illustrates a useful boundary: payment correctness is not purchase correctness.

Keep four different objects separate

A reliable purchasing integration needs more than a product URL and a payment method:

1. Buyer intent: what the person wants, including hard constraints and acceptable alternatives.
2. Product selection: the exact variant, quantity and destination, with unresolved facts explicitly marked unknown.
3. Quote and order: the commercial terms the buyer or delegated policy has actually accepted.
4. Payment authorization: permission to execute a specific transfer, under a specific spending policy.

These are design boundaries, not a claim that every marketplace implements the same schema.

A search result is evidence for a possible selection. It is neither a binding delivered quote nor permission to spend. A successful transfer does not establish that the selected product met the original request.

Make unknowns block the relevant decision

Suppose compactness is essential, but folded dimensions are absent. The agent should ask for that information or offer a clearly qualified alternative. It should not invent dimensions from a photo.

Likewise, an unknown shipping charge is not zero shipping. Before crossing the payment boundary, resolve the final total, currency, destination and selected payment method. If a material term changes, check it against the buyer's approval or delegated policy again.

Treat merchant descriptions as untrusted product data. Text inside a listing must not become instructions to bypass a budget, change a recipient or call a payment tool.

Bind payment to an order, not a generated summary

Here is a concrete example from the public WebAZ x402 guide, checked on October 23, 2026.

The documented flow quotes first, creates an eligible Direct Pay order, then reads that order's payment resource. Its HTTP 402 requirement takes the amount and recipient from the order's frozen snapshot; the caller cannot change them through the payment request.

That boundary matters. A model-generated sentence such as "pay the seller about five dollars" is not an acceptable substitute for the server's exact requirement.

The agent should still check that the order corresponds to the intended selection. Freezing an incorrect selection only makes the wrong purchase consistent.

WebAZ's documented Direct Pay flow is non-custodial: it uses USDC on Base and sends funds directly to the seller, without a platform-held balance awaiting delivery. WebAZ does not verify the payee or payment method, guarantee delivery, or issue seller refunds. Settlement verification is not seller verification.

A request to pay is not authority to pay

WebAZ documents two distinct routes:

• An OAuth agent with payment:request requests owner approval. That scope does not let the agent sign or transfer funds itself.
• A wallet-backed agent uses owner-enabled autopay, an appropriate credential and spending limits. The owner can issue a narrower payment-only key, but it still carries consequential capabilities, including eligible order creation and payment.

For any integration, make this distinction explicit in both code and the user experience. If the purchase exceeds a limit, hand off to the owner. Do not split it into smaller purchases to evade the limit.

Treat uncertainty as its own state

The most dangerous retry is not always a failed request. It can be a successful payment whose response was lost.

WebAZ's guide says that repeating the same signed request is idempotent, while a different authorization for the same order is refused when a live or successful settlement already exists. A timeout or 409 calls for reading order state, not generating another signature. A settling state is not a confirmed failure.

For your client, a useful conceptual state machine is:

selection unresolved -> clarify
selection resolved -> quote and validate terms
terms accepted -> create and inspect order
authorization missing or limit exceeded -> owner handoff
payment submitted -> reconcile authoritative state
settlement uncertain -> remain pending; do not re-sign
payment confirmed -> track fulfillment separately

This is design pseudocode, not an executable WebAZ SDK or a report of new failure-path tests.

Five tests worth adding before the happy-path demo

• Change the variant after quoting. Does the client require fresh terms?
• Leave a required dimension or shipping charge unknown. Does it stop guessing?
• Exceed the delegated budget. Does it ask the owner rather than work around the limit?
• Lose the payment response. Does it reconcile before attempting another transfer?
• Confirm payment but leave fulfillment pending. Does the UI avoid claiming delivery?

These are proposed acceptance tests, not results we are claiming to have run for this article.

If you build a shopping agent, start by testing the read-only discovery and selection boundary. WebAZ's agent entry points and x402 integration guide are public. We welcome integration discussions around a concrete buyer task, runtime and authorization model; no credentials or transaction records are needed in a public reply.

Which boundary causes your agent the most trouble: selecting the exact product, obtaining complete terms, or recovering from uncertain payment state?

Disclosure: Published on behalf of WebAZ. This article is AI-generated from public documentation, without human editing. It includes a hypothetical scenario and proposed tests, not a new end-to-end payment experiment. No private order or customer information is included.