Module 6

The Multi-Rail Future

Payment orchestration, smart routing, and how merchants will navigate a world where multiple payment rails compete based on cost, speed, and customer preference

---

The World of Multiple Rails Is Already Here

A customer in the US checking out at an e-commerce merchant in 2026 has multiple payment options available. They can pay with a credit card (Visa, Mastercard, or American Express). They can pay with a debit card. They can pay with a digital wallet (Apple Pay, Google Pay). They can pay with buy-now-pay-later (Affirm, Klarna, Afterpay). Some merchants offer direct bank transfer via ACH or a real-time payment network like FedNow. Some merchants accept peer-to-peer payment apps like Venmo or PayPal. In some cases, merchants accept stablecoins or other cryptocurrencies. The checkout is not a single payment method. It is a choice between competing rails, each with different customer experience, cost, settlement speed, and failure rate.

This fragmentation is the result of technological progress. Ten years ago, cards were the default payment method for almost all merchants. Today, cards are one option among many. Each new rail was created because it solves a problem that cards do not solve. Buy-now-pay-later solved the problem of affording expensive purchases. Digital wallets solved the problem of typing card details repeatedly. Real-time payments solved the problem of settlement speed and cost. Each rail attracted volume because it addressed a real customer or merchant need.

The result is that merchants and payment providers now face a routing problem. When a customer initiates a payment, which rail should it move through? The answer is not obvious. Different rails have different characteristics. The optimal choice depends on the customer, the transaction, the merchant's priorities, and the infrastructure available to the merchant.

The future is not cards replaced by one alternative rail. The future is a portfolio of rails, and the critical competitive advantage is the ability to route each transaction to the optimal rail based on multiple signals.

---

Payment Orchestration: The Critical Layer

Payment orchestration platforms are the software layer that sits on top of multiple payment rails and makes routing decisions. When a customer initiates a payment, the orchestration platform evaluates multiple signals and routes the transaction to the rail most likely to succeed and most optimal for the merchant.

A payment orchestration platform might evaluate signals like:

• Customer location and geography
• Device type (mobile vs. desktop)
• Payment method preference (if the customer has used the merchant before)
• Transaction amount
• Transaction type (one-time vs. recurring)
• Historical failure rates for each rail for this customer and corridor
• Real-time cost of each rail (which varies based on time of day, network congestion, and other factors)
• Customer risk profile (fraud signals)
• Merchant profitability goals for this transaction

Based on these signals, the platform decides: should this transaction go through card networks, real-time payments, ACH, BNPL, or another rail? The decision happens in milliseconds, transparently to the customer. The customer sees their preferred payment method offered first, but the platform has already decided which rail it will route through if the customer selects it.

Smart Routing in Practice

A customer in the UK purchasing a $50 item on a US merchant's website could route through multiple rails. The orchestration platform evaluates:

• Debit card: 99 percent success rate, costs 2 percent, settles next day
• UK A2A via iDEAL or Faster Payments: 95 percent success rate, costs 0.5 percent, settles in hours (through correspondent banking since the merchant is US-based)
• Digital wallet: 97 percent success rate, costs 2.5 percent, settles next day
• BNPL: 88 percent success rate, costs 4 percent, settles in 30 days

For a one-time $50 purchase, the platform likely routes to debit card (high success rate, low cost, acceptable settlement time). For a $500 purchase, the platform might route to A2A if the customer's historical success rate with A2A is high. For a $1,500 purchase where the customer has used BNPL before, the platform might offer BNPL because the merchant's historical data shows BNPL improves conversion for high-ticket items.

This optimization happens per transaction, per customer, per merchant. At scale, smart routing can improve conversion by 3 to 8 percent and reduce payment processing costs by 1 to 3 percent. For merchants processing millions of transactions, this compounds to millions in incremental revenue and cost savings.

---

Who Are the Payment Orchestration Players?

The payment orchestration layer is contested. Several categories of players are building orchestration platforms.

