Stripe integration UK: tax, GBP, and edge cases

Most guides to Stripe integration UK founders find online stop at the happy path: create a payment, take the card, show a success page. That part is genuinely easy now, and it is not where projects go wrong. What goes wrong is everything around it. Tax that was never modelled, currency settlement that quietly loses money, cards that get declined because Strong Customer Authentication was never handled, and orders that silently never get fulfilled because the customer closed the tab. This guide walks through the parts that actually matter for a UK business, in the order we work through them on a real build.

What makes a Stripe integration UK-specific?

A Stripe integration UK businesses run differs from a generic one in four places: VAT has to be calculated and recorded correctly, prices and payouts should settle in GBP rather than being converted twice, UK and European cards require Strong Customer Authentication so the payment flow has to support a challenge step, and if you sell digital goods inside a mobile app the platform rules may forbid Stripe entirely.

Everything else is the same as anywhere. Those four are the ones that create rework if you discover them late, which is why they belong at the start of the build rather than in the week before launch.

Step zero: check you are allowed to use Stripe

Before any of the technical work, answer one question: is what you are selling digital content consumed inside an iOS or Android app? If it is, Apple and Google generally require their own in-app purchase systems, and a Stripe checkout inside the app can get your submission rejected or your app pulled. Physical goods, real-world services, bookings, and most business-to-business software fall outside that rule and can use Stripe normally.

This distinction reshapes pricing more than any fee comparison, because platform commission is an order of magnitude larger than card fees. The rules on what counts as digital goods, and when you may link out to an external payment page, have shifted more than once and remain contested in several jurisdictions, so read Apple’s and Google’s current developer policies yourself rather than trusting a blog post. We wrote about the wider monetisation decision in how to price an app subscription in the UK, and it is worth settling before you build.

Getting GBP settlement right

If you are a UK company selling to UK customers, you want prices displayed in pounds and money arriving in pounds, with no conversion in between. That sounds obvious, and it still gets missed, usually when an account was set up quickly under a different entity or with a non-GBP default currency. The result is a conversion fee on every single transaction, which is small enough to ignore individually and material across a year.

The setup itself is straightforward. Register the account to the UK entity, connect a GBP business bank account, and set your default presentment currency to GBP so the amounts your customers see are the amounts they are charged. It gets more interesting when you sell abroad. If you want a customer in Germany to see euros, you are choosing to present in one currency and settle in another, and Stripe charges for that conversion. That can still be the right call, because local pricing converts better, but it should be a deliberate decision with a number attached rather than an accident. Confirm the current conversion and cross-border rates on the official Stripe pricing page, because payment pricing moves and any figure written here will age.

VAT and tax: the part people postpone

Tax is the single most common thing we see bolted on late, and it is the most painful to retrofit. The core question is whether the price your customer sees includes VAT or has it added at checkout, because that decision propagates into your database, your receipts, your accounting export, and your refund logic. Change it after launch and you are rewriting all of them.

For a UK business selling to UK consumers, the standard VAT rate is 20%, with reduced and zero rates for specific categories, and businesses must register once their taxable turnover passes the current registration threshold. Both the threshold and the category rules change, so check the current position on the official HMRC VAT guidance rather than relying on a number in an article. If you are below the threshold and not registered, you do not charge VAT, and your checkout still needs to be built so that adding it later is a configuration change rather than a rebuild.

Selling across borders adds a second layer, because digital services sold to consumers in the EU are generally taxed where the customer is, not where you are. That means detecting location, applying the right rate, and reporting it. Stripe sells an automated tax product that handles much of this calculation, and for a small team it is usually cheaper than building the logic and maintaining the rate tables yourself. What no product does is file your returns or decide your registration obligations, so this is the point in the build where we tell founders to spend an hour with an accountant. It is the cheapest hour in the project.

Strong Customer Authentication is not optional

UK and European card payments are subject to Strong Customer Authentication, which means many transactions require the customer to confirm their identity with their bank, usually through an app prompt or a code. If your integration does not support that challenge step, the affected payments simply fail, and you will see a decline rate that looks like fraud filtering but is actually your own checkout.

The practical guidance is short. Use a modern Stripe integration path that handles authentication natively rather than assembling the flow yourself, keep the customer inside a UI that can display the bank’s challenge, and treat a required authentication as a normal outcome rather than an error state. Then test it. Stripe provides test cards that force an authentication challenge, and running those before launch is the difference between finding this in staging and finding it in your first week of revenue.

Webhooks are the source of truth

Here is the edge case that costs the most money and gets caught the latest. A customer pays successfully, and then their browser closes, their phone loses signal, or they navigate away before the redirect back to your app completes. If your code grants access or triggers fulfilment on that redirect, this customer has paid and received nothing, and you will not find out until they email you.

The fix is to treat Stripe’s webhook events as the authoritative record of what happened. Stripe sends an event to an endpoint you control when a payment succeeds, and it retries if your endpoint is down, so the message arrives even when the customer’s browser did not. Verify the event signature so nobody can forge one, make your handler idempotent so a retried event does not create two orders, and do the actual work of fulfilment there. The redirect page is then just a nice confirmation screen rather than a load-bearing part of your payment system.

The edge cases we test before every launch

Six failure paths generate most of the support tickets, and all of them can be forced in test mode before you go live. The card that declines for insufficient funds, because your error message needs to tell the customer something more useful than “payment failed”. The expired or wrong-CVC card, for the same reason. The authentication challenge the customer abandons halfway, which should leave no partial order behind.

Then the ones that are less obvious. The double submission, where an impatient customer clicks pay twice and you need idempotency to stop two charges. The refund, partial and full, which has to update whatever access or entitlement the payment granted, not just move money back. And for anything recurring, the failed renewal, where a card expires eleven months into a subscription and you need a retry and reminder sequence rather than a silent cancellation. Each of these is an hour of testing that saves a week of support, which is roughly the same argument we make about scope in how to scope an app project.

What this costs and when to get help

Wiring in a simple one-off checkout with the tax decision made and webhooks handled properly is a small piece of work. Full subscription billing with proration, dunning, and entitlement logic is a system, and we broke the numbers down in how much it costs to add Stripe payments to a UK app. If you are still choosing a processor rather than integrating one, the comparison in Stripe vs GoCardless vs PayPal for UK apps covers where each one wins.

The short version of all of it: decide the platform rules and the tax model before you write code, settle in the currency you bank in, build authentication in from the start, and let webhooks rather than browser redirects decide that a customer has paid. If you want a second pair of eyes on a payments build before it goes live, send us a project brief and we will tell you what we would change.