The PCI Problem with AI Travel Agents and Conversational Booking

Ask a travel AI agent to rebook a delayed flight and it pulls your itinerary, checks fare rules, holds a new seat, and asks if you want to use the card on file. Somewhere in that exchange, cardholder data passes through a system nobody scoped for PCI DSS.

That's the part most teams shipping conversational booking miss. They build the flight search, the hotel matching, the disruption handling, all of it genuinely useful, and then bolt payment onto the end almost as an afterthought. Payment isn't the end of the conversation. In travel, it's usually several separate payments, negotiated inline, across several separate merchants, sometimes re-triggered mid-conversation when a fare changes or a flight gets cancelled.

Why travel booking is a worse case than most conversational commerce

A retail chatbot usually has one payment moment: cart,checkout, done. A travel agent handling a real trip is closer to a payments orchestrator wearing a conversational interface.

A single "book my trip to Lisbon" request can t ouch an airline PSP, a hotel PMS, a car rental gateway, and a travel insurance provider, each one a different merchant of record with its own authorization flow. The agent might hold a fare for fifteen minutes while checking hotel availability, then re-price it when the fare class sells out, then split the payment across two cards because the corporate card only covers airfare. None of that is hypothetical. It's the normal shape of a multi-leg booking.

Add disruption recovery and the volume problem gets worse.When a flight is cancelled, an AI agent doesn't handle one refund and one rebooking. It handles hundreds, simultaneously, often needing to re-authorize a card that was captured hours or days earlier. Every one of those touch points is a place where card data, or something that reduces to card data, can end up somewhere it shouldn't.

Where card data actually leaks into the stack

PCI DSS scope isn't about whether you intended to store card data. It's about whether your systems touch it, and conversational AI touches it in places that are easy to overlook.

Chat transcripts are the obvious one. A customer types their card number into a web chat because it felt faster than a form, or reads it out loud on a voice call because the agent asked "what card would you like to use?" without a proper capture flow. Now that transcript, sitting in a support tool or a training dataset, contains a PAN.

Less obvious: conversation summaries. Most conversational AI platforms generate a summary of each session for hand off, QA, or analytics. If a customer mentions "use the card ending in 4471" and that phrase gets pulled into a summary that lands in a knowledge base or a BI pipeline,that pipeline just entered PCI audit scope, even though nobody stored a full card number anywhere.

Voice transcription is the same problem with an extra layer.Speech-to-text pipelines process the raw audio of someone reading out sixteen digits, a CVV, and an expiry date, before any tokenization happens. If that audio or its transcript gets logged for training or QA, the card data is in scope twice: once in the audio store, once in the transcript.

And multi-agent hand offs. A booking agent that calls a separate rebooking agent, which calls a refund agent, which calls a loyalty agent, is passing session context between systems that may not share the same security controls. If the original card token, or worse the original PAN, rides along in that context for convenience, every hop in the chain inherits PCI scope.

Why a payment link doesn't fully solve it

The standard fix in most conversational commerce guides is:don't let the agent touch the card at all. Generate a payment link, send it i the chat, let the customer pay on a hosted page, done. That works well for afixed invoice. It works less well for travel.

A payment link assumes a static amount and a single merchant at a moment the customer controls. Travel bookings are neither. The price the agent quoted at minute two of the conversation may not be the price available at minute six, because fares and room rates move in real time. A disruption rebooking often needs to happen without the customer actively present to click a link, because the whole value of an AI agent handling irregular operations is that it can act while the customer is asleep or between meetings.

Voice has its own version of this. DTMF capture, where the customer keys in card digits on their phone keypad instead of saying them out loud, is a well-established PCI-compliant pattern that keeps the AI agent's own transcription out of scope. It's the right default for voice. But it still assumes a live customer on the line at the exact moment payment is needed,which doesn't hold for agent-initiated rebooking after a cancellation.

Travel booking needs the agent to be able to act on payment,not just defer it. That's a different problem than "keep the model away from the card number," and it's the one the card networks have spent the last year building infrastructure for.

