From the journal

UK payment orchestration regulation for an Egyptian checkout supplier

An Egyptian payments-technology company proposes to supply checkout and payment-routing software to UK online marketplaces. This hypothetical case asks, under UK payment-services law, whether it can remain a technical supplier, provide managed payments for an authorised provider, or obtain its own UK payment permission. The answer distinguishes merchant-controlled software from a service that accepts payment obligations or exercises payment authority. Neither branch assumes an executed contract, an appointed provider or a regulator's approval.

18 min read

Executive Summary

  • A merchant-controlled card gateway can fall within the UK technical-service exclusion. The supplier must support another provider's payment service, never possess the transferred funds, and supply neither payment initiation nor account information in its own right. Direct merchant contracts with acquirers support that structure. (Payment Services Regulations 2017, SI 2017/752, Schedule 1, paragraph 2(j).)
  • An undertaking to accept and process payments for merchants crosses the acquiring boundary when it satisfies the statutory definition. A downstream authorised acquirer and direct bank settlement do not prevent the supplier from also acquiring transactions. (PSRs 2017, regulation 2(1), definition of 'acquiring of payment transactions'; Schedule 1, paragraph 1(e); FCA PERG 15.3, Q21.)
  • Managed payments can operate through a genuine authorised principal. A payment institution's agent must be registered before providing payment services; the principal retains responsibility. Calling an independent merchant-acquiring business an outsourced technology service does not achieve that result. (PSRs 2017, regulations 25, 34 and 36.)
  • Merchant onboarding, fee quotations and refund interfaces require a decision-by-decision assessment. Administrative support can remain technical; accepting merchants or controlling payments under the supplier's own service undertaking changes the analysis. A commercial-agent exclusion requires authority over the underlying sale, not merely the payment-provider contract. (PSRs 2017, Schedule 1, paragraphs 2(b) and 2(j); PERG 15.5, Q33A and Q39.)
  • UK customers alone do not establish a UK payment-services business. The FCA distinguishes services supplied entirely from abroad. A UK team that accepts merchants or exercises payment powers requires a different territorial assessment from staff confined to introductions. (PSRs 2017, regulation 138; PERG 15.6, Q46.)
  • The Egyptian analysis remains separate. The UK exclusion supplies no Egyptian permission. (PSRs 2017, regulation 138 and Schedule 1, paragraph 2(j).)
  • The first product should connect existing merchant accounts, apply approved card-routing rules, display fraud alerts and report acquirer settlement events. Exclude autonomous refunds, bank-payment initiation, account aggregation, merchant balances and receipt of settlement money. Treat each addition as a release requiring a fresh perimeter decision. (PSRs 2017, regulation 2(1); Schedule 1, paragraphs 1(c), 1(e)–(h) and 2(j).)

The contracts and authority that determine classification

The Payment Services Regulations 2017 determine which services require payment-provider status. FCA PERG explains the regulator's interpretation and carries supervisory relevance, but it is guidance rather than legislation. The proposed API must be assessed against the statutory services and exclusions. Selling only to businesses does not remove a listed service from Schedule 1. No category called payment orchestration displaces those tests. (PSRs 2017, regulation 120 and Schedule 1; PERG 15.3, Q14 and Q21.)

The recommended first product is a merchant-controlled card checkout and routing connector. Assume each participating payee already has an acquiring agreement with every acquirer the connector can select. The Egyptian company contracts separately for software, integration and support. Its agreement contains no undertaking to accept payments, settle proceeds or maintain merchant balances. On those assumptions, the company supplies technical support within paragraph 2(j), provided its actual operations remain within that role. (PSRs 2017, Schedule 1, paragraph 2(j); PERG 15.3, Q21; PERG 15.5, Q39.)

The fuller branch assumes that merchants contract with the company for acceptance and processing of payments. The company decides which acquirer will fulfil that promise, sets the merchant's payment-service price and exercises refund or settlement authority. Acquiring involves a provider contracting with a payee to accept and process transactions that result in funds reaching that payee. The proposed undertaking can satisfy that definition. It does not become software support because a licensed bank performs the final settlement. (PSRs 2017, regulation 2(1), definition of 'acquiring of payment transactions'; Schedule 1, paragraph 1(e); PERG 15.3, Q21.)

