Agentic Commerce in Ticketing: Why Every Major Platform Stopped at the Handoff

Ask Claude or ChatGPT for a pair of tickets to a Saturday show under $150, and you may receive a reply that looks a lot like a screen from Ticketmaster or StubHub, with sections, prices, and sometimes even a venue map laid out inside the conversation. The biggest difference? When you tap 'Buy', the assistant sends you to the ticketing platform's own website to pay.

That handoff is the most revealing click in agentic commerce right now. All three of the largest Western ticketing platforms have built a way for AI assistants to search their inventory, and every one of those connections stops at the same spot: the assistant finds and compares, while the platform keeps the checkout, the customer record, and the fees.

It would be easy to read that as a feature nobody has finished yet, but there's more to the story. Softjourn's R&D team spent the past several months mapping how AI ticketing works across the assistants, the protocols, and the platforms, and what we found explains why the market stopped at the handoff. Those same reasons are the clearest guide to how your own platform should approach agentic commerce this year.

What Is Agentic Commerce?

Agentic commerce is buying and selling in which the buyer's AI assistant does part of the shopping, finding the event, comparing options, and, in its fullest form, paying. Instead of clicking through pages designed for a person, the assistant talks to the seller through a machine interface designed for software.

A year ago, the pitch was that the assistant would simply buy for you. What actually shipped is narrower, since in almost every live case the assistant handles discovery and comparison and then passes the buyer to the seller's checkout to complete the purchase.

What Agentic Commerce Is Not

Three things get mixed up with agentic commerce often enough that it's worth ruling them out early:

• A chatbot on your own site: the assistant belongs to the buyer and to its operator, whether that's OpenAI, Google, Anthropic, or Amazon. Your platform is one of many sellers it can reach, and the real question is whether your catalogue answers when a fan asks.
• Scraping: assistants can read a website the way a person would, and scripts already use headless browsers to watch and scrape ticketing sites, for example to catch resale tickets on Ticketmaster. Agentic commerce proper means the seller provides an interface it controls, so the assistant can call it directly.
• IBM's ACP: two protocols share the abbreviation. The one that matters here is the Agentic Commerce Protocol from OpenAI and Stripe, while IBM's Agent Communication Protocol (since merged into A2A under the Linux Foundation) lets agents talk to each other and has no cart or checkout at all.

The scraping point deserves a second look, because it means a platform without an official interface is probably already receiving automated traffic, just without any way to see who sent it, limit it, or attribute the orders it produces.

The Three Models of Agentic Commerce in Ticketing

The clearest way to place a ticketing platform is by how far the buyer's assistant can go before the buyer has to leave the conversation. Softjourn's research separates three models, and each gives a different answer to the question of where the money moves.

The three models of agentic commerce in ticketing.

Why the Handoff Agentic Commerce Model Leads

The handoff model is where nearly all of the real activity sits. When Ticketmaster launched in Gemini in August 2026, fans could search for events and choose seats inside the conversation before being sent to Ticketmaster's checkout with those seats already selected (Ticketmaster Business, 2026). Ticketmaster's Claude app, launched in July 2026, works the same way, telling fans to continue to Ticketmaster to complete the purchase (Ticketmaster Business, 2026). StubHub's and SeatGeek's ChatGPT apps follow the same pattern, linking into their own sites or apps at the moment of purchase.

