What does a payment orchestration platform really do for your payments stack?

• A payment orchestration platform is not another processing layer. It does not move or settle money, but instead decides how each payment should move through the available providers.

• For PSPs, ISOs and ISVs, orchestration helps reduce dependency on a single provider, acquirer or terminal setup by creating a control layer above the existing stack.

• In-person payment orchestration is different from ecommerce orchestration because it has to account for terminals, certifications, estate management and store-and-forward behavior.

• A vendor-agnostic orchestration layer can make it easier to add providers, change acquirers, improve routing and manage payment methods without rebuilding the underlying integrations.
  

Don't have time to read more now? Sign up to our newsletter to get the latest insights directly in your inbox. 

Most articles about payment orchestration focus on merchants. That context is useful: it explains how orchestration can connect gateways, improve approval rates and simplify multi-PSP management.

But it only gets you part of the way if you’re the PSP, ISO or ISV expected to provide the payment capability.

For you, the challenge is different. How does this layer fit into your platform? What does it change about your unit economics, go-to-market model and provider relationships?  And, critically, what does it mean when orchestration covers in-person transactions - not just online checkout?

This article looks at payment orchestration from that provider-side perspective. It explores stack architecture, real-world capabilities and practical decisions - including why in-person payment orchestration needs to be treated as its own category, rather than ecommerce orchestration with a terminal bolted on.

The terminology around payment technologies is notoriously blurry. Terms like “platform”, “gateway” and “orchestration layer” often get used to mean the same thing, depending on who’s selling what. That lack of consistency creates real friction when you’re trying to make decisions about architecture or product design.

A clearer way in is to look at each layer through the job it performs. That makes it easier to understand how they fit into the stack and what each one means in practice for a PSP or ISV.

The important point is this: orchestration isn’t another processing layer in the stack. It doesn’t move money, and it doesn’t settle transactions - it decides how the money moves.

Orchestration owns the logic, the routing rules, the fallback sequences, the token vault, the consolidated data layer, while the underlying gateways and processors still do what they do.

For PSPs and ISVs, this changes the structure of the stack. Orchestration becomes a layer you can control and build on, without being tied to a specific provider or merchant setup.

The orchestration platform handles the decisions that sit between your merchants and their payment providers. Here's what that looks like when it’s running live, and what it changes for PSP and ISV product teams:

Acquirers can be added or swapped without rebuilding integrations, and improvements in routing can be passed through to merchants as part of the overall offering.

These capabilities take your product from “we connect you to a single provider and leave it there” to “we give you intelligent control across all your providers”. That’s a different model altogether - and one that's much harder for a single-acquirer setup to replicate.

Payments architecture often looks clean in diagrams, but real stacks are messier once multiple providers sit underneath. Here's how it actually looks, both online and in-person, before and after an orchestration layer.

Online payments today (single PSP setup)

Most stacks still send every online transaction down a single path:

If that PSP goes down or experiences disruption, there’s no alternative route for the payment.

Online payments with an orchestration layer

With orchestration, your own platform talks to a control layer first, which then chooses the best route:

Here, the orchestration platform applies your routing rules. If the first provider fails it can retry via another - but you still get a consistent way to add or remove providers as your setup grows.

In‑person payments today (hard‑wired to one host)

In many estates, the terminal is still locked to a single host or acquirer:

Even small changes, such as adding a new acquirer, can trigger new integration and certification work.

In‑person payments with an orchestration platform (Aevi‑style)

With in‑person payment orchestration, the terminal or POS software talks to the cloud first, not directly to a single host:

The orchestration layer determines where each transaction is sent. Routing decisions can change without changes to the terminal, so providers and payment methods can be added or replaced without reworking the terminal estate.

Aevi’s orchestration platform is built for this reality: device-agnostic and cloud-based, it’s designed specifically for the physical complexity of in-person payments, with terminal estates, estate management and provider flexibility built in from day one - rather than adapted from an ecommerce orchestration model.

