The orchestration layer is the new database

In the database world there was a moment somewhere between 2010 and 2014 when the ORM stopped being a thin wrapper and started being the thing. The database underneath became a commodity. Swap Postgres for MySQL and, mostly, nothing in your application code changed. The ORM was the abstraction that mattered, and the database was a plugin under it.

The same thing is happening in payments right now, two years behind the hype cycle and almost nobody is writing about it honestly. The orchestration layer is becoming the load-bearing abstraction. The acquirer is becoming the plugin. If you understand that shift, a lot of the weird behavior in the payments market stops being weird and starts being predictable.

The acquirer used to be the only object in the system. Now it is one row in a routing table. That is the entire story.

1. The old model — one acquirer, one integration

For twenty years the mental model was: pick an acquirer, integrate their API, send them your card data, get an authorization back, collect a batch settlement. The acquirer was the load-bearing object. Everything in your stack depended on which acquirer you picked. Pricing was the acquirer's pricing. The chargeback process was the acquirer's process. The reporting was the acquirer's reporting. Moving acquirers was a six-month project because the acquirer was not a plugin — it was the whole system.

This is the world Stripe won. Stripe was the best-in-class single acquirer with the cleanest API. For one-merchant-one-acquirer use cases it is still unbeaten. But single-merchant-single-acquirer is not the market anymore for portfolios above three brands.

2. The shift — the orchestration layer sits above the acquirer

Orchestration is a deceptively simple idea. Instead of your checkout calling Stripe directly, your checkout calls a layer you control. That layer decides which acquirer gets the transaction based on rules you write — the brand, the BIN, the country, the amount, the vertical, the time of day, the current acquirer's health, the current acquirer's rate on that card type. The orchestration layer normalizes the response back to your application so your application does not care which acquirer actually processed.

That last sentence is the whole game. The application does not care. The moment the application does not care which acquirer processed, the acquirer is fungible. Fungible acquirers compete on price, not on API quality. Fungible acquirers cannot lock in merchants with dashboard UX. Fungible acquirers are plugins under the real system.

What routing rules actually look like

A real routing table for a 12-brand portfolio we run looks like this, roughly:

• Brand A, brand B (low-risk SaaS) — primary Stripe, failover Adyen. Pricing floor 2.3%.
• Brand C (CBD multi-state) — primary high-risk acquirer #1, failover #2. Reserve monitor alerts above 7%.
• Brand D, E (peptide research) — exclusive acquirer, no failover (category scarce). Monthly chargeback ratio cap 0.85%.
• Brand F (kratom) — primary domestic, failover offshore. Auto-switch on 3 consecutive declines per BIN.
• Brand G–L — normalized through orchestration, interchange-plus across Adyen + Worldpay + Checkout.com depending on BIN and country.

No single acquirer could service that portfolio. The orchestration layer makes it possible. The orchestration layer is the system. The acquirers are configuration.

3. The consequence for acquirer pricing power

This is the part the acquirers do not want you to understand. The moment you run orchestration, the acquirer has no pricing leverage over you. If they raise rates, you move the routing rule. If they slow settlements, you move the routing rule. If they add a fee, you move the routing rule. The cost of switching is a config file edit, not a six-month migration.

The average effective rate improvement for operators we moved from direct-to-acquirer to orchestration-layer-above-acquirer: 47 basis points in the first six months, another 18 basis points in the following year as routing rules matured. On a 10M/year portfolio that is $65k of margin you recover because the acquirer can no longer lock you in. See the CFO math post for how that compounds.

Pricing power in payments used to belong to the acquirer. Now it belongs to whoever writes the routing rules. That is a generational shift and most operators have not noticed yet.

4. The consequence for Stripe

Stripe's moat was the API. The API mattered because the acquirer was the load-bearing object. When the acquirer becomes a plugin, the API is just one row in a configuration file. The value moves up the stack to whoever normalizes the APIs together.

