AI agents are getting surprisingly good at the first half of commerce. They can search catalogs, compare options, read policies, and initiate payment.
The harder half starts immediately afterward.
A merchant still needs to know:
- Which payment instruction did the buyer actually see?
- What did the buyer and seller acknowledge?
- What is the current order state?
- Which evidence supports the next action?
Those questions sound operational, but they become protocol questions once software agents participate on both sides.
Payment is an event, not the whole transaction
Imagine an agent receives a quote and payment instruction, then the merchant updates a policy or stock state. The payment completes, but an acknowledgement times out. The agent retries. The merchant sees two possible actions and one incomplete order record.
Nothing here requires malicious behavior. The systems simply disagree about what happened.
For human checkout, support teams often reconstruct the sequence from screenshots, email, payment records, and chat history. An AI agent needs something more structured: a transaction trail it can inspect before deciding whether to retry, wait, escalate, or ask a human.
A minimum machine-readable trail
An agent-ready transaction should expose at least five things:
- The quoted amount and the version of the payment instruction shown to the buyer.
- Buyer and seller acknowledgements.
- The payment result or submitted evidence.
- The current order state.
- The next responsible party and a recovery path.
This does not require putting every commercial detail on-chain. It does require preserving the important state transitions and making their boundaries explicit.
What we are testing with WebAZ
WebAZ is an open-source commerce protocol exploring this problem. Its Direct Pay flow is live and non-custodial: payment goes from buyer to seller outside WebAZ, while WebAZ records the payment-instruction snapshot, acknowledgements, order states, and evidence around the transaction.
That boundary matters:
- WebAZ does not hold the buyer's payment.
- WebAZ does not verify the payee or payment method.
- WebAZ does not guarantee payment or delivery.
- WebAZ does not issue refunds on a seller's behalf.
The goal is not to pretend that recording state eliminates commercial risk. The goal is to make the transaction legible enough for buyers, sellers, support teams, and future agents to reason about the same sequence of events.
Why this matters for builders
Most AI-commerce demos stop at discovery or wallet execution. Real merchant operations begin when something is delayed, duplicated, disputed, or unclear.
That is where an agent needs more than permission to pay. It needs evidence of the agreement, a current state, and a clear next action.
We are building this in public and would value feedback on the state model, evidence boundaries, and agent-facing interfaces.
Project: https://webaz.xyz
Top comments (0)