Payments are the hard part of an AI travel agent: PCI scope, network tokens, and the two-sided settlement problem

Building the conversation is the easy part. A travel agent that understands “somewhere warm in March, under four hours from Boston, decent for a family” and comes back with real options is useful and, in 2026, buildable: grounding, tools, a decent model, and you are most of the way there. Then the traveler says “book it,” and you discover the actual product was never the chat. It was the payment.

The moment your agent has to collect a card and move money to an airline or a hotel, three things land on you at once: PCI-DSS scope, which turns a chatbot into a regulated payment system the instant a card number touches it; a two-sided settlement problem that the retail agentic-commerce story never has to deal with; and a fast-moving stack of agent-payment protocols and network tokens that exist specifically so an AI agent can pay without holding a raw card. We wrote about agentic commerce for Salesforce merchants, the retail case where a shopper’s agent buys a product from your store. Travel is a harder animal, and this post is about why, and what the payment architecture has to look like.

Why travel payments are not retail payments

In retail agentic commerce, the money flows one way: the buyer’s agent pays the merchant, the merchant ships the goods, done. Travel has two payment legs, and they use different rails, different timing, and different risk models.

Leg one, the traveler pays. The customer (or their agent) authorizes a charge for the trip. This is the leg everyone thinks about, and it is where PCI scope and the new agent-payment protocols live.

Leg two, the seller pays the supplier. An online travel agency or a booking platform that sold the trip now has to pay the airline, the hotel, the car company. This leg overwhelmingly runs on virtual cards, single-use card numbers minted per booking, and it has its own rules, its own settlement lag, and its own failure modes. By the end of 2022, virtual cards already represented around 40% of OTA payments to hotels, and each virtual card is typically scoped to one booking reference, guest name, and stay date so the back office can reconcile it.

An agent that “handles booking and payment” and only implements leg one has built half a system. The trip is paid for by the customer and still not paid to the hotel, and reconciling those two legs, across suppliers who settle on wildly different schedules, is where travel-payment engineering lives. This is the same operational reality behind agentic hotel distribution and airline NDC retailing: the offer is the glamorous part, the money movement is the build.

The rule that governs everything: keep the card out of the agent

Start from the constraint that dominates the whole design. The instant a raw Primary Account Number (a card number) enters a system, that system falls into PCI-DSS scope: the full weight of the payment-card security standard, with all the audit, storage, and network-segmentation obligations that implies. For a conversational agent this is a genuine hazard, because the natural, naive implementation is exactly the dangerous one: the customer types their card number into the chat, and now your LLM prompt, your transcript logs, your conversation store, and every system that touches them are all in PCI scope. That is not a compliance footnote; it is a different and far more expensive system than the one you meant to build.

So the first principle of agent payment architecture is blunt: the card number must never enter the agent’s context, its logs, or its reasoning loop. The agent orchestrates the intent to pay; something else, purpose-built and PCI-compliant, handles the actual card data. Concretely, that means one of these patterns:

• Hosted fields / a payment element. The card is entered into an iframe or SDK served by a PCI-compliant payment service provider, never into your chat surface. Your agent gets back a token; the PSP holds the card. The traveler stays “in the conversation” visually while the sensitive keystrokes go straight to the processor.
• A stored, tokenized credential the customer pre-authorized. The card was vaulted earlier, out of band, and the agent references a token, not a PAN, scoped to a specific use.
• One of the new agent-payment rails, below, which are designed from the ground up so the agent holds a scoped token and a signed authorization, never the card.

Everything else in this post is downstream of that one rule. If you get it wrong, no protocol saves you; if you get it right, the rest is architecture.

The agent-payment stack that showed up in the last year

Through 2025 and into 2026 the card networks and the AI platforms converged on the same idea from different directions: instead of an agent holding a customer’s raw card, it holds a token scoped to that specific agent, that specific merchant relationship, and a defined spending policy, plus a cryptographically signed record of what the customer authorized. The pieces you will encounter:

• AP2 (the Agent Payments Protocol. Google’s open, vendor-neutral protocol, announced September 16, 2025 with 60+ launch partners) Mastercard, PayPal, American Express, Coinbase, and Salesforce among them. Its core idea is three signed Mandates (Intent, Cart, and Payment) carried as W3C Verifiable Credentials. The payment network checks that a transaction matches the mandate’s scope (amount ceiling, allowed merchant category, valid time window) before authorizing, and denies anything out of scope at the network level. It is payment-method agnostic and even treats stablecoin rails as first-class.
• Mastercard Agent Pay issues an Agentic Token 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 Intelligent Commerce (with an Intelligent Commerce Connect on-ramp that accepts multiple agent standards) does the equivalent on Visa rails.
• ACP, the Agentic Commerce Protocol (Stripe and OpenAI), focuses tightly on product discovery and delegated checkout, the retail flow.
• x402, which revives the dormant HTTP 402 “Payment Required” status so an agent can negotiate and settle a payment inline over HTTP.

