Every insurance core platform has billing. Almost none execute payments.
Billing modules handle invoices, installment schedules, delinquency tracking, and reconciliation. They manage the record of what's owed. But when it's time to actually collect the money (capture a card, route to a processor, confirm the transaction), the platform hands off. The carrier figures it out. A third-party system takes over. The customer leaves the platform workflow.
This is the gap between billing and payment execution. And it's the single biggest missed opportunity for insurance core platforms today.
Why Insurance Core Platforms Don't Execute Payments
The reasons are structural, not accidental.
PCI compliance is the first wall. The moment card data enters a platform's infrastructure, PCI DSS applies. For a core platform that manages policy data, claims, and billing across dozens of carriers, adding PCI scope introduces a compliance burden that most product teams rightly avoid.
Every carrier uses a different PSP. Allianz has its processor. Another carrier has a different one. A regional mutual uses a third. An insurance core platform serves all of them, but can't force them onto a single payment gateway. This multi-PSP requirement makes direct gateway integrations impractical. Building one integration per carrier per PSP doesn't scale.
Payments aren't the core competency. Insurance platforms are built by teams that understand policy administration, actuarial models, and claims workflows. Payment infrastructure is a different discipline with different certification requirements, different vendors, and different operational risks.
The result: billing is table stakes. Payment execution is the missing layer.
The Three Ways Carriers Solve Payments Today
When the platform doesn't execute payments, carriers default to one of three workarounds:
1. Separate payment portal. The carrier sets up a standalone payment page, disconnected from the core platform. Policyholders navigate away from the platform workflow to pay. Reconciliation between the payment portal and the billing module is manual or semi-automated. Data lives in two places.
2. Manual phone collection. Agents read card numbers over the phone, type them into a terminal, or transfer the caller to an IVR system. This works but creates PCI scope for the contact centre, compliance risk for the carrier, and a poor experience for the customer.
3. Paper and batch processing. Checks, direct debit mandates, and bank transfers processed outside the platform. Reconciliation is slow. Delinquency detection lags. Cash flow forecasting is unreliable.
All three approaches share the same problem: the payment happens outside the platform. The platform knows what's owed but can't collect it. The carrier owns the payment relationship, and the platform has no visibility and no ability to improve the experience.
What Native Payment Execution Looks Like
When payment execution is embedded inside the insurance core platform, the entire dynamic changes.
Premium collection during a voice call. A policyholder calls about a renewal. The agent, human or AI, confirms the premium amount, triggers a secure payment capture within the conversation, and the payment is processed through the carrier's PSP before the call ends. No transfer to IVR. No "please go online." Card data never touches the platform.
Payment links for overdue premiums. The billing module identifies an overdue installment. The platform sends a branded payment link via SMS or email. The policyholder pays in two taps. The payment settles through the carrier's existing processor. Reconciliation is automatic.
Embedded checkout in the policy portal. A new policyholder purchases a policy through the carrier's digital channel. The checkout component is embedded in the platform's UI: white-labelled, carrier-branded. The card is tokenised with the carrier's gateway and used for recurring premium collection without the policyholder re-entering details.
AI agent payment capture. An AI voice agent handles a collections call for an overdue premium. The agent confirms the amount, the policyholder enters card details via DTMF, and the payment processes, all within the automated conversation. No human intervention. Card data stays out of the platform, which limits its PCI scope.
In each case, payment execution is native to the platform workflow. The carrier doesn't need a separate payment system. The platform captures the transaction.
The Multi-Tenant PSP Problem
This is the structural challenge that makes insurance platform payments different from merchant payments.
A single insurance core platform might serve 20 carriers. Each carrier has its own processing agreement, with Stripe, Adyen, Worldpay, or a regional acquirer. Enterprise carriers mandate their PSP. It's in their procurement contracts. It's not negotiable.
A platform that integrates with one PSP serves one carrier. A platform that needs to serve all carriers needs to either:
Build and maintain 20 separate PSP integrations (years of engineering, ongoing maintenance)
Force all carriers onto one PSP (impossible: they'll refuse)
Use a PSP-neutral payment layer that supports any compatible PSP through a single integration
The third option is what The Payment Layer provides. One integration from the platform. Each carrier on its own PSP. No re-engineering when a new carrier onboards with a different processor.
Allianz uses Shuttle for voice payment collections in three countries.
PCI Compliance Architecture
For insurance platforms, PCI scope is the make-or-break constraint.
Limited Scope for the Platform
The architecture that works: card data never enters the platform's environment. On a voice call, the card is keyed in through Twilio Pay and goes to the gateway; on a hosted payment page or payment link, it is entered in The Payment Layer's PCI DSS Level 1 certified environment. The platform receives only redacted data: last four digits and transaction status.
This means:
The platform's PCI scope is typically much smaller
The carrier's scope stays limited for platform-initiated payments
Call recordings contain no card data: the digits never reach the recording system
What This Saves
For an insurance core platform that isn't in the business of processing payments, carrying PCI DSS Level 1 makes no strategic sense. The Payment Layer carries it instead: PCI DSS Level 1, ISO 27001, and SOC 2 certified.
For the full technical architecture, see our guide on how AI voice agents take PCI-compliant payments.
Voice Payments for Insurance
Insurance is a voice-heavy industry. Phone renewals, collections calls, policy inception: these conversations happen daily, and many involve a payment moment.
Phone renewals. A policyholder calls to renew. The agent confirms the premium, triggers DTMF capture, and the payment processes within the call. Or an AI voice agent handles the entire renewal autonomously.
Collections calls. An overdue premium triggers an outbound call, automated or agent-assisted. The payment is captured mid-conversation through secure DTMF entry. No "please call back during business hours." No "we'll send you a letter."
PolyAI, whose AI agents handle conversations across regulated industries including insurance, puts it this way: "Shuttle let us treat legacy payment providers as a modern SaaS service. It enabled us to support the gateways our customers required and fully automate high-value transactions across regulated industries."
Payment Links for Insurance
Payment links are the fastest path to collecting overdue premiums and reducing delinquency.
The billing module identifies an overdue installment. The platform sends a branded link via SMS or email. The policyholder opens it, sees the amount and policy reference, enters payment details, and pays. Settlement routes through the carrier's PSP. The billing module updates automatically.
Why this matters for insurance:
Reduces delinquency: policyholders pay immediately instead of waiting for a letter or logging into a portal
Works across carriers: each link routes to the correct PSP for that carrier
Limited PCI scope: the payment page is hosted by The Payment Layer, not the platform
Branded: the policyholder sees the carrier's name and branding, not a third party
Build vs Integrate
The build-vs-buy decision for insurance platform payments comes down to two questions:
1. Can you justify the engineering investment? Building multi-PSP payment execution (with PCI compliance, voice payment support, payment links, and per-carrier routing) requires months of dedicated development and significant compliance investment. That's engineering capacity diverted from policy administration, claims, billing, and every other feature your carriers are actually paying for.
2. Can you justify the ongoing maintenance? Each PSP integration requires monitoring, version updates, certification renewals, and incident response. Multiply by the number of carriers. Add PCI audit cycles. The operational cost compounds.
The alternative: integrate once with The Payment Layer. 40+ PSPs supported. Voice, links, embedded checkout. PCI scope limited. The platform ships payment execution without building payment infrastructure.
For a detailed comparison, see Gateway vs Orchestrator vs PayFac vs Payment Layer.
Related Reading
Embedded Payments Without Becoming a PayFac: why most platforms shouldn't own the payment relationship
Enterprise PSP Mandates: Why Platforms Need Multiple Gateways, the enterprise constraint that drives multi-PSP adoption
PSP-Neutral vs Single-PSP Architecture: when PSP flexibility matters
PCI-Compliant Payments for Contact Centres: the full guide to human and AI agent payment flows
Payment Orchestration vs Payment Layer: why orchestration doesn't solve the platform problem
PCI-Compliant Payment Architecture for Insurance Platforms: the technical deep dive on limited-scope architecture
Shuttle is The Payment Layer for insurance core platforms. One integration. Each carrier's own compatible PSP. Voice, links, and embedded checkout. PCI DSS Level 1, ISO 27001, and SOC 2 certified. See how it works for platforms or book a discovery call.