The case for buying, not building: why Stripe Connect powers Givr

The £5,000 question that wasn't about money

The real cost of building your own payment rails isn't the engineering time. It's the regulatory overhead, the compliance audits, the insurance, the technical support for edge cases you haven't hit yet, and the existential risk of a single misconfiguration affecting 200 churches' giving on a Sunday morning.

When you're building software for UK churches, the stakes feel different. These organisations aren't using Givr because they love fintech. They're using it because their treasurer is tired of chasing Gift Aid forms by hand, and they need something that works on the Sunday they decide to launch it. That's not a market that forgives payment processing errors.

Stripe Connect Express meant we could onboard a church in under five minutes without requiring an FCA licence ourselves. That's not a shortcut; that's the whole point. Stripe handles the regulated entity status. We handle the church experience.

What we actually needed to build

The moment we decided to use Stripe Connect, the scope of our work shrank and sharpened. We weren't building payment rails. We were building the Gift Aid claim engine.

That's a very different problem. Gift Aid requires understanding HMRC's Charities Online portal, the GASDS small donation scheme, the exact data structure HMRC expects, the audit trail every claim needs, and the calendar logic around tax years. We built custom submission workflows, error handling for HMRC rejections, and retry logic for when Charities Online is temporarily unavailable (which happens). We built donor declaration capture that works in 15 seconds on a mobile browser. We built a dashboard where church treasurers can see exactly what's been claimed, what's pending, and where the money is coming from.

None of that would have been easier if we owned the payment processing layer. In fact, it would have been harder. Every hour spent debugging Stripe's API interactions or handling PCI compliance was an hour not spent on the Gift Aid logic that actually matters to our users.

The independence paradox

There's a narrative in software that using a third-party payment provider locks you in, limits you, makes you dependent. We found the opposite to be true.

By using Stripe Connect Express, we're not locked into Stripe's vision of church giving. We're freed from having to be payment infrastructure experts. A church can onboard through Givr's interface in minutes. They scan a QR code. They give. That's it. We didn't have to invent onboarding flows or explain merchant accounts or deal with underwriting delays. Stripe handles all of it. We handle the experience.

And if we ever need to change payment processors in the future, the architecture is abstracted enough that we could. Stripe Connect isn't our product; it's the rails our product runs on. We're not marrying Stripe; we're using a tool built for this exact purpose.

The real conversation in month four

I remember the conversation with our CTO that settled it. We were three weeks from private beta. One of our test churches had submitted a Gift Aid claim, and the HMRC integration had returned an error we hadn't anticipated. The error was specific to how HMRC wanted donation reference numbers formatted in their submission file.

Our CTO said something like: 'We just fixed a compliance bug that would have cost us six weeks if we owned payment processing. We'd still be debugging that while Stripe's customer would have had the same bug two years ago.' It stuck because it was true. By using Stripe, we weren't building infrastructure in isolation. We were building on top of infrastructure that processes billions in payments and has to be right.

The church treasurer who tested that QR code never saw the HMRC error. They saw a claim that worked. That's the product.

What you actually own when you choose to focus

We own the Gift Aid claim submission logic. We own the QR code user experience. We own the dashboard church treasurers use every month. We own the relationship with HMRC's Charities Online portal and the GASDS scheme documentation. We own the support conversations when something goes wrong.

We don't own PCI compliance or merchant underwriting or payment processing infrastructure. We don't have to. Stripe does, better than we ever could.

The irony is that not building payment rails made Givr better, not worse. We shipped faster. We had fewer regulatory dependencies. And when we onboard a new church now, the only thing they need to do is verify their Stripe account. Stripe handles the rest.

A platform that claims to own everything is often a platform that owns nothing well.