The AI agent is already at the checkout door: what happens in your systems when the buyer is a machine

A customer tells their AI assistant: "Buy me the black sneakers, size 27, and have them arrive Friday." The assistant opens the online store, picks the product, fills in the shipping address and reaches the payment screen. There it stops and asks the customer: "Shall I confirm?" The customer taps a button. The order enters your system.

Look at that scene from your company's side. Until the button, whoever visited your store was not a person. And after the button, your operation has to collect, invoice, ship, reconcile and, if something goes wrong, answer for a purchase that none of your systems saw originate in the way they are used to.

This is no longer a laboratory hypothesis. This article is for whoever is responsible for sales, finance, operations or technology at a bank, a fintech, an insurer, a retail chain or a regulated company. It proposes setting aside the fashionable question —will agents buy on their own?— and asking a more useful one: what happens in my systems when what arrives at the checkout is a machine? Depending on your role, the question changes: for a merchant it is the catalog, the order, the CFDI and returns; for an issuer, limits, consent and revocation; for an acquirer or payment processor, acceptance, signals and disputes; for a regulated company, authorization, traceability and data.

What did happen, and what didn't

At the end of September 2026, Shopify documented (September 28) that AI agents operating in a browser can now use four tools on its checkout screen: go to the store, read the order status, update shipping and delivery data, and submit the order. Those tools run inside the same web checkout that a person uses and with the same state that the interface shows [1].

The nuance matters: the tool that submits the order does so after the buyer's confirmation [1]. According to the documentation, moreover, control returns to the person when the additional 3D Secure verification is required, the step by which the issuing bank checks that the cardholder is the one paying [1].

In other words: in the flow Shopify documented, the agent prepares and the person confirms; other schemes, such as AP2, already contemplate autonomous purchases under prior authorization from the customer [7]. Speaking of "buying on their own" in this case would be an exaggeration. The truth is more uncomfortable and closer to home: in the flow documented by Shopify, the agent already reaches the door of the checkout, and without the store opening a special door for it: according to Shopify, those tools do not expose a new interface or require merchant configuration [1].

Two more items have been reported, and it is best to treat them as what they are. According to statements by a spokesperson reported by GeekWire, Amazon blocks Muse, Meta's shopping agent, among other reasons because it does not identify itself when it browses the store [2]. According to Infobae, Adidas had done something similar, with no confirmation from the company [2]. Neither case demonstrates a market trend.

A piece of context, so as not to inflate expectations. In a May 2026 Visa and Harris Poll survey in the United States (2,065 consumers; the payments question was asked of a subsample of about 1,030), 23% said they trust generative AI to make payments on their behalf [3]. It is a survey by a payments provider, in another country, and it does not measure purchase volume. In our review as of October 17, 2026 of the sites and press releases of the protocols and networks cited here, we found no public figures on the volume of real transactions made by agents. What does exist is the infrastructure, and that is what you need to review.

Five things your company has to resolve

All of them stem from a single idea: many e-commerce flows still presuppose a human session, with their own card and an email address. An agent can break each of those assumptions separately.

1. Identity: does it open the door or block it?

Many filters against automated traffic do not distinguish between price scraping and a customer assisted by an agent: they treat both as a bot. That protects your site from price scraping and from attacks, but it may also be rejecting, without your knowing it, real customers who buy through an assistant.

Visa and Mastercard already document mechanisms to identify agents. Visa's Trusted Agent Protocol lets a merchant tell a legitimate agent from a bot by means of cryptographic signatures tied to the merchant and to the purpose of the visit, short-lived and not reusable [4]. It relies on an open standard for signing HTTP messages, RFC 9421 [5]. Mastercard, for its part, announced that its Agent Pay acceptance framework requires registering and verifying the agent before any transaction [6].

What none of those pieces decides for you is the policy: which agents get in, with what query and amount limits, and who maintains the list. And both options have a cost. Blocking everyone can lose sales that were already closed. Opening up without criteria exposes your catalog, your prices and your inventory to mass queries. Identify who owns that decision in your organization.

2. Authorization: who said yes to this payment?

When a person buys, the authorization is on the screen: they type, confirm, the bank validates. With an agent, that depends on the scheme. There are flows in which the buyer still confirms at checkout, such as Shopify's and that of the OpenAI and Stripe protocol [1][9]. But in delegated or pre-authorized schemes, the permission was given earlier, somewhere else, and your company needs evidence that it was given.

The protocols attack this problem with similar ideas. Google's AP2 uses signed "mandates": a customer permission with rules —price cap, validity— and an approved cart, which seek to leave a verifiable trail of what was authorized [7]. Visa combines a payment token made for agents with reinforced cardholder verification through a passkey [8]. The protocol from OpenAI and Stripe uses a scoped payment token that does not expose the customer's card and leaves the merchant responsible for the sale [9].

For a company, a third type of credential appears that is neither the customer's card nor their wallet: a token with a limited amount, merchant and validity, in the hands of a program. In flows that use scoped credentials, confirm with your payment processor or acquirer how they are received, validated and reported; the mechanism depends on the protocol and on the payment route. For an issuing bank, the question is a different one: how to show the customer what their agent can spend, and how to revoke it.

3. Disputes: who answers when the agent makes a mistake?

Think of a chargeback with a new reason: "I didn't order this; my agent made a mistake." Was it the customer's error, the merchant's, the agent platform's or the issuer's? The protocols seek to preserve evidence of the original instruction: AP2 with its mandates [7] and Visa with what it calls "commercial signals" to resolve disputes [8].

