Can the AI just read the card number back to confirm it?

No. Repeating the digits puts them in the outbound audio as well as the inbound audio, so the recording now holds the number twice and so does the transcript. Confirmation is the job of the payment provider, which sends its own receipt by text or email. If your agent is reading numbers back, it was never configured to refuse card details in the first place.

Does deleting the call recording afterwards solve the problem?

It removes one copy. The transcript, the model provider's logs, the webhook payload your CRM received and any retried request in your error log are all separate copies with their own retention clocks. Deletion also happens after the fact, which means the data existed in scope for however long it sat there. Keeping the number out is cheaper and easier to prove than deleting it well.

What if we only take the card to charge a no show fee later?

Storing a card for a later charge is card on file, and it needs a token from your payment provider rather than the number itself. The provider holds the card, you hold a reference, and your agent passes the reference around. That is a supported flow with Stripe, Square and most acquirers. What it is not is a note in the booking record saying the long number.

Will callers actually pay from a text link instead of reading the card out?

Most will, and some will not, which is why it is worth measuring rather than assuming. Track links sent against links paid for a month, split by hour of day. Evening callers tend to pay on the spot because they are already holding their phone. The ones who go quiet are usually worth a short human callback the next morning rather than a lost deposit.

Can an AI receptionist take payments over the phone?

Say you run a six room med spa in Scottsdale. After a run of no shows you started asking for a fifty dollar deposit, and because nobody picks up after six, there's now an AI receptionist on the line in the evenings. It books well. Then at 7:40pm a caller says the thing callers always say: "Can I just give you my card now and get it over with?"

What happens in the next twenty seconds decides whether your call transcripts are card data.

An AI receptionist can take payments over the phone, but it should almost never be the thing that hears the card number. The pattern that holds up is narrow: the agent books the slot and sends a payment link to the number it's already talking to, so the digits go straight to your payment provider and never land in a recording, a transcript or a webhook. Capture the card in conversation instead and you pull your telephony, your AI vendor, your CRM and your log files into PCI DSS scope (the Payment Card Industry Data Security Standard, the card networks' rules for handling card data).

Can an AI receptionist take payments and stay out of PCI scope?

Yes, as long as the number never reaches the agent. A phone payment can run three ways, and only two of them are worth building.

Hand off to a link. The agent texts or emails a payment link from Stripe, Square or whichever provider you already use. The caller taps it, pays on the provider's page, and the agent is told only that money arrived.
Keypad capture on a certified path. The caller types the digits as DTMF (dual tone multi frequency, the tones a phone keypad makes) into telephony built for payments. Twilio's <Pay> verb works this way, with the keypad tones kept away from whoever else is on the line.
The caller reads the number out loud. Nobody sells this on purpose. It's what a general purpose voice agent does by default, because a model that's good at listening will listen to anything.

Most small businesses land in the third category by accident. The agent was never told to refuse, so one evening it didn't. Refusing is a design decision, the same as every other boundary in what an AI receptionist can and cannot do.

Is my AI phone agent PCI compliant?

An agent is not compliant or non compliant on its own. Your business is, and the obligation covers every system that stores, processes or transmits card data. When the PCI Security Standards Council published its information supplement on securing AI systems in September 2026, its announcement framed AI as falling under the same scoping logic as any other technology. Running something through a model doesn't put it outside the rules.

Where a spoken card number ends up

In six places, at least. Count the copies made by one call where somebody reads out sixteen digits.

The call recording in your telephony account.
A speech to text transcript, kept by the voice platform and often by the model provider too.
Prompt and completion logs on the AI side.
Whatever webhook payload your agent posted into the CRM.
A summary email or Slack message to whoever opens up tomorrow.
Error log entries, if one of those requests failed and got retried.

All of that before a cent has been charged. Deleting the recording cleans up one. Most teams only know about that one.

The security code is the part that can never be stored

PCI DSS, now at version 4.0.1, treats the short code on the back of the card as sensitive authentication data. That data must not be retained once the payment is authorised, encrypted or not. A thirty day retention policy doesn't fix that. Neither does access control. A recording of a caller saying those three digits aloud is a copy you were never allowed to make, and the transcript of it is a second one.

The pressure on card not present payments is current, not theoretical. UK Finance's Annual Fraud Report 2025 reported remote purchase fraud, the category covering card details used online, over the phone or by mail order, at just under £400 million of losses in 2024, with cases up 22 percent on the year. An archive of transcripts with card numbers in it is the raw material that market runs on.

Does DTMF masking make phone payments safe?