Pure-Play Orchestration Providers

Primer, Gr4vy, and Spreedly are pure-play payment orchestration companies. They build infrastructure that sits between merchants and multiple payment processors, enabling merchants to route transactions to different acquiring banks, payment networks, and payment methods based on smart routing rules. These platforms are gaining adoption among merchants who process sufficient volume to justify paying for orchestration infrastructure.

The pure-play providers' competitive advantage is that they are agnostic. They do not own any of the rails. They can integrate with any payment processor, any acquiring bank, any real-time payment network. Merchants can optimise their routing without lock-in to a particular payment provider.

Payment Service Providers Building Orchestration

Stripe, Adyen, Square, and other payment service providers are building orchestration into their core platforms. These providers already work with multiple payment rails (card networks, ACH, real-time payments, wallets). Adding orchestration is a natural extension. Their advantage is that they already have merchant relationships and can offer orchestration as a value-add feature.

The PSP orchestration offering is not as flexible as pure-play orchestration because the PSP has incentives to route traffic to its own acquiring relationships. But merchants increasingly demand that PSPs offer true multi-rail routing, and the PSPs are responding with more sophisticated orchestration capabilities.

Banks Building Orchestration for Corporates

Large banks (Citi, Goldman Sachs, JPMorgan) are building payment orchestration for corporate customers. A large enterprise might process payments through multiple acquiring banks, multiple payment networks, and multiple geographies. The bank's orchestration platform helps the enterprise optimise routing across all these relationships. This is primarily a B2B offering for large corporates, but the logic is identical to merchant orchestration.

---

Smart Routing Decisions: The Playbook

Payment orchestration platforms make routing decisions based on several decision trees. Understanding these trees helps explain how the multi-rail future will actually work.

Decision 1: Geography and Local Preferences

Different geographies have different payment preferences and infrastructure. A merchant selling to customers in the Netherlands optimises for iDEAL (70 percent of e-commerce). A merchant selling to customers in India optimises for UPI. A merchant selling globally optimises for a portfolio of rails that covers each geography.

The routing logic: if customer location is Netherlands, offer iDEAL first. If customer location is India, offer UPI first. If customer location is US, offer card and ACH/real-time payments. If customer location is UK, offer UK A2A via Faster Payments.

Decision 2: Device Type

Mobile checkout has different characteristics than desktop. Mobile users prefer wallets (Apple Pay, Google Pay) because they reduce friction. Mobile users are more likely to abandon checkout if it requires typing details. Mobile users prefer one-tap payment methods.

The routing logic: if device is mobile, prioritise wallet-initiated payments. If device is desktop, offer card and other methods that require more interaction.

Decision 3: Transaction Amount

High-value transactions have different economics than low-value transactions. For $10 transactions, the cost of payment processing (whether 2 percent or 0.5 percent) is significant. The merchant wants to minimise cost. For $1,000 transactions, the percentage cost matters less. The merchant cares more about conversion and settlement speed.

The routing logic: if transaction value is under $50, prioritise cheap rails (ACH, real-time payments). If transaction value is $50 to $500, prioritise high-conversion rails (cards, wallets). If transaction value is over $500, prioritise fast settlement and cost reduction (real-time payments, BNPL).

Decision 4: Customer History

A returning customer's payment history tells the orchestration platform which rails work best for that customer. If a customer has successfully paid via ACH five times and never used cards, the platform will prioritise ACH. If a customer has high chargeback rates, the platform will avoid card payments and prioritise A2A.

The routing logic: for returning customers, weight historical success rates heavily. A rail that has worked for this customer before is likely to work again.

Decision 5: Failure Rates and Fallback Chains

Payment rails fail at different rates. Digital wallets fail at low rates (less than 1 percent) because the wallet has already verified the payment method. Cards fail at 3 to 5 percent because of issuer declines. Real-time payments fail at 2 to 4 percent because some payment methods do not support RTP. A2A via Venmo or PayPal fails at less than 1 percent because the user is already authenticated.

