Payment Gateways in the UK: A Due-Diligence Guide for International Merchants

The practical question is not “Which provider has the longest feature list?” It is “Which provider can document the exact payment, currency and operating flow that this business needs?”

That distinction matters for international ecommerce, digital services, games and SaaS. A gateway can appear suitable at product-page level yet fail at underwriting, account configuration, settlement or day-to-day operations.

This guide offers a repeatable way to make that decision. It is operational guidance, not legal, regulatory or tax advice.

What a UK payment gateway needs to support

A payment gateway carries checkout data into a payment flow. It is not automatically the processor, acquirer, payment facilitator, payment-initiation service provider, account provider or Merchant of Record.

The FCA's perimeter guidance makes this distinction important. A company that only supplies technical gateway services may have a different role from the company that contracts to acquire payments for a merchant. Always identify the contracting legal company and every other entity that handles the transaction or merchant funds.

For most international merchants, a useful requirements list covers nine areas:

1. Channels: hosted checkout, embedded fields, API, ecommerce plug-in, payment link, recurring payment or other required flow.
2. Customers and instruments: customer countries, card types, wallets and any bank-payment requirement.
3. Currencies: checkout presentment, transaction processing, merchant balance, conversion and bank-account payout.
4. Authentication and fraud: Strong Customer Authentication, 3-D Secure, exemptions, challenge handling and fraud controls.
5. Money movement: authorisation, capture, clearing, provider settlement, merchant payout, reserves and bank-credit timing.
6. After-payment operations: voids, refunds, disputes, evidence submission and exception handling.
7. Reporting: stable transaction references, fees, FX, reserves, adjustments and payout reconciliation.
8. Commercial terms: total transaction cost, fixed charges, exception fees, recurring charges, contract term and termination.
9. Eligibility: contracting entity, incorporation country, industry, business model, expected volume, average transaction value and risk review.

The underlying flow should also be clear:

1. Customer checkout.
2. Authentication and authorisation request.
3. Gateway routing through the processor or acquirer, card network or payment service, and issuer or account provider.
4. Transaction processing from the authorisation result through capture and clearing or rail processing.
5. Merchant payout from the provider ledger to the merchant bank account.
6. Reporting that links the payment, refund, dispute, fees, adjustments and payout.

Each arrow can involve a different entity, currency, status and contractual responsibility. A provider's sales material is only the start of the evidence trail.

Sources: FCA Handbook PERG 15.3: Payment services, FCA: Using payment service providers and PCI SSC: Outsourced payment processing, verified 2026-08-28.

The UK payment landscape

This section describes the UK payment market. It does not confirm that HaiPay currently supports each payment method or rail.

The UK market contains several distinct systems and payment journeys:

• Card systems include Visa and Mastercard. A gateway still needs an acquiring route, merchant approval and account configuration before a merchant can accept a particular card transaction.
• Faster Payments is UK account-to-account infrastructure. Access can be direct, sponsor-settled or indirect; an access model does not prove that a provider offers a merchant checkout or collection product.
• Bacs is an electronic account-to-account service whose payments typically fall into Direct Debit and Direct Credit.
• CHAPS serves sterling high-value and time-critical payments. Its infrastructure schedule does not establish a gateway's merchant payout schedule.
• LINK is the UK's cash-machine network. Its existence says nothing about online gateway coverage.
• Pay by Bank describes a checkout journey enabled by regulated payment initiation. It is not a single national rail, and coverage can vary by bank, account and payment type.

A rail's customer-payment schedule and settlement between participating providers do not establish a PSP's separate payout to a merchant. Marketing language about a rail must never be carried across to a merchant-payout promise.

When a UK bank-payment capability is material, ask for the named product, regulated entity, access route, supported banks and accounts, payment statuses, limits, refunds, reconciliation fields, merchant eligibility and written service terms.

Sources: FCA Handbook PERG 15.3: Payment services, Payment Systems Regulator: Who we regulate, Bank of England: Payment and settlement, Pay.UK: Faster Payment participation, Pay.UK: Bacs Payment System, Direct Debit Guarantee and Open Banking Limited: Pay by Bank, verified 2026-08-28.

Card payment acceptance for international merchants