Agent-scoped tokens: what Visa, Mastercard, and Google actually shipped

Through 2025 and into 2026, Visa, Mastercard, and Googleeach shipped a version of the same underlying idea: instead of an AI agent holding a customer's raw card number, or even a general-purpose stored token,it holds a token scoped specifically to that agent, that merchant relationship,and a defined spending policy.

Mastercard's Agent Pay issues an Agentic Token, an extension of its existing tokenization infrastructure, bound to a specific agent and a specific commerce policy, so an assistant can complete a purchase without the raw card number ever entering its context. Visa's Trusted Agent Protocol takes a related but distinct approach: rather than minting a new token class, it extends Visa's existing token service with agent credentials and a signed,time-bound intent payload that a merchant can verify before honoring a request.Google's AP2 protocol sits alongside both as a shared mandate format, a cryptographically signed record of what the user actually authorized, that both networks now support so an agent's "the customer said yes to this"claim is checkable rather than assumed.

The practical effect for a travel agent, once these a rewired in properly, is that the model never sees a PAN at all. It presents a token, scoped to one merchant and one transaction, with limits the customer or the business set in advance. If that token leaks, it's useless outside its scope. Compare that to a raw card number sitting in a chat transcript, which is useful anywhere.

This is also why some conversational AI vendors are now pursuing PCI DSS certification for the platform itself, not just for the payment step bolted onto it. Sierra positions itself as the first Level 1 PCI-compliant conversational AI platform for exactly this reason: if the agent can complete a payment inside the conversation rather than handing off to a separate page, the conversation layer itself has to meet the same bar as a payment processor, not a lower one because it's "just chat."

The scope traps specific to travel

Travel has a few PCI wrinkles that generic e-commerce guidance doesn't cover.

IATA-accredited agents already carry PCI obligations through the BSP card sales channel, independent of anything AI-related. Layering a conversational agent on top of an existing accredited agency doesn't create new compliance obligations from scratch, but it does mean the new system has to fit inside controls that were often designed around phone and web forms, not a model generating and storing natural-language summaries of every interaction.

Multi-merchant bookings multiply the token relationships an agent needs to manage correctly. An agent that holds one card-on-file token and reuses it across an airline, a hotel, and a car rental company is treating three separate merchant relationships as one, which is exactly the kind of shortcut that turns a scoped, low-risk credential into a broad one.

And PII adjacent to card data quietly expands what counts as sensitive. Passport numbers, biometric check-in data, and travel documents often sit in the same session context as payment information. None of that is cardholder data under PCI DSS, but when it's stored alongside partial card numbers in the same conversation record, the practical blast radius of a lea is bigger than a strict PCI DSS reading would suggest.

What actually reduces scope

The pattern that works isn't "add security at the end." It's keeping card data out of the parts of the system that don't need it, from the first digit onward.

Card capture should happen through a hosted field, DTMF, or a dedicated tokenization step before anything reaches the model's context window, not after. If the LLM never receives the PAN, it can't leak it into a summary, a log, or a training set, because it never had it.

Transcripts and analytics pipelines need masking applied at ingestion, not as a cleanup pass afterward. By the time a partial card number has already landed in a knowledge base, the system it landed in is in scope,regardless of what you do to it next.

Agent-scoped tokens beat a single reusable stored credential. A token limited to one merchant, one purpose, and a defined ceiling contains the damage if something goes wrong. A general-purpose card-on-file token shared across every merchant an agent talks to does the opposite.

And each connected vendor should be treated as its own merchant relationship, with its own token, rather than one card number the agent reuses because it's convenient. It's more integration work upfront. It's also the difference between a compromised session exposing one booking and a compromised session exposing a customer's entire card.

The industry is still mid-transition here. Card networks have shipped the token infrastructure. Most conversational AI platforms haven't finished rebuilding around it. The gap between the two is exactly where most of today's PCI exposure in AI travel agents actually sits.

‍