Payment Orchestration in Europe: Legal and Vendor Due-Diligence Questions

Important: This article provides general information only and is not legal advice. Payment-services analysis depends on the exact product, money flow, jurisdictions, contracting entities and regulated activities. Obtain advice from qualified counsel for your specific model.

Payment teams increasingly want one technical layer in front of several acquirers, PSPs and payment methods. The engineering case is easy to understand: one integration can reduce provider-specific code, centralise routing and make it easier to add or remove payment connections.

The legal analysis is less tidy because “payment orchestration” is not itself a licensing category. Two products can use the same label while playing very different roles. One may only pass technical messages between a merchant and its contracted PSPs. Another may control onboarding, hold credentials, influence settlement, provide regulated payment services through an affiliate or bundle third-party services into a wider commercial arrangement.

That is why counsel should start with the actual architecture, not the marketing name.

Start by drawing the payment flow

Before reviewing terms, draw the transaction from the customer's action to final settlement. A useful map identifies every entity that touches money, payment credentials, authentication, transaction instructions or settlement data.

At minimum, document:

• the merchant or fintech customer;
• the orchestration or gateway layer;
• each PSP and acquirer;
• card schemes or alternative payment rails;
• authentication providers where separate;
• token or vault providers;
• fraud and risk vendors;
• settlement accounts and safeguarding arrangements where relevant;
• data processors and hosting locations;
• subcontractors that can affect service continuity.

Then mark the contracts between those parties. A common source of risk is assuming that a technical connection also creates a legal relationship. It may not. The merchant may still need direct agreements with underlying PSPs or acquirers, and the orchestrator may be only a technology vendor.

Payment orchestration is not a substitute for licensing analysis

A platform can route payment instructions without necessarily becoming the regulated payment institution in the chain. Equally, a business that describes itself as a technology provider can still perform activities that require closer regulatory analysis depending on the facts.

The right questions are functional:

• Who receives the payer's instruction?
• Who executes the payment transaction?
• Who contracts with the merchant for acquiring or payment services?
• Does any vendor hold or control client funds?
• Who provides payment-account functionality?
• Who is responsible for strong customer authentication where it applies?
• Who decides whether a transaction is accepted, routed or retried?
• Which entity appears in settlement and scheme records?

For EU and EEA partners, the European Banking Authority maintains a central register of payment and electronic money institutions under PSD2. It is a useful verification tool, alongside the relevant national competent-authority register. Check the exact legal entity and authorised activities rather than matching only the brand name.

Verify the role of the orchestration vendor

Some orchestration products are intentionally positioned as a layer above the merchant's existing provider relationships. topropay, for example, describes itself as a routing layer for merchants connecting to acquirers and PSPs.

That positioning is useful context, but it is not the end of diligence. Counsel and compliance teams should verify the contractual implementation: who the merchant signs with, who the underlying providers are, what data the orchestration vendor receives, whether it can change routes or providers, and what happens if the vendor relationship ends.

When reviewing a payment orchestration layer, focus on the division of responsibility rather than assuming that “one API” means “one regulated counterparty”. The technical surface may be unified while the legal and operational relationships underneath remain plural.

Review every underlying payment partner

An orchestration platform can make it easier to connect to providers, but it should not turn them into a black box.

Ask for a current list of the providers that may handle your transactions. For each material provider, record:

• legal name and group structure;
• home regulator and licence or registration status where applicable;
• countries and services covered;
• acquiring or processing role;
• settlement path;
• subcontractors relevant to your service;
• data locations and transfer mechanisms;
• material security certifications or attestations;
• incident and business-continuity contacts.

If the orchestration vendor can add or replace underlying providers without approval, the contract should define the notice process and any right to object where a change creates regulatory, security or commercial risk.

Follow the money, not just the API

The most important legal distinction often sits in the funds flow.

Map where the customer's money goes after authorisation. Identify the entity that receives settlement from the acquirer, any safeguarded account, the merchant settlement account and any intermediary that can control or delay funds.

Questions to resolve include:

• Does the orchestration vendor ever receive or hold merchant or customer funds?
• Are payouts made by the PSP or by another entity?
• Who can impose reserves, holds or settlement delays?
• Which contract governs chargebacks and negative balances?
• What happens to unsettled funds if a provider fails or a contract terminates?

Do not infer answers from the dashboard. The settlement statement, regulated-entity contract and bank-account structure are stronger evidence.

Allocate SCA and authentication responsibilities

For European online payments, strong customer authentication and related technical standards can affect checkout design. The relevant payment service provider remains responsible for applying the rules that attach to its role, even when technical components are outsourced.

