The Checkout Redirect Problem
A customer is mid-conversation with your AI chat agent. They've asked questions, compared options, and decided to buy. The agent says: "Great, here's a link to complete your purchase."
The customer clicks through to a checkout page. They re-enter information the agent already knows. They get distracted. They abandon.
This is the checkout redirect problem. Every time a chat agent sends a customer off to a checkout that starts from scratch, it gives them a reason to stop. The customer was ready to pay. The process got in the way.
The fix isn't a better checkout page. It's keeping the payment in the conversation: the link arrives in the thread with the amount already set, and the agent confirms in the chat when it's paid.
The customer stays in context. The payment feels like part of the conversation, not a separate transaction.
But building this creates a hard technical problem: the same one AI voice agents face, expressed differently.
Why Chat Payments Are Different from Web Checkout
Web checkout assumes a browser. The customer is on a product page, clicks "buy," and a checkout form appears. The entire flow is built around a screen, a form, and a submit button.
Chat payments break that assumption. The customer isn't on a product page. They're in a conversation, on a website widget, on WhatsApp, on Facebook Messenger, on SMS, or inside a platform's messaging system. The "interface" is a chat thread, not a web form.
This creates three specific challenges:
1. Context lives in the conversation, not the page. In web checkout, the product, price, and customer intent are expressed by the page itself. In chat, they're expressed through dialogue. The AI agent has built context over multiple messages: what the customer wants, which option they've chosen, what the price is. Sending the customer to a checkout that starts from scratch throws that context away and makes them rebuild it.
2. The capture mechanism must fit the channel. A full-page checkout form doesn't work inside a WhatsApp message. A Stripe Elements embed doesn't render in an SMS thread. The payment capture mechanism has to be native to the messaging channel: a secure inline form, a compact payment card within the chat, or a branded payment link that opens a minimal hosted checkout.
3. Card data must never enter the chat. This is the PCI compliance constraint. If a customer types their card number into a chat message, even if the AI agent tells them not to, that card data is now in the chat log, the AI model's context window, the message database, and potentially the analytics pipeline. Every one of those systems is now in PCI scope.
The architecture has to keep card data out of the chat flow. Payment capture happens in a separate, PCI-certified environment that the chat agent triggers but never sees into.
The Architecture: How Chat Agent Payments Work
An AI chat agent that captures payments needs the same four-layer architecture as a voice agent, with a different capture mechanism.
1. Conversational Layer
The AI chat agent handles the dialogue. It understands what the customer wants, guides them through options, confirms pricing, and recognises when a payment should happen. This runs on the platform's AI infrastructure: LLMs, intent classifiers, or purpose-built conversational AI.
The aim: the conversational layer never asks for or handles card data. Not in a form field, not in a webhook payload. A customer can still type a card into a message, which is why the redaction steps below matter.
2. Payment Trigger
When the customer is ready to pay, the AI agent triggers the payment layer via API. It sends the transaction details (amount, currency, customer reference) and gets back a way to pay that fits the channel:
Website chat widget: A payment link in the thread, or a form the payment layer hosts, if the widget can embed one
WhatsApp / messaging platforms: A branded payment link that opens a minimal hosted checkout
SMS: A payment link sent as a message
Platform messaging: A payment link, or an embedded form where the platform supports one
Behind the scenes, the payment capture has moved to a PCI-certified environment.
3. PCI-Compliant Capture Environment
The customer enters card details within this environment, not within the chat. Usually that's a hosted checkout opened from a link, on messaging platforms and often on web too. If a chat widget embeds a form instead, the payment layer hosts it, not the chat.
The capture environment handles:
Card entry and validation
3D Secure, where the gateway asks for it
Passing the card to the merchant's own gateway, which processes the payment
Saving the card as a token with that gateway, if the customer agrees
Returning the result
The chat agent's systems don't receive card data from the checkout. They get a transaction result: approved, declined, or pending authentication.
4. Payment Gateway(s)
The transaction routes to the business's configured PSP: Stripe, Worldpay, Adyen, or any of 40+ supported gateways. For platforms serving multiple merchants, each merchant's payments go to its own configured PSP.
For a deeper look at how this architecture works across both voice and chat, see How AI Agents Process Payments: The Infrastructure Guide.
How It Works: A Practical Example
A customer messages an insurance platform's AI chat agent on the company website:
Customer: "I need to renew my home insurance. Policy number HI-2847291."
AI Agent: "I've found your policy. Your renewal quote is £342.50 for the year, with the same cover level. Would you like to renew now?"
Customer: "Yes, go ahead."
AI Agent: "I'll send you a secure payment link now. Tap it to pay, and I'll confirm here when it's done."
A payment link appears in the chat. The customer taps it and a hosted checkout opens, with the amount and policy reference already set.
The customer enters their card details on the checkout and pays £342.50.
Behind the scenes: the card details go through the payment layer to the insurer's own gateway (Worldpay), not into the chat. The payment layer sends the result to the chat agent by webhook.
AI Agent: "Your payment of £342.50 has been processed. Your policy HI-2847291 is renewed through 15 March 2027. I've sent a confirmation to your email on file. Is there anything else I can help with?"
Human involvement: none. Card data in the chat system: none.
The PCI Problem for Chat
Chat creates a unique PCI risk that doesn't exist in web checkout: the customer can type their card number into the chat.
In web checkout, the card form is the obvious place to type a card number. In chat, there's another one: the message input field. If a customer responds to "please enter your card details" by typing "4532 1234 5678 9012" into the chat, that card number is now:
In the chat message history
In the AI model's context window
In the platform's message database
Potentially in analytics, logging, and monitoring systems
Potentially in training data
Every one of those systems is now in PCI scope.
How to Prevent It
1. Never ask for card data in the chat. The AI agent should point to the secure link or form ("tap the secure payment link to pay"), never "please type your card number." The language must direct the customer to the secure capture mechanism, not the chat input.
2. Intercept and redact. Implement a real-time filter on incoming chat messages that detects card number patterns (sequences of 13-19 digits passing Luhn validation) and redacts them before they enter the AI model's context or any logging system. This is a safety net, not a primary control.
3. Send the link or show the form straight away. If there's a delay between the agent saying "I'll take your payment" and the link appearing, the customer may type their card number into the chat as a shortcut.
4. Design the UI to make the right action obvious. Make the link or form the obvious next step, and de-emphasise or pause the chat input while the customer pays. Make it easier to pay the right way than to type a card number.
5. Audit chat logs. Regularly scan stored chat transcripts for card number patterns. If any are found, redact them immediately and investigate how they bypassed the interception layer.
This is defence in depth. The primary control is the architecture: card data is captured on a hosted checkout or a form the payment layer hosts, not in the chat. The secondary controls (interception, redaction, UI design) catch the edge cases.
Chat vs. Voice: Same Problem, Different Mechanics
Chat and voice agents face the same fundamental challenge: capturing payment during a conversation without card data touching the AI. The mechanics differ:
Chat Agent | Voice Agent | |
|---|---|---|
Capture mechanism | Payment link / hosted checkout / embedded form | DTMF keypad tones within PCI environment |
Card data risk | Customer types card into chat message | Customer speaks card aloud / tones reach AI audio |
Mitigation | Capture outside the chat + message redaction | Masked keypad capture: the digits never reach the agent, and the recording holds nothing usable |
Channel variants | Website, WhatsApp, Messenger, SMS, platform chat | IVR, agent-assisted, AI voice |
Visual feedback | Form shows card type, validation in real time | Audio confirmation only |
3D Secure | On the checkout page or form the customer pays on | Not usually needed: phone (MOTO) payments are outside SCA |
Conversion advantage | Customer sees total + form in context | Customer hears amount, no visual confirmation |
Chat has one significant advantage over voice for payment capture: the customer has a screen. This means secure forms can render inline, 3D Secure authentication can happen within the same session, and the customer gets visual confirmation of the amount and card details before submitting.
Voice has a different advantage: there's no message box to type a card into, though a caller can still read one out loud. The capture mechanism (DTMF) is inherently separate from the conversational channel (speech).
Both channels benefit from the same underlying payment infrastructure: a PCI-certified layer that takes the card and passes it to each merchant's own gateway. Platforms that support both voice and chat agents should use a single payment layer for both, rather than building separate integrations.
For a detailed look at how voice payment capture works, see AI Voice Agents and Payments: The PolyAI Deep Dive.
How Voice AI Ordering Platforms Handle Payments: the voice channel equivalent for food ordering platforms
Payment Infrastructure for Food Ordering Platforms: multi-channel payment capture for food platforms (voice, chat, links)
Where Chat Payments Create the Most Value
Chat agent payments aren't a horizontal feature. They create outsized value in specific scenarios:
Quote-to-Bind in Insurance
The AI chat agent qualifies the customer, presents a quote, answers questions about coverage, and when the customer says "yes," captures payment and binds the policy. No email follow-up. No "log into your account to complete." The sale closes in the conversation where the intent was expressed.
Upsell During Support
A customer contacts support about their subscription. The AI agent resolves their issue and identifies an upgrade opportunity. "Based on your usage, the Pro plan would save you £40/month. Would you like to upgrade now?" The agent sends a payment link in the chat with the new amount set. No hunting for the billing page.
Debt Collection and Payment Plans
A collections agent (AI or human-assisted) negotiates a payment arrangement. When the customer agrees to a payment, the agent sends the link while the commitment is fresh, so they can pay before the conversation ends.
E-Commerce Pre-Sale and Consultation
A customer asks an AI agent about product sizing, compatibility, or availability. The agent answers their questions and offers to complete the purchase: "I have that in stock in your size. Shall I process the order?" The agent sends a payment link for it, already priced. The customer never navigates to a product page or cart.
Booking and Deposits
Travel, healthcare, professional services: any business that takes bookings with deposits. The AI agent confirms the appointment or reservation and sends the deposit link in the same conversation. No separate booking email the customer has to come back to.
B2B Invoice Payment
An AI agent on a supplier's platform helps a buyer locate an invoice, confirms the amount, and captures payment on the spot. Faster than logging into a portal. Faster than downloading a PDF and paying via bank transfer. The conversation resolves the query and the payment in one interaction.
Multi-PSP: The Same Enterprise Requirement
The multi-PSP problem is identical in chat and voice. Platforms serving multiple merchants can't mandate a single PSP.
An AI chat agent deployed by an insurance platform needs to route payments to each insurer's own PSP. A chat agent embedded in a SaaS platform needs to support Stripe for one merchant and Worldpay for another. An enterprise customer evaluating your platform will ask: "Can we use our existing PSP?"
The chat agent doesn't know or care which gateway processes the payment. It triggers a payment session. The payment layer routes to the correct PSP based on the merchant's configuration.
This is why a PSP-neutral payment layer matters for chat just as much as for voice. The alternative, hardcoding Stripe into your chat payment flow, works until the first enterprise customer says "we use Adyen."
Messaging Platforms: Channel-Specific Considerations
Chat agent payments aren't limited to website chat widgets. AI agents operate across messaging platforms, each with its own constraints.
Website Chat
Capture method: A payment link in the thread, or a form the payment layer hosts inside the widget. Advantage: An embedded form gives full control over the UI and can carry card type detection and inline validation. Consideration: Any embedded form must be hosted by the PCI-certified payment layer, not by the chat platform. Same-origin restrictions apply.
WhatsApp Business
Capture method: Branded payment link sent as a message. Customer taps the link, completes payment on a hosted checkout page, and returns to the chat. Advantage: Massive global reach. Businesses are already using it for customer communication. Consideration: WhatsApp doesn't run iframes inside the chat. Its own in-chat payments only cover a few markets, such as India and Brazil, so elsewhere a payment link is the main way to take a card. The hosted checkout page has to work well on a phone and load fast.
Facebook Messenger / Instagram DMs
Capture method: Payment link or webview. Meta's platform supports webviews that can host a payment form within the Messenger app. Advantage: Rich media support. Webviews can provide a near-native payment experience. Consideration: Meta's commerce policies apply. Webview behaviour can change with platform updates.
SMS
Capture method: Payment link sent via text message. Advantage: Nearly every phone gets texts, with no app needed. Consideration: Paying needs a phone that can open the link. SMS is one-way for payment capture. The customer completes payment on a hosted page and the result is returned to the chat agent via webhook. The conversation can continue once payment is confirmed.
Platform-Native Messaging
Capture method: Varies by platform. Could be embedded forms, payment cards, or links depending on the platform's extensibility. Advantage: Deeply integrated experience. The payment feels native to the platform. Consideration: Each platform has different capabilities. A payment link works on any platform that can show a link. Anything richer, like an embedded form, takes work on each platform.
What to Look For in Chat Payment Infrastructure
If you're building AI chat agents that need to process payments, or embedding chat payment capability into a platform, evaluate on:
PCI-Certified Capture
Look for a provider validated at PCI DSS Level 1, and ask for its Attestation of Compliance. Card data should never enter your chat infrastructure, AI model, or message storage.
Channel Flexibility
Which channels does it work in today? Payment links and a hosted checkout work in any chat that can show a link, including WhatsApp and SMS. A form inside a web chat widget is a separate build, so ask whether it's live.
Gateway Coverage
How many PSPs are supported? Can your merchants or enterprise customers bring their own PSP? Adding a gateway shouldn't require re-engineering your chat payment flow.
Tokenisation
Can a card taken during a chat be saved for future payments? Look for tokenisation with the merchant's own gateway, so the saved card stays with the gateway, not with your chat platform or the payment layer.
3D Secure Support
Strong Customer Authentication (SCA) is required for many European card payments. Check that 3D Secure challenges work on the page or form the customer pays on, and that the result comes back to the chat.
Latency
Chat is real-time. If the payment form takes seconds to load, or the transaction result takes too long to return, the customer's attention moves elsewhere. The payment layer has to be quick enough that the customer stays in the conversation.
Card Data Interception
Catching card numbers typed into the chat is a job for the chat layer, before messages reach the model or your logs. Check your chat platform can detect and redact them. It's a safety net, not the main control.
FAQ
Can customers really pay inside a chat conversation? They pay through a payment link sent in the chat. The agent sends the link in the thread, the customer pays on the hosted checkout it opens, and Shuttle reports the result by webhook so the agent can confirm it in the chat. If you want the card form inside the chat widget itself, talk to us before you build it.
Is it PCI compliant to take payments in a chat? Everyone taking card payments has to be PCI compliant, and a chat channel doesn't change that. What the architecture changes is your scope: if card data never enters the chat system, the chat platform and the AI agent stay out of the card flow, and your PCI scope is heavily reduced. Capture happens on a hosted checkout or a form the payment layer hosts, not in the chat message flow.
What if a customer types their card number into the chat? This is the primary PCI risk for chat payments. Mitigation includes: directing customers to the secure link or form (never asking for card data in chat), implementing real-time card number detection and redaction on incoming messages, and making the link or form the obvious next step.
Do chat payments work on WhatsApp? Yes, via payment links. The AI agent sends a branded payment link within the WhatsApp conversation. The customer taps the link, pays on a hosted checkout on their phone, and the result is confirmed back in the chat.
Can I use the same payment infrastructure for chat and voice agents? Yes. One payment layer that takes keypad payments on calls and payment links in chat means one integration covers both channels, with each merchant's payments going to its own gateway. For calls, that gateway has to be one of the 30+ that take voice payments.
What about Apple Pay and Google Pay in chat? On the hosted checkout that a payment link opens, Apple Pay and Google Pay can show on the customer's device. The merchant turns them on, and their gateway has to support network tokens. Wallet buttons don't show when Shuttle's checkout sits inside an iframe, so don't plan on wallets inside a chat widget.
How does this work with 3D Secure / SCA? If the card needs a 3D Secure check, it happens on the checkout page the link opens, not in the chat. Shuttle supports SCA and 3D Secure; confirm the setup for your gateway. The chat agent doesn't handle it: it gets the result by webhook.
Ready to add payments to your AI chat agents? Shuttle connects chat agents to 40+ payment gateways with payment links that open a hosted checkout. Card details pass through Shuttle's PCI DSS Level 1 environment, not your chat or your AI.
Illustrated sandbox demo, not a live product, including the Google Pay button under the form. Shuttle's live route for chat payments is a payment link. Talk to us before you build a form inside the chat.