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. AXA has another. 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, no revenue participation, 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, stored securely, 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. PCI compliance handled by The Payment Layer.
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 PSP through a single integration
The third option is what The Payment Layer provides. One integration from the platform. Any PSP per carrier. No re-engineering when a new carrier onboards with a different processor.
Allianz runs call centre payments through Shuttle across 3 countries — each routing to Allianz's contracted processors. Adding a new country or a new PSP is configuration, not development.
PCI Compliance Architecture
For insurance platforms, PCI scope is the make-or-break constraint.
Zero Scope for the Platform
The architecture that works: card data never enters the platform's environment. Payment capture — whether via DTMF on a voice call, a hosted payment page, or a payment link — happens within The Payment Layer's PCI DSS Level 1 certified infrastructure. The platform receives only redacted data: last four digits, transaction status, settlement confirmation.
This means:
The platform stays at SAQ-A — the lightest PCI self-assessment (22 requirements)
Not SAQ-D — the full assessment (300+ requirements, annual QSA audit, $200K+ per year)
The carrier stays at zero scope for platform-initiated payments
Call recordings contain no card data — DTMF tones are stripped before they reach the recording system
What This Saves
PCI DSS Level 1 certification costs upwards of $2M to achieve and maintain. For an insurance core platform that isn't in the business of processing payments, carrying that burden 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, claim payments, policy inception — millions of these conversations happen daily, and a significant percentage 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."
Claim payments. A settled claim payment is issued via payment link or direct transfer, triggered from the claims module and routed through the carrier's PSP.
PolyAI — whose AI agents handle conversations across regulated industries including insurance — processes voice payments with a 75% completion rate and zero human handoffs: "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
No 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
The Revenue Model
Payment execution isn't just a feature. It's a revenue line.
When premiums flow through the platform — every renewal, every overdue collection, every new policy — the platform participates in the payment economics. Revenue share on transaction volume. No capital outlay beyond the initial integration.
For insurance core platforms, the math is compelling. Policy premiums are high-value, recurring transactions. A platform processing premium collections for even a fraction of its carrier base generates material revenue from day one.
For the full analysis of how platforms monetise embedded payment execution, see How Platforms Monetise Payments Without PSP Lock-In.
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 12+ months of dedicated development and $2M+ in 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 handled. New carriers onboard in days. 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 zero-scope architecture
Shuttle is The Payment Layer for insurance core platforms. One integration. Any carrier's PSP. Voice, links, and embedded checkout. PCI DSS Level 1, ISO 27001, and SOC 2 certified. [See how it works for platforms](/platforms/) or [book a discovery call](/discovery/).