Best SaaS Payment Gateway? Choose the Model Before the Provider

01

The first payment is the easy part

Imagine a UK software company selling a £49 monthly plan. A customer selects a package, enters a card and sees a success screen. The team celebrates because billing is working.

Then the second month arrives.

One card needs extra authentication. Another has expired. A customer upgrades halfway through the month. A finance team wants an annual invoice and Direct Debit. An overseas buyer needs the correct tax treatment. A refund reaches the payment provider but not the product database.

Those are not edge cases. They are the real subscription service.

This is why asking for the best SaaS payment gateway can lead a business towards the wrong comparison. A gateway may move the money, but it does not necessarily manage plans, calculate tax, recover failed renewals or decide whether a customer should still have access to the product.

Choose the operating model first. The provider shortlist becomes much clearer afterwards.

02

Payment gateway has become an overloaded phrase

Businesses often use payment gateway to describe every part of online billing. In practice, several different layers may be involved.

A payment processor or gateway authorises and processes a transaction. A subscription billing system manages plans, invoices, renewals and changes. A bank payment provider collects money through schemes such as Bacs Direct Debit. A Merchant of Record becomes the seller for supported transactions and takes on defined responsibilities around payment, indirect tax and buyer support.

Some providers combine several layers. Others specialise in one. Chargebee, for example, explicitly describes itself as a billing platform that sits above payment gateways rather than being a gateway itself. That distinction matters when comparing a product such as Chargebee with a processor or Merchant of Record.

03

Start with how the business sells

Before comparing provider websites, write down the commercial model in ordinary language.

Is the product sold mainly to businesses or consumers? Is it a fixed monthly price, a per seat plan, usage based billing or a negotiated annual contract? Will customers pay in pounds only, or will the company sell internationally? Do buyers expect a self service checkout, a purchase order, an invoice or a Direct Debit mandate?

A young B2C SaaS product selling £12 monthly plans across several countries has a different problem from a UK B2B platform invoicing £18,000 each year. The first may value a Merchant of Record that simplifies supported cross border tax and checkout operations. The second may need flexible invoices, purchase orders, bank payments and reconciliation with the finance system.

• Customer type, including business, consumer or both.
• Countries, currencies and expected expansion markets.
• Monthly, annual, per seat, usage based or contract pricing.
• Cards, Direct Debit, bank transfer and invoice requirements.
• Trials, discounts, credits, refunds and mid-cycle changes.
• Who owns tax, payment support, disputes and reconciliation.

The right gateway is the one that fits the sale the business is actually making, including the awkward version of that sale.

04

Decide whether the business should remain the seller

A conventional processor normally leaves your company as the seller. The business keeps close control over the customer relationship, checkout and commercial terms. It also retains responsibility for the operating process around tax, invoices, refunds, disputes and customer records.

A Merchant of Record model changes that relationship. For eligible products and transactions, the provider becomes the seller and takes on responsibilities defined by its contract. Paddle, for example, describes a service that calculates, collects and remits applicable taxes for supported markets as Merchant of Record.

That can be valuable for a small team selling a digital product into several countries. It is not free outsourcing of every legal or commercial responsibility. Product eligibility, prohibited activities, settlement terms, refund handling, customer communication, data access and exit arrangements still need reviewing.

The trade-off is control against operational scope. Keeping control is useful when the business has the people and systems to operate it. Giving a provider more responsibility can be sensible when that work would otherwise distract a small product team or create avoidable compliance risk.

05

Cards and Direct Debit solve different jobs

Cards are familiar, quick to authorise and well suited to self service checkout. They also change over time. Cards expire, are replaced, hit limits and can require additional customer authentication.

Bacs Direct Debit can suit recurring UK payments, particularly for business customers and larger regular invoices. Once a mandate is in place, the business can collect agreed recurring or variable amounts without asking the customer to enter card details each time.

Direct Debit is not an instant card substitute. Collection and failure events are asynchronous, which means the application must cope with a payment being submitted, confirmed or later reported as failed. A SaaS product should not pretend that every payment method reaches a final answer at checkout.

Many businesses need both. Cards can support immediate self service activation while Direct Debit suits established customers, annual contracts or higher value recurring bills. The useful decision is the payment mix, not a contest in which one method has to win.

06

Failed payments need a product policy, not only a retry button

A good billing platform can retry recoverable card failures, ask for a new payment method and send payment reminders. Stripe Billing, for example, documents automatic retry rules and webhook events for failed invoices. Those tools are valuable, but the provider cannot decide the business policy on its own.

