Who Weaves the Connective Fabric?

Payments is not just unbundling. It is re-layering.

Two recent moves made that clear.

Stripe has broadened multiprocessor support across its stack and rolled out multiprocessor support for Billing and Radar. Its documentation now shows Stripe Orchestration routing payments created through Billing and Checkout across supported processors, Radar scoring for non-Stripe payments, Billing integrations that work with third-party processors, and Payment Records that maintain a unified history of on-Stripe and off-Stripe payments.¹²³⁴⁵

Worldline, by contrast, finalized the sale of PaymentIQ on March 2, 2026 for approximately €160 million and described the move as part of a strategic refocus on core European payment activities.⁶

Read together, those moves point to something bigger than vendor strategy. They suggest that the value in payments is splitting into distinct layers. Software above the rails is becoming more modular. Processing remains essential, but less differentiating. And the old “middle” — especially when reduced to routing alone — looks less like a strategic destination and more like an incomplete answer.

The market’s misread: orchestration is necessary, but it is not the category

Payment orchestration emerged for a real reason. The moment a business accepts payments through multiple providers, it needs a normalization layer. That layer handles routing, retries, failover, API abstraction, processor switching, and operational resilience. It solves a genuine problem.

But orchestration solves an integration problem, not an economic problem.

It assumes the payment already exists. It asks: Which provider should process this transaction?

That is useful. It is often mandatory. But it is not enough to define the next era of infrastructure.

Because the harder question is not where to send a payment. The harder question is whether a payment should exist at all, what its terms are, who is authorized to create it, whether it must be escrowed, how it should be priced, how multiple events should be aggregated, and when final settlement should occur.

That is not orchestration.

That is coordination.

Why this shift is happening now

1. Software is separating from processing

Stripe’s processor-agnostic moves matter because they confirm that software can be modular relative to processing. Checkout optimization, fraud tooling, subscription logic, and payment records can increasingly sit above multiple processors rather than being inseparable from one acquiring stack.¹²³⁴⁵

2. Processors do not necessarily want to own the middle

Worldline’s divestment of PaymentIQ matters for the opposite reason. It shows that even a major payments company may decide that conventional orchestration is not core enough to remain strategic, especially if the company wants to simplify its portfolio and focus on core payment activities.⁶

3. The transaction itself is changing

The next wave of digital commerce will not be dominated by humans filling out payment forms. It will increasingly involve systems acting on behalf of users, businesses, devices, and agents. Those systems will not transact in neat, infrequent, human-sized payment events. They will transact in data requests, API calls, compute tasks, charging sessions, bandwidth allocations, automated service requests, and machine-to-machine flows.

In that world, routing is not enough. Identity, price discovery, permissioning, conditional release of funds, aggregation, and automated policy enforcement all become infrastructure problems.

The four-layer payments architecture

The payments stack is best understood now as four interacting layers:

Most of the industry still talks as if the missing middle is simply “orchestration.” But that framing is too small. The missing middle is not just a switching layer. It is a control plane for economic activity.

What the connective fabric must actually do

If a true coordination layer is emerging, it must do more than normalize APIs and route transactions. At a minimum, it must do six things well.

Why machine commerce makes this inevitable

A human can tolerate a cart, a billing page, a payment form, and a delayed reconciliation cycle. A machine cannot.

When a machine buys compute, charging, bandwidth, identity verification, sensor data, or API access, the hardest part is not “which processor should handle this?” The hardest part is:

• how the buyer is authenticated
• whether the provider is trusted
• how the service is discovered
• how the price is updated in real time
• whether funds should be escrowed
• whether delivery occurred
• whether many events should be grouped into one settlement event
• whether anomaly signals require intervention

That is why orchestration is not enough. Orchestration can route a payment. It cannot, by itself, create a trustworthy economic runtime for autonomous commerce.

Why incumbents are structurally conflicted

Processors want more processing volume. Software vendors want more software adoption. Networks want more network usage. All of those incentives are understandable. They also create gravity.

A processor-neutral coordination layer reduces dependence on any one processor. A rail-neutral coordination layer reduces dependence on any one rail. A machine-native coordination layer changes the center of gravity from human checkout to autonomous economic events.

That is why this category will be hard for many incumbents to own cleanly. Some will move up into software. Some will move down into core processing. But the coordination layer — if it is neutral enough to matter — sits awkwardly against those incentives.

The historical analogue: VisaNet

If this architecture sounds unfamiliar, the closest historical analogue is not a checkout product. It is a network like VisaNet.

Visa describes VisaNet as infrastructure that enables authorization, clearing, and settlement-related functions, with financial institutions and partners accessing the network directly and smaller businesses accessing it through intermediaries.⁷⁸

That is why the analogy matters. VisaNet is not primarily a storefront. It is a coordination network.

The next coordination layer, however, must do this for a broader economy:

• not just banks and merchants, but devices, APIs, platforms, and agents
• not just card flows, but multiple rails
• not just human checkout, but machine-triggered economic events
• not just approvals, but pricing, escrow, aggregation, and autonomous service execution

That is the leap from payment network coordination to machine-native economic coordination.

Where EMPIC fits

EMPIC should not be understood primarily as another processor, another checkout layer, or another thin orchestration vendor.

EMPIC is better understood as economic coordination infrastructure.

Its role is to sit between service demand and settlement. To authenticate participants. To discover and validate services. To price activity. To create enforceable economic agreements. To aggregate micro-events. To manage fraud and policy. And then to decide how and when final value should move.

That is what makes EMPIC connective fabric rather than just another tool in the stack. It is being built for the layer that appears once software separates from processing, once rails multiply, and once commerce becomes increasingly machine-mediated.

So who weaves the connective fabric?

Not the processor alone.

Not the orchestration vendor alone.

Not the software suite alone.

The connective fabric will be built by platforms that can operate sideways across processors, rails, geographies, channels, and increasingly across autonomous actors. Platforms that can do more than route payments — platforms that can coordinate them.

That means governing identity, pricing, policy, escrow, batching, risk, and settlement as one coherent control plane.

This is the category that matters next.

And this is where EMPIC fits.

The next era of payments infrastructure will not be defined solely by who owns the rails, or by who has the best checkout, or by who can route to the cheapest processor in real time.

It will be defined by who weaves the coordination layer.

It will be defined by who weaves the connective fabric.