Move billing from in-house to Stripe
PublicCreated 11 Dec 2025
Reduce billing drop-off and incidents, make pricing/checkout changes safer and faster, and stop burning engineering time on our home-grown billing stack. We’ve been running our own billing for years. It’s tightly coupled to the monolith, painful to change, and every pricing tweak turns into a mini project. Support keeps flagging failed payments, and funnel data suggests we’re leaking revenue at the billing step.
Summary
The initial problem was a high drop-off rate during the billing step of the checkout process, leading to significant revenue loss and increased support workload. Analysis revealed that the in-house billing system was a bottleneck due to its complexity and lack of ownership, prompting the exploration of alternative solutions. After evaluating options, the team decided to migrate to Stripe due to its robust self-serve tooling and the team's prior experience with it. The migration began with new EU customers, using Stripe Payment Elements, which led to a notable reduction in billing drop-off and support tickets. Encouraged by these results, the rollout was expanded globally for new customers, resulting in a 9-point increase in billing conversion and an estimated revenue uplift of £45–60k per month. The project now plans to migrate existing subscriptions to Stripe, aiming for the deprecation of the in-house system once most subscriptions are transferred.
Story Tracks
Customers are dropping in the billing step
Learning•11 Dec 2025
Funnel analysis shows a ~21% drop-off between Review order and Enter card details – noticeably worse than any other step. Session replays show people re-typing card details, hitting vague “payment failed” errors, and abandoning.
Support tickets mentioning “card declined / payment didn’t go through” are up ~30% QoQ.
At current volume this drop-off is roughly £80–100k / month in lost bookings, plus support load.
Tags (3):
billing
checkout
funnel
Quick copy + error message tweaks (didn’t move the needle)
Change•11 Dec 2025
Before touching billing tech, we tried a low-effort change:
- Clarified “Your card was declined” to more specific messages.
- Added reassurance copy around security and accepted cards.
- Tweaked CTA from “Pay now” to “Complete payment”.
Two-week A/B test showed no meaningful change in billing completion. Confirms the issue isn’t just wording; points to deeper problems with the billing flow / tech.
Tags (3):
experiment
copy
noimpact
In-house billing is a change bottleneck
Learning•11 Dec 2025
Engineering spike uncovering the current state:
- Custom card form + validation coupled to legacy code.
- Single gateway integration with flaky error handling.
- No owner; billing changes are a “favour” from whoever has time.
- Adding new payment methods is weeks of work + risky deploys.
Every pricing experiment, payment method, or checkout improvement is blocked on the same fragile stack and a couple of engineers.
Tags (3):
techdebt
billing
risk
Stripe vs Adyen vs staying in-house
Choice•11 Dec 2025
We compared three paths:
- Refactor in-house over 6–12 months.
- Move to Stripe (Payment Elements + Billing).
- Move to Adyen and use their checkout SDK.
Key factors:
- Both vendors support our markets; Stripe has better self-serve tooling for retries/dunning.
- Team has prior Stripe experience; none with Adyen.
- Stripe offers a phased rollout (elements first, then subscriptions).
- Engineering effort for “refactor in-house” is high with unclear end state.
Decision:
Take a phased migration to Stripe, starting with new customers.
Tags (3):
vendor selection
stripe
build vs buy
Stripe Elements behind a feature flag for new EU sign-ups
Change•11 Dec 2025
First step of the migration:
- Replaced the legacy card form with Stripe Payment Elements for new EU customers only.
- Removed redundant fields (card nickname, extra address line).
- Enabled Stripe’s real-time validation and 3DS where required.
- Wrapped the whole thing in a feature flag so we can dial traffic back.
Rolled out to 5% of new EU sign-ups for 48 hours, then 100% EU once metrics looked stable.
Tags (3):
change
checkout
stripe
Early numbers: billing drop-off down, tickets down
Result•11 Dec 2025
Two weeks after the EU rollout:
- Billing step drop-off improved by ~7 percentage points vs control.
- “Card declined / payment failed” support tickets for EU new sign-ups are down ~25%.
- No Stripe-related incidents; on-call reports have been quiet.
Tags (3):
support reduction
conversion uplift
result
Roll out Stripe checkout to all new customers
Change•11 Dec 2025
Based on the EU results, we:
- Switched all new sign-ups globally to the Stripe checkout.
- Left existing subscriptions on the old system but synced key data nightly for support.
- Assigned ownership of the Stripe integration to the Payments squad with a clear incident runbook.
Tags (3):
rollout
ownership
operations
Stripe becomes the default, we plan subscription migration
Result•11 Dec 2025
A month into global rollout:
- New-customer billing conversion is +9 pts vs pre-Stripe baseline.
- Estimated revenue uplift £45–60k / month for the migrated cohort.
- Support time on billing issues continues to trend down.
Based on this, we agreed to:
- Plan migration of existing subscriptions to Stripe over the next two quarters.
- Target deprecation of the in-house billing path once 90%+ of active subscriptions are on Stripe.
Tags (3):
results
roadmap
deprecation
This story was shared publicly. Only people with this link can view it.