Claims Payment Integration — Connect Your System

Last updated: 29 May 2026

Most insurers we talk to already have a claims system. They've been running it for years. The platform handles FNOL, triage, reserves, adjuster notes, supplier networks, the lot. What it doesn't do — and this is true even of the modern cloud-native ones — is take a card payment in a way that keeps you out of PCI scope. That gap is where claims payment integration lives, and where most of the cost and risk of running a claims operation actually sits in 2026.

We've built integrations into Guidewire ClaimCenter, Duck Creek Claims, Sapiens, EIS, Insurly, two different homegrown systems written in C#, and a Ruby on Rails platform that one regional broker has been quietly polishing for fifteen years. The patterns repeat. So this guide is the practical version — what to wire up, what to skip, and how to spot the design choices that will bite you eighteen months later when your QSA shows up.

What claims payment integration actually means#

At its narrowest, claims payment integration is the API layer between your claims management system and the service that moves money — in or out. In the typical UK general insurance shop, that's two distinct flows. Inbound: the policyholder owes an excess, an underinsurance shortfall, or a contribution toward a betterment. Outbound: you owe them, a third party, or a supplier. Both flows have to land back in the claim record so the adjuster, the reinsurance team, and the auditor all see one consistent story.

The narrow definition doesn't tell you much, though. The real question is what gets integrated. A claims payment integration that just opens a hosted payment page in a browser tab and writes a transaction ID back to the claim is technically an integration. It's also useless to the contact centre, because the adjuster still has to read out a URL, the policyholder has to copy it into a phone they can't see while they're on the call, and the failure rate is somewhere north of 30%. Anyone who tells you a hosted page is an integration is selling you something.

A real claims payment integration handles four things from FNOL through settlement: (1) initiating the payment from inside the claims UI without spawning a separate session for the policyholder, (2) capturing the card data without any of it touching your network or your call recording, (3) returning a structured result — authorisation code, scheme, last four, AVS/CVV outcome, tokenised PAN if you've asked for one — back to the claim record automatically, and (4) handling the inevitable edge cases. Decline. 3DS challenge timeout. Policyholder hangs up mid-keypress. Adjuster cancels and re-quotes a different amount. That last 20% of the integration is what separates a working build from a demo.

The four payment moments in a claim lifecycle#

It's worth being concrete about where money moves in a claim, because each moment has different integration requirements and different compliance traps.

Excess collection at FNOL. The customer rings to report a loss, the adjuster validates cover, and the policy excess (£100, £250, sometimes more for commercial lines) is due before the claim progresses. This is the highest-volume integration point and the one that benefits most from being handled inside the same call. If the adjuster can collect the excess before the call ends, settlement velocity improves and abandonment drops. The wrong pattern is sending a payment link to email and waiting — abandonment runs at 40–60% in our experience with brokers we've migrated.

Recovery from a third party. When liability sits with another insurer or an uninsured party, you're often chasing money over the phone or over email. Same integration pattern as excess collection, different counterparty, sometimes different fraud profile. A claims payment integration that supports outbound payment workflows with the same compliance posture as the inbound flow is rare in the legacy world but increasingly expected.

Salvage and supplier payments. Money flowing out — to repairers, hire car suppliers, medical providers, third-party valuation services. This is usually a BACS or Faster Payments flow rather than a card flow, but the integration discipline is the same: trigger the payment from the claim, get a structured confirmation back, attach it to the audit trail, and don't let an adjuster type a sort code by hand into anything other than the claims platform itself.

Settlement to the policyholder. The final number, paid out. Most insurers still do this by BACS, but Faster Payments is now the expected experience for personal lines, and a growing share of household and motor settlements happen via push-to-card. If your integration layer doesn't support all three rails from the same trigger, you'll end up with three different processes and three different reconciliation feeds.

Why bolt-on payment portals create the scope problem#

The most common claims payment setup in the UK market in 2026 is still some variant of: claims platform on one side, a generic gateway portal on the other, and an adjuster who copies amounts between the two. We see this in shops running Guidewire, in regional brokers running spreadsheets, and in the surprisingly large number of MGAs running bespoke .NET apps written by a contractor in 2014.

This pattern is a PCI scope generator. The moment an adjuster reads the card number from a call recording — or from the policyholder reading it out loud while the call is recorded — the call recording is in scope. The contact centre desktop, the recording infrastructure, the QA platform, the WFM tool that touches the recording metadata, the storage layer it sits on, all of it. You're now in SAQ D territory with hundreds of controls to evidence rather than the 22 controls of SAQ A.

