Executive summary
From one-time payments to a full subscription billing platform.
Our client is a UK insurance business operating multiple insurance distribution models, including Income Protection policies sold directly to consumers. The client was already running Stripe as the payment gateway for one-time premium payments. The ambition for this engagement was to extend that foundation into a full subscription billing platform: letting customers pay for their Income Protection cover on a recurring basis, with flexible billing frequencies, automated policy renewals, automated refunds on cancellation, and support for the payment methods the UK insurance market requires, including BACS Direct Debit with its legally mandated mandate flow.
iTechCloud Solution designed and built the Salesforce-Stripe integration behind this platform. The result is a subscription billing engine orchestrated from Salesforce, where policy and customer data live, and executed on Stripe, where the money moves. The two systems stay synchronized in near-real-time, so customer-facing processes (renewal, cancellation, refund) run automatically and the client's operations team no longer touches the billing side of the policy lifecycle unless something genuinely needs their attention.
- Client
- A UK insurance business operating multiple distribution models, including Income Protection cover
- Industry
- Insurance: direct-to-consumer Income Protection and related subscription products
- Challenge
- Extend an existing one-time Stripe setup into a full subscription billing platform with automated renewals, refunds and UK-specific payment methods
- Solution
- Salesforce-Stripe integration: subscription management, BACS Direct Debit with mandate flow, Stripe Elements for PCI-compliant payment forms, flexible billing frequencies, automated renewal and refund workflows, multi-method payment architecture
- Engagement
- Full-lifecycle delivery: discovery, design, build, Stripe test environment validation, production rollout and ongoing managed services
The client
A UK insurer running multiple distribution models.
Our client is a UK insurance business that operates across several insurance distribution models (direct-to-consumer, affinity and partner channels) and sells a range of insurance products including Income Protection. The business's reach depends on the quality of the digital experience each distribution model provides, and particularly on the ease with which customers can purchase and pay for cover online.
On the technology side, the client runs Salesforce as the system of record for policies, customers and the day-to-day operations of the business. Payments were already being processed through Stripe, a reasonable choice for a modern digital insurer selling direct, but the Stripe implementation was limited to one-time payments. That limitation was now the constraint on the next phase of the business.
The situation
One-time payments in a subscription-first market.
The commercial reality of modern insurance distribution is that customers want flexibility. For an Income Protection product, the natural customer behaviour is to pay monthly, matching the cadence of the salary the policy is designed to protect, not annually in one lump. Payment flexibility is both what customers expect from any modern subscription service and, in practice, a material driver of conversion for insurance products of this type.
The existing setup did not support that. Stripe was in place, but configured for one-time payments only: there was no concept of subscription plans, no recurring billing, no automated renewal when the cover period ended. Everything on the subscription side of the business, if there was going to be one, would need to be built.
Alongside the subscription gap, the engagement had four specific technical requirements shaped by the UK insurance market and the client's commercial plans:
- BACS Direct Debit as a first-class payment method. In the UK insurance market, Direct Debit is a dominant choice for monthly premium payments. Supporting it meant more than adding another Stripe payment method: it required collecting account name, account number and sort code, and presenting the customer with a BACS Direct Debit mandate form they could legally agree to. The mandate is not optional under UK Direct Debit rules, so it had to be built in from the start.
- Apple Pay readiness. Apple Pay was not needed for the Income Protection product at launch, but the client wanted the integration prepared so it could be switched on in future for other products, controlled from the client's Stripe account rather than requiring new code.
- Flexible billing frequencies. The business needed to support not just annual billing, which it had, but monthly, weekly and daily premium payments depending on the product and the customer's preference.
- Automated renewals and refunds. Policy renewal needed to happen without manual intervention when the subscription period ended, and when a customer cancelled, the refund (where applicable) needed to flow through automatically rather than sitting in an operations queue.
These four requirements, together with the core subscription billing gap, defined the scope of the engagement.
Our approach
Salesforce orchestrates. Stripe executes.
The architectural principle we worked from was straightforward: Salesforce is the system of record for policies and customers; Stripe is the system of record for subscriptions and payments. The integration between them should make each system do what it is best at, and keep them synchronized so the client's operations team and customer-facing systems always see a single consistent view of the state of a policy and its billing.
In practice that meant subscription plans would live in Stripe, whose subscription management is a mature product that would have added complexity without benefit if reimplemented inside Salesforce. But the policy, the customer and the lifecycle events that mattered to the business would live in Salesforce, with Stripe's subscription state continuously synchronized into Salesforce so that any team looking at a customer's record sees the full picture, including the subscription they are paying under and the state of their next payment.
On the customer-facing side, the design principle was equally clear: the payment experience had to be secure by construction, legally compliant for BACS Direct Debit, and genuinely frictionless. We used Stripe Elements, Stripe's iframe-based payment form components, so sensitive card and bank data never touched the client's own servers, which keeps the compliance surface area minimal. The custom payment forms we built around those Elements collect the information Stripe does not, present the BACS mandate flow where Direct Debit is selected, and hand off cleanly to Stripe for the actual payment.
A payment integration done well is invisible. The customer never thinks about where their data is going or what system is charging them. The operations team never has to intervene in a renewal that should have happened automatically. If anyone is talking about the payment platform, something has gone wrong.
Subhash Panchani, CEO & Co-Founder, iTechCloud Solution
What we built
A Salesforce-Stripe subscription billing platform, end to end.
The platform has six integrated components: the Salesforce-Stripe integration foundation, subscription plans with flexible billing frequencies, BACS Direct Debit with its mandate flow, secure PCI-compliant payment forms, a multi-method payment architecture, and the automated renewal and refund workflows that run on top of all of it.
Salesforce-Stripe integration foundation
At the base of the platform is the integration layer between Salesforce and Stripe. We built the server-side logic to call Stripe's API using the Secret API key, with the sensitive key material held securely on the server side rather than exposed to the client. Every subscription-relevant event in Stripe (a new subscription, a successful or failed payment, a plan change, a cancellation, a refund) flows back into Salesforce so the policy record always reflects the current billing state. Equally, actions taken in Salesforce that need an effect in Stripe, such as cancelling a policy or triggering a refund, propagate correctly in the other direction.
Subscription plans with flexible billing frequencies
Subscription plans are defined in Stripe's dashboard, which gives the client's commercial team a familiar place to manage the plans themselves. The platform supports billing frequencies from annual down to daily, which was the specific gap the engagement needed to close. Trial periods and plan changes are handled through the Stripe API, with the resulting state synchronized back into Salesforce so the policy record always shows the current plan, trial status and billing cycle for each customer.
BACS Direct Debit with legally compliant mandate flow
For Direct Debit payments, we built the full BACS flow into the purchase experience. When a customer selects Direct Debit at checkout, they are presented with a payment form that collects account name, account number and sort code and, critically, includes the BACS Direct Debit mandate form the customer must agree to before the mandate is set up. The mandate is a legal requirement under UK Direct Debit rules; we treated it as a first-class part of the flow rather than a disclaimer bolted on at the end.
Secure PCI-compliant payment forms via Stripe Elements
Payment data handling is where security and compliance obligations are most acute. We built the customer-facing payment forms using Stripe Elements, the iframe-based components that render Stripe-hosted fields for sensitive card and bank data inside the client's own interface. The sensitive data goes directly from the customer's browser to Stripe, never passing through the client's servers. That architecture keeps the PCI compliance scope minimal and gives the client the benefit of Stripe's own hardened payment-form infrastructure. Our custom forms wrap those Elements with the data collection and mandate flows Stripe does not provide out of the box.
Multi-method payment architecture
The platform supports credit cards, debit cards, digital wallets and BACS Direct Debit, with the architecture designed so that enabling or disabling specific methods is controlled from the client's Stripe account rather than requiring code changes. Apple Pay is included in the architecture but not yet activated for the Income Protection product: it is ready to switch on when the client chooses. The same mechanism lets the client add new payment methods for new products in future without further integration work.
Automated renewal and refund workflows
The two operational workflows that previously would have required manual intervention, policy renewal at the end of a subscription period and refund processing when a customer cancels, now run automatically. Renewals are handled by Stripe's native subscription billing, with the renewed state synchronized back into Salesforce so the policy continues cleanly. Cancellations and refunds initiated from Salesforce, or by the customer, propagate to Stripe, trigger the refund where applicable, and flow the outcome back into Salesforce. The operations team is out of the loop for the common cases and engages only when something genuinely needs human judgement: a disputed payment, an edge-case cancellation, a mid-cycle plan change requiring manual review.
The outcome
Subscription billing, running on its own.
The platform delivered the specific outcomes the engagement set out to achieve, inside a payments architecture the client can continue to evolve as new products and distribution models come onstream.
Subscription payments across every billing frequency
Customers can now buy Income Protection cover annually, monthly, weekly or daily, rather than being limited to the lump-sum annual payment the previous setup supported. For a product designed to protect monthly income, matching the billing cadence to the income cadence is the natural purchase pattern, and the platform now supports it.
BACS Direct Debit, mandate-compliant from day one
Direct Debit is now a first-class payment method, with the legally required mandate form built into the payment flow. UK customers set it up in the same checkout experience as cards and digital wallets, with the compliance obligations handled by design rather than as an afterthought.
Automated policy renewals, no manual effort
Renewals that would previously have needed manual intervention at the end of each subscription period now happen automatically. Cover continues without a lapse, the operations team is not pulled into the renewal cycle, and the renewal is captured cleanly in Salesforce so the policy record stays accurate.
Automated refunds on cancellation
When a customer cancels, the refund (where applicable) flows automatically from Stripe back to the original payment method, with the cancellation and refund both recorded on the policy in Salesforce. The operations overhead of processing cancellations has been engineered out of the day-to-day.
A secure, compliant payment foundation
Keeping sensitive card and bank data out of the client's own servers, using Stripe Elements and Stripe's hosted payment infrastructure, minimizes the client's PCI compliance surface area. The security model is built into the architecture rather than layered on top of it.
Platform & tooling
What's under the hood.
Salesforce platform
System of record for policies and customers: custom data model for subscription state, lifecycle events and billing records synchronized from Stripe.
Payment platform
Stripe: subscription management, Stripe Elements for PCI-compliant payment forms, Stripe-hosted iframe fields for sensitive data.
Payment methods
Credit cards, debit cards, digital wallets and BACS Direct Debit with mandate flow, in a multi-method architecture with admin-controlled activation per product.
Integration
Server-side Apex integration with the Stripe API using the Secret API key, webhook handlers for subscription events, bi-directional state synchronization.
BACS Direct Debit
Custom payment form for account details, embedded BACS Direct Debit mandate form, legal compliance built into the flow.
Automation
Automated renewal processing at the end of each subscription cycle, automated refund workflow on cancellation, error handling for declined payments and connection failures.
Security
Sensitive card and bank data isolated to Stripe-hosted components, encryption in transit, authentication best practices, PCI compliance scope minimization.
Testing & deployment
Stripe test environment validation across success and failure scenarios, controlled transition from test to live mode, monitoring of initial production transactions.
Working with iTechCloud
How the engagement actually ran.
Payment integration work carries a specific kind of risk: the failure modes are visible to customers, they involve real money, and the compliance obligations are non-negotiable. The way we structured this engagement reflected that risk profile: deliberate design, exhaustive testing, careful rollout.
Engagement model
Full-lifecycle integration delivered under a defined scope, followed by ongoing managed services to evolve the platform as new products and payment methods come onstream. The build moved through discovery, design, implementation, Stripe test environment validation and a controlled production rollout, each stage with explicit entry and exit criteria.
Team shape
The engagement was led by a solution architect with Salesforce and payment integration experience, supported by developers across Apex, Lightning Web Components and Stripe API integration, with QA throughout. CEO and Co-Founder Subhash Panchani sponsored the engagement and stayed personally involved through its critical phases, the founder-engaged model we apply to every major client engagement.
Testing and rollout
Payment integrations fail in interesting ways, and the only way to find the failures before customers do is to look for them systematically. We used Stripe's test environment extensively, running both successful and failed payment scenarios, validating subscription lifecycle events, and verifying how the integration handles edge cases: declined payments, failed subscriptions, connection errors. The transition from test to live mode was staged, with careful monitoring of real transactions during the initial production period.
