The Problem Insurance Platforms Face
Insurance core platforms manage the entire policy lifecycle: quoting, binding, billing, claims. But when it's time to collect a premium, take an excess payment, or process a renewal, the platform hands off to someone else.
The carrier handles payment collection separately. Or the platform builds a brittle integration to one PSP that breaks the moment a second carrier needs a different processor. For PAS vendors and MGA platforms specifically, see Payments for Insurance Carriers and MGA Platforms.
This page compares the four approaches insurance platforms use to add payments, and explains which one fits the multi-carrier, multi-channel reality of modern insurance.
The Four Approaches
1. Direct Gateway Integration
Integrate directly with a payment gateway (Stripe, Adyen, Worldpay) and build payment flows into the platform.
What you get:
Full control over the payment experience
Direct relationship with the PSP
Well-documented APIs
What you don't get:
Multi-PSP support (each carrier's PSP requires a separate integration)
In-call voice capture (you still need a telephony layer for keypad capture)
Multi-tenant architecture (gateways serve merchants, not platforms)
PCI scope: Shared with the gateway; hosted fields reduce it Carrier flexibility: One PSP per integration. 10 carriers = 10 integrations.
2. PayFac Model
Become a Payment Facilitator, through a full PayFac licence or a managed PayFac service, or use a PSP platform product such as Stripe Connect or Adyen for Platforms.
What you get:
Control over merchant onboarding
Unified experience for carriers
What you don't get:
Carrier PSP flexibility (carriers mandate their PSP, and they won't switch to yours)
Fast time to market (a full PayFac takes time to set up)
Low compliance overhead, if you become the PayFac (PCI, AML and KYC obligations)
Voice payment channels
PCI scope: A full PayFac owns it, plus AML/KYC and risk management Carrier flexibility: None. Carriers must use the platform's PSP.
For most insurance platforms, the PayFac model fails on the first constraint: carriers won't abandon their existing processor. See Embedded Payments Without Becoming a PayFac.
3. Payment Orchestrator
Use an orchestration platform (Primer, Spreedly) to abstract multiple PSP connections behind a single API.
What you get:
Multi-PSP routing through one integration
Retry and provider configuration
Unified reporting across PSPs
What you don't get:
Voice payment support (orchestrators are checkout-page-centric)
White-label merchant onboarding
Multi-tenant architecture designed for platforms
PCI scope: Reduced by the orchestrator's vault and hosted forms Carrier flexibility: Good for routing, but designed for merchants rather than multi-tenant platforms
Orchestration solves the wrong problem for insurance platforms. Orchestrators optimise routing for a merchant with multiple PSPs. Insurance platforms need each carrier to use their own PSP: a fundamentally different architecture. See Payment Orchestration vs Payment Layer.
4. The Payment Layer
A purpose-built layer that sits between the platform and 40+ supported PSPs. The platform integrates once. Each carrier uses its own processor, if it is one of them. Card data never touches the platform.
What you get:
Multi-PSP support (each carrier's PSP, from 40+ supported, through one integration)
Multi-channel payments (voice, links, embedded checkout)
Limited PCI scope for the platform
White-label carrier onboarding and payment experiences
PCI DSS Level 1, ISO 27001 and SOC 2 certification held by the layer
What you don't get:
Direct PSP control (the layer manages PSP connections)
PCI scope: Card data is captured inside the layer's certified environment and tokenised with the carrier's own gateway, so the platform's scope stays limited Carrier flexibility: 40+ supported PSPs. Each carrier on its own. One integration.
Comparison Table
Gateway | PayFac | Orchestrator | Payment Layer | |
|---|---|---|---|---|
Multi-carrier PSP support | One per integration | None (carriers must use yours) | Multiple (merchant-facing) | Each carrier's PSP, from 40+ supported |
Voice payments | Agent-keyed MOTO | No | No | Yes |
Payment links | Gateway's own links (e.g. Stripe, Adyen) | Limited | Varies (Gr4vy: yes) | Yes (white-label) |
Embedded checkout | Build it yourself | Yes | Build it yourself | Yes (white-label) |
PCI scope | Shared (reduced via hosted fields) | Shared; a full PayFac carries more | Reduced via the orchestrator's vault | Card data never touches the platform |
Carrier onboarding | Manual per carrier | PayFac KYC process | Manual per carrier | White-label, self-service |
Multi-tenant | No | Yes (heavy) | Varies (Gr4vy for Platforms) | Yes (thin) |
Which Approach Fits Your Platform?
You need a direct gateway if:
You serve one carrier with one PSP
You only need web checkout
You're willing to handle PCI scope
Payment is a minor feature, not a strategic capability
You need a PayFac if:
Payment revenue is your primary business model
Your carriers don't have existing PSP preferences (unlikely in insurance)
You have the time and budget to invest in compliance infrastructure
You need an orchestrator if:
You're a single merchant optimising routing across your own PSPs
You don't need card capture inside voice calls
Multi-tenancy isn't a requirement
You need The Payment Layer if:
You serve multiple carriers, each with their own PSP
You need voice payments for phone renewals and collections
You need payment links for overdue premium collection
You want to limit your platform's PCI scope
How Shuttle Fits
Shuttle is The Payment Layer for insurance core platforms. One integration from the platform. Each carrier's PSP, from 40+ supported. Voice, links, and embedded checkout. PCI DSS Level 1, ISO 27001, and SOC 2 certified.
Allianz uses Shuttle for voice payment collections in three countries. An insurance core platform uses Shuttle to provide payments across its carrier base, with each carrier on its own PSP and limited PCI scope for the platform.
Results from one platform:
$360K saved in a year, versus building and maintaining its own payment infrastructure
12 months of development time saved
Related Reading
Payments for Insurance Core Platforms: the complete guide to embedded payments for insurance
PCI-Compliant Payment Architecture for Insurance Platforms: limited-scope architecture for voice, links, and checkout
Gateway vs Orchestrator vs PayFac vs Payment Layer: the canonical comparison across all four categories
Embedded Payments Without Becoming a PayFac: why most platforms shouldn't own the payment relationship
PayFac Alternatives for Platforms: the full landscape of PayFac alternatives
Shuttle vs Building In-House: the real cost of building payment infrastructure yourself
Book a discovery call to explore how Shuttle adds payments to your insurance platform, or see how it works for platforms.