Card acceptance is a chain, not a logo list. A useful card review tests the entire route:

• Which merchant entity signs the contract?
• Which acquirer and card schemes are involved?
• Which customer locations, card types and transaction types are eligible?
• Which currency is shown, authorised, captured and paid out?
• Is capture automatic or merchant-controlled?
• How are reversals, retries and duplicate requests handled?
• Which authentication data and decline information reach the merchant?
• What happens to stored credentials during a provider migration?

UK Strong Customer Authentication rules can apply when a payer initiates an electronic payment or performs certain remote actions, unless an exemption applies. EMV 3-D Secure can carry authentication data before card authorisation. It does not itself guarantee authorisation, an exemption, a liability shift or compliance for every transaction.

HaiPay's public card page displays the label “3D Secure 2.0 authentication” at general platform level. Without controlled product evidence and route/account confirmation, that label does not establish the version enabled for a UK route or particular merchant account. It also does not establish exemption logic, challenge flow or account eligibility. A merchant should request the supported 3DS version, message fields, exemption ownership, challenge and fallback behaviour, evidence retained, and production test cases for its own configuration.

Outsourcing checkout can reduce the card-data environment, but it does not erase the merchant's PCI DSS responsibilities. Ask for current compliance evidence and a written responsibility matrix covering the merchant, gateway, processor and any ecommerce platform.

Sources: FCA: Strong Customer Authentication, Visa Secure with EMV 3-D Secure, PCI SSC: Outsourced payment processing and HaiPay: Credit Card, verified 2026-08-28.

How to evaluate UK local payment requirements without assuming provider support

Start with the buyer need, not a provider label. “We need bank payments” is too broad to evaluate. Convert it into an operational requirement:

For open-banking payments, verify the authorised PISP and its exact FCA permission. Then verify bank, account and payment-type coverage separately. The Open Banking Standard includes multiple payment statuses and documented refund models, but a standard does not prove that a commercial provider has exposed every status, webhook or refund workflow.

For Bacs Direct Debit, ask the provider to document its access and collection model, advance-notice process, error-refund process and cancellation procedure. The Direct Debit Guarantee does not alter the payer's underlying contract with the biller. Do not describe it as general purchase-dispute protection.

None of these market facts establishes provider support. They belong in an RFP or sales-call checklist until country-specific product evidence and merchant approval are in writing.

Sources: FCA: Account information and payment initiation services, Open Banking Standards: Payment Initiation Services, Open Banking Standards: Payment statuses, Open Banking Standards: Refund Payment Fulfilment, Pay.UK: Bacs Payment System and Direct Debit Guarantee, verified 2026-08-28.

UK Market Need vs HaiPay Evidence Boundary Map

Three layers must remain separate throughout selection and contracting.

The governing rule is simple: layer 1 cannot establish layer 2, and layer 2 cannot establish layer 3.

The merchant-configuration documentation reinforces the account-level distinction. Configuration can carry enabled methods, currency, limits, fees, refund support and settlement fields. A public product statement should therefore be checked against the final account configuration before launch.

Sources: HaiPay: Pricing and HaiPay: Merchant Payment Config, verified 2026-08-28.

What Europe-level coverage does—and does not—prove

Regional coverage is useful screening evidence. It is not a country-level contract.

For this review, the public product material is usable only as regional context. No positive UK-local-method coverage statement is made from it. Europe-level material does not establish:

• UK domestic acquiring;
• acceptance for a particular UK or non-UK merchant entity;
• support for Faster Payments, Open Banking, Pay by Bank, Bacs, Direct Debit, CHAPS or LINK;
• GBP presentment or GBP settlement;
• a settlement bank account in the UK;
• a UK-specific fee, tax treatment or payout timetable; or
• activation for a specific industry, card type, transaction type or risk profile.

The local payment product page places the United Kingdom inside its Europe navigation. That geographic label is not method-level availability evidence.

If a required capability is absent from the final quote and production configuration, treat it as unavailable for the launch plan. Do not fill the gap with a regional example, a general API field, another country's terms or a description of UK infrastructure.

Sources: HaiPay: Local Payment and HaiPay: Merchant Payment Config, verified 2026-08-28.

