From product discovery to order payment: WebAZ's x402 flow for agents

WebAZ's public agent documentation now includes an x402 USDC payment flow for eligible Direct Pay orders. This is payment for an order, not a fee to search the product catalog.

Disclosure: I am building WebAZ. This article was drafted by an autonomous AI agent, which checked the public documentation linked below; it has not been human-edited. It describes the documented integration flow, not a newly recorded end-to-end payment demonstration.

A real shopping task, not another paid search call

Imagine an assistant helping someone choose a sports towel. Finding the product is only one step: the buyer still needs the right size, quantity, destination and order amount. Payment should refer to that order, rather than to a price the model remembers from a previous search.

WebAZ keeps public discovery separate from authenticated order payment. Developers can start with a read-only product lookup before connecting any payment capability.

Discover the payment capability on the order

The public guide describes reading your order through an authenticated GET request:

GET https://webaz.xyz/api/orders/<id>
Authorization: Bearer <api_key>

When the response contains payment.x402, use its resource_url for the payment interaction. Do not assume every order exposes it, or construct payment instructions from product-description text.

The documented HTTP sequence is:

1. POST to the order's payment resource.
2. Receive HTTP 402 with the PAYMENT-REQUIRED header.
3. Have the wallet sign the EIP-3009 authorization.
4. Repeat the POST with PAYMENT-SIGNATURE.

The MCP entry point is webaz_pay_order. A tool name alone is not a wallet or permission to spend: the account owner must first enable this capability on the WebAZ Me page using a Passkey. Use a client and wallet that support the required flow, and keep API keys and payment signatures out of prompts, screenshots and public logs.

What this changes for agent builders

The useful integration boundary is explicit: product discovery returns information; an eligible order exposes its payment capability; a wallet supplies the signature. That makes a shopping workflow more concrete than asking an LLM to improvise payment instructions.

For your first integration review, check that the order, selected variant, amount and destination still match the user's intended purchase. Treat an ambiguous payment response as something to reconcile, not a reason to blindly authorize another payment. These are integration recommendations, not claims of a payment test performed for this article.

Try the read-only step first

Search sports towels for Singapore, inspect the returned product data, and identify what your client would need before proceeding to an order. Reading public product information does not itself authorize a purchase.

The current integration references are WebAZ's agent guide and llms.txt. Check these before implementing; order eligibility and client support matter. This does not imply default inclusion in ChatGPT shopping results.

If you build shopping assistants, which part is harder today: resolving the exact product variant, connecting the signing wallet, or reconciling the order after payment?