Payments in Agentic Commerce: What You Keep Control Of When an Agent Checks Out for Your Customer
The word that makes most merchants nervous about agentic commerce is payments, and the fear usually rests on a misunderstanding that, once cleared up, turns anxiety into a genuinely favorable picture. The instinct is that letting an AI agent complete a purchase means surrendering control of the money, the customer, and the relationship to some third party sitting between you and your buyer. If that were true, caution would be warranted. It is not true. The protocols being built for agentic commerce were deliberately designed to let a merchant sell through an agent while keeping the things that matter, and understanding exactly what you retain is the difference between refusing a channel out of fear and entering it with confidence.
Start with the single most important fact, because it resolves most of the anxiety on its own. In the major agentic commerce standards, the merchant remains the seller of record, sometimes called the merchant of record. This is not a technicality. It means you keep the direct relationship with your customer, you process the payment through your own provider, you handle fulfillment, and you own the returns and the support. The agent facilitates the discovery and the initiation of the purchase, but it does not become the merchant, and it does not insert itself as the party your customer is buying from. The customer is still buying from you. The agent is the surface through which they found and started the transaction, much as a shopping search once was, not a middleman who takes over the sale. When you hold onto merchant of record status, you hold onto the commercial relationship that is the actual asset.
The mechanics of how payment credentials move are where the engineering got clever, and the design goal throughout was security through not exposing raw payment data to the agent. Rather than handing an agent your customer's actual card details, the systems pass secure tokens. A payment token represents the authorization to charge without revealing the underlying credential, so the agent can carry the intent to pay from the buyer to your backend without ever holding the sensitive information itself. On the OpenAI and Stripe side, this shows up as a shared payment token approach that lets a business accept an agent-initiated payment while continuing to use its existing payment processor, in many cases with minimal changes to the integration a store already runs. On Google's side, there is a dedicated agent payments protocol built around cryptographically signed authorizations, so that a payment an agent makes on a shopper's behalf is backed by a verifiable mandate the shopper granted. Different implementations, same underlying philosophy, which is that the agent should be able to move a payment forward without ever becoming a point where raw credentials leak.
This tokenized, mandate-backed design does real work for trust, and it addresses the two parties whose confidence the whole system depends on. For the shopper, it means the agent is acting within explicitly granted authority, with the buyer confirming steps and the agent's spending authorization being verifiable rather than open-ended. For the merchant, it means accepting an agent-initiated payment does not require rebuilding the payment stack or exposing anything that increases fraud risk in obvious ways, because the transaction flows through the processor relationships already in place, carrying tokens rather than credentials. The systems were built on the recognition that agentic commerce only works if both the person delegating the purchase and the business accepting it can trust that the payment is authorized, secure, and traceable, and the payment architecture is where that trust is engineered.
There is an important flexibility point that removes another common objection, which is that adopting agentic payments does not force you to abandon your current payment provider. The standards were designed to work across processors. A business already on one major processor can often enable agentic payments with a small change, and a business on a different processor can still participate through the shared-token mechanisms the protocols define, without switching providers. This matters because the fear of being forced onto a specific payment rail, with the switching cost and lock-in that implies, is a legitimate reason a merchant might resist a new channel. The protocols anticipated that resistance and built for provider neutrality, so that agentic commerce becomes an addition to your existing payment setup rather than a replacement for it. You are extending what you already have, not tearing it out.
The skeptical, honest caveat belongs here, because the payment layer is genuinely the hardest part of agentic commerce and it is still maturing. Automated transactions introduce fraud considerations that are not fully settled, because an agent initiating a purchase looks different from a human clicking a button, and merchant fraud systems have to learn to tell a legitimate agent-initiated order from a malicious one without wrongly cancelling good transactions. There are operational details, like the handling of sales tax and the mechanics of returns for purchases that originated through an agent, that the early rollouts revealed were not fully solved and are being worked out. And the multiplicity of approaches, with different assistant ecosystems using different token systems and payment protocols, means a multi-surface merchant may have to accommodate more than one payment pathway. None of this makes the payment layer unusable. It means the payment layer is real infrastructure being built under load, with rough edges, and a merchant should enter it aware that the mechanics are still hardening rather than assuming everything is settled.
It helps to keep the payment question in its proper proportion relative to the rest of agentic commerce, because obsessing over it distracts from where the near-term value actually is. The prize in the current phase is discovery, being seen and recommended, and discovery does not require you to have solved agentic payments at all. A shopper can be recommended your product by an assistant and then complete the purchase through your own ordinary checkout, with your existing payment flow, no agentic payment token involved. The payment protocols matter for the flows where the purchase completes inside or through the agent, and those flows are valuable and worth being ready for, but they are downstream of the visibility work that pays off first. A store that lets uncertainty about agentic payments stop it from doing the discovery work has the priorities backwards, because it is letting the hardest and least urgent part block the easiest and most valuable part.
For the store owner who wants the practical distillation, the reassuring core is this. Entering agentic commerce does not mean surrendering your customer, your money, or your provider. You remain the seller of record, keeping the relationship and the fulfillment and the returns. Payments move as secure tokens and signed mandates rather than exposed credentials, engineered so that both the shopper and the merchant can trust the transaction is authorized and safe. You can accept agent-initiated payments through your existing processor, often with minimal change, rather than being forced onto a new rail. The genuine rough edges, fraud handling for automated orders, tax and returns mechanics, and the plurality of payment approaches, are real and still settling, so enter with clear eyes rather than blind faith. And keep it all in proportion, because the immediate value is in discovery, which needs none of the payment machinery solved, while the payment flows are a valuable capability to grow into rather than a prerequisite to fear. The merchants who understand what they keep control of will not hesitate at the payment question. They will see that agentic commerce was built to let them sell through agents while remaining, unmistakably, the business their customer is buying from.
The most useful posture toward the payment layer, given that it is real infrastructure still hardening, is to enable what serves you today without waiting for every edge to be smoothed. If you already run a major processor, understanding that you can often accept agent-initiated payments with a small change means the option is there when a valuable agentic checkout flow becomes relevant to your business, without a disruptive project. But you do not have to rush into the payment flows to participate in the channel, because the discovery value that matters most now flows to your own ordinary checkout regardless. This lets you sequence sensibly: prioritize the visibility work that pays off immediately and requires none of the payment machinery, keep an eye on how the fraud, tax, and returns mechanics settle for agent-initiated orders, and adopt the agentic payment capabilities when the flows they enable are genuinely worth it for your specific mix of products and surfaces. The mistake is to treat the payment layer as either an urgent prerequisite or an unusable mess. It is neither. It is a maturing capability to grow into deliberately, on a timeline set by where it actually adds value for you, while the discovery work proceeds in parallel and delivers the near-term return