We are building a payment processing voice agent using Retell’s conversation flow. Our use case requires collecting credit card details (PAN, expiration, CVV) via DTMF keypad input during a call.
We need to understand whether Retell’s built-in PCI/PII controls are sufficient for PCI DSS compliance when card data is captured within a conversation flow, or whether we must use a custom-LLM agent to keep card data entirely out of Retell’s infrastructure.
Specifically:
When a caller enters card digits via DTMF on a press_digit node or a subagent node with allow_dtmf_interruption: true, does the raw card number pass through Retell’s LLM context (prompt/completion), or is it handled at the telephony layer only?
With data_storage_setting: "everything_except_pii" and pii_config set to redact credit_card, bank_account, and pin – does Retell redact the card data before it reaches the LLM, or only after (in storage/transcripts)?
Is Retell PCI DSS Level 1 certified, or does PCI scope remain with the customer even when using Retell’s PII scrubbing?
We attempted to use agent_swap from a conversation-flow agent to a custom-llm agent (where our WebSocket server handles DTMF capture directly, keeping card data off Retell’s LLM). However, agent_swap consistently fails with "Could not transfeer to another agent" in ~20ms when the target is a custom-LLM agent. Does Retell support agent_swap to agents with response_engine.type: "custom-llm"? The custom-LLM agent is not listed in the Agent Transfer dropdown in the dashboard, but we configured it via the API. If agent_swap to custom-LLM is not supported, is there a planned timeline for it?
If agent_swap to custom-LLM is not supported, what is the recommended PCI-compliant architecture for collecting card details via DTMF within a Retell call without the raw digits transiting Retell’s LLM?
DTMF and the LLM: DTMF digits captured via press_digit / allow_dtmf_interruption are injected into the LLM chat history as (User pressed digit: N) user messages (consecutive presses are coalesced into one turn). DTMF does not stay at the telephony layer on Retell — it transits the LLM.
*pii_config timing:** pii_config.mode is server-enforced to post_call only (any other value is rejected). Redaction runs against stored call artifacts at upload time, after the LLM has already seen the data, and the original (unscrubbed) transcript is always uploaded alongside the scrubbed one. pii_config is post-call hygiene; it does not reduce PCI scope.
PCI posture: Retell is not currently publicly certified as PCI DSS Level 1. Our Trust Center (https://trust.retellai.com) publishes SOC 2 and a HIPAA BAA. For a formal PCI scoping conversation, we can route you to our enterprise/legal team (https://www.retellai.com/enterprise-plan).
*agent_swap to a custom-LLM agent:** This is an intentional guard, not a bug. The server explicitly rejects swap targets whose response_engine.type is custom-llm (the dashboard also filters those agents out of the Agent Transfer dropdown by design). The Could not transfeer to another agent string you saw comes from that guard. We don’t have a timeline for changing this.
PCI-compliant patterns on Retell today: Two paths customers typically use:
Warm-transfer at the payment step via transfer_call to a PCI DSS Level 1 certified DTMF-suppression IVR provider (your own PCI-scoped IVR or a third-party PCI-compliant payment-capture service you’ve separately validated). The Retell agent hands the call off before any cardholder DTMF is pressed, so card data never traverses Retell or the LLM.
Build the agent on a custom-LLM response engine from the start, where DTMF/transcript handling lives in your own infrastructure end-to-end. Because agent_swap into a custom-llm target is blocked, the custom-llm decision needs to be made at agent creation, not mid-call.