Insurance Payment Solutions Compared: Payment Layer vs Gateway vs PayFac

By Shuttle Team, February 21, 2026

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



Book a discovery call to explore how Shuttle adds payments to your insurance platform, or see how it works for platforms.

Talk to us

See how Shuttle can power payments for your platform: multi-PSP, multi-channel and white-label.