But evidence is not a standard for deciding. In our review as of October 17, 2026 of publications by the CNBV, Banxico and CONDUSEF (Mexico's banking regulator, central bank and financial consumer protection agency), we found no Mexican rule that expressly assigns liability for an agent's error; it is not an exhaustive legal review. Review network and acquiring contracts and the applicable obligations before setting a policy. In the meantime, your company's protection depends on what you can demonstrate: what instruction it received, from which agent, with what permission and what your store showed at that moment. It is worth deciding today which evidence to keep and for how long, according to the applicable retention policy, because reconstructing it after the first dispute may not be possible.

4. Tax data: who gets the invoice?

Here is the most local problem and the easiest one to overlook. In Mexico, CFDI 4.0 (the electronic tax invoice) requires data on the recipient: their RFC (taxpayer ID), their name or business name, their tax regime and the postal code of their tax address [10]. A person enters them in a form, or their account already has them. An agent may not carry them.

Without the recipient's data, a named CFDI cannot be issued during checkout. Your team then has three paths, and all three cost something: asking the customer for the data afterward, with the friction and delay that brings; applying a later-invoicing policy; or including the transaction in the global invoice (factura global), which applies to transactions with the general public under the conditions of rule 2.7.1.21 of the Resolución Miscelánea Fiscal (Mexico's annual tax rules) [14], and which does not replace a named CFDI when the customer asks for one. None of the sources we consulted settles who the tax recipient is for a purchase made through an agent. It is an open question and it is worth answering before the cases multiply.

5. Fraud: how do you tell a legitimate purchase from a stolen one?

The risk models that protect a merchant are fed, in large part, by signals from a person: the device, the browsing pattern, the time, the rhythm of typing. When an agent is involved, those signals may be missing: the traffic comes from a program, and models calibrated for human traffic may need to be revalidated.

That forces a review of rules, a decision on when to ask for additional human confirmation and the incorporation of the new signals that the networks offer. And it forces something more basic: knowing that the order came from an agent. If that fact is not stored in the order together with who authorized it, reconciliation and the defense against a chargeback become manual work. The same goes for returns: define with your acquirer the route through which they go back.

The protocols, by layer

The names multiply —ACP, UCP, AP2, Visa, Mastercard— and it is easy to believe you have to pick one. They do not compete for the same thing: each one solves a different layer. And they are at different stages of maturity, which are best not confused.

A company could end up speaking several of these protocols at once. Hence the useful question is not "which one do we adopt?" but "what do my systems need to have resolved in order to speak any of them?"

What they have in common is what falls to you: a catalog, prices and inventory that a machine can query through an interface with no person in between; an order that records its origin; and a file of who authorized what.

Scenario: an online store with 10,000 orders a month

Illustrative scenario, with invented figures to show the effect. It does not describe any company.

An online store receives 10,000 orders a month. Suppose 3% start arriving through agents: 300 orders. So far, a small figure. Now suppose a fifth of those customers ask for an invoice and the agent did not carry the tax regime or the use of the receipt: that is 60 invoices that cannot be stamped on the spot.

If an analyst spends 15 minutes on each one, that is 15 hours a month of manual work that did not exist before. If the share of agents rises to 10%, those hours become 50. And we have not counted a single chargeback, a single return over an order the agent misunderstood, or a single reconciliation that cannot find which agent the charge came from.

The lesson of the example is not the figure: the scenario lets you estimate hours, delays in the close and missing evidence.

What is worth doing this week

You don't need a project to start. You need to answer five questions with the right people at the same table:

1. Traffic. How much of what your site rejects as a bot could be a customer's agent? If you don't measure it today, that is the first answer.
2. Access policy. Who decides which agents get in, with what limits, and what is the cost of each decision?
3. Evidence. When an order comes from an agent, what is stored: who authorized, what was shown, what was charged?
4. Invoicing. What does your tax area do with an order that has no recipient data, and who tells the customer?
5. Liability. If the agent makes a mistake, who absorbs the cost: the customer, you, the issuer or the platform, and where is it written?

So that the answers stop being opinion, it helps to measure three things your team can gather today, without anyone else's figures:

• Traffic rejected as a bot. What percentage of the visits your site blocks or challenges corresponds to patterns that could be a customer's agent? Who reviews it and how often?
• Cost of rebuilding an invoice. How much time and how many people does it take today to redo an invoice when the order arrived without complete tax data? Multiply it by the number of orders that could arrive that way.
• Cost of a chargeback. How much does it cost you today to handle a chargeback from start to finish —time, fee, merchandise and evidence— and how much more would it cost if the reason were "my agent made a mistake"?

If two or more of the answers are "I don't know" or "it depends on who answers," it is not a failure of your team: these are questions that, until a few months ago, nobody had a reason to ask. What has changed is that the pace is no longer set only by your internal agenda: the ecosystem is setting it.

There is also a technical part that already has a guide. That an agent can query your catalog, retry without duplicating an order and receive errors it understands is not a checkout matter alone: it is a property of your interfaces. We develop it in the article APIs ready for AI agents.

What Hábil does

The problems above have something in common: they occur at the seam between systems. The order is born in one channel, the charge in another, the invoice in a third and the reconciliation in a fourth, and none of them is responsible for knowing that the buyer was an agent. Hábil works at that seam: integrating existing systems with the aim that operations leave an audit trail of who authorized them and that a new channel does not force rewriting the earlier ones.

If your company is thinking about how to receive —or how to limit— AI agents, the Hábil AI page explains what we do with them, and the article APIs ready for AI agents details what your system needs so that an agent can use it under control.

The next step is simple: write to us on WhatsApp. In a first conversation, at no cost, we tell you where money, time or evidence is probably being lost in the interfaces of your operation and whether an in-depth assessment, with an agreed scope, is worthwhile.