PCI scope is the single biggest reason insurance core platforms don't execute payments.
The moment card data enters the platform's environment — in memory, in storage, in transit, in a call recording — the platform is subject to PCI DSS. For a platform that manages policy data, claims, and billing across dozens of carriers, that's a compliance burden that dwarfs the value of adding a payment feature.
This guide explains the architecture that eliminates that trade-off. Insurance platforms can execute payments — across voice, links, and embedded checkout — without card data ever touching their infrastructure.
Why PCI Scope Is the Real Blocker
Insurance core platforms handle sensitive data already: policyholder information, health data, financial records. Adding payment card data on top of that creates a new compliance surface that intersects with existing ones.
The problem isn't just the PCI audit. It's what PCI DSS requires operationally:
Network segmentation between cardholder data environments and everything else
Encryption at rest and in transit for all card data
Access controls, logging, and monitoring for every system that touches card data
Annual penetration testing of the cardholder data environment
Quarterly vulnerability scans by an Approved Scanning Vendor
Incident response procedures specific to card data breaches
Staff training for everyone with access to payment systems
For a platform that serves 20+ carriers, each with different security requirements and audit cycles, layering PCI on top of existing compliance obligations is a non-starter.
The Architecture: Separating Card Capture from the Core Platform
The solution is architectural, not procedural. Card data never enters the platform's environment. Period.
How It Works
`` Policyholder → Platform Workflow → Payment Layer (PCI Level 1) → Carrier's PSP → Acquirer ↑ Card data stays here Platform never sees it ``
The platform initiates a payment request. The billing module identifies a premium due, or an agent reaches the payment moment in a call. The platform sends a payment request to The Payment Layer — amount, currency, carrier ID, reference number. No card data.
The Payment Layer captures card data. Depending on the channel:
- Voice: DTMF tones captured within The Payment Layer's PCI-certified telephony environment - Payment links: Hosted payment page served by The Payment Layer's infrastructure - Embedded checkout: iFrame or SDK component rendered from The Payment Layer's domain
**The Payment Layer routes to the carrier's PSP.** Each carrier has a pre-configured PSP connection. The layer routes the transaction to Stripe, Adyen, Worldpay, or whichever processor the carrier uses.
The platform receives a result. Transaction approved/declined, last four digits, reference ID. No card numbers, no CVVs, no expiry dates. The billing module updates. The conversation continues.
At no point does the platform's infrastructure handle, process, or store card data.
DTMF Capture for Voice Payments
Insurance is a voice-heavy industry. Phone renewals, collections calls, and claim payment queries all create payment moments during conversations.
The DTMF Architecture
When a policyholder is ready to pay during a call:
The agent (human or AI) triggers the payment flow. The call enters a secure segment.
The policyholder enters card digits via keypad (DTMF tones).
DTMF tones are captured by The Payment Layer's PCI-certified environment — not the platform's telephony stack.
Tones are stripped from the audio stream before reaching the agent, the call recording system, or any monitoring feed.
The payment processes through the carrier's PSP.
The agent receives confirmation — "payment approved" — and the conversation resumes.
What Gets Stripped
Agent audio: DTMF tones are suppressed in real time. The agent hears silence or a masking tone during card entry.
Call recordings: No card data in any recording. Full compliance with PCI DSS Requirement 3 (protect stored cardholder data).
Screen pop / agent dashboard: Only last four digits displayed. No full card numbers visible to agents.
Quality monitoring: Supervisors and QA teams never have access to card data in reviewed calls.
This is the same architecture used by Allianz, which runs call centre payments through Shuttle across 3 countries. Each country routes to Allianz's contracted processors. The contact centre agents never hear or see card data.
Payment Links: Collecting Premiums Without Touching Card Data
Payment links are the simplest path to zero-scope premium collection.
How It Works for Insurance
The billing module identifies an overdue premium or upcoming renewal.
The platform generates a payment link via The Payment Layer API — passing amount, currency, carrier PSP, and policy reference.
The link is sent to the policyholder via SMS or email.
The policyholder opens the link, sees a branded payment page (carrier branding, policy details), and enters card details.
The payment page is hosted entirely within The Payment Layer's PCI-certified infrastructure.
The transaction routes to the carrier's PSP.
The platform receives a webhook: payment confirmed, reference ID, last four digits.
Why This Matters for PCI
The payment page is on The Payment Layer's domain, rendered from The Payment Layer's servers, processed within The Payment Layer's PCI boundary. The platform's infrastructure is not involved in card capture at all. This is the cleanest possible PCI scope reduction.
For the platform: SAQ-A. 22 self-assessment questions. No QSA audit required. No network segmentation. No cardholder data environment to maintain.
Multi-Tenant PCI: Each Carrier's PSP, One Compliance Boundary
The multi-tenant PSP problem is unique to platforms. A platform serves many carriers. Each carrier has its own PSP. The platform needs to route payments to the correct processor per carrier — without building a separate PCI-compliant integration for each one.
How The Payment Layer Handles This
One PCI boundary covers all carriers. The Payment Layer's PCI DSS Level 1 certification applies regardless of which PSP processes the transaction.
Per-carrier PSP routing is configuration, not code. When a new carrier onboards, their PSP connection is configured within the layer. No platform development required.
Tokenisation spans PSPs. Cards tokenised through The Payment Layer can be used for recurring payments regardless of which PSP processes them — useful for premium installment plans that may need to fail over between processors.
This means the platform achieves multi-PSP payment execution with a single compliance posture. Whether a carrier uses Stripe, Adyen, Worldpay, or a regional acquirer, the platform's PCI scope doesn't change.
SAQ-A vs SAQ-D: The Cost Difference
This is where the business case becomes concrete.
SAQ-D (Full PCI Scope)
If the platform handles card data — even transiently:
300+ requirements in the self-assessment questionnaire
Annual QSA audit by a Qualified Security Assessor — typically $150K-$300K per year
Network segmentation between cardholder data environment and everything else
Dedicated security personnel for PCI operations
Quarterly ASV scans and annual penetration testing
Incident response plan specific to card data breaches
Total annual cost: $500K-$2M+ depending on complexity
SAQ-A (Zero Scope)
If the platform delegates all card handling to a PCI-certified provider:
22 requirements — mostly confirming you don't handle card data
No QSA audit required — self-assessment only
No network segmentation for payment data
No dedicated PCI security team
Total annual cost: Negligible — part of normal security operations
The difference is not marginal. It's the difference between a platform that can add payment execution in weeks and a platform that needs a year of compliance preparation before writing a line of payment code.
What "Zero PCI Scope for the Platform" Actually Means
Zero scope doesn't mean zero responsibility. It means the platform's responsibility is limited to:
Not handling card data. No card numbers, CVVs, or expiry dates in the platform's systems, logs, or communications.
Using a PCI-certified provider. Verifying that The Payment Layer maintains current PCI DSS Level 1 certification.
Securing the integration. API keys, webhooks, and authentication between the platform and The Payment Layer must follow standard security practices.
Not circumventing the architecture. If a developer adds a text field that captures a card number, PCI scope returns instantly.
What zero scope does NOT require:
Annual QSA audits
Cardholder data environment segmentation
Card data encryption infrastructure
PCI-specific incident response
Quarterly vulnerability scans of payment systems
For insurance platforms already managing compliance obligations across multiple regulatory frameworks, eliminating PCI scope is a material simplification.
Related Reading
Payments for Insurance Core Platforms: The Complete Guide — the full picture of embedded payment execution for insurance
How AI Voice Agents Take PCI-Compliant Payments — the technical architecture for AI agent payment flows
PCI-Compliant Payments for Contact Centres — agent-assisted and automated payment capture
What Are Voice Payments? — the complete guide to IVR, agent-assisted, and AI voice payments
What is PCI DSS? | What is PCI Scope? | What is a Payment Layer?
*Shuttle is PCI DSS Level 1, ISO 27001, and SOC 2 certified. Insurance platforms integrate once and execute payments across voice, links, and embedded checkout — without card data entering their environment. See how it works or book a discovery call.*