Direct answer: before a UK tour operator, OTA, airline retail desk, hotel group or travel ops team lets an **AI assistant** sit next to checkout — chat, voice, agentic booking or "pay for me" flows — **cardholder data must stay outside the model**. That means primary account numbers (PAN), CVV/CVC, full track data and other sensitive authentication data must not enter prompts, retrieval context, tool transcripts, support logs or third-party model APIs. Route payment capture through **hosted checkout, tokens or scheme-approved agent payment containers**, and keep **Strong Customer Authentication (SCA)** with the human payer where UK payment rules require it.
That is the operator question Kaize is answering here. We are a UK AI product studio for travel and hospitality. This is not a payment-gateway shopping list. It is a **control-stack** article: what must already be true in PCI DSS scope, scheme agent protocols and UK SCA before AI is allowed near money movement. It sits beside — and does not replace — our CMA AI-agent consumer-law, DMCC drip-pricing quote, GDPR/ATOL booking-change and AI agent access-control pieces.
Primary evidence is first-party: the PCI Security Standards Council PCI DSS (entities that store, process or transmit cardholder data — or that can affect the cardholder data environment), Visa’s Trusted Agent Protocol under Visa Intelligent Commerce, and UK public authorities — FCA Strong Customer Authentication under the Payment Services Regulations 2017, plus HM Treasury’s Payments Forward Plan (published 26 February 2026), which explicitly flags consideration of regulation for **agentic AI payments** in the Q2 2026 payments-law review. We do not invent client results, fine outcomes, GSC lifts or GEO ranks.
What PCI DSS actually scopes (and what AI quietly expands)
PCI DSS is the industry baseline for protecting payment account data. The PCI SSC states it applies to entities that store, process or transmit **cardholder data (CHD)** and/or **sensitive authentication data (SAD)**, or that could impact the security of the **cardholder data environment (CDE)** — including merchants, processors, acquirers and service providers.
An AI assistant expands that boundary in ways a classic hosted form does not. If a customer types or speaks a card number into chat; if a tool scrapes a payment field; if a transcript, RAG index or vendor log keeps CVV "for debugging"; if a multi-agent workflow copies booking + payment into one context window — those paths can pull systems into CDE scope even when the "main" website uses a hosted payment page.
- Treat conversational and agentic channels as payment channels until proven otherwise.
- Map every place CHD/SAD could enter: chat, voice, browser automation, screen-share copilots, CRM notes, refund tools.
- Assume reduced PCI scope from a hosted checkout is **voided** if AI re-collects PAN alongside it.
Visa Trusted Agent Protocol: prove the agent — do not paste the PAN
Visa’s Trusted Agent Protocol (part of Visa Intelligent Commerce) is designed so merchants can cryptographically recognise an **approved agent with commerce intent**, with time-bound, merchant- and purpose-bound signatures that resist replay and relay. For payment interactions, agents are expected to pass **hashed credentials**, tokens and signed payment containers — not to treat raw card entry in a free-text LLM as a normal path.
Visa’s own position on virtual accounts still draws a hard line: EMVCo payment tokens and certain low-risk virtual numbers with dynamic CVV may sit outside classic PAN protection requirements, but **ordinary Visa PANs must still be protected in accordance with PCI DSS**. Design implication for travel: if your agent can "just type the card", you are choosing the highest-risk architecture.
- Prefer token / vault / lodge-card / virtual-card paths where the model never sees PAN.
- If key-entry automation is used at all, require scheme-grade hashed credential validation — not prompt trust.
- Bind agent identity, merchant domain and payment purpose in signed containers before money moves.
UK SCA still needs a human payer — AI does not waive it
Under the UK Payment Services Regulations 2017, Strong Customer Authentication applies when a payer initiates an electronic payment, accesses a payment account online, or carries out a remote action that may imply a risk of payment fraud — unless an exemption applies. The FCA’s SCA page is the practical reference for firms.
Travel already learned this the hard way with deposits, no-shows, MOTO and hotel card-not-present flows. An AI agent that "completes checkout for the guest" does not erase SCA. If the customer is initiating a remote card payment, design for **3-D Secure / issuer challenge / Open Banking authentication** with the **human**, then let the agent continue only on authorised tokens or merchant-initiated patterns that your acquirer has confirmed are correctly flagged.
HM Treasury’s Payments Forward Plan (26 February 2026) is explicit that the Q2 2026 review of assimilated payment services law will include **updates to the SCA regime** and **consideration of whether change/development of regulation is needed to support agentic AI payments**. That is a signal to product teams: do not hard-code today’s workarounds as if agentic payment law were finished.
Gate 1 — CHD/SAD never enter model context
Before go-live, security and payments must prove the AI stack cannot accept, store or transmit PAN/SAD.
- Input filters and UI that refuse card patterns in chat/voice; redirect to hosted payment.
- Tool schemas that exclude payment fields from LLM-visible arguments.
- Log/redaction policy covering prompts, completions, traces, eval sets and vendor exports.
- No "paste card for agent to book" runbooks for staff or customers.
Gate 2 — Payment capture is hosted, tokenised or scheme-containerised
Kaize POV: the safest travel AI payment design is the one that **never** needs the model to know the card. Hosted pages, iframes, payment links, network tokens, lodge cards and Visa Trusted Agent payment containers are the pattern. Your booking assistant can confirm itinerary, total price (see our DMCC controls) and ATOL status — then hand off to a payment component that is out of model scope.
- Named payment provider path with documented PCI responsibility split.
- Tokens only in booking/CRM systems the agent may read for "card on file" metadata — never full PAN.
- Refund and chargeback tools use the same token boundary.
Gate 3 — SCA and consent are human-owned
- Human completes SCA for in-scope payer-initiated remote payments.
- Agent may prepare the basket and wait; it must not fake or bypass authentication.
- Retain evidence of consent/mandate suitable for disputes — especially for agent-assisted or agent-initiated follow-on charges.
- High-value or non-refundable bookings require explicit human confirmation before capture.
Gate 4 — Scope map, vendors and incident readiness
If any AI vendor, observability tool or browser-automation layer can see CHD, it is in the CDE conversation. Contracts must allow inspection of prompts, retention, subprocessors and breach notification. Incident playbooks must include "model/transcript exposure" as a payment-data event, not only a classic database leak.
What this is not
- Not a claim that Kaize is a QSA or that any deployment is "PCI certified by this article".
- Not permission to skip ATOL, Package Travel, DMCC price display or CMA consumer-law duties.
- Not advice to scrape checkout pages with agents as a substitute for proper APIs.
- Not invented rankings, case studies or fine amounts.
Operator checklist (before production)
- Data-flow diagram: booking AI ↔ payment component ↔ acquirer/token vault.
- Proof that PAN/SAD cannot reach prompts, tools, logs or eval corpora.
- SCA path tested for card and (if used) Open Banking.
- Scheme agent protocol path reviewed if you claim agentic checkout.
- Legal/compliance sign-off that trader responsibility for consumer outcomes still sits with the travel firm (CMA).
- Rollback: kill-switch that disables AI near checkout without breaking hosted payment.
FAQ
Can our AI take card numbers if we encrypt the database?
Encryption at rest does not make it safe to put PAN into an LLM context. Once card data is in prompts, completions, vendor APIs or shared traces, you have expanded who can see it and how hard it is to prove deletion. Prefer never collecting it in that channel.
Is a "PCI-compliant AI vendor" enough?
Vendor claims do not remove your merchant/trader duties. Validate scope reduction with your acquirer/QSA path, keep CHD out of your model stack, and still meet SCA and consumer-law obligations for the journey you sell.
How does this relate to Open Banking?
Account-to-account checkout can reduce card CHD in the travel stack, but it does not remove authentication, consent or agent-authorisation design. HMT’s Payments Forward Plan ties Open Banking’s long-term framework and agentic AI payments into the same modernisation programme — design for both, invent neither.
Kaize next step
If you are designing AI for booking, contact-centre or agentic retail, start with the payment boundary: what the model must never see, where SCA stays human, and how tokens replace PAN. See services, thinking and contact. Related reading: control AI agents on booking systems, CMA consumer law for AI agents, DMCC total price.