For PSPs, ISOs and ISVs, orchestration becomes valuable when it removes problems that would otherwise sit inside your own product, integration, or engineering teams. 

The impact is commercial as much as technical: slower launches, higher integration costs, weaker provider flexibility and payment performance that becomes harder to improve at scale.

Most PSPs and ISVs have inherited a patchwork of integrations: one gateway for domestic cards, another for cross-border, a third for a key vertical, and a local scheme bolted on per market. In-store, you add terminal vendor dependencies on top. 

In-person estate management is where stack complexity becomes genuinely painful. Different terminal manufacturers, local certification requirements, firmware update cycles, and store-and-forward behavior all add complexity at the device level.

An in-person orchestration platform like ours handles this at the infrastructure level, so your product and engineering teams can focus on the merchant experience rather than terminal estate operations.

That means faster rollout and less duplicated certification work being held back by the limitations of the terminal estate.

The “walled garden” issue shows up differently for PSPs and ISVs than it does for merchants. If your token vault lives inside a specific PSP's infrastructure, merchant migration becomes more complex - and your own ability to change providers is constrained.

A vendor-agnostic orchestration layer separates commercial decisions from the technical stack.

You can change acquirers or add providers freely and still respond to pricing changes without rebuilding integrations, so margin and product strategy aren’t dictated by whichever vendor relationship is hardest to unwind.

You can hear more on this from Nadim in 'Breaking the walled garden in payments'.

Online payments are already heavily orchestrated. E-commerce has already embedded routing logic and tokenization into their payment environment, with multiple providers running through the same setup.

In-person payments technology hasn’t followed that path. It still runs on fixed terminal estates, provider-specific certifications, and tightly coupled acquirer relationships, which makes change slow and fragmented.

That gap is where orchestration becomes relevant - as a way to move decisioning out of the terminal layer and into something configurable.

Our global payment platform is built around that idea, with in-person payments treated as software infrastructure rather than a hardware dependency. And once that happens, the stack opens up.

Use this checklist to see whether your current payments setup is making change harder than it should be.

If you're a merchant:

• You're routing all transactions through a single gateway and seeing avoidable declines
• You're expanding into new markets and hitting new local scheme or APM requirements
• You run both online and in-store payments, and they're managed in completely separate stacks
• You want to switch acquirers or add a provider without a six-month integration project

If you're an ISV:

• Your payment integration is tied to a single provider’s SDK or certification path
• Merchants ask for additional acquirer or APM options, but each one requires new integration work.
• You want to offer payments as a core part of your platform, not just an add-on
• You serve sectors with in-person requirements (retail, hospitality, fuel & mobility), and your current stack can't handle estate complexity at scale

If you're a PSP or acquirer:

• Your product roadmap is blocked by per-acquirer certification cycles
• Adding a new market or payment method requires significant engineering effort each time.
• You're losing merchants who want multi-acquirer flexibility you can't offer
• Your in-person setup is tied to specific terminal vendors, and you carry estate management costs that should sit at the infrastructure level

• A vendor-agnostic platform should connect into your existing providers rather than locking you into new ones or replacing what’s already there.
• For in-person payments, it should be cloud-based and device-agnostic - working across terminal manufacturers instead of being embedded in a single hardware stack.
• It should separate decisioning from processing, so routing rules, tokenization, reporting, and retry logic are controlled by you, not individual providers.
• Data access should be open, allowing you to build services and reporting on top of the aggregated data without relying on a vendor’s reporting tools.
• In-person capability should be treated with the same importance as online, with estate management, remote configuration, multi-acquirer routing, and store-and-forward handling built in rather than treated as add-ons.

Aevi’s platform was built with these criteria in mind: cloud-native, device-agnostic, designed from the ground up for in-person payment orchestration alongside online, and built to operate across complex in-store estates.

If your current setup is making it harder to add providers or scale your product across markets, it’s worth seeing how a vendor-agnostic orchestration layer could change that. Talk to Aevi today.