Let your AI bot take the call. We'll take the payment.

Ask which voice AI tools can take a PCI-compliant card payment over the phone and the answers get muddled, because the question hides a split. Voice AI platforms build conversation — intent detection, turn-taking, speech that doesn't sound like a robot. Card capture is a different discipline with its own certification regime, and almost no bot platform holds PCI DSS Level 1 certification of its own. So the payment capability comes from a certified layer you connect the bot to. AI CallSynch is ours.

A working setup is two products, not one. Your voice agent runs the call — a custom build, a managed platform, or a speech-to-speech service, it doesn't matter which. Paytia holds the card. When the conversation reaches the payment moment, one API call from your bot opens a secure session on our PCI DSS Level 1 platform. The caller keys their card on their own handset, the tones are masked before they reach your transcription engine or your recording, the card is tokenised, and the outcome comes back to you on a webhook. Your bot resumes the conversation holding a result, never a card number.

That division is the whole design. The AI keeps what it's good at: context, intent, tone, the actual dialogue. We keep the part that carries regulatory weight. Because nothing sensitive crosses the line, your LLM provider, your speech-to-text vendor and your own infrastructure all sit outside the cardholder data environment — which is the difference between a payment step you can put in front of an auditor and one you can't.

Four things have to be true before a voice AI payment is genuinely compliant, and they're worth checking against anything you evaluate. The digits must be masked before they reach transcription or recording. No card number may land in a log, a transcript, or a model's context window. The processing must happen inside a platform that's certified and can produce its Attestation of Compliance. And the data-processing agreement has to say clearly who holds what. Get those four right and the AI can run the rest of the call however you like.

It's available now and working on live calls. If you're building the bot yourself, the integration is an API call and a webhook, identical in sandbox and live. If you're buying a voice AI product from someone else, ask them whether the payment step runs on certified infrastructure or on something assembled inside the bot — a vague answer is the reason this layer exists. The wider picture across chat, web and voice sits on our conversational and AI payments hub.

Two separate questions hide inside “how do you authenticate the caller”, and mixing them up is why the answer often sounds woolly. The first is whether this person is who they say they are and is entitled to act on the account. The second is whether the card being used belongs to them. Different mechanisms answer each one, and they happen at different points in the call.

Identity comes first, and it happens before the secure leg ever opens. The cheapest signal is the number the caller is ringing from, matched against the account on file — that turns the opening line from “please key your sixteen-digit reference” into “I've got the account ending 4521, is that right?”. Where the number doesn't match, a short reference plus one piece of personal data does the job: a postcode, a date of birth, an invoice number. Those inputs can be validated live against your own records where the integration is wired for it, so a wrong answer stops the call before any payment step begins. That work belongs on your side of the line, with your bot and your data — we don't hold your customer records, and we'd rather you didn't hand them to us.

Card authentication is ours. We support 3D Secure 2 as a step-up where the customer has their mobile to hand during the call, which is what Strong Customer Authentication asks for under PSD2 and what moves fraud liability to the issuer. It isn't always available on a phone payment — if the customer hasn't got their phone, the transaction falls back to unauthenticated card-not-present, and fraud screening and tokenisation carry more of the weight. We'd rather say that plainly than pretend every call gets a liability shift.

Worth saying what we don't do. We don't provide voice biometrics, and we'd be cautious about anyone offering a voiceprint as the only check before a payment on an AI call. Nor does the AI ever authenticate itself against the card — it can't, because it never sees one. Every check that matters either runs on your records before the payment or inside our platform during it, which keeps the audit story simple: identity here, card there, nothing shared between them.

PCI DSS scope is the set of systems, people and processes that touch cardholder data, and it's what decides whether your annual assessment is SAQ D's 329 controls or SAQ A's 22. Putting an AI in the call path usually grows that set rather than shrinking it, because AI stacks are built to keep things. Model providers log inputs and outputs by default. Transcription services retain audio. Sub-processors sit behind sub-processors, with retention windows you can't override and a fine-tuning pipeline nobody quite owns.

So a card number spoken to a bot doesn't land in one place. It lands in the transcript, the recording, the model provider's logs, and any downstream system that reads them — and every one of those becomes an in-scope system holding data you can't certify or reliably delete. That's a data-flow problem, and no policy document fixes it.

Masking fixes it because it's physical rather than procedural. The digits are replaced with flat audio before they reach anything you or your AI vendor operate, so there is no card number in the transcript to govern, no PAN in a log to redact, and no audio archive to hunt through when a deletion request arrives. Your assessment covers the systems around the payment, not the payment itself, which is what makes the drop to SAQ A defensible rather than optimistic. Under PCI DSS 4.0 the treatment of recordings and sensitive authentication data got stricter, which makes keeping digits out of the recording in the first place the cheaper path by a distance.

You still own things, and it's worth being clear about which. You're the merchant, so the annual self-assessment is yours to complete, your acquirer relationship is yours, and your access controls and passwords are yours. We're the certified service provider in the card path, which means we hand you the evidence your assessor asks for — our Attestation of Compliance, our data-processing agreement, and the transaction-level audit trail showing when each capture happened and what came back from the gateway.

The risk that shows up later isn't architectural, it's drift. A chat fallback gets added and a customer types their card number into the bot window. A human agent starts reading digits back “just to confirm”. A new transcript export lands in a data warehouse nobody scoped. Each of those puts card data back where you spent the project removing it. Review the paths into your bot whenever you change them, and keep the rule simple for everyone building on it: the AI never handles a card number, in any channel, for any reason.

A bot isn't the right answer to every phone payment, and pretending otherwise is how conversion rates fall. The shape that suits it is predictable: the amount is known or easily agreed, the caller isn't upset, and the conversation around the money is short.

Deposits fit that shape well. So does a booking with a payment attached — the bot confirms the appointment, takes the deposit, and gets the outcome back before the caller hangs up, all on one call. Routine bill payments, renewals and top-ups fit. So does anything recurring: because we tokenise the card, a caller can authorise an ongoing arrangement once and the same token carries the later charges, refunds or balance payments without asking for the number again. Our recurring payments page covers how the token behaves afterwards. Out-of-hours collection is the other clear win — a line that answers at 11pm collects money a 9-to-5 desk never sees.

The bot loses on complexity and on emotion. A disputed bill, an arrangement to pay, a bereavement, a customer in financial difficulty — those need a person, and routing them to one quickly matters more than any efficiency gain. Refunds shouldn't run through a self-service flow at all, for fraud reasons. Multi-card splits and part payments where the caller is still working out what they can afford belong with a human too. Some callers simply don't get on with automated systems, and pressing zero should always reach somebody.

The good news is that handing over doesn't change the security model. A human agent taking the call captures the card through exactly the same masked path — see agent-assisted payments for how that looks on the agent's side. If most of your payment calls are routine and don't need conversation at all, a self-service IVR payment line is cheaper to run than an AI agent and does the same job. Most contact centres end up running two or three of these side by side, which is fine: they share one platform, one audit trail, and one route to SAQ A.

One design note that decides more outcomes than the technology. Tell the caller what's about to happen before the capture starts — that the bot will step back, that they'll be typing on the keypad, that nobody and nothing is listening to the digits. Callers who understand the handover complete it. Callers surprised by silence hang up.