From recommending a product to completing a purchase
Suppose someone asks a shopping agent for a rain-suitable jacket costing no more than ¥20,000 including delivery. Recommending candidates is largely an explanatory task. Buying one requires a size, available stock, delivery choice, tax-inclusive total, payment method, return conditions, and a record of what the user authorized. A conversational preference must become a transaction that sellers and payment services can verify.
Google introduced the Universal Commerce Protocol (UCP) in January to connect discovery, purchase, and post-purchase support. Its current concepts documentation describes businesses declaring capabilities that applications and agents discover and consume. The aim is to reduce separate integrations for each AI service.
I see this as an attempt to connect product understanding with authority to transact. Shared interfaces give participants a common way to handle purchase conditions. Declaring protocol support still does not ensure that every payment method or additional authentication flow works. Both sides must establish compatible capabilities and versions for the transaction.
The seller supplies price and order facts
The Agentic Commerce Protocol (ACP) architecture gives the agent responsibility for interpreting intent, displaying checkout, and managing the interaction. Sellers retain inventory, pricing, taxes, shipping calculations, payment processing, and fulfillment. Moving the purchase interface into an agent preserves the merchant’s underlying operations.
The ACP Checkout API returns the seller’s authoritative current checkout after changes. Its lifecycle distinguishes missing information, readiness for payment, payment processing, and completion after successful payment and order creation. A failed payment may return the session to readiness.
These distinctions belong in the conversation too. Finding a candidate, assembling a checkout, processing payment, and confirming an order are separate facts. A fluent agent should not announce completion while processing continues. Totals and completion messages must follow seller and payment responses. Model-generated narration cannot establish that a transaction occurred.
Bind purchase authorization to payment authorization
Who approved the seller’s checkout, and what did they approve? The current Agent Payments Protocol (AP2) v0.2 specification addresses that evidence with two mandate types: a Checkout Mandate authorizing the purchase and a Payment Mandate authorizing its payment. A hash of the merchant-signed checkout binds both to the same transaction.
AP2 defines the consent interface as a non-agentic Trusted Surface and requires mandate validation and processing in deterministic code. A statement from the model that payment was authorized is insufficient; receiving parties verify the signature and transaction binding.
This establishes correspondence with authorized conditions. Whether the product suits the buyer, its description is accurate, or it will arrive as promised remains separate. I would evaluate transaction authorization and recommendation quality separately, because cryptographic approval of a poor recommendation does not make it a good purchase.
Approve a purchase now, or approve its constraints in advance
AP2’s flow examples distinguish direct approval of a specific checkout and payment from autonomous purchasing under previously approved constraints. In the latter case, a user approves an open mandate, and the agent later binds it to a particular transaction. The authorization chain remains traceable.
The Checkout Mandate document defines allowed-merchant and item/quantity constraints. The Payment Mandate document defines constraints such as amount range, currency, and payee. The authorization rules require unknown constraints to fail evaluation rather than be ignored.
A concrete payment mechanism is Stripe’s Shared Payment Token (SPT). It grants a specified seller scoped payment-method access with currency, maximum amount, and expiration limits. Additional customer authentication can still be required. Issuing a token does not complete a purchase, and enforcing an amount limit does not establish that a jacket suits rainy weather.
Translating a preference into authorization therefore remains consequential. A product interface can narrow permission to candidates the user has reviewed or define conditions verifiers can check. Where an unresolved preference cannot be evaluated, returning to the user is a reasonable design. AP2’s examples also describe returning an autonomous flow to direct approval when a constraint remains unresolved.
A jacket purchase exposes price changes and delayed responses
Consider the hypothetical jacket purchase. An ¥18,000 item may acquire ¥3,000 delivery charges after the destination is entered. The agent must compare the seller’s total with the ¥20,000 all-in limit. It can seek another item or ask the user to change the budget; the displayed product price alone is insufficient.
If size, quantity, shipping, or total changes after approval of a specific checkout, the implementation should determine whether the new contents remain authorized. This does not imply that every change requires another confirmation screen. It distinguishes changes already allowed by a delegated constraint from changes outside permission.
A delayed completion response introduces another problem. Failure to receive a result does not establish that the seller failed to create an order. ACP provides an idempotency identifier for safe retries. An implementation should preserve transaction identity, retrieve current state, and establish the outcome before retrying. The interface needs an unresolved-result state and a recovery route that avoids a second order.
ACP capability negotiation helps establish which payment and intervention flows both sides support. It can expose incompatibility before a final authentication step becomes impossible to display. Shared interfaces are valuable when they explain where processing stopped and who must act next, as well as how a successful call works.
After purchase, distinguish promises from events
An order confirmation does not finish the shopping journey. UCP’s Order specification records purchased items, fulfillment expectations, actual fulfillment events, and post-order adjustments such as returns and refunds. It distinguishes expected Friday delivery from an actual delivery event. Refund information can change independently of shipping.
ACP order webhooks send merchant-signed full order updates to the purchasing interface. This supplies concrete information for later explanations. Representing returns or refunds does not establish that every merchant supports agents executing them automatically. Supported operations, merchant rules, and completed outcomes still need checking.
For buyers, linking approval with what actually happened leaves a durable route back to the order. Payment authorization, the seller’s order identifier, delivery updates, and refund results should remain connected even after a conversation ends. This gives a purchasing agent evidence for answering subsequent questions.
Measure completion and recovery as part of convenience
The specifications establish concrete transaction and authorization mechanisms. They do not measure time saved, purchase satisfaction, or reduced return and verification effort. The number of companies supporting a standard is also not the proportion of purchases that complete under comparable conditions.
I would first compare a direct-approval agent experience with existing checkout. Include shipping changes, stock shortages, additional authentication, delayed responses, and return/refund updates. Record false completion messages, duplicate processing, and occasions requiring users to start again. Expand autonomous purchasing from conditions people understand and receiving systems can verify. Keeping failed attempts exposes the cost of confirmation and recovery.
A useful shopping agent combines recommendation ability with a connection from user permission to checkout, payment, and post-purchase facts. UCP and ACP define commerce exchanges, AP2 supplies authorization evidence, and SPT provides a constrained payment mechanism. After connecting them, the important question is whether people can understand the conditions and recover from failure through the same identifiable order.