• Oleg Ishchenko, Sales Manager at Corefy


• 10.08.2026 08:15 am
#payments

Picture a Tuesday night. Your main provider in Brazil starts timing out — not failing outright, just hanging. Checkout looks fine. The dashboard looks fine. Your approval rate is quietly bleeding out, and nobody notices until the morning report lands.

The fix is a five-minute configuration change. But getting to that change takes three days, two engineers, and a Slack thread forty messages long.

That's usually the moment a business starts shopping for a payment orchestration platform. And that's also the moment things get confusing, because every platform on the shortlist promises the same five things: faster integrations, higher approvals, better routing, unified reporting, access to hundreds of providers.

The differences only show up once you're running real traffic across several providers, markets, methods, and legal entities. Here's what I'd recommend to look at.

First, name the thing that's broken

Before booking a single demo, I'd recommend writing down the constraint you want removed. Otherwise, a good demo will impress you with capabilities that change nothing.

The usual symptoms:

• Integrations take too long to build and longer to maintain.

• Routing rules live in three places, half of them hard-coded into the app.

• Every provider reports transactions differently, so approval performance can't be compared like-for-like.

• Reconciliation runs on spreadsheets and detective work.

• Adding one payment method turns into a cross-departmental project.

• Switching traffic during an outage takes longer than the outage costs.

None of that is really a technology problem. It's what happens once a business becomes a multi-provider operation without a layer that manages the providers.

Corefy's State of Payment Maturity 2025 study puts a number on how common this is. Across 672 completed assessments, 58.5% of businesses were still at the 'Fragmented payments' stage; only 11.7% had reached the more advanced Responsive or Agile stages. Manual handling has nearly disappeared, but genuine adaptability is still rare.

That's the baseline a payment orchestration platform is meant to fix: replace fragmentation with standardized flows, shared data, and a fast path to change.

Connector count is the most overrated number in this category

A large connector library does help — more providers, fewer builds, faster entry into a new region. But an integration is only worth what it actually supports. A connector library works like a phrasebook: a few hundred phrases you can't actually pronounce lose to fifty you speak fluently.

So for each connector that matters to your business, I'd ask:

• Does it cover refunds, recurring payments, tokenization, disputes, payouts, and the asynchronous statuses that arrive hours later?

• How are that provider's error codes normalized into a common model?

• How fast does the platform absorb the provider's API changes?

• Can you keep your own account and your own commercial terms?

This gets more pressing as portfolios grow. In the same research I mentioned above, the share of businesses running five or more providers rose from 24.6% in 2024 to 37.1% in 2025, while single-provider reliance dropped from 41.3% to 33.5%.

Depth is the actual argument here. A platform with fifty deeply supported integrations is more useful than one with a long but shallow connector list, because 'deeply supported' has a specific shape: every flow the business needs is covered, not just the happy path; error codes read the same way across providers instead of forcing a translation layer; a status change two days after the original transaction updates the record instead of silently going stale. Ask any vendor to show you that shape connector by connector, rather than quoting a total.

Routing and cascading: judge them together

Routing decides where a payment goes first. Cascading decides what happens after that attempt fails. They're one decision path, so evaluate them as one thing.

Reliable routing should be making live decisions on signals like country, currency, amount, method, card type, BIN range, merchant category code, customer segment, provider limits, cost, and how a given provider has been performing this hour. It should also let the payments team see and adjust that logic directly through a visual rule builder, not a backlog ticket. The more signals it acts on, and the more exposed that logic is, the more control you actually have over where a transaction goes.

What matters more: can your team see why a transaction went where it went? Which rule won, whether the intended route was actually followed, and what changed after someone edited a rule on a Friday afternoon. Without that visibility, routing is a black box that happens to be automated, and automation without visibility is just someone else's opinion running your traffic.

Where 'omnichannel' actually means something

Reconciliation stays fragmented once online, mobile, marketplace, and alternative payment flows run through separate systems and get reported separately, even when the transactions themselves are unified at checkout. A genuine omnichannel payment orchestration strategy solves that, but it's worth being precise about what it covers.

In payments, 'omnichannel' is often used to include point-of-sale, and a platform that only processes card-not-present transactions shouldn't claim coverage that includes the shop floor. What a digital orchestration layer actually delivers is consistency across digital flows: same transaction states, same decline codes, same reporting model whether the payment started on a website, an app, a marketplace checkout, or a local payment method. That's still a genuine and underserved problem for most businesses. A retail group running in-store terminals alongside a web and app presence will need a separate solution for the physical side — digital-only orchestration won't cover that half, and no platform should imply otherwise.

