Payment providers and banks

Payment providers sit at the moment of purchase for thousands of merchants. Integrating Phew once lets every one of those merchants offer repair-first cover without building anything themselves, and gives you a new revenue line on the same transaction.

This page is written for product and engineering teams at payment providers, buy-now-pay-later providers, acquirers and banks. Your security and risk teams should read Security overview alongside it.

Integration models

You can combine these. Most providers start with one and add others later.

In your checkout

Show the offer inside your hosted checkout or payment sheet, after the basket is known and before the customer confirms. The premium is added to the same payment.

After purchase

Offer cover on the receipt, in the order confirmation email or in your app, within the cooling-off window. The customer pays for it as a separate payment.

Merchant enablement

Let merchants switch Phew on from your merchant portal. You onboard them through the Partner API; Phew handles the rest.

Split settlement

Split the premium out of the payment at capture and route it to Phew, so neither you nor the merchant holds it.

How the offer appears

Phew classifies every item in the basket automatically and only returns an offer for items it can cover, so there’s no product mapping to maintain for your merchants. You choose how the offer is shown:

Option	Best when
Iframe embed	Payment pages and in-app web views where third-party scripts aren’t allowed. Fully isolated, needs only frame-src.
Drop-in SDK	Web surfaces where you’re happy to load a versioned Phew script and want the tightest visual integration.
Build with the API	You want the offer in your own native components, in your design system, end to end.

Whichever you choose, policies are created by your server with one API call, and the security level below applies to every request.

Architecture

All calls are server-to-server from your backend. Phew never sits in the payment authorisation path: if Phew is slow or unavailable, the payment goes through without the offer.

Your infrastructure

OAuth 2.0 · mTLS · signed messages

Phew

Checkout or payment sheet

Offers, policies, cancellations

Checkout API

Merchant portal

Merchant onboarding, statements

Partner API

Webhook receiver

Signed events

Webhooks

Call	API	When
Onboard a merchant	Partner API, POST /v1/merchants	Merchant enables Phew in your portal
Get an offer	Checkout API, POST /v1/offers	Basket is known
Create a policy	Checkout API, POST /v1/policies	Payment captured
Cancel a policy	Checkout API, POST /v1/policies/{id}/cancel	Refund of the covered item
Receive events	Webhooks	Claims, cancellations, statements

When you act for one of your merchants, send their Phew merchant ID in the Phew-Merchant header. One partner credential covers every merchant you onboard; Phew checks on every request that the merchant belongs to you.

Choosing a security level

All endpoints are available at every level. The level determines how your systems authenticate and how messages are protected. You choose per environment, so a pilot can run on Standard while production uses Bank-grade.

Control	Standard	Enhanced	Bank-grade
TLS 1.2+ with modern ciphers	✓	✓	✓
Secret API key, scoped and rotatable	✓	✓
IP allowlist		✓	✓
Signed requests (RFC 9421) with body digest		✓	✓
OAuth 2.0 client credentials, 10-minute tokens			✓
Client authentication with private_key_jwt or mTLS			✓
Certificate-bound access tokens (RFC 8705)			✓
Webhooks signed with Ed25519 (RFC 9421), keys published as JWKS		Optional	✓
Webhook delivery over mTLS			Optional
Dedicated security contact and joint incident runbook			✓

Details: Security levels, OAuth 2.0 and mTLS, Request signing.

If you only want an API key

A smaller provider can be live with a single restricted API key and HMAC-signed webhooks. Start with API keys and move up later without changing any endpoint.

Bank-grade quick look

private_key_jwt

# 1. Sign a short-lived client assertion with your private key (kid registered with Phew).
# 2. Exchange it for an access token.
curl https://partner-api.getphew.com/oauth2/token \
  -d grant_type=client_credentials \
  -d client_id=cli_01JD8A... \
  -d client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer \
  -d client_assertion=eyJhbGciOiJQUzI1NiIsImtpZCI6InBzcC0yMDI2LTEwIn0... \
  -d scope="offers:write policies:write policies:cancel claims:read merchants:write"

mTLS

# The client certificate authenticates you and binds the token to it.
curl https://partner-api-mtls.getphew.com/oauth2/token \
  --cert client.pem --key client-key.pem \
  -d grant_type=client_credentials \
  -d client_id=cli_01JD8A... \
  -d scope="offers:write policies:write"

Then call the APIs with the token. Tokens last 10 minutes; request a new one before expiry.

curl https://api.getphew.com/v1/offers \
  -H "Authorization: Bearer eyJhbGciOiJFUzI1NiIs..." \
  -H "Phew-Merchant: mer_01JD7Z..." \
  -H "Idempotency-Key: 3d2c8a8e-..." \
  -H "Content-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:" \
  -H 'Signature-Input: phew=("@method" "@target-uri" "content-digest" "phew-merchant");created=1761220329;keyid="psp-2026-10";alg="ecdsa-p256-sha256"' \
  -H "Signature: phew=:MEUCIQ...:" \
  --json @offer.json

Split settlement

With split settlement, the premium is separated from the payment when it’s captured and paid to Phew directly. It works with any provider that supports split payments or marketplace payouts.

1. When the customer adds cover, include the premium in the payment amount as its own line.
2. At capture, split the premium portion to Phew’s settlement account (we provide the account or sub-merchant ID for your platform).
3. Send the payment reference in payment.reference when you create the policy, so we can match the funds.
4. On refund of the covered item, cancel the policy and reverse the split. Phew refunds the premium portion.
5. Reconcile with the monthly statement, which lists every premium by payment reference.

Your responsibilities

When you show Phew to customers, you are part of the distribution of an insurance product. Phew provides the copy, documents and review; you make sure that in your flow:

• The offer shows the plan, the price including taxes, and links to the terms and the IPID before purchase.
• The offer is never pre-selected, and declining is as easy as accepting.
• Cover appears as a separate line on the receipt.
• Customer details you send are accurate and only what the API asks for.

Phew handles the regulated parts: product governance, the contract with the insurer, policy documents, claims, complaints and regulatory reporting.

Working with us

1. Discovery call. We walk through your flows, your security requirements and which models fit.
2. Security review. Your security team gets our controls documentation and can send their questionnaire. We agree the security level and the data processing agreement.
3. Sandbox. We issue sandbox credentials (or register your OAuth client and certificates) and open a shared channel between our engineering teams.
4. Build and certify. You build against the sandbox. We review the customer-facing flow and run through the go-live checklist with you.
5. Pilot. Live with a small group of merchants, then wider rollout.

To start, register your interest and choose Payment provider or bank.