A multi-provider setup can make this operationally complex. One route may use a provider-hosted authentication flow while another relies on merchant-side components. Exemptions, challenge handling and 3-D Secure data may also differ by route.

The contract and technical design should therefore identify:

• who determines whether SCA is required;
• who requests an exemption where available;
• who controls 3-D Secure configuration;
• what authentication evidence is stored;
• how routing works after an authentication step;
• whether rerouting can invalidate or complicate prior authentication;
• how failures are logged and investigated.

This is an area where engineering diagrams and legal responsibility matrices should agree.

Treat payment data as a separate diligence workstream

Payments can involve cardholder data, account identifiers, customer details, device information, transaction metadata and fraud signals. Different vendors may act as processors, independent controllers or regulated recipients depending on the data and purpose.

Build a data map that records:

• data categories sent to each provider;
• purpose of the transfer;
• controller/processor role;
• hosting region;
• subprocessors;
• international-transfer mechanism where required;
• retention period;
• deletion and export process;
• security incident notification path.

If the architecture uses tokenisation or a hosted payment page to reduce the merchant's exposure to raw card data, confirm exactly which components are in scope and obtain the appropriate PCI DSS evidence from the relevant service providers.

Put routing governance in writing

Routing is a product feature, but it can also affect cost, customer outcomes, risk and contractual obligations.

A routing policy should say what factors may influence a decision. Examples may include geography, payment method, currency, provider availability, transaction risk, commercial rules or previous soft declines.

The governance questions are straightforward:

• Who can change routing rules?
• Is there four-eyes approval for material changes?
• Are changes logged?
• Can the vendor change algorithmic logic without notice?
• Can the merchant override a route?
• Are there routes the merchant is legally or contractually prohibited from using?
• How are retries limited to prevent inappropriate duplicate attempts?

If machine-learning or adaptive decisioning is involved, ask for enough explanation and logs to understand material route decisions during an incident or dispute.

Contract for resilience, not just uptime

A payment contract should do more than promise a percentage uptime figure.

Review:

• service-level definitions and exclusions;
• incident severity levels;
• notification times;
• support availability;
• recovery objectives;
• failover testing;
• business-continuity testing;
• dependency on specific cloud regions or subcontractors;
• historical incident disclosure where appropriate;
• rights to receive post-incident reports.

For an orchestration layer, also ask what happens if the layer itself is unavailable. A merchant with three acquirers can still have a single point of failure if all three routes depend on one untested orchestration service.

Reconciliation and auditability matter

Multi-provider architecture should not make the payment trail harder to reconstruct.

The merchant should be able to connect an order to the orchestration transaction ID, the provider transaction ID, authentication result, capture, refund, dispute and final settlement entry.

Contractual and technical diligence should therefore cover:

• stable identifiers across systems;
• downloadable transaction and settlement data;
• retention periods;
• access to logs after termination;
• reconciliation frequency;
• handling of partial captures and refunds;
• dispute evidence;
• audit and regulator-access rights where relevant.

If a provider promises “one ledger”, test whether that ledger can be reconciled to underlying provider statements rather than treating the abstraction as the only record.

Plan the exit before signing

Payment migrations are painful when token portability, transaction history and provider relationships have not been considered at the start.

The exit clause should answer:

• Can the merchant keep direct provider contracts?
• Can stored tokens be migrated in a compliant form?
• How long will transaction and settlement data remain available?
• What assistance is provided during migration?
• Are there fees for export or transition?
• How are live refunds, disputes and chargebacks handled after termination?
• Can the merchant continue processing directly with an underlying provider?

Avoid making “we can always switch later” an assumption. Put the switch mechanics in the contract.

A practical diligence checklist

Before approving a payment-orchestration vendor, confirm that the file contains:

1. A current payment-flow diagram.
2. A list of all contracting and regulated entities.
3. Regulatory-register checks for relevant PSPs and EMIs.
4. A funds-flow and settlement map.
5. A responsibility matrix for SCA, fraud, refunds and disputes.
6. A data-flow map and GDPR analysis.
7. PCI DSS evidence relevant to the implementation.
8. Subprocessor and critical-dependency details.
9. Routing governance and change controls.
10. Incident, resilience and failover terms.
11. Reconciliation and audit-access provisions.
12. A workable exit and data-portability plan.

The legal work should mirror the architecture

Payment orchestration can reduce engineering sprawl, but the legal structure underneath should remain visible. The safest review does not ask whether the vendor is a “gateway” or an “orchestrator” and stop there. It asks who performs each function, which entity is authorised where necessary, who controls money and data, and how responsibility moves when a transaction is rerouted.

When the contracts, system diagram and operating model tell the same story, a multi-provider payment stack becomes much easier to govern. When they tell different stories, the gap is where risk tends to accumulate.