GBP presentment, settlement and FX

“Supports multiple currencies” is incomplete. A merchant should map five currency layers before comparing providers.

A “GBP payment” may describe only the shopper-facing amount. It does not automatically mean the merchant holds GBP or receives GBP in its bank account. Likewise, infrastructure settlement between payment providers is different from the provider's payout to the merchant.

The reviewed product sources do not establish GBP presentment, GBP settlement, a GBP merchant account, a UK bank-account requirement or a UK-specific FX benchmark. These items should remain written confirmation points rather than launch assumptions.

Sources: Bank of England: Payment and settlement, HaiPay: Pricing and HaiPay: Merchant Payment Config, verified 2026-08-28.

Fees, VAT and settlement timing

A headline rate rarely describes total cost. Model the actual card and currency mix using:

Estimate total monthly cost by adding:

• variable transaction charges;
• fixed transaction charges;
• scheme, processing or international-card components where applicable;
• FX and payout charges;
• platform, monthly or minimum charges;
• refund, dispute and other exception charges; and
• integration, compliance and operational costs.

For a low-value transaction, the fixed component may drive more of the effective cost than the percentage component. Use several scenarios based on expected monthly volume, average transaction value, card mix, international share, refund rate and dispute rate. Include declined attempts, reserves, payout charges and ecommerce-platform surcharges where the contract makes them relevant.

HaiPay's public card pricing starts from 2.5% + US$0.30 for eligible card transactions. This is general published starting pricing, not a UK quote. Actual terms depend on the merchant entity, market, payment method, transaction volume, risk profile, contract and final quote.

The reviewed evidence does not establish a UK-specific VAT treatment, payout schedule or outbound fee for this product. This guide therefore quotes none of them. Request a final fee schedule that states whether each amount is inclusive or exclusive of applicable tax and identifies every transaction, exception, FX and payout charge.

Request settlement terms as a money-flow specification, not a single number. It should define the capture cut-off, pending period, reserves, weekends and holidays, payout currency, payout instruction, receiving-bank timing and reconciliation report. Never infer a merchant payout schedule from a payment rail's operating schedule.

Sources: Payment Systems Regulator: Card-acquiring provision of information, Payment Systems Regulator: Implementation advice, Bank of England: Payment and settlement and HaiPay: Pricing, verified 2026-08-28.

Merchant entity, underwriting and contract requirements

Company registration does not guarantee gateway eligibility. Underwriting commonly depends on the contracting entity, beneficial owners, business model, industry, products, customer locations, fulfilment, expected volume, average and maximum transaction values, recurring use, refund profile and risk controls.

Before sharing documents, identify the legal company that will contract with the merchant. Check that company—not just the trading brand—on the Financial Services Register where a UK-regulated service or permission is claimed. Confirm the exact permission and service. A gateway, acquirer, payment facilitator, PISP and e-money institution can occupy different parts of the flow.

If an entity holds relevant funds, ask which safeguarding regime applies, when safeguarding begins and ends, how reconciliations are performed, and what happens if a provider or partner fails. Safeguarding is not the same as FSCS deposit protection.

The final contract and account configuration should cover at least:

• approved merchant entity and websites or apps;
• accepted business activities and excluded activities;
• payment methods, schemes, card types and transaction types;
• presentment, processing, balance and payout currencies;
• transaction and account limits;
• reserve, hold and termination terms;
• refund and dispute operations;
• settlement bank-account requirements;
• data, PCI and security responsibilities;
• service levels, incident escalation and support hours; and
• token, data and reconciliation access on exit.

Sources: FCA: Using payment service providers, FCA Handbook PERG 15.3: Payment services and FCA: Safeguarding requirements, verified 2026-08-28.

Authentication, fraud, refunds, disputes and reconciliation

These functions should be tested as workflows rather than accepted as feature labels.

Authentication and fraud

Ask who requests SCA exemptions, which party controls 3DS routing, what happens after a challenge failure, which fraud rules can be configured and which decision fields are returned. Compare false-decline handling and manual-review operations without accepting unsourced approval-rate claims.

Refunds

