Payment Gateways: What Your Build Actually Needs
A checkout can look finished long before it is ready to take money reliably. The real work behind payment gateways sits in the less visible details: customer authentication, subscription changes, failed payments, refunds, invoices, tax handling and the events your product receives after a transaction. For a brochure site selling a handful of services, the answer may be straightforward. For a SaaS product, marketplace or customer portal, payment architecture becomes part of the product itself.
Choosing a provider is therefore not just a question of transaction fees or adding a payment button. It is a decision about how your business bills, supports customers and grows without creating avoidable manual work.
What payment gateways actually do
A payment gateway is the service that securely passes card or wallet payment details between your website, the customer’s bank and the payment processor. In practical terms, it gives your product a way to create checkout sessions, confirm payments and react when money has been successfully collected.
Most modern providers also cover far more than a basic card form. They may support Apple Pay and Google Pay, recurring subscriptions, direct debits, saved payment methods, invoices, refunds, dispute handling and fraud checks. This is why a gateway often becomes a central integration in a web app rather than a small feature added at the end.
For many UK businesses, Stripe is a sensible starting point because its APIs, hosted checkout options and subscription tooling are well suited to custom websites and SaaS products. That does not make it the automatic choice for every build. If your business already relies on a particular accounting platform, sells through several channels, needs specific local payment methods, or operates in a regulated sector, the right setup may be different.
Start with the billing model, not the provider
Before comparing payment gateways, map out how customers will actually pay. A one-off payment for a fixed service has very different requirements from a product with monthly plans, usage-based billing or team seats.
A simple paid consultation or digital product may only need a hosted checkout page and a confirmation email. Hosted checkout reduces the amount of sensitive payment handling on your own site and can be quicker to launch. It is often the right call when conversion and reliability matter more than controlling every pixel of the payment form.
A SaaS product needs more planning. Consider what happens when a customer upgrades halfway through a billing period, changes from monthly to annual billing, cancels but retains access until the end of the month, or fails to pay after a card expires. Those rules should be agreed before development starts. Otherwise, billing behaviour ends up scattered across application code, provider settings and support inboxes.
Usage-based billing needs another layer of care. If a customer is charged for API calls, reports generated, seats used or credits consumed, the product needs an accurate source of truth for usage. The gateway can calculate charges, but it cannot tell whether your app measured activity correctly.
The integration is more than the checkout screen
A common mistake is treating a completed checkout page as proof that payments are integrated. A customer can complete a payment in their browser while your application never receives the final confirmation. Networks fail, browser tabs close and payment methods may take time to settle.
This is why webhooks matter. A webhook is a signed notification sent from the payment provider to your server when something changes, such as a successful payment, failed renewal, refund or subscription cancellation. Your backend should verify the event, record it safely and update the customer’s access or order status.
For a membership product, a successful subscription webhook might activate a user’s account and store their plan details. A failed payment event might begin a grace period, send the right notification and eventually pause access if the account remains unpaid. For an online shop, payment confirmation should trigger fulfilment only after the trusted server-side event arrives.
Webhooks must also be built to handle duplicate delivery. Providers may resend an event if your server does not acknowledge it quickly enough. Good implementation uses event IDs and idempotent processing, meaning the same event can arrive twice without creating duplicate orders, emails or account changes.
Keep customer access separate from payment status
Payment data and product permissions are related, but they should not be the same thing. A gateway knows whether an invoice was paid. Your application needs to know what the customer can access, for how long and under which conditions.
This separation makes awkward cases manageable. A business may offer a manual extension while a customer resolves a payment issue, grant complimentary access to a partner, or restrict one feature while retaining another. If access is controlled only by a single payment field, these normal operational decisions become harder than they should be.
A production-grade setup usually stores the provider’s customer and subscription IDs alongside its own user and organisation records. It also maintains a clear internal entitlement model. That gives the app a dependable record of who has access, while the gateway remains the source of truth for transactions and billing events.
Security and compliance without unnecessary scope
You should never send raw card details through your own server unless there is a compelling reason and the compliance work has been properly scoped. Hosted checkout pages and provider-hosted payment fields keep card data away from most of your infrastructure. That reduces risk and limits the burden of PCI DSS compliance.
Security still needs attention elsewhere. API keys belong in environment variables, not frontend code or a public repository. Webhook signatures must be checked. Admin actions such as refunds should be restricted and logged. Customer portals should require appropriate authentication, especially where invoices, payment methods and business billing details are available.
For UK and European customers, Strong Customer Authentication can introduce extra steps during a payment. A properly integrated gateway handles the authentication flow, but the product still needs to account for payments that require customer action or remain incomplete. Treating every created subscription as active is an easy way to give access before payment is confirmed.
Fees matter, but failed payments cost more
Transaction fees are visible and easy to compare. The larger cost often appears later in lost renewals, support time and messy reconciliation. A provider with a slightly higher fee can be worthwhile if it offers better subscription recovery, invoicing, reporting or payment methods that suit your audience.
Consider the complete operating picture: currencies, payout timing, refund workflow, chargeback visibility, accounting exports, customer receipts and the effort needed to answer a billing query. A founder should be able to find out why a payment failed or whether an invoice was refunded without asking a developer to inspect logs.
For businesses selling internationally, exchange rates and local payment preferences deserve early attention. Cards may be enough for one market, while another responds better to bank payments or digital wallets. Adding every possible method is not always useful. It can increase testing and support requirements, so prioritise the methods your customers are likely to use.
Test the awkward scenarios before go-live
A payment integration needs more than a successful test transaction. The less glamorous scenarios are where customer trust is won or lost. Test them in a staging environment and document the expected behaviour for the people who will support the product.
Useful tests include a declined card, an expired card on renewal, a payment requiring authentication, a cancelled checkout, duplicate webhook delivery, a partial refund, a full refund and a subscription upgrade or downgrade. If you offer trials, test the moment a trial ends. If accounts belong to teams, test what happens when the paying owner leaves or changes their email address.
It is also worth checking the emails generated by both your product and the provider. Customers should not receive conflicting messages about whether they have paid, lost access or been refunded. Clear billing communication prevents a surprising amount of support work.
Build for operational clarity
The strongest payment setup is not necessarily the most customised one. It is the one that matches the business model, handles real-world exceptions and gives the team clear answers when a customer gets in touch.
For a fast marketing site, that may mean a hosted payment page connected to a simple order flow. For a SaaS platform, it may mean a considered Stripe integration, webhooks, subscription management, a billing portal and reliable entitlement logic built into the app from day one. Zak Furness builds these systems end to end, from the customer-facing flow through to the backend events and operational tooling behind it.
Start by writing down the payment moments your business must handle: first purchase, renewal, failed charge, cancellation, refund and support request. Once those are clear, the right gateway and integration approach become much easier to choose.