Choosing a payment setup for a UK business
The provider comparison you find online is usually about headline rates. The things that actually cause problems are payouts, disputes and how hard it is to leave.
Rates are the least interesting difference
Published rates across mainstream providers sit close enough that for most businesses the difference is not what decides it. What decides it is how the provider behaves when something goes wrong, and how much of your business is trapped inside it.
Ask instead: how quickly do funds settle, what happens when a customer disputes a charge, and what does leaving look like.
Payout timing is a cash-flow decision
Money taken today is not money you have today. Standard settlement is commonly two to seven working days, and new accounts are frequently held longer while the provider assesses risk. For a business with stock to reorder or contractors to pay, that gap is the whole question.
It is also not fixed. A sudden spike in volume — a good campaign, a viral post — can trigger a review and a hold, precisely when the cash is most needed. Worth knowing before it happens rather than during.
Disputes and chargebacks
A chargeback removes the money and adds a fee, usually before anyone reviews your side. You then submit evidence and wait, often weeks. Providers differ substantially in how much of this they automate and how clearly they tell you what evidence helps.
What you can control is the evidence you keep: delivery confirmation, the customer's IP and the address used, a record of what was agreed, and clear billing descriptors so the charge is recognisable on a statement. A large share of disputes are simply customers not recognising the name on their statement, which is a fixable problem.
SCA is not optional and affects conversion
Strong Customer Authentication applies to UK and European card payments, and additional verification will be requested on a meaningful share of transactions. Implemented well it is a brief step. Implemented poorly it drops customers at the final moment, and it will do so silently — the customer just disappears.
This is a real argument for a provider with a mature, well-tested payment flow rather than a hand-rolled integration. Payment UX is one of the few places where using the provider's component is usually better than building your own.
Lock-in, and the question to ask early
Card details are stored by your provider, not by you. If you later want to move, those stored cards are the obstacle — particularly for subscriptions, where re-asking every customer for their card means losing some of them.
The major providers will migrate stored credentials to another PCI-compliant provider on request, but the process takes time and is easier to start before you need it. Ask about it when you sign up, not when you are leaving.
A reasonable default
For most UK businesses selling online, a mainstream provider with a well-supported integration covers it, with PayPal offered alongside because a segment of customers will only use PayPal. Direct acquiring becomes worth the additional complexity at higher volume, where a fraction of a percent is real money.
Whatever you choose, handle webhooks properly. Payment confirmation must come from the provider's server-to-server callback, verified and idempotent — never from the browser redirect alone. Trusting the redirect is the most common serious payment bug, and it is exploitable.
Common questions
Should I use more than one provider?
Offering PayPal alongside cards is common because some customers will not use anything else. Running two full card providers adds reconciliation work and is usually only worth it for redundancy at scale.
How do I stop double-charging on webhooks?
Make webhook handling idempotent. Record the provider's event ID and ignore repeats. Providers retry deliberately, so the same event will arrive more than once by design.
Can I take payments without storing card details?
Yes, and you should. Use the provider's hosted fields or checkout so card data never touches your server. This removes most of your PCI scope and most of your risk.
Need this done properly?
Describe the problem in plain language and I’ll tell you what it actually needs — including if that is less work than you expected.