Stripe knows this. Stripe has tried to become the orchestration layer — Financial Connections, Terminal, Checkout, Link — all attempts to own more of the stack above the acquirer. None of them have cracked multi-acquirer orchestration for the obvious reason that Stripe cannot be an orchestration layer while simultaneously being the acquirer underneath. It is a structural conflict. See why Stripe will lose the multi-brand market for the longer argument.

5. The consequence for operator risk

When the acquirer is load-bearing, acquirer risk is merchant risk. Stripe freezes your account, you are out of business until it unfreezes. When the orchestration layer is load-bearing, acquirer risk is vendor risk. One vendor goes down, the routing rule fails over to the next one, and the operator keeps processing.

We have watched this save multiple portfolios in the last twelve months. One client had a primary acquirer go down for 72 hours in Q3 of 2025. The orchestration layer failed over to a secondary within 90 seconds of the first declined auth. Revenue loss for the 72-hour event: under 4%. That same event, one year prior, when the client was single-acquirer, cost them 38% of weekly revenue and a two-week reconciliation nightmare.

6. The consequence for data ownership

The orchestration layer sees every transaction from every acquirer in a unified schema. That is the most valuable dataset in a multi-brand portfolio. It is the only place where "what is the true cost of processing at the BIN level across my entire book" can actually be answered. No single acquirer can answer it. Orchestration owns the data gravity.

The operator who owns the orchestration layer owns the reporting. The operator who rents orchestration from someone else rents the reporting. We think this is the single most underrated decision in multi-brand payment architecture — who owns the layer that holds the unified transaction log.

7. The counter-argument

Here is the steelman for acquirer primacy: orchestration adds latency, adds an extra vendor, adds complexity, adds cost. For a single-brand low-volume operator, that overhead is not worth the routing benefit. You run into marginal gain on one acquirer against the fixed cost of operating the orchestration layer. Fair. For a single-brand SaaS doing $2M/year on Stripe, orchestration is over-engineering. For a 5-brand portfolio doing $20M/year across three verticals, not running orchestration is under-engineering.

The other steelman: orchestration providers can become the new lock-in. True. The way you avoid it is by owning the orchestration layer yourself, or running one with open routing logic and a portable export. We think orchestration lock-in is the next wave of bad payment architecture decisions and operators should be asking the same hard questions about their orchestration vendor that they once asked about their acquirer. See orchestration vs aggregation.

8. The adjacent shift — the merchant of record conversation

There is a parallel conversation happening about merchant of record — who is legally the seller, who holds the liability, who receives the funds. The MoR layer is a different abstraction than the orchestration layer but they are converging. In a well-structured multi-brand portfolio in 2026, you have one MoR (a parent merchant) and one orchestration layer routing between multiple acquirers under that MoR. The MoR is the legal structure. The orchestration is the technical structure. Together they make the acquirer a plugin.

9. What to do if you are a mid-market operator right now

If you are between 3 and 20 brands, the decisions in front of you in 2026 are:

• Do you pick an orchestration layer now or wait? (Answer: now, because the switching cost compounds.)
• Do you keep multiple direct acquirer relationships or collapse into one MoR? (Answer: one MoR with orchestration under it.)
• Do you let your acquirer host the orchestration, or do you own it? (Answer: own it, or rent it from a provider whose incentives are aligned with yours — see why we don't charge monthly fees.)
• Do you build the orchestration layer internally or buy? (Answer: almost never build it — the maintenance cost on payment infrastructure is not a good use of your engineering budget.)

10. The prediction

By 2028 the industry will talk about payment processing the way the web industry talks about databases. The acquirer will be a plugin. The orchestration layer will be the system. The operators who understood this shift in 2026 will have a 200–300 basis point cost advantage over the operators who did not. That gap is already opening.

By 2028 the acquirer is a plugin. The orchestration layer is the system. Operators who act on that today have a two-year head start on their competitors.

If you are running a multi-brand portfolio and you are not running orchestration, the first conversation we have with you will be about what your routing rules should look like. Start there.