The contractual payee must also be identified within each marketplace. A marketplace buying and reselling goods as principal receives payment for its own sales. A platform collecting proceeds for independent sellers presents a different payment-services question. The pilot should admit only payees whose contracts and merchant accounts match the real seller relationship. It should exclude supplier-controlled collection and distribution among marketplace sellers. (PERG 15.5, Q33A; PSRs 2017, Schedule 1, paragraphs 1(c), 1(e) and 1(f).)

Checkout should identify the actual seller or payee and accurately describe the provider's role. In an agency model, payment-service users must receive the required agency disclosure. The supplier's logo does not determine classification, but a representation that it accepts or settles payments can contradict a technical-only contract. The sales materials, checkout, receipts and statement descriptors should reflect the same allocation of responsibilities. (PSRs 2017, regulations 34(16), 138 and 139.)

Neither an orchestration licence nor a payment gateway licence is a separate UK permission. The relevant questions concern the listed payment services and exclusions. Stored value would introduce a further question outside the proposed card connector. Licentium's payment institution and EMI explainer addresses that broader product distinction. (PSRs 2017, regulation 2(1) and Schedule 1.)

Checkout, routing and fraud monitoring

Displaying checkout, processing transaction data and providing authentication technology can qualify as technical services. Paragraph 2(j) requires support for payment services without possession of the transferred funds. Its express exceptions for payment initiation and account information prevent a blanket exemption for every funds-free API. (PSRs 2017, Schedule 1, paragraph 2(j).)

Automated routing need not itself amount to acquiring. Under the narrow design, the merchant approves its acquirer accounts and routing policy; the software applies those instructions. Each selected acquirer accepts and processes transactions under its own merchant agreement. The supplier cannot add an acquirer, substitute another merchant identifier or change the destination account on its own authority. These restrictions preserve the factual basis for technical support. (PSRs 2017, regulation 2(1), definition of 'acquiring of payment transactions'; Schedule 1, paragraph 2(j); PERG 15.3, Q21.)

Routing becomes a different proposition when the company sells one managed acceptance service and appoints acquirers to discharge its own obligations. The FCA explains that acquiring can involve more than one acquirer and need not be limited to the card scheme's acquirer of record. Independent selection is evidence of that undertaking, rather than a standalone statutory test. A pricing algorithm or routing algorithm must therefore be assessed with the merchant contract. (PERG 15.3, Q21.)

Fraud scoring and alerts can remain data-processing support. The pilot should leave the merchant and acquirer responsible for acceptance, authentication and payment decisions. A delegated fraud-blocking function does not automatically create a separate payment service, but discretionary powers must be allocated and supervised within the provider relationship. Authority to release, redirect or reverse transactions requires assessment beyond the production of a risk score. (PSRs 2017, Schedule 1, paragraph 2(j); regulations 25 and 36; PERG 15.5, Q39.)

Merchant onboarding and fee setting

The UK sales team may demonstrate software and collect information for an acquirer's onboarding process under the narrow design. The acquirer must decide whether to accept the merchant and enter the acquiring agreement. Staff should not approve merchants under the company's name, issue merchant accounts or promise settlement. Document collection alone does not satisfy the acquiring definition; acceptance of the merchant under an own-name payments contract can. (PSRs 2017, regulation 2(1); PERG 15.3, Q21.)

A separately invoiced software subscription or usage charge does not, by itself, make the supplier an acquirer. Neither does communicating an acquirer's approved fee quotation. Negotiating payment-service terms under authority to bind a principal requires an agency assessment. Setting the price of an own-name acceptance service points toward the managed-payments branch, even when the supplier calls its margin a technology fee. (PSRs 2017, regulation 2(1), definitions of 'agent' and 'acquiring of payment transactions'; regulations 34 and 36.)

The strongest technical-service argument is that one interface can perform substantial administration while every payment obligation remains with the merchant's acquirers. That argument survives only where the agreements and operating powers support it. An acquirer's licence does not cover a separate acquiring undertaking given by the company to merchants. The pilot should therefore price software separately and prohibit staff from varying acquiring terms outside documented authority. (PSRs 2017, Schedule 1, paragraph 2(j); PERG 15.3, Q21.)

