Digital commerce was designed around a familiar sequence: a person opens a page, searches for a product, compares options, adds items to a cart, enters their details, chooses a payment method, and confirms the purchase. For years, almost the entire e-commerce architecture started from the idea that a person is navigating a visual interface and making each decision directly on the screen.
AI agents change that premise.
When an agent can interpret an intent, search for products, compare terms, assemble a basket, track inventory, calculate shipping, and initiate a purchase, checkout stops being just a page. It also becomes a set of capabilities that other systems need to be able to discover, understand, and operate securely.
This does not mean stores, ERPs, gateways, PSPs, and order systems cease to exist. The more interesting shift is the opposite: the infrastructure that already supports commerce needs a layer capable of exposing its capabilities to new channels without losing control over the catalog, pricing, inventory, identity, payment, and after-sales service.
It is precisely this boundary that makes agentic commerce an infrastructure topic, not just an interface topic.
What are AI agent payments?
AI agent payments are payments initiated within a journey in which a software agent actively participates in discovering, deciding on, preparing, or executing a purchase on behalf of a person or company.
The agent can have different degrees of autonomy. In one scenario, it simply finds options and takes the user to a traditional checkout. In another, it assembles the cart and asks for confirmation before proceeding. In more advanced architectures, it can operate within predefined limits on amount, category, merchant, frequency, or purpose.
The important difference is not simply having AI at the beginning of the journey. The turning point comes when a system stops merely recommending and starts executing actions that change the actual state of commerce.
Querying a catalog is a read operation. Reserving inventory is an action. Creating an order is an action. Selecting shipping is an action. Confirming a charge is a financial action.
The further the agent advances along this chain, the greater the need for identity, authorization, limits, traceability, and state control.
Agentic commerce does not eliminate existing commerce
A superficial interpretation would be to imagine that agents will replace traditional e-commerce with an entirely new technology stack. In practice, the emerging protocols and products point in another direction: agents connect to existing infrastructure through structured interfaces.
The merchant still needs a catalog, inventory, pricing, promotional rules, logistics, orders, fraud prevention, payment, customer service, and reconciliation. What changes is the entry point.
Today, much of commerce's capabilities are accessed through pages designed for people. In an agentic journey, those same capabilities need to be accessible to software in a predictable and verifiable way.
The principle is simple: commerce continues to belong to the merchant. The agent becomes a new channel.
This is also AZPay Agents' public proposition. The initiative starts from the infrastructure the company already uses and adds a layer for agents, keeping the catalog, checkout, customer, order, payment, and after-sales service within the existing operation. The product page describes an architecture in which e-commerce platforms and management systems are connected to a common layer, in partnership with Trydak, to prepare commerce capabilities for supported agentic channels.
This approach avoids a common trap of new technologies: requiring a company to rebuild everything before trying a new channel.
What does it mean to turn checkout into capabilities?
A checkout page presents options to a person. An agentic integration needs to present states and actions to another machine.
Consider a simple cart. For a person, the interface may display the product name, image, price, quantity, shipping, and purchase button. For an agent, the infrastructure needs to answer questions in a structured way: does the item still exist? What is the current price? Is it in stock? Which delivery options are available? Are there restrictions for the postal code? Is there an applicable discount? What is the final total? Is the session still valid? Which payment methods can be used?
More importantly, the response needs to be authoritative.
An agent should not complete a purchase using a price that appeared in a recommendation several minutes ago if the merchant has already updated that amount. The final state needs to be confirmed in the infrastructure responsible for the order.
That is why agentic commerce architectures tend to work with checkout sessions, complete cart states, and explicit creation, update, and completion operations.
OpenAI's public Agentic Commerce Protocol documentation follows this logic: the merchant creates and updates checkout sessions, returns the authoritative cart state, receives a completion call, and keeps order and payment processing within its own infrastructure.
The architectural point goes beyond any specific protocol: agents need clear contracts to discover state and execute changes.
Who is responsible for payment when an agent makes a purchase?
An agent can initiate or coordinate a purchase without necessarily becoming the financial processor of the transaction.
In current agentic commerce models, the merchant continues using its payment infrastructure. The agent or platform may carry an authorization, a token, or a limited instruction, while the PSP and traditional participants execute authorization, capture, and settlement.
This preserves an important separation of responsibilities.
The agent understands intent and coordinates the journey. The commerce infrastructure validates the order. The payment infrastructure executes the financial flow according to its own security, risk, and authorization rules.
In the Agentic Commerce Protocol, for example, the Delegated Payments model was designed to allow a payment credential or authorization to be delegated in a limited way, with restrictions such as merchant, amount, and expiration. The merchant and its PSP remain responsible for processing the payment.
This shows why agentic payments is not simply handing a card to an AI. The problem is creating an authorization that can only be used within a specific context.
Delegation does not mean unrestricted access
For agent payments to be acceptable, delegation needs limits.
Imagine the difference between two instructions.
The first is vague: use my card whenever you think it is necessary.
The second is operationally verifiable: you may complete this purchase with this merchant, up to this amount, within this session, and before this time.
The second can be represented by policies and data that systems can validate. The first requires excessive trust in a single component.
That is why a good agentic architecture tends to turn human intent into explicit permissions.
These permissions can involve a maximum amount, an authorized merchant, a validity period, a purpose, the agent's identity, and the session's identity. Depending on the protocol, they can also be represented by single-use tokens, delegated credentials, or cryptographic signature mechanisms.
The goal is to reduce the agent's implicit power and make the action more verifiable.
How does the merchant know it is communicating with a trusted agent?
In traditional e-commerce, bots are often treated as suspicious traffic. In agentic commerce, some automated traffic may represent a legitimate buyer acting through an authorized agent.
This creates a new problem: distinguishing trusted automation from malicious automation.
Visa, for example, developed the Trusted Agent Protocol to allow approved agents to identify themselves to merchants. The proposal includes signatures and time-related elements to reduce replay and associate the request with the context in which it should be used.
The specific details of each protocol may change. The need is structural.
The merchant needs to be able to answer questions such as: who is the agent? On whose behalf is it acting? Which action was authorized? Is the request recent? Has it been altered? Is this authorization valid for this domain and this action?
Without a trust layer, increased automation may simply expand the surface for fraud and abuse.
Payments still need idempotency
The arrival of agents does not eliminate classic distributed systems problems. In fact, it can make them even more important.
Consider an attempt to complete an order. The agent sends the request, but the connection drops before it receives the response. It does not know whether the order was created. If it repeats the action without controls, it may generate two orders or two charges.
Idempotency allows the infrastructure to recognize that two requests represent the same intent and avoid producing duplicate effects within the supported scope.
This is already essential in payment APIs. In agentic commerce, it becomes part of the boundary between two autonomous systems.
A good implementation needs to identify at least the session, the purchase intent, and the execution attempts. It also needs to distinguish a communication failure from an actual business failure.
A timeout is not proof that nothing happened.
Webhooks stop being an integration detail
A purchase journey does not end when the HTTP request returns.
A payment may be confirmed later. An order may change state. An item may be picked, shipped, canceled, or refunded. A delivery may be updated. A merchant may need to communicate these changes to the channel where the purchase began.
That is why agentic protocols treat asynchronous events as a central part of the architecture.
The Agentic Commerce Protocol documentation uses webhooks to keep order state synchronized between the merchant and the agent experience. The same principle applies to payments: asynchronous events help close the loop between intent, authorization, and final state.
The challenge is ensuring that these events are authenticated, deduplicated, and processed in a sufficiently ordered way so the system does not revert to an incorrect state.
When the interface stops being an isolated page and becomes a relationship between systems, state consistency becomes the user experience.
Tokenization takes on an even more strategic role
Agentic payments increase the importance of tokens and restricted credentials.
A card's PAN is a sensitive and powerful credential. The more systems need to interact during a purchase, the greater the need to reduce exposure of that credential.
Tokenization allows primary data to be replaced with identifiers that have a controlled scope. Depending on the model, a token may be associated with a merchant, device, channel, or usage scenario.
EMVCo defines Payment Tokenisation as a way to replace the PAN with an alternative value whose use can be restricted to specific contexts.
In an agentic architecture, this characteristic is especially valuable: the agent does not need to receive a universal credential to participate in the journey.
The trend is to bring identity, intent, and credentials closer together. Instead of simply asking whether a valid payment method exists, the infrastructure starts asking whether this credential can be used by this actor, for this purchase, within these limits.
Agentic commerce meets payment orchestration
When an agent initiates a purchase, the processing problem still exists after the intent reaches the merchant.
The payment may still pass through a gateway, PSP, acquirer, fraud prevention, authentication, and other components. If the operation works with multiple providers, there is still a decision about which route to use.
This creates a natural connection between agentic commerce and payment orchestration.
The agent does not need to know the merchant's internal payment topology. It expresses the commercial intent. The merchant's infrastructure and its orchestration layer can decide how to execute that intent according to rules for availability, method, geography, cost, performance, and risk.
This separation is healthy because it avoids exposing operational complexity to the channel.
An agent should not need to know which acquirer is processing the transaction to complete the purchase. Likewise, the merchant should not need to change the agent every time its routing strategy changes.
Agents increase the importance of observability
When a user says a purchase made by an agent failed, the team needs to be able to reconstruct what happened.
Did discovery find the right product? Was the returned price up to date? Was inventory confirmed? Did the checkout session expire? Was the user's authorization within its limits? Was the token valid? Was the payment declined? Was there a timeout? Was the order created? Did a webhook arrive later?
Without correlation between these events, the new channel can create an operational black box.
That is why agentic commerce requires observability that crosses boundaries.
There is no need to expose every internal detail to the agent, but the operation needs to be able to correlate an intent with a session, an order, a payment attempt, and its asynchronous events.
Consistent identifiers are part of the architecture.
What changes for fraud prevention and risk?
Today, many risk strategies use signals tied to a user's browser session: device, IP, behavior, history, identity, and purchase context.
When an agent enters the flow, some of that context changes.
A request may come from the agent's infrastructure rather than the buyer's end device. Browsing behavior may disappear. At the same time, new signals emerge: agent identity, delegation chain, explicit limits, request signature, and agentic authorization history.
This does not mean agents are necessarily more or less secure. It means the risk model needs to understand a new actor.
Trying to assess an agentic transaction using exactly the same signals as human browsing can produce false positives or leave gaps.
The likely evolution is to combine traditional payment signals with signals specific to delegation and agent identity.
The user still needs control
Automation does not eliminate consent.
The more autonomous an agent is, the more important it becomes to define in advance what it can do.
There is a profound difference between an agent that asks for confirmation for every purchase and a corporate agent authorized to reorder a particular supply when inventory falls below a threshold. Both can make sense, but they require different permission models.
The system needs to know whether the action requires confirmation at that moment or whether a valid prior authorization exists.
This is one reason agentic payments bring the world of commerce interfaces closer to the world of access policies.
Purchasing also becomes a matter of software authorization.
Brazil adds its own layers
Global agentic commerce cannot ignore local realities.
In Brazil, a commerce experience may need to handle Pix, installment payments, boleto, different logistics models, tax rules, and local platforms. This changes the design of an integration that cannot assume every purchase ends with a credit card and a single delivery flow.
AZPay Agents was publicly presented with precisely this concern in mind. The page highlights Pix, installments, shipping, tax operations, and local platforms as part of the reality of Brazilian commerce.
In addition to platforms such as Shopify and WooCommerce, the project shows connections with relevant ecosystems in the country, including Nuvemshop, Loja Integrada, Tray, and VTEX, as well as management and back-office systems such as Bling, Tiny ERP, Omie, Conta Azul, and Odoo.
The architectural message matters: adapting commerce for agents is not about creating a parallel catalog. It is about connecting capabilities that already live in different systems within the operation.
Where does AZPay Agents fit in?
AZPay Agents is an AZPay initiative in partnership with Trydak to connect existing commerce operations to supported agentic channels.
The public proposition is to work from the infrastructure the company already has. The layer organizes capabilities that agents can query or operate and prepares those capabilities for new channels and protocols as support becomes available.
This preserves a fundamental distinction.
AZPay Agents does not start from the idea that a company needs to abandon its e-commerce platform, ERP, or checkout. It starts from the idea that these systems already contain the necessary business capabilities and need to be presented appropriately to a new kind of software consumer.
The expected result is a new entry point without losing control of the operation.
The catalog still belongs to the merchant. The order still belongs to the merchant. Payment stays within the merchant's infrastructure. The customer relationship still belongs to the company.
Agentic commerce is a new channel, not a new owner of the operation
This principle helps evaluate any proposal for agent-based commerce.
If adopting a new channel requires the merchant to permanently hand over its catalog, relationships, data, payments, and after-sales service to another platform, there is a structural change in dependency.
If, on the other hand, the channel can operate through clear contracts on top of the existing infrastructure, the company preserves more portability.
This discussion resembles the evolution of payments. Integrating a PSP solves processing. Orchestrating multiple PSPs creates control over routes. Similarly, publishing products in a channel solves distribution. Exposing commerce capabilities in a structured way creates a control layer that can serve different channels.
The question stops being which agent will dominate the market and becomes whether your commerce operation is prepared to communicate with different agents.
What should a company prepare now?
There is no need to predict exactly which protocol will win to start organizing the architecture.
The first step is to understand where the sources of truth are. Which system controls the catalog? Which controls pricing? Which controls inventory? Who calculates shipping? Where is the order created? Which system represents its state? How is payment initiated? How are subsequent changes communicated?
The second is to turn important capabilities into consistent integration contracts. An API does not need to be public to the entire world, but the company needs to know which actions can be exposed and under which permissions.
The third is to improve identity and traceability. Sessions, orders, attempts, and events need identifiers that make it possible to reconstruct a journey.
The fourth is to review idempotency and asynchronous events. If an external integration repeats a call, the system should produce the correct behavior. If an event arrives twice or out of order, the operation should not corrupt state.
The fifth is to treat payment as a separate domain. The channel should submit a purchase intent; authorization, routing, risk, and capture decisions should remain under the control of the payment infrastructure.
Do I need to rebuild my checkout to sell through agents?
Not necessarily.
This is one of the most important questions for companies looking at agentic commerce now. If the catalog, inventory, pricing, checkout, order, and payment already exist, the opportunity lies in organizing how these capabilities can be accessed by new channels.
A company may need to create or improve APIs, webhooks, and state contracts. It may need to review authentication, authorization, and idempotency. It may need to make some rules less dependent on a visual interface.
But that is different from abandoning the current operation.
The principle behind AZPay Agents is precisely to connect what already exists and add a layer for agents.
Will agents replace websites and apps?
It is too early to treat that outcome as inevitable.
Websites, apps, marketplaces, messaging, and agents can coexist as different channels. Some purchases are simple and intent-driven. Others depend on visual discovery, entertainment, brand, experimentation, or human interaction.
What seems more relevant architecturally is preparing commerce so it does not depend on a single interface.
If products, pricing, inventory, orders, and payments can only be operated through a specific page, each new channel will require a rebuild. If those capabilities are organized as services and contracts, new interfaces can emerge without rewriting the entire business.
Agentic commerce serves as a maturity test for commerce architecture.
The challenge is not getting an AI to click buy
Automating a click is easy compared with the rest of the problem.
The real challenge is proving the action was authorized, ensuring the price is still valid, confirming inventory, calculating terms correctly, protecting credentials, preventing duplicates, processing payment, keeping states synchronized, and enabling the team to explain what happened when something fails.
That is why the next generation of commerce will not be built solely at the interface layer.
It will depend on APIs, identity, authorization policies, tokenization, webhooks, observability, orchestration, and systems capable of operating clearly in distributed environments.
The screen may become optional in some journeys. The infrastructure will not.
Commerce beyond the screen
For years, checkout was treated as the endpoint of the digital journey. Agentic commerce turns checkout into an interface between systems.
This changes the kinds of questions companies need to ask.
It is not enough to ask whether an agent can find my product. We need to ask whether it can receive an authoritative price, understand the available options, act within a verifiable authorization, initiate a payment securely, and track the actual order state without taking control of the operation.
This is the transition from commerce designed solely for people on screens to commerce also prepared for agents.
At AZPay, we see this change as an engineering challenge. Existing commerce needs to keep working. Innovation lies in creating a layer that allows it to participate in new channels without losing its identity, control, and infrastructure.
That is the territory of AZPay Agents: connecting today's commerce to commerce beyond the screen.
To distinguish the roles of tools, checkout contracts, and verifiable authorization, see MCP, ACP, UCP, and AP2: what each protocol solves in agent-based commerce.