The pattern that is emerging as the production shape is a division of labor: open protocols like AP2 carry the agent’s identity and the signed intent; network tokens (Agentic Tokens on Visa/Mastercard rails) move the actual money. An AP2 mandate envelope wrapping a Mastercard Agentic Token is a concrete example, the protocol proves what the customer agreed to, the token executes it without exposing the card. For a travel agent, this is the machinery that lets “book it” become an authorized charge without your chat surface ever seeing a PAN.

The proof that this is past theory: in May 2026, Mindtrip launched an end-to-end agentic flight-booking experience built with Sabre and PayPal: search, compare, and pay inside a chat with no redirect, where Sabre supplies the air content and Mindtrip the conversational surface, and PayPal’s infrastructure carries the payment inside the flow. That is the reference architecture for leg one, shipped.

The airline and hotel legs still break in travel-specific ways

Here is where the retail agentic-commerce playbook stops being enough, because travel’s supply side has rules that predate, and constrain, any of this.

Airlines and Resolution 890. The traveler-pays leg is only half the transaction; the seller still has to pay the airline. Many airlines restrict agent-issued virtual cards under IATA’s Resolution 890 rules, often because accepting a virtual card carries a card-acceptance cost the airline would rather avoid. So an agent that books a flight cannot assume it can simply mint a virtual card to pay the carrier, the supplier-payment leg may have to route through BSP settlement or a form of payment the airline accepts. The offer engine and the settlement rails, not your agent, own this constraint.

Hotels and reconciliation. Virtual cards dominate OTA-to-hotel payment, and they work well precisely because each card is scoped to a booking, but that scoping is also the reconciliation problem. Your agent booked the stay and the customer paid; the virtual card that pays the property has to carry the right amount, activate on the right date, and match the folio when the guest checks out. A mismatch (a rate change, an incidental, a partial no-show) is a back-office exception a human resolves, not something the agent should silently paper over.

Refunds, disputes, and partial changes. Travel is unusually full of post-purchase money movement: a schedule change, a cancellation inside a fare rule, a downgrade. Each is a payment event with its own rules, and an agent that can take money must have an explicit, human-supervised path for giving it back, the escalation discipline we argued for in keeping a human in the loop. “The agent issued a refund it should not have” is a worse headline than “the agent could not issue the refund.”

Where the agent platform fits

If you are building on Salesforce and Agentforce, the healthy division of responsibility falls out of the PCI rule directly. The agent orchestrates; a payment service handles the card.

The agent’s job is the conversation, the grounding, the offer selection, and the decision to invoke a payment, then it calls a payment action (a Flow, an Apex invocable action, an external service, or one of the agent-payment rails above) that hands off to a PCI-compliant PSP and returns a token and a result. The card data, the vault, and the PCI audit live with the payment provider, deliberately outside your agent and outside your CRM’s scope. Salesforce being an AP2 launch partner matters here: the intent-and-mandate layer is something the platform is aligning to, but the money still moves on payment rails, not through the LLM.

Two guardrails make this safe rather than merely functional:

1. Screen the payment intent like any other high-consequence action. An agent that can spend money is a prompt-injection target, a malicious itinerary description or a poisoned supplier feed trying to redirect a charge is exactly the risk we covered in prompt injection against agents. The signed-mandate model (AP2’s amount ceilings, merchant-category and time-window scoping) is a structural defense: even a manipulated agent cannot authorize outside the mandate. Use it, and enforce spend policy at the token, not just in the prompt.
2. Keep the whole thing inside the trust boundary. Payment confirmations, tokens, and transaction records that flow back through the agent are grounding data the Einstein Trust Layer should be masking and auditing like anything else sensitive, and the transcript still must never carry a PAN.

The takeaways:

• A travel agent’s real product is payment, and it has two legs: the traveler pays, and the seller pays the supplier (usually by virtual card). Building only leg one ships half a system.
• The dominating constraint is PCI-DSS: the card number must never enter the agent’s context, logs, or reasoning. Use hosted fields, pre-vaulted tokens, or an agent-payment rail so the PAN goes straight to a compliant PSP.
• The 2025–26 agent-payment stack (AP2 (Salesforce is a partner), Mastercard Agent Pay, Visa Intelligent Commerce, ACP, x402) exists to give the agent a scoped token and a signed mandate instead of a card. Open protocols carry intent; network tokens move money.
• Travel’s supply side breaks in travel-specific ways: IATA Resolution 890 limits agent-issued virtual cards to airlines, hotel virtual-card reconciliation is a real exception path, and refunds/changes need an explicit human-supervised route.
• On Agentforce, let the agent orchestrate and a PSP handle the card: screen the payment intent against injection, enforce spend at the token, and keep card data out of the CRM’s PCI scope entirely.