Refunds, payment instructions and settlement money

A refund interface can transmit a merchant's instruction without giving the supplier an independent refund service. For the pilot, the merchant should approve the refund in its acquirer's controlled environment. Supplier staff may prepare a request or display status, but should have no production credential that authorises refunds. The acquirer executes the transaction and remains responsible under its payment contract. This is a deliberately narrower design than all possible excluded technical services. (PSRs 2017, Schedule 1, paragraph 2(j); PERG 15.5, Q39.)

Autonomous refund authority removes that factual protection. A power to debit balances, choose recipients or execute refunds under the company's own service undertaking can involve acquiring or execution of payment transactions. An online service that initiates a merchant's bank-payment order at its request may instead constitute payment initiation. A refund button is not a statutory category; the account, instruction, mandate and responsible provider determine the applicable service. (PSRs 2017, regulation 2(1); Schedule 1, paragraphs 1(c), 1(e) and 1(g).)

Brief receipt of settlement money defeats the technical-service exclusion's no-possession condition. A transit account, suspense account or account described as held for merchants does not create a timing exception. Depending on the complete service, receipt and onward transmission can constitute acquiring, execution or money remittance. A trust or segregation arrangement addresses protection of funds; it does not establish the technical exclusion. (PSRs 2017, regulation 2(1); Schedule 1, paragraphs 1(c), 1(e), 1(f) and 2(j); PERG 15.3, Q22.)

Control also requires examination where the account is legally held by an acquirer. Supplier powers to change beneficiaries, release reserves or direct payouts can establish payment authority without a transfer into its own bank account. Those powers do not automatically prove legal possession, but they undermine an analysis confined to data transmission. The pilot should prohibit bank mandates, settlement-account credentials and unilateral instructions over merchant proceeds. (PSRs 2017, regulation 2(1); Schedule 1, paragraph 2(j); PERG 15.3, Q21 and Q25B.)

Payment initiation and account-information access

A pay-by-bank feature requires its own classification. Payment initiation is an online service initiating a payment order at a user's request concerning an account held at another payment service provider. The supplier need not hold funds to provide it, and paragraph 2(j) expressly excludes it. The FCA distinguishes transmitting card details and a payment order without possessing personalised security credentials. That distinction does not exempt an open-banking initiation service. (PSRs 2017, regulation 2(1); Schedule 1, paragraphs 1(g) and 2(j); PERG 15.3, Q25B.)

A provider-hosted bank-payment option can be added only after identifying whether it involves a payment-initiation service and, if so, who supplies it to the payer. A genuine agent may present the principal's service, with the required registration and disclosures. An embedded provider API does not by itself transfer the supplier's own initiation obligations to that provider. The first release should omit this feature rather than assume every bank redirect or API integration is excluded. (PSRs 2017, regulations 2(1), 34 and 36; FCA, Payment Services and Electronic Money: Our Approach, May 2026, paragraphs 5.2–5.8.)

Settlement reporting should use transaction and settlement events supplied by acquirers, without accessing merchant payment accounts. An online service providing consolidated information about one or more payment accounts held with another provider can constitute account information services. A statement covering only one account is not exempt merely because it performs no multi-bank aggregation. The pilot should exclude bank-account feeds, account-access consent journeys and bank credentials. (PSRs 2017, regulation 2(1), definition of account information service; Schedule 1, paragraphs 1(h) and 2(j); PERG 15.3, Q25A.)

Data obtained through an authorised account-information provider requires the same attention to the downstream service. Technical processing for that provider can remain outsourced support. A company that uses the data to supply its own account-information service needs the appropriate status, unless it acts as the provider's genuine agent. Receiving data from an authorised source does not resolve that distinction. (PERG 15.3, Q25A; FCA Our Approach, May 2026, paragraphs 5.8–5.10.)

Commercial agency and authorised-provider arrangements

The commercial-agent exclusion is a poor fit for this proposed checkout supplier. Paragraph 2(b) requires contractual authority to negotiate or conclude the underlying sale or purchase for either payer or payee, but not both. Authority to negotiate acquiring fees, introduce merchants or process their payments does not establish authority over the sale of marketplace goods. The FCA also distinguishes a binding sales agency from a technical ordering facility. (PSRs 2017, Schedule 1, paragraph 2(b); PERG 15.5, Q33A.)

