UK businesses have access to one of the world's most sophisticated payment infrastructures, covering real-time bank transfers, card schemes, Open Banking-powered payments, and direct debit. Choosing the right payment systems and integrating them effectively into your software stack is a decision that affects cost, customer experience, fraud risk, and regulatory compliance simultaneously. Getting it right creates a competitive advantage; getting it wrong creates friction that drives customers to competitors and creates liability under increasingly demanding PSR and FCA rules.
The UK interbank payment systems are operated by Pay.UK (which runs Faster Payments and Bacs), the Bank of England (which operates CHAPS), and the card schemes (Visa, Mastercard, American Express). Open Banking, overseen by the Open Banking Implementation Entity (OBIE) with FCA backstop authority, adds a fourth layer that is reshaping the competitive dynamics of both consumer and business payments. Understanding how these systems work, how they interconnect, and what they cost is essential context for any payment integration decision.
Softomate Solutions delivers payment system integrations for UK businesses, from e-commerce platforms integrating multiple payment methods to financial services firms connecting to bank payment rails directly. This guide covers the main UK payment systems, their technical integration requirements, and the regulatory obligations firms must address.
The Faster Payments Service (FPS) is the UK's real-time credit transfer system, processing bank-to-bank transfers of up to ยฃ1 million in seconds, 24 hours a day, seven days a week, 365 days a year. Launched in 2008, it now processes more than four billion transactions per year, making it the backbone of UK retail and SME payments. For businesses, Faster Payments is the mechanism behind same-day supplier payments, instant payroll, instant refunds, and Open Banking payment initiations.
Direct participation in Faster Payments requires Bank of England settlement account access and technical connection to Pay.UK's central infrastructure. This is only viable for large banks and specialist payment institutions. The vast majority of UK businesses access Faster Payments indirectly, through one of three routes:
Our API development and system integration team has connected UK businesses to Faster Payments via all three routes. The right choice depends on your transaction volumes, latency requirements, regulatory status, and pricing tolerance.
Open Banking payment initiation, delivered through the PIS (Payment Initiation Service) framework regulated by the FCA under the Payment Services Regulations 2017 (which implemented PSD2 into UK law), lets a business instruct a bank to transfer money from a customer's account to the business's account without the customer ever leaving the business's interface to log into online banking. The customer authenticates with their bank through a redirect or embedded consent flow, and the payment is then pushed by the bank over Faster Payments within seconds.
The differences from a standard bank transfer or card payment are significant:
For UK businesses considering Open Banking payment initiation, the highest-value starting points are bill payment (insurance premiums, utilities, subscription renewals), B2B payments where card acceptance is not expected, and any context where instant settlement matters more than a frictionless checkout.
Bacs Direct Debit is the UK's scheme for pulling recurring payments from customer bank accounts. It is the mechanism behind most UK standing orders and direct debits for subscriptions, insurance premiums, mortgage payments, and B2B invoice collection. Bacs processes approximately 4.5 billion transactions per year, with the vast majority being regular recurring amounts.
Direct Debit operates on a three-day cycle: a payment instruction submitted on day one is processed on day three. This makes it unsuitable for contexts requiring instant confirmation of payment, but it is highly reliable (failure rates well below 1 percent for established recurring mandates) and low cost (typically 2p to 20p per transaction, depending on volume and provider).
Collecting Direct Debit requires either direct Bacs sponsorship (available to large organisations with sufficient volume) or using a Bacs-approved bureau service such as GoCardless, Bottomline, or Elavon. GoCardless has become the dominant choice for UK software businesses and SaaS companies due to its developer-friendly API, webhook-based payment status notifications, and variable payment support (enabling amounts to vary between billing periods without restarting the mandate).
The FCA's Consumer Duty has added focus on how businesses inform customers about Direct Debit collections, particularly variable amount collections. Pre-notification requirements (informing customers at least ten working days before a variable collection, or a shorter agreed period) must be built into payment communication workflows. Our financial services software development practice builds Direct Debit collection workflows with the communication templates and notification timing built in from the start.
Most UK businesses need to support more than one payment method: cards for immediate e-commerce purchases, Open Banking for high-value or cost-sensitive payments, Direct Debit for recurring billing. Integrating each payment method independently creates maintenance complexity, inconsistent reconciliation, and difficulty producing the unified reporting that finance teams need.
The best architecture for multi-payment integration uses a payment abstraction layer: a single internal API through which all payment operations flow, regardless of the underlying payment method or provider. External provider integrations (Stripe for cards, GoCardless for Direct Debit, TrueLayer for Open Banking) sit behind this abstraction layer as pluggable adapters. Business logic (reconciliation, refund workflows, reporting) interacts only with the abstraction layer, not with individual providers.
Key benefits of this approach include:
Our API development and system integration service designs and builds payment abstraction layers for UK businesses, covering card, bank transfer, Open Banking, and Direct Debit in a single coherent architecture.
Payment integration is one of the most regulated areas of UK financial technology. The applicable requirements depend on whether the business is a regulated payment service provider or a merchant accepting payments.
For merchants (businesses accepting payments for goods and services):
For businesses that provide payment services to others (payment institutions, e-money institutions, account information service providers, payment initiation service providers), FCA authorisation is required, and the full FCA Handbook regulatory framework applies, including capital requirements, safeguarding of client funds, fraud reporting obligations, and operational resilience requirements.
Payment reconciliation, matching payments received against expected amounts and allocating them to the correct invoices or accounts, is a process that many UK businesses underestimate until the volume grows to the point where manual reconciliation becomes unworkable. For businesses that accept payments across multiple channels (cards, bank transfer, Direct Debit, Open Banking), reconciliation complexity multiplies quickly, and errors in reconciliation create both accounting problems and potential FCA regulatory reporting issues for regulated firms.
The fundamental challenge is that each payment system has its own settlement timing, its own transaction identifier format, and its own way of reporting failed or returned payments. Stripe settles card payments on a T+2 basis (two business days after the transaction date), with its own payout identifier distinct from the card network transaction reference. GoCardless Direct Debit payments settle on a three-day Bacs cycle, with separate identifiers for the mandate, the payment, and the payout. Faster Payments settle in seconds but the payment reference provided by the sender (which should match an invoice number or account identifier) is a free-text field that humans fill in inconsistently. Open Banking-initiated payments inherit the Faster Payments settlement timing and reference quality issues.
Automated reconciliation systems address this by using deterministic identifiers assigned at the point of payment initiation, not relying on payer-supplied references. For card and Open Banking payments, the business assigns a unique payment reference that becomes the payment identifier throughout the lifecycle. For Direct Debit, the GoCardless payment ID provides a stable reference. For inbound Faster Payments where the payer controls the reference, fuzzy matching algorithms (matching on amount and expected payment date windows) can automate a high proportion of allocations, with the remainder going to a manual exception queue.
From a regulatory perspective, FCA-authorised payment firms must maintain accurate transaction records and be able to reconcile client money held in safeguarded accounts against individual client balances at any point in time. The Client Money Sourcebook (CASS 5/7/15) sets specific reconciliation frequency requirements (daily for most client money) and requires a documented reconciliation process and evidence trail. Automated reconciliation is not just an operational efficiency in this context; it is a regulatory obligation. Our API development and system integration service builds reconciliation pipelines that satisfy both operational efficiency and FCA evidencing requirements from a single implementation.
For UK businesses below the FCA-regulated threshold, the business case for automated reconciliation is purely operational. A 10,000-transaction-per-month business spending one hour per day on manual reconciliation is spending roughly 22 staff hours per month on a process that a well-built automated system can reduce to less than one hour of exception review. At a conservative fully-loaded staff cost of ยฃ35 per hour, the saving funds a significant reconciliation automation investment within twelve months.
Simply accepting payments for goods and services you provide does not require FCA authorisation. You are a merchant, not a payment service provider. FCA authorisation is required if you are providing payment services to others (holding or moving their money), operating as an e-money issuer, or offering account information or payment initiation services. If you are unsure whether your business model requires FCA authorisation, the FCA's Perimeter Guidance Manual (PERG) and its online tool can help, but formal legal advice is recommended for complex business models.
The Faster Payments Service itself supports transactions up to ยฃ1 million per payment. However, individual banks and payment service providers set their own limits, which are often lower than the scheme maximum. Most retail bank accounts have a default Faster Payments limit of ยฃ25,000 to ยฃ250,000, which customers can often increase by request. For higher-value transfers, CHAPS (the Bank of England's same-day high-value system) has no practical upper limit and is the standard mechanism for property transactions, corporate treasury transfers, and high-value B2B payments. CHAPS carries a higher transaction cost, typically ยฃ20 to ยฃ35 per payment, compared to pence for Faster Payments.
Confirmation of Payee (CoP) is a UK service that verifies whether the account name provided by a payer matches the account number and sort code at the receiving bank. It was developed to reduce APP fraud, where fraudsters trick victims into sending money to accounts the fraudster controls. CoP is mandatory for the largest UK banks and payment service providers under PSR rules. Smaller PSPs are subject to PSR guidance strongly encouraging adoption. From a technical perspective, CoP requires either direct connection to the Pay.UK CoP infrastructure or access via an intermediary that provides a CoP API layer.
Strong Customer Authentication (SCA) requires that online payments are authenticated using at least two of three factors: something the customer knows (PIN or password), something the customer has (a registered device or card reader), and something the customer is (biometric). For card payments, this is implemented through the 3D Secure 2 (3DS2) protocol, which the card scheme or payment gateway handles. Exemptions from SCA apply in certain circumstances (low-value transactions below ยฃ30, transactions to trusted beneficiaries, merchant-initiated transactions). These exemptions are applied by the customer's card issuer, not by the merchant, so merchants cannot unilaterally exempt transactions from SCA.
Both are FCA-regulated entities that provide payment services in the UK, but there is a key distinction. Payment institutions facilitate the transfer of money between parties but do not issue a stored value product. E-money institutions issue electronic money, meaning they hold funds on behalf of customers in digital wallets or prepaid accounts that can be spent later. Both must safeguard client funds by either holding them in a ring-fenced bank account or obtaining an insurance policy or bank guarantee covering the same amount. The capital requirements and regulatory permissions differ between the two categories, and choosing the right structure is an early decision in any fintech business model design process.
More from the blog
Let us help
Talk to our London-based team about how we can build the AI software, automation, or bespoke development tailored to your needs.
Softomate Solutions Limited
Deen Dayal Yadav
Online