For the platform, this split keeps everything that is hard to get right about a ticket sale (the seat, the payment, and the buyer's identity) on infrastructure it already runs, while still putting its inventory in front of buyers who now begin their search in an assistant.

It's also easy to overestimate how far any platform has gone. Ticketmaster's Google AI Mode launch first read like an in-chat purchase, but a closer look at the announcement shows the flow sends fans to Ticketmaster's own checkout, and the wider market has already tried in-chat checkout once and stepped back from it.

Why the Market Stopped at the Handoff

What OpenAI's Checkout Reversal Showed

In September 2025, OpenAI and Stripe launched ACP together with Instant Checkout, which let ChatGPT users buy from retailers without leaving the chat. About six months later, OpenAI changed course, saying it was "allowing merchants to use their own checkout experiences while we focus our efforts on product discovery" (OpenAI, 2026).

The reasons reported around the change all pointed to merchants, who described difficult onboarding, stock falling out of sync, weaker customer loyalty, and better results on their own storefronts. All of that happened in retail, where products are interchangeable and delivery can wait a few days, which is worth keeping in mind because tickets are the harder case on almost every one of those counts.

Why Ticketing Can't Simply Switch to In-Chat Checkout

Ticketing never reached in-chat checkout in the first place, and there are structural reasons a platform can't just turn it on:

1. No open buying program lists tickets: none of the merchant programs run by OpenAI, Google, or Microsoft names tickets as an eligible category, and Amazon's Alexa+ Agentic Ads is the one exception.
2. Every program starts in the US: most admit merchants by application, and even where Shopify now switches on direct checkout by default for eligible stores, those stores need to sell to US buyers, which still leaves platforms elsewhere with few routes in.
3. Google's shopping rules appear to exclude concert tickets: Google's checkout requires approved free listings, and the free listings policy doesn't allow concert tickets. No single Google page says tickets are excluded from agentic checkout, so this is a strong inference rather than a stated rule.
4. The protocols don't fit tickets: this is the largest obstacle of the four.

What the Ticketing Industry Hasn't Done Yet

When Softjourn's R&D team checked UCP's list of co-developers and endorsers, the partners named in AP2's launch post, x402's members page, and ACP's project site in August and September 2026, they found no ticketing platforms named on any of them. A separate check on September 7, 2026 showed that the standard address where a merchant publishes its Universal Commerce Protocol (UCP) profile returned "not found" at Ticketmaster, StubHub, and Eventim, even though ordinary retail brands serve a profile at the same location.

How the ticketing market got to the handoff.

Why Agentic Commerce Protocols Don't Fit Tickets

ACP, UCP, and AP2 in Plain Terms

The commerce protocols get most of the attention, so a short map helps. ACP, the Agentic Commerce Protocol, was started by OpenAI and Stripe, with Meta now a lead maintainer. UCP, the Universal Commerce Protocol, was launched by Google with Shopify and other large retailers. Both define a checkout session that an assistant can create, update, complete, or cancel. AP2, the Agent Payments Protocol, was created by Google and has since been contributed to the FIDO Alliance; it records signed proof that a person approved a purchase within set limits.

All three were written with warehouse goods in mind, where any unit is as good as the next and delivery can follow later. A ticket works differently, because it is one specific seat at one performance, sold in a rush to more people than there are seats.

From a chat to a ticket in seven stages, and where the handoff sits.

The Five Gaps Between Ticketing and the Protocols

Read at field level, the protocols leave five gaps that a ticket sale can't work around:

1. There is no seat hold: neither ACP nor UCP has an operation to hold, reserve, or lock inventory. Both offer a checkout session that expires, and Softjourn's review of the UCP specification found a default session lifetime of six hours, against seat holds that typically last a matter of minutes.
2. Consent freezes the price: under AP2, the buyer's approval is tied to the exact checkout they signed, so any price change cancels it, even a drop. The one exception is AP2's open payment mandate with a price range, which can survive a change without going back to the buyer.
3. No hold has its own timer: both protocols represent checkout expiry (six hours by default in UCP), but neither protocol's main checkout schema defines a separate seat hold with its own timer, so a ticketing platform has to define that lifecycle itself.
4. Nobody decides the race for a seat: ACP prevents a single caller from repeating the same request twice, but nothing settles what happens when two callers want the same seat at the same moment.
5. There is no queue or per-person limit: no protocol has a state for a virtual waiting room, and none can express a rule like "this person may buy at most four."

Every approach stops at the seat hold: which purchase stages each protocol and live assistant connection can handle.

The standards groups are aware of the problem. A UCP discussion thread names concert tickets as the failure case, and a later proposal for timed-entry tickets drew no reply until the October council proposal listed it as prior work to fold in, while the only booking capability added to UCP so far, a draft built for hotels, treats its hold as optional. The closest movement so far came on October 9, 2026, when Stripe filed a proposal for a UCP Local Services council, backed by Meta, Wix, Squarespace, and others, that calls for short, time-limited holds on appointments and capacity-limited classes and events (UCP on GitHub, 2026). It is still awaiting review by UCP's governing council and has no public replies yet. Short holds are in its first phase, but only for appointments and capacity-limited classes and events, with reservations and rentals left for later, and neither ticketing nor seat maps appear anywhere in its scope.

The Seat Hold Problem in Practice

To see what the first gap means for a buyer, picture an assistant trying to finish a purchase inside the chat. The assistant opens a checkout and the platform, to be safe, holds Section 102, Row G, Seat 4 and starts a timer, but because the protocol has no field for that timer, all the assistant receives is a price and a session ID. The buyer steps away for a few minutes to check their plans, the hold quietly expires, and someone else buys the seat, so when the buyer finally says yes, the platform has to answer that the seat is gone.

The seat hold problem as it plays out for the buyer and the platform (illustrative).

If the platform hadn't held the seat at all, the same failure would simply arrive one step later, with the buyer approving a payment for a seat that sold while they were deciding.

The market's working answer is to avoid that moment inside the assistant entirely. When the buyer is handed off at the point of selection, the hold, the race for the seat, and the payment all happen on infrastructure the platform already controls.

Telling an AI Agent From a Scalper

There's a second reason platforms keep the transaction close, which is that an authorized shopping agent and a scalper's script send identical requests. A signed request can reveal which operator sent it, but no signature says how many tickets this person has already bought, and that question now carries legal weight.

On September 28, 2026, a federal judge refused to dismiss the FTC's case against Live Nation and Ticketmaster, holding at this early stage that the BOTS Act "does not preclude platforms from facing liability" in a case about brokers running many accounts to get around ticket limits, not AI agents (court order, 2026).

Telling an agent from a scalper takes signature checks at the edge, identifying the buyer before a hold, and per-person limits that count holds as well as orders across every channel. We'll cover each of these in a follow-up article.

Agentic Commerce in the US vs. Outside the US

Every assistant buying program covered in this article starts in the US, so a platform based in Europe or elsewhere begins from a different place than one selling mainly to American fans. Softjourn's research gathered the regional conditions for each route into one view:

What This Means for Platforms Outside the US

For a European, Latin American, or Asia-Pacific platform, the groundwork is the same as anywhere else: a readable catalogue and your own connector work wherever buyers use assistants that accept connectors, while directory listings and in-chat checkout remain largely US-only for now.

Europe adds one more consideration, since strong customer authentication makes the bank's extra check a routine part of paying online, which tilts the case even further toward handing buyers off to a checkout the platform controls.

The research is also open about what it hasn't covered yet. The agent policies of major European ticketers such as Eventim, Pretix, and Weezevent haven't been studied in depth. Early examples do exist: Seatpin, a European ticket marketplace, already has an app in ChatGPT (PYMNTS, 2026). But no first-party assistant connector has appeared yet from CTS Eventim, while Fever already has a Gemini app and tickadoo offers one connector across ChatGPT, Claude, Gemini, and Perplexity.

What a Ticketing Platform Can Build Today in Agentic Commerce

None of this requires waiting for the assistants to change their rules. The research points to a clear order of work in which each step is useful on its own and makes the next one possible.

Groundwork Any Assistant Can Use

1. Make the catalogue readable: this is the groundwork for the discovery-only model, and everything else depends on it. Much of it is data hygiene that ticketing systems often skip:
2. • one stable ID for each performance and ticket type, with the event as its parent
   • a typed price with the base price and fees kept in separate fields
   • an availability status for each ticket type
   • refund and cancellation terms stored as fields, not only written into page copy
   • structured data on event pages, with no login wall in front of them
   • a complete daily feed, which is also what Google's events referral program asks for
2. Build your own connector with a handoff: this is the position the major platforms hold today. A connector is the platform's own MCP server, and in our reference design, getting started takes less than most teams expect: a handful of tools that don't require sign-in (search, event details, an organizer's events, and a purchase link), plus a link that opens your checkout with the ticket type and quantity already chosen. Tagging every order that arrives this way lets it show up in reporting, and platforms that serve many organizers should let each one opt in.

A connector built this way already works in Claude, can be added by users in ChatGPT, and can be attached through Gemini's Custom apps by US users, while a listing in an assistant's app directory is a separate approval that wraps the same connector later.

The Parts No Protocol Provides

3. Verify agents before they reach the hold: check signatures at the edge, keep catalogue browsing open to signed agents, and allow holds and checkout only once a buyer is linked and checked against their per-person limit.
4. Build the hold layer: because no protocol provides one, this is where a platform has room to lead. It means a hold with its own ID and expiry time that can be extended or released safely, a fixed rule that gives one buyer the seat and tells the other immediately, buyer identity linked before the hold rather than at payment, and a per-person limit that counts live holds as well as orders across every channel.
5. Lock the price for the life of the hold: calculate every fee before the buyer sees a quote, keep that quote fixed, and treat any repricing as a reason to ask the buyer again rather than a silent change.
6. Add protocol adapters last: a UCP profile, an ACP checkout, or an AP2 adapter only pays off once an assistant's program admits tickets, and each one is a thin layer that depends on the hold layer beneath it.

The seat hold problem, step by step, and the hold layer that fixes it.

The research's working hypothesis is that whoever owns steps 4 and 5 will have the shorter road to in-chat checkout if a program ever opens to tickets. In the meantime, the same work gives a platform a safer on-sale and a cleaner first-party channel on its own terms.

What Softjourn's Test Build Showed

Softjourn's R&D team built these pieces in a test environment in September 2026 to check that they hold together in practice: a public connector with a handoff, signature checks, holds with a set lifetime, a database rule that turns racing requests into a single winner, and a per-buyer cap that counts both holds and orders.

It's proof that the pattern works rather than a product, and any client version would be built inside the client's own stack.

What You Can Measure Today (and What Nobody Can Yet)

The only public figure we found is relative: SeatGeek has said visitors arriving from AI tools convert at "roughly twice the rate" of search traffic, without sharing the numbers behind it (TicketNews, 2026). We found no absolute conversion rate, and there's a practical reason behind that. The tag marking an order as coming from an assistant is reported by the link itself, and few systems count how many buyers arrived from an assistant without purchasing, which leaves no denominator to divide by.

What a platform can track from the first day is narrower but still useful:

• orders carrying the assistant tag, broken down by assistant
• signed versus unsigned agent traffic, and how many requests were refused
• holds created versus holds paid for each agent, which is the clearest early sign of abuse
• requests turned away under the per-person cap

A first pilot with real events is what will produce a conversion figure worth quoting, so it pays to be cautious with anyone who offers one before that.

What Comes Next for Agentic Commerce in Ticketing

Softjourn's research keeps a clear line between what it has verified and what it expects, and everything in this section falls on the second side of that line.

What the Research Expects

• The handoff will hold: assistants get valuable discovery while platforms stay protected from transaction risk, and the research reads that balance as a stable arrangement rather than a stop on the way to in-chat checkout.
• The missing hold explains the gap: the research suspects the lack of a hold feature is the reason live events were left out of UCP's list of supported categories.
• Platforms may extend the protocols themselves: a ticketing platform could publish its own live-events extension under UCP, although assistants would only adopt it if there is real demand from buyers and sellers.
• Purchase limits will move into identity: rather than becoming a field on the cart, per-person limits are expected to end up as claims about the buyer that travel with their identity.

If those expectations hold, assistants will take on discovery and seat choice, platforms will keep the transaction, and the first protocol-based ticket checkouts will come from extensions that platforms publish rather than from the standards bodies.

Signals Worth Watching

A handful of developments would change the picture quickly, and each one is easy to track from the outside:

• an assistant buying program adding events or tickets to its list of eligible categories
• a hold or booking feature merged into UCP or ACP, or a maintainer response on the open ticketing threads
• the UCP Local Services proposal being approved, and whether its time-limited holds ever stretch to ticketed or seated events
• OpenAI clarifying whether its "physical goods only" rule for apps covers a ticket app whose only commerce action is a link to an external checkout
• Google publishing an exception path for categories its free listings currently exclude
• a second ticketing platform, after SeatGeek, verifying agent signatures in production
• browser-based agents such as Gemini in Chrome starting to call tools that web pages offer directly, a draft standard known as WebMCP

Agentic Commerce in Ticketing: Where This Leaves Your Platform

The handoff isn't a half-built feature, but the point where assistants are genuinely useful for discovery and platforms stay protected from the parts of a ticket sale that no protocol handles yet. The platforms already there built a readable catalogue and their own connector, and they kept the seat, the payment, and the customer relationship on their side of the line.

For everyone else, that combination is the realistic next step, with the hold layer as the longer investment that makes in-chat checkout possible if assistants ever open their programs to tickets. If you're weighing what your platform should expose first, our MCP Server Development page explains how we approach connectors. Contact Softjourn to find out where your platform sits among the three models and what it would take to reach the next one.