The strongest contrary case would give the company genuine authority to conclude sales solely for sellers. That is a materially different commercial role, with an underlying sales mandate and conduct consistent with it. Unlike paragraph 2(j), paragraph 2(b) is not framed around a prohibition on possession of funds. It can therefore require assessment even when money is collected. The proposed payment-routing functions alone supply no basis for adopting that exclusion. (PSRs 2017, Schedule 1, paragraphs 2(b) and 2(j); PERG 15.5, Q33A.)

A technical-service contract is the preferred UK pilot route. Each authorised acquirer supplies acquiring under a merchant agreement; the company supplies the connector under a software agreement. A further integration or outsourcing contract may be needed with the acquirer. The company does not become a payment agent merely because it supports an authorised provider, and the provider's involvement does not excuse independent regulated services. (PSRs 2017, regulation 2(1); Schedule 1, paragraph 2(j); PERG 15.5, Q39.)

For a managed service, a payment institution can appoint the company as its agent within the principal's authorised services. Registration must precede provision through that agent. The agency arrangement must identify the principal, the services delegated, permitted decisions, access rights and customer disclosures. The principal remains responsible for acts and omissions and must supervise the operation. A commercial-agent exclusion and a registered payment-agent arrangement have different legal foundations. (PSRs 2017, regulations 34(1), 34(16) and 36(2); Schedule 1, paragraph 2(b).)

Bank-acquirer arrangements require assessment under the bank's applicable rules. Regulation 34 concerns agents of payment institutions; it should not be transplanted into a bank arrangement without identifying the applicable route. For this case, the defined managed-agent alternative assumes an authorised payment institution as principal. The intended service must fall within that principal's permissions. (PSRs 2017, regulations 34 and 36; FCA Our Approach, May 2026, paragraphs 5.1–5.3.)

Outsourcing provides no substitute for genuine allocation of the payment service. Regulation 25 requires a payment institution to notify operational outsourcing and restricts outsourcing of important functions. It cannot impair internal control or the FCA's supervision, delegate senior management responsibility or alter the institution's obligations to users. The contract should provide audit access, incident reporting, subcontracting controls and an executable exit process. Those controls support the principal's compliance; they do not authorise an independent payment business. (PSRs 2017, regulations 25 and 36.)

UK territorial scope and an own payment institution

An Egyptian company does not need UK payment permission solely because a UK merchant can access its website. In Q46, the FCA generally distinguishes a company incorporated and located abroad that supplies services entirely from outside the UK. That is a territorial assessment separate from the technical-service exclusion. The presence of UK customers cannot replace analysis of where the company provides its payment service. (PSRs 2017, regulation 138; PERG 15.6, Q46.)

A UK sales presence makes staff authority important. A team limited to demonstrations and introductions presents different facts from one accepting merchants, binding acquiring contracts or directing refunds. The pilot should confine that team's powers and record where each operational decision occurs. A foreign governing-law clause or Egyptian incorporation cannot decide the statutory location question. The recommended technical design avoids making the launch depend entirely on a remote-supply argument. (PERG 15.6, Q46; PSRs 2017, regulation 138.)

Own UK authorisation is the appropriate route when the group intends to provide acquiring in the UK under its own responsibility. It should establish a UK-incorporated applicant with its head office and registered office in the UK. The applicant must carry on, or plan to carry on, at least part of its payment-services business in the UK. A branch of the Egyptian company does not satisfy the payment-institution incorporation condition. The FCA examines actual central management and administration, not merely a registered address. (PSRs 2017, regulation 6(4)–(5); FCA Our Approach, May 2026, paragraphs 3.49–3.54.)

The application must cover the payment services actually proposed. Acquiring requires initial capital of at least €125,000, with separate ongoing own-funds obligations. The applicant also needs the required business plan, suitable management, security and financial-crime controls, and arrangements for any outsourced functions. Payment initiation requires professional indemnity insurance or a comparable guarantee. These conditions require an operating business capable of performing the authorised service. (PSRs 2017, regulations 6 (including 6(7)(e)) and 22, Schedule 2 and Schedule 3, Parts 1 and 2; FCA Our Approach, May 2026, paragraphs 3.45–3.60 and 9.9–9.10.)