Normalized data is the whole foundation

Every provider has its own identifiers, status model, decline wording, time zone, settlement structure, and report format. Without normalization, the team spends days translating one provider's version of a transaction into another's.

Messy data quietly blocks everything downstream: comparing providers, finding the cause of an approval-rate drop, investigating incidents, automating reconciliation, calculating true processing cost, running a routing experiment, reporting consistently across entities.

Corefy's State of the Payment Manager Role 2026 report looked at 112 job descriptions, and reporting and analytics came out as the most frequently mentioned responsibility, appearing 69% more often than PSP management, the next cluster down. Data and analytics was also the largest hard-skill category in the same dataset.

That tells you what you're really buying. Analytics isn't a screen bolted on after processing; it's load-bearing. Which is why I'd push any vendor to demo the ugly cases, not the happy path: a timeout, a soft decline, a chargeback, a partial refund, a duplicate attempt, a transaction whose status changes two days later. That's the demo that tells you something.

Can your team change things without an engineering cycle?

This is the cleanest single measure of value a payment orchestration platform can offer. In the same Payment Maturity study, 27.8% of respondents said adding a new provider was either a significant project or took several months. Long cycles usually mean provider-specific logic is scattered through internal systems, so every change drags workflows, testing, reporting, and training behind it.

Orchestration should give the business one consistent layer to build against, while provider differences get handled behind it — not zero engineering, but noticeably lighter engineering on the routine stuff.

Test the routine stuff directly in the demo: add a route for one market, turn a provider off, reorder fallbacks, launch a local payment method, write a rule for a new legal entity, expose a new field in reporting, compare performance before and after the change. If any of those need a support ticket, the platform hasn't removed the constraint — it's just moved it somewhere less visible.

At scale, it's a governance product

The bigger the company, the less useful it is to evaluate a payment orchestration platform as a standalone routing engine. Enterprise payment orchestration has to support organizational complexity — multiple brands, merchant accounts, regions, currencies, teams, and permission levels — on top of everything already covered.

That means:

• role-based access control

• separate environments and approval workflows

• configuration history and audit logs

• versioning and rollback on routing changes

• retention and export controls

• defined incident procedures with clear service levels.

Security, compliance, and data residency belong at the start of the evaluation, not the final week of procurement. A technically excellent platform that can't satisfy the business's governance model is still a no. The same logic applies to scale itself: ask not just about peak transaction throughput, but how the architecture handles traffic spikes, provider latency, queued callbacks, failover, and delayed status updates arriving out of order.

Watch how they run discovery

Even a mature platform depends on the people implementing it. During selection, pay attention to the questions the vendor actually asks. Do they want to understand the provider contracts, the flows, the markets, the decline structure, the reconciliation process, who owns what internally? Or do they head straight for the standard deck?

In my experience, the quality of discovery predicts the quality of the eventual implementation almost every time. A team that pushes back on assumptions before signing is a team that will push back on a bad routing rule later.

Price the whole thing: connector fees, transaction fees, support tiers, implementation charges, custom development, data retention, volume commitments — all of it can materially change the total cost. A lower platform fee isn't a lower operating cost if the business still needs two engineers to hold it together.

The question almost nobody asks: how do you leave?

A payment orchestration platform gets deep into a company's infrastructure fast, which makes portability worth asking about before signing, not after. What happens to stored tokens, provider credentials, transaction exports, routing configurations, and historical data? What would it take to add a direct connection, move to a different orchestrator, or bring part of the stack back in-house?

The entire point of orchestration is to reduce dependency on any single payment provider. It shouldn't hand that dependency to a new one wearing a different logo. A strong platform gives the business more options and makes the payment stack easier to evolve, and easier to leave, if it ever comes to that.

Final thought

The right platform answers a fairly unglamorous question: will this make payments easier to run as the business gets more complicated? That means looking at how it normalizes data, explains its own routing, governs change, survives failure, and supports reconciliation, while being clear-eyed about what stays manual, what still needs engineering, and where new dependencies land.

The technology matters, but the value shows up in what the team can actually do with it: launch faster, react sooner, understand performance, and improve payments continuously instead of once a quarter. That's the difference between a connector hub and something a business can actually run its payments operation on.