The routing logic: if a transaction fails on the primary rail, route to a secondary rail. A customer attempts to pay with card, the card is declined, the platform reroutes to ACH. The customer authorises ACH and the payment completes. The customer never sees the card decline. They see one transaction flow from initiation to completion, even though it routed through two different rails.

---

Embedded Finance: When Payments Are Not Separate

The future of payment rails extends beyond e-commerce checkout. Embedded finance refers to payments and other financial services integrated directly into software products. A project management app (like Asana) might offer invoicing and payment processing directly in the app. A freelancer marketplace (like Upwork) might offer payment disbursement directly to contractors without requiring them to link a bank account externally.

Embedded finance requires sophisticated payment orchestration because the financial service provider (the app) does not own the payment rails. It must route through multiple payment providers to achieve coverage. A project management app needs to support payments to contractors in 50+ countries. It needs A2A in some countries, card payments in others, bank transfers in others, stablecoins where infrastructure exists. The app cannot support all these natively. It must orchestrate.

Embedded finance is transforming how customers think about payments. Payments are no longer a separate friction point. They are a feature of the software. A customer invoicing a client does not think "I need to access my payment processor." They click a button in the software and the payment happens. The orchestration layer handles the complexity of routing to the appropriate rail.

This trend will continue. Over the next five years, expect more software products to offer embedded payments. The competitive advantage will not be in building payment infrastructure (that is commoditised by orchestration platforms). The advantage will be in integrating payments so seamlessly that they feel like a native feature, not a separate product.

---

Building for a Multi-Rail World: What Payments Architects Need to Know

If you are building payment infrastructure today, you are building in a multi-rail environment. Understanding which rail to use in which scenario is critical. Here is the framework:

When to Use Cards

Cards remain optimal when: consumer protection matters, rewards programs drive purchasing decisions, universal merchant acceptance is required, the customer is international and unlikely to have A2A infrastructure, cross-border payments are required. Cards should be an option in all geographies because some customers will prefer them.

When to Use Real-Time Payments (FedNow, Faster Payments, UPI, PIX)

RTP networks are optimal when: both parties are in the same country with an RTP network, settlement speed matters (merchant needs working capital quickly), cost is critical (RTP has lower fees), recurring payments (low failure rate), and high-value B2B transactions. RTP networks should be the default for domestic payments in countries that have them.

When to Use Open Banking A2A

Open banking A2A is optimal when: the customer is willing to authenticate with their bank (higher friction, but more secure), the transaction is not time-sensitive, the customer is in a market with mature open banking infrastructure (EU, UK, Australia), cost is critical. A2A should be offered as an option but not the default at checkout (due to friction) except in markets where it dominates (Netherlands with iDEAL).

When to Use Digital Wallets

Digital wallets are optimal when: the customer is on mobile, frictionless authentication is the priority, the customer is already in the wallet ecosystem. Wallets should be the primary option for mobile checkout.

When to Use Buy-Now-Pay-Later

BNPL is optimal when: the customer is making a high-value purchase and financing matters, the merchant's conversion data shows BNPL increases conversion for high-ticket items, the customer's risk profile is good (BNPL providers screen for fraud). BNPL should be offered for high-value transactions but not as the default.

When to Use Stablecoins

Stablecoins are optimal when: cross-border settlement speed and cost are critical, both parties have stablecoin infrastructure, regulatory compliance is manageable, volatility risk is acceptable. Stablecoins should be explored for B2B cross-border payments and remittances, not yet for consumer e-commerce.

The key principle: no single rail is optimal for all scenarios. The merchant's job is to offer a portfolio of rails and route each transaction to the optimal rail based on the scenario. The orchestration platform automates this decision.

---

How the Payment Landscape Will Consolidate

In the next 12 to 24 months, watch for consolidation and specialisation in the payments infrastructure space.

Consolidation of Orchestration Platforms