The cost of that scope creep is not theoretical. We've seen a regional motor specialist pay £180,000 a year in QSA fees, network segmentation tools, and remediation work because their claims process touched cardholder data in five different systems. After we integrated their claims platform with DTMF masking so the policyholder types the card into their keypad directly into our PCI-DSS Level 1 environment, all five of those systems came out of scope. The QSA bill the following year was £42,000.

How DTMF masking changes the integration shape#

The technical magic underneath a properly integrated claims payment flow is DTMF suppression. When the adjuster transfers the policyholder into the capture flow — without dropping the call, without putting them on hold — our platform mutes the audio of the keypad tones to everything on your side of the call. Your call recording captures conversation, not the dial-tone payment data. The DTMF digits are decoded and tokenised inside our PCI environment, never reaching your network.

From an integration perspective, this means your claims platform never sees the PAN. It sees a request, a session ID, an in-flight status, and a result. The result includes a tokenised card reference if you've asked for one (useful for storing a card on file for future excess collections, recurring premium top-ups, or scheduled payments toward a deductible plan), the authorisation code, the scheme, the last four digits for the policyholder to recognise on their statement, and the outcome.

The data model is straightforward but the operational reality matters. We've seen integrations where the claims platform polled our API every 500ms during a 90-second capture and chewed through 180 calls per claim — fine on test, expensive at 50,000 claims a month. We've also seen integrations where the platform fired off a single request and then sat blocked waiting for a callback that never came because of a webhook misconfiguration. The right pattern is documented in the claims processing guide and worth reading before you start building.

API integration patterns that actually work#

Three patterns cover 90% of the integrations we've built or reviewed. Pick the one that matches where your claims platform sits architecturally — don't try to invent a fourth.

