PCI scope is a major reason insurance core platforms hold back from executing 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. For carrier-side and MGA-platform-specific payment architecture, see Payments for Insurance Carriers and MGA Platforms.
This guide explains the architecture that limits 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 → Payment Layer (PCI DSS Level 1) → Carrier's PSP → Acquirer
↑
Card data passes through here in transit, Shuttle stores none
Platform Workflow ↔ Payment Layer: payment request and result only, no card dataThe 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: digits captured through Twilio Pay and passed to The Payment Layer's PCI-certified environment
Payment links: Hosted payment page served by The Payment Layer's infrastructure
Embedded checkout: iFrame or embeddable 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 Access, or another compatible 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).
The digits are captured through Twilio Pay and passed to The Payment Layer's PCI-certified environment, not the platform's telephony stack.
The digits never reach 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 Never Sees Card Data
Agent audio: The digits never reach the agent during card entry.
Call recordings: No card data in any recording.
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.
Shuttle runs voice payment collections for Allianz in three countries.
Payment Links: Collecting Premiums With Card Data Kept Off Your Platform
Payment links are the simplest path to limited-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 own servers do not receive or handle the card data. This is a clean PCI scope reduction.
For the platform: PCI scope is typically smaller, because card data does not reach your systems.
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.
Saved cards stay with their gateway. Cards are tokenised with the carrier's own gateway, and recurring premium instalments on a stored card run through that gateway. If a carrier moves payment types to another connected gateway, saved cards stay with the gateway that stored them.
This means the platform achieves multi-PSP payments with a single compliance posture. Whether a carrier uses Stripe, Adyen, Worldpay Access, or another connected provider, the platform's PCI scope isn't expanded by the provider a carrier uses.
Heavily Reduced PCI Scope vs Full Scope: The Cost Difference
This is where the business case becomes concrete. A platform serving other businesses is assessed at full service-provider level either way (SAQ-D, or a Report on Compliance at Level 1 volumes); what changes is how much of it applies to your systems.
Full PCI Scope
If the platform handles card data, even transiently, the full set of requirements applies to those systems:
The whole cardholder data environment is in scope
Assessment scope covers every network, system and person that touches card data
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: high, depending on complexity
Heavily Reduced PCI Scope
If the platform delegates all card handling to a PCI-certified provider, it still completes the same SAQ-D (or a Report on Compliance at Level 1 volumes), but fewer of its own systems are in scope:
Fewer systems to segment for payment data
Less of your own environment to secure and monitor
Total annual cost: lower, because fewer requirements apply to your systems
The difference is in how much of your environment the requirements cover.
What "Limited PCI Scope for the Platform" Actually Means
Limited scope doesn't mean no responsibility. The platform still completes its service-provider assessment (SAQ-D, or a Report on Compliance at Level 1 volumes), and everyone taking card payments has to be PCI compliant. What changes is how much of the platform's own environment those requirements cover. The core of the platform's part is:
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.
What limited scope reduces, but does not remove:
How much of your environment has to be segmented as a cardholder data environment
How much card data encryption infrastructure you have to build and run yourself
How many systems need card-data-specific access controls, logging and monitoring
How many systems fall under quarterly vulnerability scans and periodic penetration testing
For insurance platforms already managing compliance obligations across multiple regulatory frameworks, minimising PCI scope is a material simplification. Requirements that apply to your organisation as a whole still apply, including security policies, incident response and managing your service providers, and quarterly vulnerability scans and periodic penetration testing still apply to whatever stays in your scope. Compliance still has to be validated, and your acquirer or QSA confirms which requirements apply.
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 a PCI DSS Level 1 Service Provider, ISO 27001 Certified and SOC 2 Type 2. 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.