Pure-play orchestration providers (Primer, Gr4vy, Spreedly) will consolidate with payment processors, acquiring banks, or fintech platforms. The standalone orchestration layer is a valuable product, but merchants want one-stop infrastructure. Expect acquisitions where orchestration companies are integrated into larger payment platforms or where orchestration platforms acquire complementary services.

Specialisation of Payment Processors

Payment processors will specialise by use case or geography rather than trying to be universal. A processor might specialise in B2B payments, leveraging best-in-class orchestration for that use case. Another processor might specialise in emerging markets, building local payment rail integrations. Universal processors (Stripe, Adyen) will remain important, but will face competition from specialised providers.

Rise of Embedded Finance Providers

Software companies will increasingly embed payments as a native feature rather than integrating a third-party provider. Expect middleware platforms to emerge that make embedded payments easier to build. These platforms will bundle orchestration with compliance, settlement, and reporting.

The Question of Card Network Survival

Card networks (Visa, Mastercard) will remain relevant but will face pressure on volume and on pricing. In markets with mature RTP and A2A infrastructure, card volume is already flattening. Card networks will need to offer new value propositions beyond settlement. They are exploring real-time settlement, embedded finance integration, and risk management services. If they do not adapt, their margin pressure will worsen.

---

What to Watch Over the Next 12 Months

Several key developments will shape the multi-rail payment landscape in 2026-2027.

Nexus adoption: Watch whether central banks adopt Nexus for cross-border RTP linkage. If Nexus is implemented successfully in a cohort of developed economies, it will accelerate the shift to RTP for international payments and pressure correspondent banking.

Stablecoin adoption in B2B: Watch whether stablecoin infrastructure expands into more corridors and whether regulatory clarity improves. If stablecoins become the default for B2B cross-border payments in even one major corridor (US to EU, or Asia-US), the economics of stablecoin infrastructure will improve dramatically and accelerate adoption elsewhere.

Real-time payment network volume growth: Monitor whether FedNow and Faster Payments volume growth accelerates. If RTP volume reaches 10 to 15 percent of total payment volume in any major market, the economics will flip decisively in favour of RTP and away from cards for domestic payments.

ISO 20022 migration completion: Track whether the migration from SWIFT MT to ISO 20022 completes on schedule. If migration happens smoothly, new cross-border infrastructure will be easier to build. If migration is delayed, cross-border modernisation will slow.

Consolidation in orchestration: Watch for acquisitions of pure-play orchestration platforms. These acquisitions will indicate that standalone orchestration is consolidating into larger platforms and that orchestration as a service is maturing.

Payment AS a feature adoption: Track how many new software products launch with embedded payments in 2026-2027. If embedded payments adoption accelerates, it will signal that payments are becoming a standard feature of software, not a niche offering.

---

The Payments Architect's Playbook for 2027 and Beyond

If you are building or managing payment infrastructure, here is the playbook for the next 18 months:

First, do not assume cards remain the default. In many markets, they should no longer be. Evaluate your customer geography and identify which payment rails dominate in each market. Prioritise building infrastructure for the rails that will capture most of your volume.

Second, build for multi-rail from day one. If you build for cards first and add other rails later, you will pay a higher integration cost and will face architectural compromises. If you design for multi-rail from the start, you can optimise routing and orchestration as new rails emerge.

Third, invest in orchestration logic. The competitive advantage in payments over the next five years is in orchestration, not in any single rail. Build or buy orchestration that can route based on geography, device, amount, history, and cost. This orchestration will become increasingly critical as the number of viable rails expands.

Fourth, stay flexible on new rails. Stablecoins, CBDC, and other emerging rails will continue to be invented. Build your infrastructure so that new rails can be added without redesigning the whole system. Modularity matters.

Fifth, understand the economics of each rail in your market. The optimal routing decision depends on the cost, failure rate, and customer preference for each rail in your specific geography and use case. What works for a UK e-commerce merchant will not work for a US merchant. What works for one-time purchases will not work for recurring payments. Understand your specific scenario deeply.