Yes, an AI receptionist can take a card payment over the phone. What gets a business into trouble is not the AI hearing the number, it is the recording and the transcript that keep it: PCI DSS Requirement 3.3.1 bans storing a card's security code after authorization, and the PCI Security Standards Council says a CVV kept in a .wav or .mp3 file after authorization breaks that rule. So the question for a vendor is not "are you PCI compliant" but "what happens to the recording while the caller reads the card".
I read the four platforms' own pages on 25 September 2026 for this piece, because I build these agents for trades businesses through our AI calling for home services work, and a deposit over the phone is a request I hear from trades owners.
Every AI receptionist can take a card number. The good ones are built to forget it.
The mistake: asking whether the AI can hear the card
Owners ask me whether a bot should hear a card number. That is the smallest part of the problem. A human receptionist forgets the number once the payment goes through. An AI receptionist runs on a stack that keeps things by default: a recording, a transcript, a call log, and often a model-written summary. Each of those is a copy of the card, so the number can land in four places before anyone decided it should.
The other half of the mistake is reading "PCI compliant" on a pricing page as a property of the platform. On the pages I read it is a switch, a plan tier, or a document under NDA, and in one case the words are not there at all.
What PCI actually forbids
The Council's FAQ 1210, updated June 2025, answers the exact question: may audio recordings contain sensitive authentication data? Requirement 3.3.1 prohibits storing that data, which includes the card validation code, after authorization, even encrypted. Storing the code in any digital audio recording after authorization is therefore a violation.
The FAQ then ranks the fixes, and the order is the useful part. Where technology exists to suppress or redact the audio while the digits are entered, enable it. If you cannot prevent the recording, delete the data securely on authorization. If you cannot do that either, you are into compensating controls: an annual risk assessment, controls that stop anyone querying the recordings, and documentation for an assessor. The FAQ also says PCI DSS does not override local rules on how long calls must be kept.
Four platforms, four different answers
Twilio has a purpose-built verb, <Pay>. The caller keys the card on the keypad, Twilio handles retries, and your application gets back a token from your payment connector (Stripe is one of them) with the security code redacted in the response. It sits behind PCI Mode, enabled per account, which redacts the payment details, keeps recordings from those workflows for one year by default and then deletes them, takes Twilio's native transcription off the menu, and cannot be turned off once it is on. Twilio's AI agent layer, ConversationRelay, supports PCI only with speech providers that are themselves PCI compliant, and its guide says not every provider on the menu is guaranteed to be.
Vapi has a per-assistant toggle, pciEnabled, and its default is false. With it on, the assistant is restricted to the PCI-compliant model, voice and transcriber options, nothing is kept unless you supply your own storage or webhook, and recordings, transcripts and logs leave the dashboard. The pattern its docs recommend is a squad of three assistants: one greets and records, a second takes over with recording, logging and transcription off while the caller keys the card, and a third confirms on a recorded line. Switch HIPAA on at the same time and no recording or transcript is stored or transmitted at all.
Retell lists HIPAA, GDPR and SOC 2 Type 1 and Type 2 on its compliance page. The words PCI, payment and card appear there zero times. What Retell publishes is a three-level storage setting per agent, a retention period, and a PII scrubber whose categories include credit_card. The scrubber runs after the call ends, beeps over the audio, replaces keypad digits in the transcript, and deletes the raw originals. That is the FAQ's second option, delete after, not its first, suppress during. Even at the strictest storage level, the webhook still carries a recording link for ten minutes.
Bland lists PCI DSS v4.0 on its trust page with an independent QSA and annual reassessment. The attestation is under NDA, and the pricing FAQ puts the compliance documentation on Enterprise.
PCI compliant.
The claim on three of the four vendors’ pages, read 25 September 2026. Retell’s does not make it.
Turns recording off during the digits, or deletes the recording afterwards, or hands you a token. Three different things.
Twilio PCI Mode, Vapi pciEnabled, Retell PII scrubbing, from each vendor’s documentation.
What this means for a deposit over the phone
Picture a plumbing company whose agent takes a $150 deposit for a Saturday slot. Path one: the agent asks the caller to read the card aloud, and every default stays on. The recording has the number and the code, the transcript and the log have them as text, and the model's call summary may repeat them. Path two: the agent tells the caller to key the card in, recording and transcription are off from the first digit, and the processor hands back a token that says approved. Same call, same customer, same $150. One of them becomes a violation the moment a recording with the code in it is kept past authorization.
Recording is not the only copy. A spoken card number is text in the model's context and the transcriber's stream even when nothing is saved, which is what Vapi's restriction of a PCI assistant to specific model and transcriber options, and Twilio's warning about its speech providers, are both about. The cleanest design keeps the digits out of the conversation entirely: the telephony layer captures the keypad entry, and the agent only hears that the payment went through. That is how I build the deposit step in our AI calling for home services agents, before I write the greeting.
Three moves before the agent asks for a card
Make the caller key it, never say it
Keypad entry is the difference between a number the telephony layer can mask and a number the transcriber has already written down. Twilio, Vapi and Retell all document keypad capture; use it for the card and the code.
Turn the artifacts off before the first digit
Recording, transcription and logging all need to be off during entry, not scrubbed afterwards. Then place a test call, key a test card, and read the transcript and the log to confirm the digits are not in either.
Ask for the document, not the badge
Ask who the assessor is, whether an attestation exists, and which of the speech and model providers in your stack are in scope. Bland will show you under NDA; Twilio publishes a responsibility matrix; read the answer before the first live deposit.
The bottom line
An AI receptionist can take a payment. The build decides whether it leaves a copy of the card in four places or none, and the vendors have thought about it to very different depths, so read the documentation, not the pricing grid.
I have built outbound and inbound systems for more than 200 businesses, and the deposit flow is the one I refuse to leave on defaults. If your agent is about to start taking cards, send me the platform and the call flow and I will tell you where the number is kept.