An authorised institution receiving relevant funds must meet regulation 23 and the applicable safeguarding rules. CASS 15 has applied since 7 May 2026 and includes protection, records and reconciliation requirements. A proposed balance, reserve or payout service must be designed around those obligations before launch. Small-payment-institution registration is a separate regulated route. Its conditions include a €3 million monthly-average transaction limit over the preceding twelve months and exclude payment initiation and account information. For an applicant that has not started payment services or has provided payment services for less than twelve months, the monthly average may use projected transactions over twelve months. It supplies no technical-service exemption. (PSRs 2017, regulations 14(3)–(4), 14(12) and 23; CASS 15.1.2R, 15.2.1R, 15.8.3R, 15.8.19R and 15.8.42R.)

Contract and technical controls for the first UK pilot

The pilot agreement should identify the software supplier, each acquiring provider and the actual merchant payee. It should attach a responsibility schedule covering onboarding decisions, payment acceptance, routing changes, refunds, fraud decisions and complaints. The supplier should warrant its restricted role and contractually prohibit staff from giving payment undertakings. Before contracting, verify the exact provider entity and relevant permissions on the FCA register. The acquirer should approve the integration and retain direct payment-service obligations to the merchant. These are proposed controls for the paragraph 2(j) analysis, rather than a statutory template. (PSRs 2017, Schedule 1, paragraph 2(j); PERG 15.3, Q21.)

The funds-flow specification should trace payer payment, acquiring, settlement and refunds for each supported transaction type. It must show settlement directly to the identified merchant's account, with no supplier transit account or supplier-controlled distribution. Software fees should be invoiced separately. Licentium's payment-processor selection guide addresses provider acceptance, settlement terms and reserve exposure. (PSRs 2017, Schedule 1, paragraph 2(j); PERG 15.3, Q21–Q22.)

Production permissions should enforce the contract. Use acquirer-controlled card capture and authentication, merchant-specific identifiers and approved routing destinations. Restrict service credentials so supplier staff cannot issue refunds, change settlement accounts, draw funds or access bank-account information. Require merchant approval for routing-policy changes, record each instruction's origin and prevent duplicate processing. Security administrators should have an emergency suspension function without authority to redirect transactions. (Design controls derived from PSRs 2017, Schedule 1, paragraph 2(j), and PERG 15.3, Q21 and Q25A–Q25B.)

Before live traffic, test attempted unauthorised refunds, destination changes, duplicate retries and failure of an acquirer connection. Record data categories, access locations, subprocessors, retention and incident handling. The project should clear personal-data transfers through a separate legal and security review. The pilot's product owner should sign off the implementation against the contractual responsibility schedule, while the chosen providers confirm their own acceptance of it. No provider contract or regulator approval is assumed by this proposed checklist. (PSRs 2017, regulations 25 and 36 where outsourcing applies.)

Features requiring a new authorisation assessment

An own-name merchant acceptance agreement is the decisive managed-payments release. It requires assessment for acquiring even where a downstream provider handles every pound. The same release review must cover master-merchant accounts, unilateral selection of new acquirers, acceptance of merchants under the supplier's terms, and pricing that forms part of its own payment undertaking. These facts must be evaluated together against the acquiring definition. (PSRs 2017, regulation 2(1); Schedule 1, paragraph 1(e); PERG 15.3, Q21.)

A separate release gate should cover autonomous refunds, settlement-account mandates, reserves, escrow, split payouts, net settlement and any receipt of customer money. Each can change the existing classification or defeat the technical-service condition. Bank-payment initiation and account-information products need their own review despite a funds-free design. Added UK decision-making authority requires territorial reassessment as well. (PSRs 2017, Schedule 1, paragraphs 1(c), 1(e)–(h) and 2(j); PERG 15.6, Q46.)

The release decision should identify the responsible legal entity, permission or exclusion, principal relationship and approved production powers. Where the company chooses a genuine agency route, the principal must complete the applicable registration and contractual changes before the new service begins. Where it chooses independent UK acquiring, the group should obtain the relevant UK permission before exercising that undertaking. A software deployment should not precede the legal change it implements. (PSRs 2017, regulations 6, 34 and 138.)