The product needs an agreed grace period. It needs rules for warning an account owner, limiting access, protecting stored data and restoring service after payment. Support needs to see what happened without asking a developer to inspect raw events.

Cancelling access immediately after one temporary failure creates unnecessary churn. Leaving unpaid accounts active forever creates a different problem. The right middle ground depends on the product, contract and customer relationship.

Design dunning as part of the customer experience. A clear message, a secure route to update payment details and sensible recovery can protect revenue without making a loyal customer feel accused of something dramatic because a card expired on a Sunday.

07

The success page must not control access

The browser returning from checkout is not reliable proof that the subscription is paid and active. The customer can close the tab, the network can fail and some payment methods complete later.

Use signed server to server events from the provider. Store each event identifier, process it once and update an internal subscription record. The product should then grant or remove entitlements according to explicit rules.

This processing must be idempotent, which means receiving the same event twice produces the same safe result. It should also tolerate events arriving later than expected or in an unusual order. Payment systems retry webhooks because real networks fail. The application should treat that behaviour as normal rather than exceptional.

• Verify every webhook signature before processing the event.
• Store the provider event ID and prevent duplicate processing.
• Keep product entitlements in the application rather than scattering provider checks across every page.
• Log state changes with enough context for support and reconciliation.
• Provide a controlled retry route for events that fail internally.

Keep a visible event history and reconciliation route. Finance should be able to connect customers, invoices, payments, refunds and settlements. Support should be able to explain the account state. Engineering should be able to replay a failed event without editing the database by hand.

08

Outsourcing checkout reduces PCI scope, not responsibility

A hosted checkout or provider controlled payment form can keep sensitive card details away from the application and reduce the amount of payment card security work the business must perform.

The PCI Security Standards Council makes the boundary clear. Eligibility for the simplest outsourced ecommerce assessment depends on every payment page element coming from a compliant provider and on the merchant meeting the other criteria. A business still needs to confirm the provider is validated and protect its own website, accounts, scripts and integration.

UK Strong Customer Authentication rules can also affect online payment journeys. The Financial Conduct Authority explains that authentication is normally required for payer initiated electronic payments unless an exemption applies. Recurring transactions, saved cards and exemptions need testing with realistic customer journeys rather than assumed from a happy path demonstration.

Security is therefore part of provider selection, but it is also part of implementation. Hosted payment details do not compensate for a compromised admin account, a leaked API key or a webhook endpoint that trusts unsigned requests.

09

Compare the whole operating cost

The advertised transaction percentage is only one line in the cost model.

Add subscription billing fees, Merchant of Record charges, currency conversion, payout costs, chargebacks, refunds, tax tooling, implementation work and ongoing support. Include the finance time needed to reconcile settlements and the engineering time needed to investigate failures.

Then model the real mix of transactions. A fixed fee behaves very differently on a £7 plan and a £700 invoice. International cards can cost more than domestic ones. A provider that appears expensive may remove tax or support work that the business would otherwise need to fund. A cheap processor can become expensive if the surrounding operation is fragile.

Pricing changes, so treat published rates as inputs to verify when the shortlist is ready. The more durable comparison is who owns each responsibility and what it costs the business to operate that responsibility well.

10

Build a shortlist by model

A useful shortlist groups providers by the job they perform. It does not put every payment related product into one league table.

The examples below are starting points rather than endorsements. Provider eligibility, countries, payment methods, contracts, current pricing and technical limits must be checked against the real product.

11

Prove the awkward cases before signing

A polished checkout demonstration proves very little about subscription operations.

Build a small proof of concept and run the events that create support tickets later. Test a first payment requiring authentication, a renewal failure, an expired card, a failed Direct Debit, a plan upgrade, a seat reduction, an annual invoice, a partial refund, a chargeback, cancellation and reactivation.

Replay a webhook. Deliver two copies of the same event. Send events out of order. Disconnect the finance export. Confirm that the product reaches the correct state and that somebody can understand why.

Also test the exit. Confirm which customer, mandate, subscription, invoice and event data can be exported. Migrating a live subscription base can be difficult, but a clean internal billing boundary and accessible records make it far less dangerous.

Return to the £49 SaaS product. The best payment setup is not the one that processed the first card in the shortest demo. It is the one whose responsibilities fit the business, whose failure states the team can operate and whose events keep the product and finance records correct month after month.

If you are choosing or replacing a SaaS payment setup, I can help map the commercial responsibilities, model the integration and prove the difficult subscription events before the decision becomes expensive to reverse.