The documentation includes card refund-application and refund-query routes. It also indicates that refund availability can be configuration-specific. That supports a general refund workflow, but not UK or GBP activation for a particular merchant.

Request written confirmation of full-, partial- and repeated-refund availability. Test only the variants enabled for the account, including currency, destination, reference linkage, status changes, failure recovery, fees and reconciliation.

Disputes

A merchant refund and a card chargeback are different processes. A chargeback is scheme-based, recovery is not guaranteed, and evidence or timing can vary. Ask how the merchant is notified, what reason codes and evidence are supported, which provider deadlines apply, how representment works and how fees or reserves appear in reports.

Reconciliation

Require one stable chain linking authorisation, capture, refund, dispute, adjustment and payout. A useful report separates gross amount, fees, FX, reserves, adjustments and net payout. Test duplicate webhooks, delayed events, report revisions and month-end cut-offs before launch.

Sources: FCA: Strong Customer Authentication, Visa UK: Purchase disputes and chargeback, HaiPay: Refund Apply, HaiPay: Refund Query and HaiPay: Merchant Payment Config, verified 2026-08-28.

A fair comparison of provider models

This comparison covers provider models that solve materially different parts of the merchant problem. They include a full-stack PSP or acquirer, technical gateway, bank-payment or payment-initiation specialist, cross-border payment aggregator, and contract-defined Merchant of Record model. A single company may occupy more than one model.

Methodology. Models were included because they recur in the observed Google UK result set or change the legal and operational payment flow. Evaluation uses the same criteria for every model: role, entity, channels, payment coverage, currencies, authentication, fees, settlement, refunds, disputes, reconciliation, eligibility, support and exit. Missing evidence is treated as not verified, not as a negative score.

Data sources and date. The framework uses FCA, Bank of England, PSR, Pay.UK, Open Banking and PCI SSC materials, plus provider contracts and product documentation where a merchant performs an evaluation. The comparison was last verified on 28 August 2026.

Limitations and conflict disclosure. Categories overlap, contracts vary and public pages can change. This guide is published by HaiPay, a payment-services vendor. The publisher receives no automatic ranking advantage, and no paid placement determines inclusion. The table compares operating models rather than copying a competitor ranking.

Sources: FCA Handbook PERG 15.3: Payment services, FCA: Account information and payment initiation services and FCA: Using payment service providers, verified 2026-08-28.

UK Payment Gateway Due-Diligence Matrix

Use this matrix as a request-for-evidence sheet. “Europe-level only” is not a negative verdict; it means a UK or account-level conclusion would exceed the evidence.

Sources: FCA Handbook PERG 15.3: Payment services, FCA: Strong Customer Authentication, FCA: Payment initiation services, Payment Systems Regulator: Who we regulate, Payment Systems Regulator: Card-acquiring information, Bank of England: Payment and settlement, Pay.UK: Faster Payment participation, Pay.UK: Bacs Payment System, Direct Debit Guarantee, Open Banking Standards: Payment Initiation Services, Visa UK: Purchase disputes, PCI SSC: Outsourced payment processing, HaiPay: Credit Card, HaiPay: Merchant Payment Config and HaiPay: V20260701 Global Cashier, verified 2026-08-28.

UK Payment Gateway Selection Flow

1. Define the provider role. Decide whether the business needs a gateway, an acquirer or full-stack PSP, a bank-payment specialist, an orchestrator, or a Merchant of Record.
2. Write the required customer journey. List channels, customer countries, cards, wallets, recurring flows and any named UK bank-payment journey.
3. Test entity eligibility first. Provide the real contracting entity, industry, products, countries, volumes, average transaction value and risk profile. Stop if the provider will not underwrite the actual model.
4. Map every currency layer. Confirm presentment, processing, balance, conversion and payout independently. Stop if a required GBP layer is absent from written evidence.
5. Demand method-level proof. For any UK rail, obtain the product name, responsible entity, access route, coverage, statuses, refunds, reconciliation and merchant eligibility. Market existence is not proof.
6. Run authentication and exception tests. Exercise 3DS challenges, failures, refunds, duplicate events, disputes and report corrections in a test environment.
7. Model total cost. Use the merchant's actual transaction values, card mix, volume, international share, FX, exceptions, recurring charges and platform fees.
8. Review the contract and exit path. Check reserves, holds, payout terms, termination, data access, token portability, service escalation and migration effort.
9. Approve only the documented configuration. Reconcile the final quote, contract, production settings and test evidence before routing live traffic.

