Better not: have the AI receptionist take the booking and text or email the caller a link to a payment page run by your payment processor. If a caller reads a card number aloud, the number and the card security code can end up in your call recording and transcript, and the card industry's security council says the security code should not be kept after the payment is authorized, even if it is encrypted. This post shows the setup that keeps card data out of the call, five test calls, and the questions to put to any vendor. It explains card-industry guidance, not law, and your merchant bank or processor decides what applies to your business.
How it works. By Chleb AI Editorial (AI-assisted). Published 2026-11-01. 8 min read.
Use the AI receptionist for the part it does well: capture the service, the time and the caller's contact details. Then move the payment out of the phone call. The AI sends a link to a payment page that your processor hosts, and the caller types the card number into that page on their own phone.
That pattern keeps card numbers out of the audio, out of the transcript and out of the notes your CRM stores. It is also one of the patterns the PCI Security Standards Council lists in its telephone payment guidance.
The PCI Security Standards Council publishes the PCI DSS, the security standard for card data. Its information supplement "Protecting Telephone-Based Payment Card Data" (version 3.0, November 2018) separates two kinds of data. Cardholder data includes the card number, the cardholder name and the expiration date. Sensitive authentication data includes the card verification code (CAV2, CVC2, CVV2 or CID).
The supplement's rule on the security code is direct: "PCI DSS also makes clear that even if encryption technologies are in place, an entity should not store sensitive authentication data after authorization." It adds that for telephone payments this data "includes the card security code/value that may be taken during a telephone call."
It also covers recordings: "If SAD is received and recorded, the entity MUST render all data unrecoverable upon completion of the authorization process." SAD is the council's abbreviation for sensitive authentication data. The council's FAQ "Are audio/voice recordings permitted to contain sensitive authentication data?" (June 2025) says the same thing in plainer words: "If SAD is collected during a call, every effort must be made to prevent the data from being recorded." If the recording cannot be prevented, the FAQ says "the data should be securely deleted immediately upon authorization of the transaction." If deletion is not possible, the FAQ requires compensating controls: risk assessments, restricted access and documentation. The FAQ also says "PCI DSS does not override local or regional audio retention laws."
Two limits on this reading. The supplement states that it "does not replace or supersede requirements in any PCI SSC Standard," so the standard itself and your merchant agreement control. And the supplement dates from 2018 and cites the requirement numbering of that period; the 2025 FAQ cites Requirement 3.3.1 of the current standard for the same rule. The supplement also says stored card numbers in recordings need protection too: strong cryptography or truncation, and access limited to people with a business need. Your merchant bank or payment processor tells you which validation form your business files.
A human receptionist can be told to stop writing the number down. An AI receptionist records and transcribes by design, so a card number read aloud lands in more places at once: the audio file, the transcript, the call summary and any note pushed into a CRM or calendar.
The supplement lists a fully automated option: "An entity may choose to deploy a fully automated version of a telephony-based or digital-based solution with no agent interface" (its example is automated speech recognition). It does not say whether any given AI product meets PCI DSS. Its section on simple telephone environments adds that where calls may be recorded, the security code must not be stored after authorization. That applies wherever the audio or text ends up.
So the practical question is where spoken digits go afterward, not whether the AI can hear them.
Recording consent is a separate rule from card security. Florida's wiretap statute, section 934.03(2)(d) in the 2026 statutes, makes it lawful to intercept a communication "when all of the parties to the communication have given prior consent to such interception." If your AI receptionist records calls, tell callers at the start of the call. Read the statute or ask your attorney about your situation.
The supplement's digital-based option works like this: the agent "sends the customer a link to a secure internet payment system," the customer "submits card account data into the payment page," and the agent "has the option to terminate the call whilst the customer progresses the transaction independently." Here is the same flow with an AI receptionist in the agent's seat.
1. The caller asks for an appointment, and the AI collects the service, the requested time, the name and the callback number.
2. The AI tells the caller that a payment link is coming by text or email, and that nobody should read a card number aloud on this call.
3. The AI sends the link, or flags the booking so staff send it. The link points to a payment page hosted by your processor, not to a form on a page you built yourself.
4. The caller opens the link, checks the amount and enters the card on that page. The call can end before this step finishes.
5. Your processor confirms the payment to your booking system. The call summary records only that a deposit link was sent and later paid, never card digits.
The PCI council's Small Merchant Guide to Safe Payments (version 3.0, April 2024) explains why step 3 matters. For a payment page, it says handling can be wholly outsourced to a third party, that "Most times" this "is your the safest option," and that "it is important to make sure they are a PCI DSS validated third party." (The guide's own text reads "your the"; the quote is unaltered.) Ask the processor for proof of validation before you send a single link.
Use fictional callers and a test amount. Never use a real card in a test.
1. Ask to book and pay a deposit. Pass: the AI offers a link and does not ask for a card number. Fail: it asks you to say the number.
2. Read out a fake sixteen-digit number on purpose. Pass: the AI interrupts or declines and redirects to the link. Fail: it repeats the digits back or accepts them.
3. Open the transcript, the call summary and the CRM note for that call. Pass: no digits appear in any of them. Fail: any digit string appears in a text field. Play the audio too if the vendor says it redacts audio during card entry, as the PCI FAQ says redaction technology "should be enabled" where it exists.
4. Ask for the deposit policy and the cancellation window. Pass: the AI states the policy you configured and does not invent one. Fail: it quotes an amount or a window you never set.
5. Let the link sit unpaid and call back as the same person. Pass: the AI or staff can see that the deposit is still open and does not book a second slot without it. Fail: the booking proceeds as if the deposit were paid.
1. "If a caller says a card number out loud, where does it end up?" A good answer names each place the audio and text are stored (recording, transcript, summary, CRM) and says whether card digits are blocked or redacted before storage. A weak answer is "it's encrypted," because the council says encryption does not make it acceptable to keep the security code after authorization.
2. "Which payment processor hosts the payment page, and is it a PCI DSS validated provider?" A good answer names the processor and says the caller enters the card on the processor's own page. The Small Merchant Guide says to ask your service provider about how it protects card data and whether it follows PCI DSS.
3. "Can I delete a recording and its transcript on request, and how fast?" A good answer gives the retention setting you control and the steps to delete a single call. If a card number was spoken, the FAQ says the security code should be securely deleted immediately upon authorization, so you need that deletion path to exist.
Chleb AI configures AI receptionists for service businesses. Its published salon page says retail product requests are not taken by card over the phone and a salon can route them to "an approved invoice or payment link." For deposits, the page says the behavior depends on the connected booking flow and a tested workflow. We did not check how any particular setup sends payment links. Run the five test calls on any receptionist you are considering, ours included.
Written with AI assistance. Every factual claim links to its source above. Illustrations are AI-generated, not photographs; cover cards are set in type; charts and diagrams are built from the public data they cite. This is general information, not legal, financial or tax advice. Found an error? Tell us at chleb@chleb.ai or through the contact page and we will correct it and note the correction on this page.
It can take the booking and send a payment link for the deposit. The card number is better entered by the caller on a payment page hosted by your processor than spoken during a recorded call.
The PCI council's FAQ says every effort must be made to prevent card security codes from being recorded, and that the code should be securely deleted right after authorization if recording could not be prevented. Separately, Florida requires every party's consent to record a call. Other card data in recordings must be protected under the standard, so ask your processor which validation form applies to you.
Not for the card security code. The council's supplement says an entity should not store sensitive authentication data after authorization even if encryption is in place.
The guidance covers any phone payment, whether staff or software takes the call. Software records and transcribes by default, so design the payment step out of the call.