Stripe vs GoCardless vs PayPal for UK apps

If you are building an app in 2026, the Stripe vs GoCardless UK question arrives the moment you need to charge someone. It looks like a simple pick between payment providers, but it quietly sets your transaction fees, the kind of payments you can take, how much of the checkout you control, and how painful failed payments will be a year from now. The honest answer is that none of the three wins outright. Stripe, GoCardless, and PayPal each fit a different kind of app and a different way of getting paid, and this comparison unpacks all three on the dimensions that actually move money: fees, payment type, developer effort, and where each one costs you later.

Stripe vs GoCardless vs PayPal: the short answer

For most UK apps in 2026, Stripe is the sensible default because it handles card payments, subscriptions, and payouts through one developer-friendly platform. GoCardless is the better choice when your revenue is recurring and predictable, because it pulls payments straight from a customer’s bank by Direct Debit at a lower fee than cards. PayPal earns its place as an additional checkout button rather than your core processor, because a share of UK buyers trust it enough to convert when they would abandon a card form.

That is the skimmable version. The reasoning matters, because this choice shapes the percentage you lose on every sale, the failure rate on renewals, and how much engineering time your payments stack burns before launch.

What Stripe is, and when to pick it

Stripe is a developer-first payments platform that lets an app take card payments, store cards for later, run subscriptions, split payouts to other parties, and handle refunds and disputes through one set of well-documented APIs. For a mobile or web app that needs to charge cards and move money reliably, it is the closest thing the market has to a default.

The strategic reason to pick Stripe is coverage and control. It accepts the card networks UK customers actually use, supports Apple Pay and Google Pay, handles Strong Customer Authentication under UK rules so more payments clear on the first try, and gives your developers the tooling to build exactly the checkout you want. Its standard published rate for UK cards is 1.5% and 20p per successful charge, with higher rates for EEA and international cards, and you can confirm the current numbers on the official Stripe pricing page. Fees change, so treat that page as the source of truth rather than this paragraph.

Stripe suits marketplaces, subscription products, on-demand services, and any app where you want card payments plus the flexibility to grow into more complex flows. The trade-off is that it is a card-based processor, so on high-value recurring charges you pay a percentage every time, and that adds up in a way a fixed bank-collection fee does not. For a business built on monthly card subscriptions at scale, that percentage is the number to watch.

What GoCardless is, and when to pick it

GoCardless is a bank-to-bank payments platform built around Direct Debit, the UK system that lets a business pull an agreed amount straight from a customer’s bank account. Instead of charging a card each cycle, you set up a mandate once and collect on schedule. That single design choice is the whole pitch.

The strategic reason to pick GoCardless is cost and reliability on recurring revenue. Bank collections do not fail when a card expires or gets replaced, which removes one of the biggest causes of involuntary churn in subscription businesses. Its standard published pricing starts at 1% plus 20p per transaction with a per-payment cap, which on larger recurring amounts is meaningfully cheaper than a card percentage with no ceiling. The current figures live on the official GoCardless pricing page, and again, confirm them there before you model your margins.

GoCardless suits memberships, SaaS billed monthly or annually, subscription boxes, and any UK app where the same customer pays you repeatedly. The trade-off is speed and scope. Direct Debit is not instant, so it is wrong for one-off checkout where the customer expects to pay and receive immediately, and it does not give you a card-style buy-now moment. It is a collections engine, not a checkout button, which is exactly why it pairs well with a card processor rather than replacing one.

What PayPal is, and when to add it

PayPal is a digital wallet and payment processor that lets customers pay with a PayPal balance, a linked bank account, or a card, without re-entering card details on your site. In the UK it has something the others do not: a large base of consumers who already have an account and trust the brand at the moment of payment.

The strategic reason to offer PayPal is conversion, not cost. For consumer apps, some buyers will complete a PayPal checkout who would abandon a card form, either because they do not want to hand card details to a small brand or because paying is two taps instead of twelve. Its standard UK rate for online commercial transactions is around 2.9% plus a fixed fee, which you can check on PayPal’s official merchant fees page. That is higher than Stripe’s card rate, so PayPal usually earns its keep as an extra option rather than the default rail.

PayPal suits consumer-facing apps, one-off purchases, and any product where buyer trust at checkout is the bottleneck. The trade-off is fees and control. You pay more per transaction, the checkout experience partly lives inside PayPal rather than your app, and dispute handling follows PayPal’s process. For a business optimising purely on margin it is rarely the cheapest, but as a conversion lever alongside cards it often pays for itself.

Side-by-side comparison

Here is how the three compare on the dimensions that actually affect a UK founder’s decision. The fee figures are the standard published rates at the time of writing and should be confirmed on each provider’s own pricing page, because payment fees move and often depend on your volume and plan.

The pattern in that table is the whole decision in miniature. Stripe gives you flexible card payments and full control. GoCardless gives you cheap, reliable recurring collections but no instant checkout. PayPal gives you conversion from trust at a higher fee. Most apps do not choose one and reject the rest, which leads to the point founders most often miss.

The honest answer: most apps use two of these

Founders frame this as picking a single winner, and the strongest UK payments stacks usually are not built that way. A common and sensible setup is Stripe for card checkout and one-off payments, GoCardless for recurring Direct Debit on subscriptions where the amounts are large enough that card percentages hurt, and PayPal added as an extra button where consumer conversion matters. Each rail does the job it is best at, and you stop paying card fees on collections that do not need a card.

The reason this works is that the three tools solve different problems. Stripe is your general-purpose processor. GoCardless is your low-cost recurring-collections engine. PayPal is a trust-and-conversion add-on. Combining them costs a little more integration effort upfront and saves real money and churn over the life of the product. The right combination depends on whether your revenue is one-off or recurring, how price-sensitive your customers are, and how large each payment is.

The trap nobody warns you about: in-app purchases

One caveat matters more than any fee comparison, because getting it wrong can get your app removed. If you are selling digital content or subscriptions that are consumed inside an iOS or Android app, Apple and Google generally require you to use their own in-app purchase systems, which take a commission of up to 30%, reduced to 15% for many small businesses and for subscriptions after the first year. Stripe, GoCardless, and PayPal are for physical goods, real-world services, and payments outside that digital-goods rule, not for unlocking premium features inside the app itself.

This single distinction reshapes a lot of pricing decisions. Rules on what counts as digital goods, and when you may link out to external payment, have shifted and continue to be contested, so confirm the current position in Apple’s and Google’s own developer policies before you design your monetisation. Getting this right early is part of why understanding the full cost picture matters, which we broke down in how much an app costs to build in the UK in 2026. The payments rail is only one line in that budget, and choosing the wrong monetisation model is far more expensive than choosing the wrong processor.

What to do next

Choosing between Stripe, GoCardless, and PayPal matters less as a single verdict than as a fit to how your app actually earns. Default to Stripe if you need card payments and flexibility, which covers most products. Add GoCardless when your revenue is recurring and the amounts are large enough that a card percentage with no cap costs you real money. Offer PayPal when consumer trust at checkout is what stands between a browser and a buyer. And settle your in-app purchase position before you build, because that decision outweighs every fee on this page.

The right stack depends on your specific product, your customers, and whether you are billing once or forever, so it is a decision best made alongside the people who will build and run it. If you want an honest read on which payments setup fits your app, send us a project brief and we will tell you straight, including where a single provider is plenty and adding more would just cost you integration time. And if you are still deciding what to build the whole thing on, our comparison of Firebase vs Supabase vs a custom backend covers the infrastructure decision that usually sits right beside payments.