Merchant guide

Agentic commerce: what AI ordering actually requires.

Assistants are starting to place orders on people's behalf, and every payments vendor now has a slide about it. Underneath the slides are two competing protocols, one invitation-only pilot, and a set of questions about who takes the money that most announcements skip. This guide is the version without the hype: what exists, what it actually takes to participate, and the three things worth doing today no matter which standard wins.

What "agentic commerce" means, minus the hype

An assistant does the shopping on a customer's behalf: it finds a merchant, reads what is available, assembles an order, and completes a checkout. The customer still chooses and still collects the goods. What changes is the audience for a storefront. For twenty years the reader was a human with a browser. Now some of the readers are programs, and a program cannot interpret a PDF menu, a photo of a chalkboard, or a price that only exists in someone's head.

That is the whole shift, and it is less mystical than it sounds. The practical requirement is that a merchant's catalog, prices, hours and availability exist somewhere a machine can read reliably, and that an order can arrive without a human retyping it.

Two protocols, and they are not the same thing

The industry has not settled on one standard, and a merchant does not have to pick a side to be ready.

  • UCP — the Universal Commerce Protocol. An open specification published at ucp.dev, backed by Google and Shopify among others. A business publishes a discovery profile at a well-known address describing what it supports, and assistants use a defined checkout API against the business's own server. Square, Google and others have said they are extending it to food ordering.
  • ACP — the Agentic Commerce Protocol. OpenAI's route, developed with Stripe, is how ChatGPT-side commerce works. It is a different specification with a different onboarding path.
  • Payment authorization. A separate layer again addresses the harder question underneath all of this: proving a human actually authorized a purchase an agent executed.

The useful takeaway for a merchant is structural rather than technical: discovery, checkout and payment authorization are three separate problems, and a vendor claiming to have solved all three for you today is describing a roadmap.

What Square's Google announcement actually was

In August 2026 Square announced that its US food and beverage sellers can surface in Ask Maps, Google's conversational layer in Google Maps, with menus, hours and location details syncing automatically from Square Dashboard to Google, and checkout running through Order by Cash App.

It is worth being precise about the mechanics, because they are frequently reported as something a merchant can simply switch on:

  • Square documents an activated Google Business Profile as the prerequisite for its sellers. Google has not published a general requirement.
  • Menu, hours and location data syncs automatically from Square Dashboard to Google. A copy of the catalog lives outside the merchant's system.
  • Ordering inside Maps is partner-mediated — Google works with named integration partners rather than accepting any merchant who publishes an endpoint.

Separately, Google runs a Universal Commerce Protocol checkout program that a merchant joins through Merchant Center by expressing interest and being selected. It targets Google's AI answers in Search and Gemini rather than Maps, and a merchant registers and validates their endpoints inside Merchant Center — publishing a profile is not, on its own, how Google finds you. Two different rails, frequently conflated.

The part a payments company should be asked about: who takes the money

Most coverage of agentic commerce stops at discovery. The questions that decide whether it is safe for a merchant are further down.

Pay at pickup

The assistant places an unpaid order; the merchant collects at the counter on their existing rails. Nothing about the merchant's processing changes and no cardholder data touches the ordering path, so it introduces no new card-data flow. Overall PCI scope still depends on the whole environment and is a question for your assessor. The trade is real but modest: goods are prepared or held before money is committed, so stock reservation and a no-show policy matter.

Checkout inside the conversation

Payment is authorized during the assistant's flow. This is where a merchant should slow down and ask the questions that determine cost and liability:

  • Who is the merchant of record? That answer drives the funding flow, the descriptor a cardholder sees, and who fields the dispute.
  • Which rate applies? An agent-completed sale is card-not-present. If it is being priced like a card-present tap, the economics on the slide are not the economics on the statement.
  • Who owns a chargeback, and on what evidence? "The assistant said the customer approved it" is not compelling representment evidence. Ask what artifact proves cardholder authorization.
  • What happens to a refund? Reversals need to land on the rail that captured the money.

None of that argues against agentic commerce. It argues for reading the contract, which is the same advice that applies to every new channel that has ever been sold to a merchant as free incremental revenue.

Three things worth doing today, whichever standard wins

  1. Activate and complete a Google Business Profile. It is free, independent of any point of sale, and the prerequisite Square documents for its own sellers on Ask Maps. If a business does one thing from this page, this is the one.
  2. Make the catalog true in the system of record. Prices, availability, hours and what is actually sellable online. Every agent surface reads from that data, and no protocol rescues a catalog that is wrong.
  3. Check the point of sale can publish a catalog and take an order without a human retyping it. That plumbing — a readable catalog and an order queue staff already work — is what every protocol ultimately depends on. A business that already runs online orders is most of the way there.

What we are building, stated plainly

LiftedPOS, the point of sale built by Lifted Holdings, is implementing the published UCP profile and checkout API so a merchant can be ordered from on the open standard rather than through one vendor's private integration. It is in development and not enabled for merchant accounts today.

Two design choices are worth stating because they are the opposite of how this is usually done:

  • No feed leaves the store. Nothing is uploaded, synchronized or registered with Google, OpenAI or anyone else. An assistant asks the merchant's own address and the system answers the request. There is no copy of the catalog sitting in a third party's database to go stale or be repurposed.
  • Orders arrive unpaid. The first version takes no card at all. The order lands in the online-order queue staff already work and the counter collects the money, so a merchant's payment setup and PCI posture are untouched by turning it on.

When a specific assistant can order from a LiftedPOS merchant, we will say so and name it. Until then the honest claim is narrower: the store speaks the standard, and the merchant keeps their data.

Related reading