Pattern 1: Embedded iframe inside the claims UI. Suitable when your adjuster desktop is browser-based (Guidewire ClaimCenter post-Cloud release, modern Duck Creek, anything React-based you've built in the last five years). The adjuster clicks a "collect excess" button, our embedded component appears inside the claim record, the policyholder is invited to enter card data via DTMF on their phone, and the result lands back in the claim within the same browser session. This is the lowest-friction pattern for the adjuster and the cleanest from an integration perspective.

Pattern 2: REST API with webhook callbacks. Suitable when your claims platform is server-side, on-premise, or older. The platform calls our /payments endpoint with the amount, currency, claim reference, and customer phone number. We initiate the capture flow with the policyholder (who's already on the call with your adjuster), and post the result back to a webhook URL on your side. The platform updates the claim record and surfaces the outcome to the adjuster via whatever UI you've got. This is the workhorse pattern and the one we'd recommend for anyone running a heterogeneous claims estate.

Pattern 3: Outbound payment via API + reconciliation feed. For settlement and supplier payments where money goes out rather than in. The claims platform fires a payment instruction to our outbound API, we move the funds via Faster Payments or BACS, and a daily reconciliation feed comes back into the platform's general ledger. This pattern is mature, well-documented, and the failure modes are predictable. The main integration risk is on the reconciliation side — make sure your finance team has agreed on the file format before development starts. We've watched a five-week integration become a five-month integration because the GL team wanted CSV and engineering built JSON.

What about Guidewire specifically?#

Guidewire ClaimCenter is the dominant platform in mid-to-large UK insurance, so it's worth being specific. The integration surface is the App Connect framework, with a published REST API and the option to extend the data model with plugin handlers. Our integration uses the standard Activity Pattern to surface the payment workflow as a claim activity, which means the adjuster sees it in the same UI as everything else they do — no separate tab, no copy-paste, no swivel chair.

The gotcha with Guidewire integrations is the upgrade path. We've seen insurers build a beautiful integration against ClaimCenter 9, then spend six months reworking it for ClaimCenter 10's revised entity model. The fix is to encapsulate all the payment-specific logic in a plugin module and keep the configuration data in the standard typelist structure. When the upgrade comes, the rework is contained.

The data model: what should land back in the claim record#

Every integration we've reviewed has under-specified this. The bare minimum a claims platform needs in the claim record after a payment is the authorisation code, the amount, the currency, the timestamp, the scheme, the last four digits, the outcome (approved/declined/cancelled), and a transaction ID for later reference. The next tier — and you want this from day one if you're handling any volume — is the cardholder name as entered, the AVS result, the CVV2 result, the 3DS authentication outcome, the merchant ID under which the payment was processed (matters if you've got multiple), and the tokenised PAN if you're storing for future use.

The integration we recommend includes all of that in the webhook payload. The claims platform stores what it needs in the claim record and discards the rest. The full structured result lives in our reporting environment, retrievable via API if your fraud team or your reconciliation team needs it. This separation matters because the claims platform should not be a payment data warehouse. Conflating the two is how SAQ A insurers slide back into SAQ D.

Fraud and the integration boundary#

The claims payment integration is also where you make a decision about fraud screening. Most UK insurers we work with route claims-related payments through the same fraud engine as their underwriting flow — Featurespace, ThreatMetrix, an in-house rules engine. Some don't, and pay for it later. A claims payment captured in the contact centre carries a different risk profile from an e-commerce checkout, and the fraud team's rules should reflect that. If you're rebuilding your claims payment integration, this is the right moment to wire in the fraud feed properly. Insurance company fraud detection covers the rules and the signals in more depth.

One specific signal that the integration should always pass through is whether the call was inbound or outbound, and whether the phone number on the call matches the phone number on the policy record. We've seen account-takeover attempts where the fraudster has bypassed the IVR by ringing a direct line and posed as the policyholder. The DTMF-captured payment lands cleanly, the AVS passes (because the fraudster has the address), and the loss only surfaces three weeks later. A fraud rule that flags claim payments where the inbound number doesn't match the policy number would have caught it.

SAQ A versus SAQ D — the integration choice that decides your scope#

The single biggest commercial outcome of a well-designed claims payment integration is staying on SAQ A rather than SAQ D. The PCI DSS standard is the same; the assessor evidence required is dramatically different. SAQ A is for merchants who have fully outsourced cardholder data capture, storage, and transmission. SAQ D is for merchants who haven't.

The integration design choice that decides which one you're on is whether cardholder data ever touches a system you control. If the policyholder enters their card into your IVR using your telephony provider's DTMF recognition, you're on SAQ D — the IVR, the recording, the storage, all in scope. If they enter their card into your CRM, you're on SAQ D — the CRM, the database, the backups, the disaster recovery, all in scope. If they enter their card into our PCI-DSS Level 1 environment via DTMF masking, with the digits intercepted before they reach your network, you're on SAQ A. The difference is the difference between a £40,000 annual compliance bill and a £180,000 one. PCI compliance for insurance claims goes deeper on the scope rules.

Real client example: Pinnacle Group#

One of our insurance clients — Pinnacle Group, a multi-line insurer with a 200-seat claims operation — was running a swivel-chair process where adjusters were copying card data from a recorded call into a gateway portal. They were on SAQ D, paying for full network segmentation, and spending the equivalent of 1.4 FTE on QSA evidence preparation each year. After we integrated their claims platform with our DTMF masking via the REST API pattern (Pattern 2 above), they cut their PCI scope by 95%, dropped from SAQ D to SAQ A, and recovered roughly 60 seconds of average handle time per call where payment was taken. At their call volume, that's about 18,000 hours of agent time per year.

The integration took six weeks of effort — two weeks of design and API contract work, three weeks of build and test, one week of UAT and production cutover. Most of the elapsed time was on their side. The Paytia integration component is the same one we use across all client integrations; we don't rebuild it for each insurer.

What to watch out for during the build#

A few things consistently trip up insurance integrations. We mention them here because they're cheaper to plan for than to debug.

First, currency. Most UK insurers run in GBP only, but if you've got branches in Ireland, Channel Islands, or Gibraltar, you'll need EUR and GBP at minimum and possibly USD for marine and aviation lines. Specify this at the API contract stage. Retrofitting multi-currency is painful.

Second, partial payments. Excess collection sometimes happens in instalments. The claims platform needs to track how much of the excess has been collected against the planned total. Our integration supports schedule-aware tokenised future payments, but the claims platform has to drive the schedule. Don't try to delegate that to the payment platform — it doesn't know what a claim is.

Third, refunds and reversals. When a claim is reopened, when an excess is waived after an investigation, when a duplicate payment is taken in error, you need a clean reversal path. The integration should support full refund, partial refund, and void (before settlement) as first-class operations. We've seen integrations where refunds were treated as a manual operations task and the customer service team spent two hours a week processing them in a portal. Bad design.

Fourth, reconciliation. Whatever your finance team uses — Sage, Oracle, SAP, a custom GL — there will need to be a daily reconciliation feed that ties the claim payments to the settlement file from your acquirer. Get the file format agreed before development starts. This is the single most common cause of post-go-live emergency rework we see. Spec it up front.

Build versus buy versus integrate#

The third option — integrate — is what we're describing here, and it's almost always the right one for UK insurers. Building a PCI-compliant payment capture environment from scratch is a multi-million-pound undertaking and a permanent operational liability. Buying a separate payment portal and bolting it on with manual processes creates the scope problem we've covered. Integrating a specialist PCI-DSS Level 1 service into the claims platform via a well-designed API gives you the operational efficiency of a built-in system with the compliance posture of a fully outsourced one.

The economics are straightforward. A well-designed claims payment integration pays for itself in QSA fee reduction alone within the first 18 months for any insurer doing more than 500 transactions a month. Add the agent handle time savings, the reduced policyholder abandonment, and the lower fraud exposure, and the payback period typically lands inside the first year.

The role of tokenisation in the integration#

Tokenisation is the bit that turns a one-off payment integration into something the rest of the business can use. When we tokenise a card during an excess collection, the claim record stores a token reference that can later be used for a betterment top-up, a recurring premium payment, or — increasingly common — a deductible payment plan over six or twelve months. The integration becomes the gateway not just to claims payments but to the policyholder's payment lifecycle.

The tokens are scope-out by default. They live in our PCI environment, they're useless outside it, and the claims platform holds nothing more sensitive than an opaque reference string. This is also how we support cross-product payment flows — the same token from a claim can be used by the underwriting team to charge a mid-term adjustment without re-collecting card data. The policyholder experience is better, the compliance posture is the same.

Industry context: insurance is not retail#

One thing worth flagging for anyone coming to claims payment integration from a retail background: the design constraints are different. Retail prioritises checkout speed and cart abandonment. Insurance claims prioritise policyholder identification, fraud screening, and audit trail. The integration patterns that work for e-commerce don't always work here. A claims payment integration is, fundamentally, a regulated workflow inside a regulated industry, and it needs to be built like one.

That doesn't mean it has to be clunky. The best claims payment integrations are invisible to the adjuster — payment capture happens as a natural part of the claim conversation, the result lands back in the claim record without anyone refreshing anything, and the adjuster moves on to the next claim. The technology underneath is doing a lot. The user experience is doing very little. That's the right design.

Testing strategy for a claims payment integration#

The testing phase is where most claims payment integrations either lock down properly or quietly accumulate technical debt. We've seen insurers go live with a test suite that hit two happy paths and called it done, only to discover three months later that their integration didn't handle a particular acquirer response code that the gateway returned for legitimate-but-unusual transactions. The cleanup was a Friday-night production patch and a very long Monday-morning meeting with the head of claims.

A serious test plan covers four categories. First, transactional happy paths: each payment type (excess collection, recovery, settlement, supplier) for each card scheme (Visa, Mastercard, Amex, the occasional Diners), with successful authorisation, capture, and reconciliation. Second, transactional failure paths: declines for insufficient funds, declines for fraud rules, 3DS challenge failures, 3DS challenge timeouts, mid-flow policyholder hang-ups, mid-flow adjuster cancellations, and gateway timeouts. Third, integration boundary failures: claims platform unavailable when the webhook arrives, claims platform slow to respond, claims platform returns a 500 to the webhook, duplicate webhook deliveries (they happen), out-of-order webhook deliveries (they happen). Fourth, edge cases specific to insurance: claim closed before payment completes, claim reassigned to a different adjuster mid-payment, policy cancelled before the payment lands, fraud-flag added to the policy mid-payment.

Each of these scenarios needs to be testable in your UAT environment without burning real card numbers. Our test environment provides a full set of test cards that simulate every response code we've ever seen in production, plus a webhook simulator that lets you replay failed deliveries and out-of-order events. If you're integrating with anyone who doesn't provide that, push back. The cost of debugging in production is an order of magnitude higher than the cost of debugging in UAT.

Rolling out to the contact centre#

Even the best-integrated technology can be undone by a botched rollout. The mistake we see most often is treating the contact centre as an afterthought — engineering builds the integration, finance signs off the reconciliation, and the adjusters find out about the new payment flow the morning of go-live. Predictably, AHT spikes, abandonment goes up, and someone senior asks why the project's not delivering the benefits case.

The rollout pattern that works is staged, narrow, and instrumented. Start with a single team — maybe 10 to 15 adjusters — and a single claim type, typically motor first notification of loss. Train them on the new flow with screen-share sessions, not with a PDF. Watch them use it for two weeks. Look at the data: how long does the payment step take versus before, what's the policyholder abandonment rate, how often does the adjuster bypass the integration because they don't trust it. Fix what's wrong. Then expand to the next team and the next claim type. We've seen insurers roll the full integration across a 200-seat operation in eight weeks using this pattern. We've also seen insurers try to flip the whole estate in one weekend, fail, and roll back. Don't do that.

Multi-system claims estates#

If you're running more than one claims platform — and most UK insurers above £100M GWP are running at least two, often because of an acquisition that never quite got rationalised — the integration question gets more interesting. The naive answer is to build the integration twice. We've seen that, it works, it's expensive, and the two integrations drift apart over time as each platform team makes their own decisions.

The better answer is a thin platform-specific adapter on each claims system that talks to a single canonical integration with our service. The adapter handles the platform-specific bits — the Guidewire Activity Pattern on one side, the REST callout on the legacy Sapiens box on the other — and the canonical integration handles everything else. When we ship a new feature (push-to-card payouts, new fraud signals, updated tokenisation), it's available to both platforms simultaneously. When the legacy Sapiens box gets retired in three years, the canonical integration stays. This pattern adds maybe a week of architecture work upfront and saves about half the maintenance cost over the integration's lifetime.

UK regulatory context#

A claims payment integration in the UK sits under several overlapping regulatory frameworks beyond PCI DSS. The FCA's Consumer Duty (in force since July 2023) sets expectations about fair treatment of customers in claims handling, and slow or failed payments are increasingly the focus of FCA supervision visits. The Insurance Distribution Directive (now part of UK rules post-Brexit) requires fair-value assessment of payment processes. And the Financial Ombudsman's published decisions on claims-related complaints show a clear pattern: insurers who can't evidence a clean, auditable payment trail tend to lose contested cases.

A well-designed integration helps with all of this. The structured result data lands in the claim record automatically, the audit trail is consistent and machine-readable, and the policyholder gets a faster, less error-prone payment experience. None of that's why you build the integration, but it's why the project case to your Risk and Compliance director is easy to defend.

Worth noting separately: the FCA's expectations around vulnerable customers apply to claims payment flows. A policyholder who's just reported a major loss is, definitionally, in a state of stress. The integration should support graceful fallbacks for customers who can't complete a DTMF capture — maybe because they're calling from a hands-free car kit, maybe because they're using a SIP phone that handles DTMF differently, maybe because they're elderly and finding the keypad navigation difficult. Our solution offers an agent-assisted fallback path where the adjuster can verbally walk the customer through the capture step-by-step without ever hearing or recording the digits, but the integration has to surface that option cleanly. Specify it during the design phase.

Observability: what you should monitor#

Once the integration's live, you need a small but disciplined set of dashboards to know whether it's working. We typically wire up four signals into the customer's monitoring stack — usually Datadog, sometimes Splunk, occasionally a homegrown ELK setup.

First, capture success rate, broken out by claim type and adjuster team. A drop in success rate for a specific team usually means a training gap, not a technical fault. Second, average time-to-capture from "initiate payment" to "result received", with a P95 alert. A slow capture path doesn't show up in success rates but kills handle time. Third, webhook delivery latency from our service to the claims platform, with an alert on backed-up queues — usually the first sign of a claims platform performance issue. Fourth, reconciliation feed health: are the daily files arriving, do the totals match the gateway report, are there any unmatched transactions. The fourth one is where finance teams have their visibility, and it's the one most often missed by engineering teams during the build.

Disaster recovery and business continuity#

Insurance is a business where the worst day for the policyholder is the busiest day for the insurer. The integration needs to hold up during a major event — a storm losses surge, a motor crime wave, a data breach at a third party that triggers a wave of fraud claims. We size our platform for 10x normal volume and run continuous game-day exercises against our own infrastructure. Your claims platform needs to do the same, and your integration should fail gracefully when either side is degraded.

Specifically: the claims platform should be able to queue payment requests if our service is slow to respond, retry with exponential backoff, and surface to the adjuster a "payment in progress, will complete" message rather than a hard error. We should be able to absorb a burst from the claims platform without dropping requests, and we do — our SLA covers it. The integration design should make the failure modes visible to operations on both sides without spamming the adjuster, who is on a call with a stressed customer and doesn't need a popup about webhook retries.

Glossary references and further reading#

If you're new to some of the terms — API integration, network token, payment gateway API — the glossary covers the definitions. For the broader context on how claims processing platforms work from FNOL through settlement, the claims processing software guide pillar is the right starting point. For the compliance side, PCI DSS v4 covers the standard we operate under.

Next steps#

If you're scoping a claims payment integration — whether you're rebuilding an old one or starting fresh — we run a half-day technical discovery session with your platform team and your QSA's lead assessor. It covers the integration patterns, the data model, the scope implications, and the build estimate. There's no charge. Book a discovery call or see the integration live with one of our solutions engineers. We'll show you the API, the webhook payloads, the embedded UI, and the SAQ A evidence pack — everything you'd need to take to a build approval.