Payment Gateway vs Processor vs Orchestration: What UK Businesses Need

What is the difference between a gateway, processor and orchestration?

A payment gateway connects checkout to payment processing services, a processor handles transaction messages, and an orchestration layer coordinates multiple payment providers. One provider may perform several of these functions.

The processor handles transaction messages; the acquirer enables card acceptance and is responsible for settlement to the merchant under the acquiring agreement. The card issuer normally decides whether to authorise the payment. One provider may combine processing and acquiring.

A simplified online card-payment flow:

1. Initiation and routing: The customer submits payment details through the secure checkout. If orchestration is used, it selects a connected provider to handle the payment.
2. Authentication, where required: The customer verifies their identity, commonly through 3-D Secure. Successful authentication does not itself authorise the payment or move funds.
3. Authorisation: The processor sends the request through the card network to the issuer. Approval generally reserves funds or available credit; it does not mean the merchant has received payment.
4. Capture and clearing: The merchant submits the approved payment for completion, automatically or later. Transaction records are exchanged to calculate the amounts owed between participating institutions.
5. Settlement and payout: Funds move between financial institutions, and the acquirer or PSP pays the merchant according to the agreed schedule. Settlement and availability in the merchant’s bank account are separate milestones.

This flow describes card payments. Direct Debit and pay-by-bank use different processes and do not necessarily involve every layer shown.

PSP means payment service provider. In online commerce, a PSP often combines gateway, processing and acquiring services, directly or through partners. UK businesses may therefore obtain several functions under one contract. However, a single orchestration integration does not automatically combine the contracts or payout arrangements of its connected providers.

Which payment setup does your business need?

For online payments, choose the fewest layers that meet your market, payment-method, performance and control requirements. A payment service provider, or PSP, may combine checkout, processing, acquiring and settlement, so separate contracts are not always necessary.

A bundled PSP is usually a practical starting point for a UK business selling through one website or app and settling mainly in GBP. It can simplify integration, onboarding and reconciliation. Check support for the methods your customers need: cards and digital wallets for checkout, Direct Debit for suitable recurring collections, and pay-by-bank where relevant. Confirm which services the PSP supplies directly and which depend on partners.

Consider a separate gateway plus an acquiring arrangement when you need control over acquiring terms, compatibility with an existing merchant account, specialist fraud tools or a checkout independent of the acquirer. Processing may be supplied by the acquirer or a separate provider; a technical processor alone does not replace acquiring. This setup offers commercial flexibility but requires coordination of authentication, refunds, disputes and reconciliation across providers.

Payment orchestration becomes relevant when selecting between providers is a recurring operational need. Typical triggers include:

• coverage gaps across countries, currencies or payment methods;
• measurable authorisation-rate differences by market, issuer or transaction type;
• provider concentration that justifies tested failover;
• multiple PSP or acquiring relationships creating duplicated integration and reporting work.

The business also needs sufficient payment volume, financial benefit and technical capacity to justify managing routing rules and exceptions.

Marketplaces need a separate assessment of their contracts and money flows: receiving customer funds before passing them to sellers may constitute a regulated payment service. A standard merchant account or orchestration layer alone does not resolve those requirements.

Base the decision on customer locations, currencies, payment methods, transaction values, recurring-payment needs, refund and dispute rates, payout timing and peak volumes. Define checkout availability, acceptance and reconciliation targets, then test whether one provider can meet them.

Investigate declines before adding orchestration: payment-data quality, fraud rules, authentication or checkout design may be the cause. Add another layer only when a controlled pilot demonstrates benefits that outweigh its implementation and ongoing operating costs.

How do costs and operational trade-offs compare?

Compare payment setups on total cost per successful transaction, not a single advertised fee. Include gateway or platform charges, processing and acquiring, payment-method and scheme fees, foreign exchange, refunds, disputes, fraud losses, failed-payment handling and internal engineering and reconciliation costs.

