The transaction chain when the buyer is an AI agent
Agentic commerce payment workflow connects a buyer’s instruction to the merchant cart, approval, constrained payment credential, authorization and final order. See how responsibility and transaction state must survive each handoff when an AI agent shops and initiates payment on the buyer’s behalf.

An agentic commerce payment workflow has more control points than a normal checkout because the software choosing the product may also negotiate terms, present the cart, carry payment credentials and initiate the transaction. The difficult part is preserving the buyer’s intent as responsibility passes from agent to merchant to payment provider and finally into fulfillment.
At 8:42 a.m., someone asks an assistant to buy two replacement laptop docks. They need to arrive by Friday, and the total should stay below ₹18,000.
The user does not open a retailer’s website. The agent searches, compares compatible models, checks delivery dates and finds stock at a merchant the user has never bought from before. A few seconds later, it has a candidate purchase. Nothing has been paid yet.
Several decisions still have to survive the trip from the conversation to an actual order. Is this the product the user meant? Is the merchant seeing a legitimate commerce agent or automated traffic it should block? Are the quoted price, tax and shipping terms still current?
Did the user approve this exact cart, or did the original instruction already permit the agent to commit? Which payment credential can the agent use, and can that credential be used only for this merchant and amount? Did the merchant actually create an order after the payment request was accepted?
Agentic commerce compresses the visible buying experience. Underneath it, the transaction chain gets longer.
What actually happens when an AI agent buys something?
A conventional online purchase already spans several systems. The customer browses, and the merchant calculates the cart. A payment service provider handles payment details, while the issuer authorizes or declines the charge. The merchant creates an order, and fulfillment starts.
An AI agent inserts another decision-making layer before checkout. That layer can search merchants, filter products, interpret a user’s conditions and decide when a candidate purchase satisfies them. Depending on the arrangement, it can also initiate checkout without the user manually re-entering every detail.
Current agentic-commerce standards are beginning to expose those handoffs directly.
Google’s Agent Payments Protocol (AP2) distinguishes a Checkout Mandate, which establishes authority to purchase an agreed checkout, from a Payment Mandate, which establishes authority to pay for that checkout. In its current specification, open mandates can record the constraints authorized in advance for autonomous purchases, while closed mandates bind the authorization to a particular checkout and payment.
That separation matters because “find me something suitable” and “buy these exact items at this exact price” are not the same commercial event.
The merchant needs to recognize the shopper before it trusts the checkout
The laptop-dock agent reaches a merchant site. From the merchant’s infrastructure, the request is automated traffic. That is not enough information to decide whether it deserves access to product data, checkout or payment.
Visa’s Trusted Agent Protocol was designed around this problem. Its specification allows an agent to present signed information indicating that it is a recognized agent acting with commerce intent. The merchant can verify the signatures and use the information while deciding how to handle the interaction.
The merchant may need to know whether the automated visitor is a legitimate commerce agent acting for an authenticated customer, requesting inventory and price information, or merely behaving like an unknown bot.
Visa’s specification covers both browsing interactions and payment interactions. An agent can first request product availability, shipping eligibility and final cost, then later provide the information required to purchase.
The transaction chain therefore begins before a card credential is involved.
The merchant still owns the authoritative cart
The agent may have discovered the docks at ₹7,600 each. That does not make ₹15,200 the final transaction amount.
Inventory may have changed. Shipping may cost extra. Tax may depend on destination, and a promotion may have expired. The merchant needs to return the commercial state it is prepared to honor.
The Agentic Commerce Protocol (ACP), maintained by OpenAI and Stripe, follows that model. Its checkout specification keeps the merchant in control of inventory, pricing, tax calculations and payment processing. The agent can create and update a checkout session, but the merchant returns the authoritative cart state.
That division avoids a subtle failure mode. The agent can reason about an offer, but only the merchant can commit to what the merchant is actually selling.
If the requested docks are now ₹7,900 each and Friday delivery costs ₹1,200, the agent should receive that changed state before the transaction proceeds. Commercial commitment is being reconstructed against current merchant state.
Approval has to attach to the purchase the merchant will execute
The merchant returns a cart containing two docks, a ₹15,800 merchandise total, ₹1,200 expedited shipping, applicable tax and delivery by Friday.
The relevant approval now has something concrete to refer to.
AP2’s closed Checkout Mandate is designed for this distinction in human-present purchases: the user can review the merchant’s proposed checkout and authorize the specific purchase, creating cryptographic evidence bound to its contents.
Delegated purchases need a different path. If the original instruction said, “Buy two compatible docks, no more than ₹18,000 total, delivery by Friday,” the agent may already possess enough authority to proceed when the merchant’s cart satisfies those conditions.
Under AP2’s autonomous transaction model, the user approves constrained open mandates in advance. The agent can subsequently assemble and authorize closed checkout and payment mandates within those constraints, subject to verification and any additional confirmation the merchant requires.
The important part is not that a human clicks again. It is that the eventual transaction can still be tied to the instructions that justified it.
Mastercard’s Agent Pay architecture makes a similar point through Verifiable Intent, with agent transactions tied to authenticated user intent and explicit consent, while registered agents transact using network-token infrastructure.
It is one link in the transaction chain: evidence connecting the agent’s commercial choice to the buyer’s instructions.
The agent should not carry a reusable payment credential into every merchant
The approved cart now needs a payment mechanism. Giving autonomous software an unrestricted reusable card number creates an unnecessarily broad capability.
Current agentic-payment designs are moving toward constrained credentials instead.
The Agentic Commerce Protocol includes a delegated-payment mechanism in which a payment credential can be tokenized under explicit allowances. The current specification supports constraints including maximum amount, currency, checkout session, merchant and expiry.
Stripe describes its Shared Payment Tokens as a mechanism for initiating authorized payments without exposing the buyer’s underlying credentials. Tokens can be restricted to a business, bounded by time or amount and monitored or revoked. The merchant can use the resulting token within its payment-processing flow.
Visa Intelligent Commerce also describes agent-specific payment tokens and controls intended to compare payment-credential requests and authorization activity with the user’s authenticated payment instructions.
The agent does not need general access to the customer’s funding instrument. It needs a credential that can satisfy this checkout under the conditions the payment system is prepared to accept.
Checkout and payment authorization are separate events
The payment token reaches the merchant.
Under ACP, the merchant receives the checkout request and payment information, remains merchant of record, and processes the payment through its existing payment provider. Stripe’s description of ACP transaction roles explicitly separates the AI agent, the business receiving the checkout and the payment provider.
That preserves several familiar payment responsibilities. The merchant can still run fraud checks, the PSP can validate the credential, the payment network can process the authorization, and the issuer can approve or decline the transaction.
Agentic commerce changes who assembled and initiated the checkout without removing the payment infrastructure underneath it.
The commerce layer may determine that the purchase satisfies the buyer’s instruction. The payment layer still decides whether the proposed charge can be authorized.
An authorization response is not yet an order
Suppose the issuer approves the ₹17,450 charge. The merchant now has to complete its own order state.
Its checkout session has to produce an order. Inventory needs to attach to that order, and the promised delivery service needs to remain associated with it. The agent needs an authoritative confirmation from the merchant rather than inferring success from the payment response.
ACP’s checkout specification makes the merchant responsible for the order lifecycle and defines completion of the checkout session as the step that processes payment and creates the order.
That distinction is easy to lose in conversational interfaces. A user may see:
Purchased. Arriving Friday.
Behind that sentence, at least two different facts have to be true: the payment was successfully processed, and the merchant accepted the checkout and created the order.
If payment succeeds but order creation fails, the system has a recovery problem. If the order exists but the agent never receives the response, retry behavior has to avoid purchasing the same item twice.
Those are commerce-state problems, not language-model problems.
Fulfillment can change after the money moves
Order creation hands responsibility to another part of the commerce system.
The merchant may later discover that expedited inventory was incorrect. A shipment can fail, an item can be partially fulfilled, or the buyer may cancel. A return can trigger a refund. A dispute may require evidence of what the user instructed the agent to buy and what the agent actually submitted.
This is one reason transaction evidence has to survive checkout.
Visa Intelligent Commerce describes commerce signals that connect the user’s original instruction with details of authorized purchases, intended in part to support dispute resolution.
AP2 similarly frames its Checkout and Payment Mandates and associated receipts as evidence that can be brought together to reconstruct and verify the transaction in a dispute.
For agentic commerce, the receipt may eventually need to explain more than the amount and merchant.
It may need to reconstruct what the buyer asked for, which agent acted, which merchant terms were returned, what was approved and which credential was used. It may also need to establish what the payment network authorized, which order the merchant created and what was ultimately fulfilled.
That evidence matters when the human was not present for every transition.
The chain needs an owner at every handoff
At 8:42, the user gave the agent a purchasing task. By 8:43, several systems have participated.
The agent interpreted the request and found a merchant. The merchant supplied authoritative price, inventory and fulfillment terms. The buyer’s approval or prior mandate established what the agent could commit to.
A payment provider issued or handled a constrained credential. The merchant submitted the payment through its PSP, and the payment network and issuer evaluated the authorization. The merchant created the order before fulfillment took responsibility for what happens next.
No single participant controls the entire chain. That is why the phrase “the AI bought it” hides more than it explains.
The AI may choose. It may negotiate the path to checkout. It may carry evidence of intent and submit a payment token. But the commercial transaction only holds together if every downstream system can identify the state it received, the authority it relied on and the state it produced.
For the laptop docks, the user finally sees a short confirmation:
Two items purchased.
₹17,450 total.
Delivery Friday.
The visible experience has collapsed the purchase into three lines. The system underneath should still be able to reconstruct every handoff that made those three lines true.