This process favours evidence over brand familiarity. It also gives the merchant a reusable record for renewals and periodic provider reviews.

Where HaiPay may fit—and where confirmation is required

HaiPay may be worth evaluating when an international merchant has a small-ticket card use case and is prepared to validate its entity, currencies and account configuration. Its versioned international-card documentation lists a US$0.99 to US$1,000 transaction range for the documented USD card route. That range does not establish a GBP limit or UK merchant eligibility.

The public card page displays a “3D Secure 2.0 authentication” label, and the API documentation includes card refund routes. These are useful starting points for a technical and commercial review, not proof of UK-route or account-level activation.

Do not select the provider on an assumption that it supports Faster Payments, Open Banking, Pay by Bank, Bacs, Direct Debit, CHAPS, LINK, GBP presentment or GBP settlement. The reviewed evidence does not establish those HaiPay capabilities for a UK account.

Before proceeding, request written confirmation of:

• the contracting and service entities;
• eligibility for the merchant's country, industry and business model;
• card schemes, customer/card geographies and transaction types;
• each presentment, processing, balance and payout currency;
• the settlement bank-account requirements and payout schedule;
• the exact 3DS, refund, dispute and reconciliation configuration;
• every required UK payment method or rail, without relying on regional wording; and
• the complete fee schedule, tax treatment, limits, reserves and contract terms.

Review the broader international payment gateway guide, compare local and cross-border acquiring, inspect the card product and public pricing, then contact HaiPay with the completed due-diligence matrix.

Sources: HaiPay: Pricing, HaiPay: Credit Card, HaiPay: Versioned Card API, HaiPay: Refund Apply and HaiPay: Merchant Payment Config, verified 2026-08-28.

Sources