Define the metric consistently. For example, divide total payment-related costs by the number of captured payments in the same transaction cohort. Keep subsequently refunded or charged-back payments in that denominator, include associated fees and net losses in the costs, and report refund and chargeback rates separately. Avoid counting the same fraud and chargeback loss twice.

A bundled PSP can simplify contracts, billing and reporting, but a bundled service does not necessarily mean blended pricing. Blended pricing combines payment-cost components into a quoted rate, often with a fixed transaction fee. Interchange-plus pricing separates interchange from the provider’s markup; check how scheme fees are treated. Interchange-plus-plus typically separates interchange, scheme fees and provider markup. Compare the actual fee breakdown rather than relying on pricing labels.

Confirm which events attract charges: authorisation attempts, captures, retries, refunds and disputes. Check whether declined attempts are billed, whether original processing fees are returned after a refund, and which international-card, currency-conversion or premium-feature charges apply.

Separate gateway, processing and acquiring arrangements can offer more commercial control. High-volume merchants may negotiate acquiring terms or select specialist services independently. However, multiple minimum commitments, invoices and reports can increase operating costs. Savings may disappear if finance and engineering teams spend more time resolving mismatched identifiers or reconciling fees and settlement across providers.

Orchestration adds platform or usage charges while retaining underlying PSP and acquiring fees. Higher acceptance, cheaper routing or reduced downtime can justify it only when measured contribution and savings exceed implementation and ongoing operating costs.

Model authorisation and fraud together. More approvals may also produce more disputes or fraud losses. Measure incremental contribution margin after payment costs, fraud, disputes and support. Value failover only where testing confirms token compatibility, appropriate fraud checks and authentication handling without duplicate charging.

Settlement terms also affect cash flow. Compare payout frequency, currencies, cut-off times, reserves, withholding and refund funding. Lower fees may be outweighed by slower payouts or working capital tied up in reserves. Confirm whether settlement reports show gross or net amounts and how fees map to ledger entries.

Use a three-year model covering implementation, parallel running, migration and exit. Separate fixed and variable costs, test conservative and growth scenarios, and include internal work on incidents, PCI DSS, data protection and month-end close. Choose the lowest risk-adjusted total cost that meets the required performance.

What UK security and regulatory requirements matter?

Map the legal entities responsible for processing, acquiring, payment initiation, funds receipt and settlement. Regulatory status depends on activities and contracts, not product labels. A purely technical gateway or orchestration supplier may fall outside payment-services regulation; its absence from the FCA Register is not automatically a concern. Businesses collecting money for other sellers should assess whether their own activities require authorisation or registration.

Check entities performing regulated activities on the FCA Financial Services Register, including their status, relevant permissions and restrictions. For an agent, verify its registration and principal. Where a provider holds funds, confirm the applicable safeguarding or deposit protection and insolvency treatment. Small payment institutions can choose whether to safeguard, so registration alone does not establish protection. Safeguarding is not the same as FSCS deposit protection.

Strong Customer Authentication (SCA) generally requires at least two independent factors from different categories: knowledge, such as a password; possession, such as a registered device; and inherence, such as a fingerprint. For online card payments, EMV 3-D Secure supports authentication by the card issuer. The checkout must pass the required data, support challenges and handle authentication-related soft declines.

Distinguish permitted SCA exemptions from transactions outside its scope. Qualifying merchant-initiated transactions are outside scope, but establishing the payment mandate electronically can require SCA. Labelling a payment “recurring” does not determine its treatment. Confirm transaction indicators, exemption handling and liability information, and test routing so retries preserve valid authentication context without duplicate charging.

PCI DSS obligations arise through card-scheme and acquiring requirements. Hosted checkout and tokenisation can reduce scope but do not remove all merchant responsibilities. Agree the appropriate validation method with the acquirer. Requirements 6.4.3 and 11.6.1 address payment-page scripts and tamper detection, but applicability depends on the integration and assessment route.

