Key takeaways
- Agentic commerce is when an AI agent completes a purchase for someone within boundaries they approve beforehand, acting on its own instead of waiting for a click at every step.
- For a payments platform, the shift is about acceptance, taking in a charge that an agent started rather than one that the customer made directly.
- Most coverage tracks retail, but services are the bigger market, and their recurring payments are the first an agent will handle.
- Taking an agent’s payment safely turns on four things: proof that the buyer delegated it, fraud checks aimed at agents rather than humans, tokens that replace a live card, and support for the protocols now taking shape.
- Much of what an agent needs is already live for ordinary payments, the stored tokens, recurring billing, and transaction data, so getting ready is less a rebuild than tidying that foundation and deciding how far an agent’s autonomy should go.
Online transactions always end the same way. A person looks at a screen, decides, and enters the payment themselves. Agentic commerce changes who takes that last step, handing it to an AI agent that acts on permissions a customer granted earlier.
This guide approaches it as a payments question rather than a shopping one, written for the software platforms that will have to take these payments. Increasingly, the buyer placing them is an agent, not a person.
What is agentic commerce?
Agentic commerce is a transaction model in which an AI agent completes a purchase on a person’s behalf, working from the intent and limits they set in advance instead of their moment-to-moment attention. The person says what they want and where the boundaries sit. The agent then finds an option that fits and carries the payment through.
What makes it agentic is that the software acts rather than advises. A recommendation engine waits for someone to browse. A chatbot answers a question, then hands the checkout back to a human. An agent is the first of these that finishes the job, placing the order or authorizing the charge within the authority the buyer gave it up front.
Most definitions stop at a shopper and a cart. That picture is too small for what is arriving. A transaction can be a membership that renews, an invoice paid on the first of the month, or a service plan held active under a price cap. When the instruction is “keep my pest control running unless the price moves,” the agent is not shopping. It is authorizing a recurring payment on a schedule, the kind of repeatable, rule-bound work that software handles well.
For a payments platform, the shift lands in one place. Card and bank rails were built around a person approving each charge in real time, and that assumption stops holding the moment an agent initiates the payment. The question is not whether an agent can shop. It is whether your merchants can accept a payment that an agent placed for the customer, not the customer themselves. That is a Pay In question, and it is the one this guide is built around.
How is agentic commerce different from traditional e-commerce?
In traditional e-commerce, a person does the clicking. In agentic commerce, an agent does. That is the surface, and it is where most explanations stop. Agents move through the same catalogs and checkout pages people use, and settle over the same card networks, so most of a transaction looks familiar from the outside.
The difference that matters to an embedded payments platform sits underneath, at the moment of payment. Once the person steps out of the approval, the signals a merchant’s systems lean on go with them, from the device in hand to the behavior that reads as human. What sets off the charge changes, too. It now fires on a rule the buyer set earlier, not a click made in the moment.
For service businesses, the gap runs deeper because their commerce was never a single cart to close in the first place. The customer relationship is ongoing, and so is the billing. A person tends that relationship by signing in when something changes. An agent tends it by holding a standing permission to pay and acting when the conditions are met. Accepting a one-time guest checkout and accepting an agent who will pay again next month without being asked are different problems, and the second is the one arriving in need-to-pay verticals first.
What your payments stack needs to support agent-initiated transactions
An agent-initiated payment arrives without the human signals that a merchant’s systems were tuned for, and it often stands for an ongoing permission rather than a single sale.
Four capabilities decide whether your SaaS platform can take agent-initiated transactions safely:
1. Delegated authorization and agent mandates
The first question a merchant has to answer is easy to ask and hard to prove. “Did the buyer actually authorize this agent to make this payment?”
The answer comes from a mandate, a signed record of what the person permitted and where the limits fall. For a one-time purchase, that mandate covers a single charge. For a service business, it has to carry something larger, a standing authority to pay on a schedule, within a cap the customer sets, that holds until they revoke it.
Your stack needs to capture that grant, check each agent’s payment against it, and keep the record in case anyone asks later.
2. Agent-aware fraud and risk
Fraud screening was built to spot a person acting suspiciously. An agent is not a person, so even a legitimate one can trip the alarms meant to catch fraud.
The stack has to recognize the agent itself, judge whether its behavior fits what an authorized agent should be doing, and flag any spend or velocity that breaks the pattern.
Treating every agent as a bot to block is an expensive mistake because it turns away real revenue. What matters is telling an authorized agent apart from a malicious one, and keeping a clear trail of what each agent did.
3. Tokenized credentials for AI buyers
An agent should never hold a live card number. It should hold a token, a stand-in that works only within set limits and can be switched off without touching the card behind it.
For recurring service payments, the same mechanism does double duty. A scoped token lets an agent keep paying a plan each cycle while the underlying account stays shielded, and a misbehaving agent can have its token pulled on its own, without forcing the customer to reissue the card.
4. The emerging standards (ACP, AP2, MCP)
No single company will define how agents and merchants transact. A set of open standards is forming to do that, and three matter most right now. They sit at different layers of the same flow:
- Anthropic’s Model Context Protocol gives an agent a common way to connect to tools and data.
- Google’s Agent Payments Protocol carries proof that a buyer authorized a payment, and it draws a useful line for service billing by separating a one-off approval from a standing one that runs within preset limits.
- OpenAI’s Agentic Commerce Protocol handles the checkout step and is already running inside ChatGPT.
None of the three is final yet, and they are converging rather than competing. The safer move is to build on infrastructure that can adopt them as they mature, rather than committing your platform to any one of them.
Where agentic commerce will hit need-to-pay verticals first
Almost every account of agentic commerce is a shopping story. The demos buy sneakers and flight upgrades, the case studies feature retailers, and the projections count products moving through carts.
That framing quietly measures the smaller half of the economy. The number everyone cites, McKinsey’s estimate that agents could orchestrate $3 trillion to $5 trillion in commerce by 2030, comes with a caveat that most coverage drops. It counts goods alone, not services, and leaves out the B2B market too.
Goods are the smaller side of what people actually pay for. Services make up about two-thirds of US consumer spending, with goods accounting for the rest.
These are not one-time purchases an agent stumbles into. They are scheduled and repeated, which makes them the simplest payments for an agent to manage, and the first place agent-initiated acceptance is likely to land. That points away from retail and toward the need-to-pay verticals, where a payment is less a discretionary purchase than a recurring obligation.
This is the services lens Payabli works from by default, because these verticals are its customers. They already run their recurring and scheduled payments through Pay In, which makes agent-initiated acceptance less of a new product than the same flow with a new kind of buyer at the front of it.
How should payment platforms prepare for agentic commerce?
Preparing is less daunting than it sounds, because much of what an agent-initiated payment depends on is infrastructure that most payment platforms already run.
On Payabli, platforms already store payment methods as network tokens, bill on a schedule through auto-pay and subscriptions, screen charges with machine-learning models and rules, and pull their transaction data as it happens through query APIs and webhooks. Each of those is a piece that an agent-initiated payment will rely on, already in production for everyday acceptance.
What none of it does yet, on its own, is take a payment that an agent starts. That is the new piece, and it is the one Payabli is building. The groundwork beneath it already exists.
So preparing is mostly a matter of keeping that foundation clean and consistent, because the gaps a person works around are the ones an agent trips on. The harder part is a decision rather than a task. How much should an agent be allowed to do on a merchant’s behalf before a person signs off? Trust in agent payments is still forming, so the steadier path is to widen autonomy as it builds rather than ahead of it, and to set that authority by merchant and by flow instead of all at once.
Get your merchant-facing teams ready as well. When a merchant asks how an agent was cleared to pay on their customer’s behalf, that should be a conversation they can have, not a ticket they file.
None of this waits for a finished product. The platforms that get those basics right and answer the governance question early are the ones that will be ready to accept an agent-initiated payment the day it fits their merchants.
Frequently asked questions
1. What are agentic payments?
Agentic payments is the broad term for any payment an AI agent makes on someone’s behalf, rather than a person entering it by hand. Agentic commerce, the subject of this guide, is one-half of that, an agent paying a merchant to buy something. The other half is an agent paying a business’s own vendors and suppliers, a different problem with different controls, which we cover in a separate guide on agentic payments.
2. Can existing payment systems support agentic commerce?
For the most part, yes, and the lift is smaller than the word rebuild suggests. An agent’s payment clears and settles on the rails a merchant already uses, so the part that moves the money does not change. What gets added is a layer at the front of the transaction that recognizes an agent and confirms it was authorized. That front layer, and the standards behind it, is what is still being built out, not the infrastructure underneath.
3. How is fraud prevention different when an AI agent is buying?
The biggest change is not a new kind of theft but a new kind of dispute. Traditional card fraud is a stranger using a card that isn’t theirs, and the defenses are built to catch that. With an agent, the card and the customer are usually real, so the risk that grows fastest is the buyer who later says the agent bought the wrong thing or spent more than they wanted, a problem closer to friendly fraud than a stolen card. Because it surfaces after the sale, the evidence that resolves it is the saved record of what the customer told the agent to do, not the live checkout signals fraud systems have always read.