1. PERG 15.3: Payment services. Financial Conduct Authority Handbook. https://handbook.fca.org.uk/handbook/perg15/perg15s3. Accessed 2026-08-28. Supports the distinction between acquiring and technical gateway services.
2. Using payment service providers. Financial Conduct Authority. https://www.fca.org.uk/consumers/using-payment-service-providers. Accessed 2026-08-28. Supports legal-entity, permission and funds-protection checks.
3. Safeguarding requirements for payment institutions and electronic money institutions. Financial Conduct Authority. https://www.fca.org.uk/firms/emi-payment-institutions-safeguarding-requirements. Accessed 2026-08-28. Supports safeguarding and reconciliation diligence.
4. Strong Customer Authentication. Financial Conduct Authority. https://www.fca.org.uk/firms/strong-customer-authentication. Accessed 2026-08-28. Supports the stated scope and conditional nature of SCA.
5. Account information services and payment initiation services. Financial Conduct Authority. https://www.fca.org.uk/firms/account-information-services-payment-initiation-services. Accessed 2026-08-28. Supports PISP and payment-initiation role checks.
6. Who we regulate. Payment Systems Regulator. https://www.psr.org.uk/how-we-regulate/who-we-regulate/. Accessed 2026-08-28. Identifies designated UK payment systems and operators.
7. Payment and settlement. Bank of England. https://www.bankofengland.co.uk/payments/payment-settlement. Accessed 2026-08-28. Supports customer-processing and inter-provider-settlement distinctions; the merchant-payout warning is a conservative non-inference.
8. Faster Payment participation.Pay.UK. https://www.wearepay.uk/what-we-do/payment-systems/faster-payment-system/faster-payment-participation/. Accessed 2026-08-28. Supports direct, sponsor-settled and indirect access distinctions.
9. Bacs Payment System.Pay.UK. https://www.wearepay.uk/what-we-do/payment-systems/bacs-payment-system/. Accessed 2026-08-28. Supports Bacs system and payment-type context.
10. Direct Debit Guarantee.Pay.UK/Bacs. https://www.directdebit.co.uk/direct-debit-guarantee/. Accessed 2026-08-28. Supports Direct Debit operational diligence and the limits of the Guarantee.
11. Pay by Bank. Open Banking Limited. https://www.openbanking.org.uk/pay-by-bank/. Accessed 2026-08-28. Supports the typical checkout journey and PISP role.
12. Payment Initiation Services. Open Banking Standards. https://standards.openbanking.org.uk/customer-experience-guidelines/payment-initiation-services/latest/. Accessed 2026-08-28. Supports bank-, account- and payment-type-specific coverage.
13. Refund Payment Fulfilment. Open Banking Standards. https://standards.openbanking.org.uk/customer-experience-guidelines/appendices/refund-fulfillment/latest/. Accessed 2026-08-28. Supports refund-model and reconciliation questions.
14. Card-acquiring provision of information. Payment Systems Regulator. https://www.psr.org.uk/media/dlgl0ibz/sd14-summary-boxes-online-calculators-varied-may-2024.pdf. Accessed 2026-08-28. Supports fee and billing-information diligence.
15. Implementation advice for summary boxes and quotation tools. Payment Systems Regulator. https://www.psr.org.uk/media/b51llcrz/implementation-advice-summary-box-oqt-trigger-oct-2024.pdf. Accessed 2026-08-28. Supports total-cost comparison fields.
16. Visa Secure with EMV 3-D Secure. Visa UK. https://www.visa.co.uk/run-your-business/small-business-tools/payment-technology/visa-secure.html. Accessed 2026-08-28. Supports the distinction between authentication and authorisation.
17. Purchase disputes and chargeback. Visa UK. https://www.visa.co.uk/how-you-pay-matters/chargeback-purchase-disputes.html?linkId=146440116. Accessed 2026-08-28. Supports refund-versus-chargeback distinctions and operational questions.
18. Does PCI DSS apply when all payment processing is outsourced? PCI Security Standards Council. https://www.pcisecuritystandards.org/faqs/does-pci-dss-apply-to-merchants-who-outsource-all-payment-processing-operations-and-never-store-process-or-transmit-cardholder-data/. Accessed 2026-08-28. Supports shared PCI responsibility.
19. Pricing. HaiPay. https://www.haipay.net/pricing. Accessed 2026-08-28. Supports only the general starting card price used here; it is not treated as a UK quote.
20. Credit Card. HaiPay. https://www.haipay.net/products/credit-card. Accessed 2026-08-28. Supports only that the current public page displays a general-platform “3D Secure 2.0 authentication” label; it does not establish UK-route or account activation.
21. Local Payment. HaiPay. https://www.haipay.net/products/local-payment. Accessed 2026-08-28. Supports only the Europe navigation label discussed here, not UK method availability.
22. Merchant Payment Config. HaiPay API documentation. https://doc.haipay.net/docs/zh/api/version2/MerchantPaymentConfig.md. Accessed 2026-08-28. Supports account-specific configuration fields.
23. Versioned Card API. HaiPay API documentation, V20260701. https://doc.haipay.net/docs/zh/V20260701/api/version2/creditcard. Accessed 2026-08-28. Supports the documented USD international-card transaction range.
24. Refund Apply. HaiPay API documentation. https://doc.haipay.net/docs/zh/api-reference/card/api/refundApply.md. Accessed 2026-08-28. Supports the existence of a general card-refund request route.
25. Refund Query. HaiPay API documentation. https://doc.haipay.net/docs/zh/api-reference/card/api/refundQuery.md. Accessed 2026-08-28. Supports the existence of a general card-refund query route.
26. Information flow: Payment statuses. Open Banking Standards. https://standards.openbanking.org.uk/customer-experience-guidelines/appendices/info-flow-payment-status/v3-1-2/. Accessed 2026-08-28. Supports the existence of multiple documented payment-status states and the need to define a fulfilment rule.
27. Global Cashier. HaiPay API documentation, V20260701. https://doc.haipay.net/docs/en/V20260701/api/version2/GlobalCashier.md. Accessed 2026-08-28. Supports only that the API documentation describes a transaction-currency field and lists GB | United Kingdom | GBP in its region-code table; it does not establish a selected UK card route, merchant-account activation, authorisation/capture configuration, ledger currency, FX, settlement or payout.