For SAQ A, merchants using embedded payment forms must meet the script-security eligibility criterion through protective techniques or qualifying confirmation from their PCI DSS-compliant payment provider, implemented as instructed. That specific criterion does not apply to redirects or fully outsourced payment links; other applicable PCI DSS obligations remain.

UK rules prohibit surcharges on most consumer credit and debit card payments. Check the rules for each payment instrument before configuring checkout fees; processing costs cannot automatically be passed to customers as a surcharge.

Payment and fraud records often contain personal information. Under UK GDPR, establish controller and processor roles, use processor contracts where required, minimise data collection, set retention limits and apply appropriate security. Review subprocessors and data locations, and assess international-transfer requirements when personal information is transferred or made accessible to a separate organisation outside the UK.

Contracts should allocate responsibility for fraud screening, refunds, disputes, unauthorised transactions, complaints, incident reporting and data breaches. Retain evidence according to applicable legal, tax, scheme and contractual requirements.

A provider’s compliance evidence does not establish that the merchant’s integration is secure. Test the complete payment and refund flow, including failures, and monitor the controls the business owns.

How should you evaluate providers and implement your chosen setup?

Define requirements from the actual payment flow: legal entities, sales channels, customer countries, currencies, payment methods, average and peak volumes, recurring payments, refunds, disputes, settlement needs and finance systems. Separate mandatory capabilities from optional features.

Ask each provider to identify the gateway, processor, acquirer, settlement entity, orchestration layer and relevant subcontractors. Confirm which contracts, merchant accounts and onboarding checks are required. Independently verify the entities performing regulated activities and their permissions, then compare the proposed money flow with the contracts.

Compare pricing using the same transaction mix and definition of a successful payment. Include internal engineering, finance, fraud, compliance and support costs. Measure authorisation improvements as incremental contribution after payment costs and losses. For orchestration, include the underlying providers’ charges and operational responsibilities.

Define pilot metrics before testing: first-attempt authorisation rate, eventual payment success per unique payment after retries, and checkout conversion per checkout session. Keep retry attempts separate from unique payments so extra attempts do not distort results. Compare equivalent traffic using controlled cohorts and a holdout where practical.

Run a technical and operational proof of concept covering payment-detail collection or token creation, SCA challenges, authorisation, capture, partial and full refunds, dispute workflows, timeouts, duplicate callbacks and settlement failures.

Set retry rules using provider responses and card-scheme requirements. Distinguish technical failures, responses requiring authentication, retryable declines and responses that prohibit retries. Apply the relevant limits, delays and fees. If a timeout leaves the original payment’s status unknown, hold the order as pending, await a webhook or query its status, and escalate unresolved cases. Do not automatically submit another charge through a different provider while the first may have succeeded.

Implement in stages:

1. Approve the architecture, responsibility matrix, data model and accounting treatment.
2. Configure access, secrets, fraud rules, transaction limits and change approval.
3. Map stable internal payment IDs to provider IDs and build provider-to-ledger-to-bank reconciliation.
4. Plan migration of stored credentials and recurring-payment references; confirm portability and any customer action required.
5. Assign ownership for pending captures, historical refunds and disputes, and retain access to old-provider records and required functions.
6. Complete acceptance testing, then pilot a limited traffic segment with value limits and parallel reporting.
7. Expand only when agreed performance and exception thresholds are met.

Set go-live criteria before testing: duplicate-charge prevention, reconciled payouts, approved access, working refunds, tested dispute handling, monitored webhooks, tested rollback and named incident owners. Keep the previous route available for a defined rollback period covering representative live processing and payout cycles. Separately retain the access and arrangements needed to handle legacy refunds and disputes, which may arise months later.

After launch, monitor payment success, checkout conversion, cost, fraud, disputes, uptime, payout timeliness, unreconciled amounts and support contacts by route. Review the setup when markets, volumes or provider performance change.