It can, in contact centres designed around it, and it's usually the wrong purchase for a business of nine people. Masking suppresses the keypad tones so they never reach the person or the recording, while a payment certified provider turns them into a charge. Done properly it keeps the agent environment out of scope. Done casually it's worse than nothing, because now everyone believes the problem is handled.

What DTMF bleed is

Some masking implementations detect a tone first and then suppress it, which leaves a fraction of the leading tone in the audio before suppression starts. The industry name for that leak is DTMF bleed. It's why masking is something you verify by making a real call and listening back, rather than something you tick off because a feature page says so. The PCI SSC's guidance on protecting telephone based payment card data, version 3.0 from November 2018, is still the reference document here.

Two questions sort the serious vendors from the rest. Ask for their Attestation of Compliance, the document an assessor signs, and ask your acquiring bank which Self Assessment Questionnaire they expect once your phone system sits in the payment path. Vague answers mean you're the one carrying the risk.

A flow diagram showing a booked appointment moving from the voice agent to a payment link and back as a confirmed deposit.

How to take a deposit without the agent touching the card

Here's the build, roughly a day's work on top of an AI voice agent that already books.

The agent confirms the slot and writes it to the calendar as a hold, not a confirmed booking.
It triggers a payment link from your provider, sent by SMS to the number on the call, and says out loud that the text is coming.
The provider's webhook, the automatic callback it sends when money lands, fires. Your automation flips the hold to confirmed and stamps the deposit against the customer record.
If nothing arrives within thirty minutes, the hold releases and a human gets a task with the caller's name and number.
The transcript of all this reads "payment link sent". That's the point.

Step three is where it breaks. A payment webhook that quietly stops firing looks exactly like a slow week, and you find out when somebody notices the holds piling up. Alert on it, because an automation that stopped working rarely announces itself. Check too that the deposit writes to the customer record rather than to a dashboard inside the voice platform, which is the gap behind most AI receptionist CRM integration claims.

One snag for US numbers. Application to person SMS runs through 10DLC registration, the carrier regime for business texts from a ten digit number, and unregistered traffic gets filtered. To the caller, a link that never arrives looks like your agent lied. Register the brand and the campaign first.

When an AI receptionist should not take payments at all

Pay by link assumes a caller holding a phone that can open a link, and some of yours aren't. The 82 year old booking a chiropody appointment from a landline is a real customer with real money. So is the fitter under a van in Coventry with wet hands and a cracked screen. If a decent slice of your callers look like that, the link flow quietly costs you deposits, and the honest answer is a human with a card terminal or payment taken on arrival.

Volume changes the maths too. A clinic in Dubai Marina taking a 200 dirham holding fee on most calls has a different problem from a landscaper asking for a deposit twice a week. At the high volume end, a certified agent assisted payment path is probably the right buy, with the assessment work and the annual cost that come with it. That's a payments project rather than a receptionist feature, and we'd scope it as one or send you to your acquirer first.

Worth saying plainly: we build the routing, not the attestation. We'll keep card data out of the systems we touch and show you where it would otherwise have landed. Signing off your PCI position is your assessor's job, and anyone whose voice agent supposedly makes you compliant is selling something they can't deliver.

What changes next for AI agents and payments

The guidance caught up this autumn. The PCI SSC's AI supplement, published on 15 September 2026, is advisory rather than a new requirement, and the Council is explicit that where guidance and the standard differ, the standard wins. Coverage of it picked out the advice that certain AI driven actions involving cardholder data should need a human sign off. Expect that language in your acquirer's questionnaire next year.

The card networks are moving in parallel. Mastercard announced Agent Pay in April 2025, built on what it calls Agentic Tokens, an extension of the tokenisation already behind contactless and card on file. Visa followed with its Trusted Agent Protocol in October 2025, a way for merchants to tell an approved agent from a bot, built on HTTP Message Signatures, the web standard for signing a request. Both target agents that buy for consumers rather than agents that collect for businesses. The direction is the part that matters to you: a token tied to a verified agent identity, never a number read down a phone line.

So the cheap decision is the one you make now. An agent that only sends links can swap in an agent payment API later. Eighteen months of transcripts with card numbers in them is a cleanup first.

The one thing to do this week

Call your own number after hours and say "can I pay the deposit now?" Then read the transcript, open the recording, and look at the webhook payload your CRM received. If any part of a card shows up in any of the three, you've found the job. If you'd like a hand turning it into the link and hold flow above, tell us what your agent does today and we'll tell you what we'd change.