Module 6

Future-Proofing Your Stack

How to build payments infrastructure that adapts as the landscape shifts, supports emerging payment rails, and scales with your business

---

The Shifting Payments Landscape: What Is Changing and Why It Matters

The payments landscape is in continuous flux. Ten years ago, wallets and mobile payments were emerging. Five years ago, real-time payments networks (RTP, SWIFT gpi, BACS) were becoming operational. Today, central bank digital currencies (CBDCs) are in pilots. In parallel, stablecoins and blockchain payments are attracting merchant and consumer adoption. Open banking (PSD2, PSD3) is enabling new flows. The question is not whether change will happen. It is whether your infrastructure can adapt when it does.

A future-proof payments stack anticipates these changes. It builds in flexibility so that adding a new payment rail does not require re-architecting your core logic. It uses abstraction layers that shield business logic from payment provider details. It separates payment orchestration from transaction settlement so you can evolve either independently.

The cost of not building for change is much higher than the cost of building with flexibility in mind. Every new payment method that does not fit your architecture costs engineering time to retrofit.

Payment Landscape Trends Through 2028

Understanding the trends helps you prioritise which changes matter for your business. Real-time payments (RTP in the US, SEPA Instant in EU, UPI in India, PIX in Brazil) are transitioning from novelty to mainstream. CBDC pilots are accelerating. The Federal Reserve, ECB, Bank of Japan, and others are testing retail CBDCs. Merchant adoption of stablecoins (particularly USDC and USDT) is growing, though from a small base. Open banking payments (paying directly from bank accounts without card networks) are growing in markets with mature infrastructure. Embedded finance (payments as a feature, not a destination) is driving demand for flexible, programmable payment infrastructure. Agentic commerce (AI agents making transactions on behalf of humans) is creating new authentication and spending control requirements.

For most businesses, the immediate priorities are: adding real-time payment support where relevant, preparing for multi-rail routing to support these new rails, and ensuring compliance with emerging regulatory frameworks (PSD3, CBDC participation if relevant).

---

Multi-Rail Architecture: The Foundation for Flexibility

A multi-rail architecture supports multiple payment methods (card, real-time payments, open banking, wallets, BNPL, stablecoins) through a unified orchestration layer. Instead of integrating directly with each payment method provider, your core payment logic talks to the orchestration layer, which routes transactions to the appropriate rail and processor.

Single-Rail Limitations

A single-rail architecture (card-only, for example) works until market conditions change. Card networks dominate in North America and Western Europe, but card penetration is lower in Asia-Pacific, LATAM, and emerging markets. As your customer base grows geographically, card-only becomes a liability. When you finally decide to add local payment methods or real-time payments, you discover that adding a new rail requires changes to your payment handler, reconciliation process, settlement accounting, and fraud detection. The changes compound. What seemed like a simple "add a new processor" becomes weeks of integration work.

A card-only architecture also creates vendor lock-in. If your core payment code expects card-specific fields (card number, CVV, expiry), you cannot easily switch processors or add new payment methods. You have coupled your business logic to the card payment model.

Multi-Rail Architecture Components

A multi-rail architecture has four layers. The client layer (your checkout UI or API) collects payment information. The orchestration layer decides which payment rail to use. The provider layer integrates with individual payment providers (card processors, RTP networks, stablecoin settlements). The settlement layer accounts for funds across all rails and reconciles against your ledger.

The orchestration layer is the key. It abstracts payment provider details from the rest of your system. Your core payment code does not know whether a transaction is going through a card processor or an RTP network. The orchestration layer knows. It also handles routing logic (which processor should handle this transaction based on geography, payment method, amount, risk profile, or cost optimisation). Routing decisions can be changed without touching business logic.

Building vs. Buying a Multi-Rail Platform

Building a multi-rail platform from scratch requires significant engineering. You need to integrate with multiple payment providers (each with different APIs, error codes, and settlement models), build routing logic, handle reconciliation across providers, and support fraud detection across all rails. Estimated effort is 6 to 12 months for a team of two to three engineers, with ongoing maintenance.

Buying a multi-rail platform (like Stripe Payments, Adyen, Wise, or newer platforms like Pine, Spreedly) provides immediate multi-rail capability and ongoing updates as new payment methods emerge. The tradeoff is cost (0.2 to 0.5 percent effective rate premium compared to custom orchestration at scale) and reduced control over routing logic.

Most companies should buy multi-rail capability initially and migrate to custom orchestration only if they reach sufficient scale (over $500 million annual transaction volume) to justify the engineering cost. At smaller scales, the cost of maintaining custom orchestration exceeds the savings.

---

Agentic Commerce Readiness: Preparing for AI-Initiated Transactions

Agentic commerce is the next shift. Today, humans initiate all transactions. Tomorrow, AI agents will initiate transactions on behalf of humans. An AI shopping assistant might place orders automatically when prices hit targets. An AI business intelligence system might execute transfers to settle accounts. An AI travel agent might book flights and hotels. These transactions will be initiated by non-human actors, creating new authentication and control requirements that current payment architectures do not support.

What Your Payments Stack Needs for Agentic Commerce

Agentic commerce requires three new capabilities. Delegated authentication allows an agent to prove it has permission to make transactions on behalf of a human, without requiring the human to authenticate each transaction. This is distinct from recurring billing (where permission is explicit and upfront) or APIs (where a service account authenticates). Instead, it requires flexible delegation policies that specify what an agent can do, up to what limit, for how long.

Machine-readable pricing allows an agent to understand pricing upfront before committing to a transaction. Today, pricing is often discovered through the UI after you add items to a cart. Agents need pricing as an API response so they can evaluate transactions programmatically. This requires exposing pricing information that is typically hidden behind UI.

Programmable spending controls let you set limits on what an agent can spend. An agent might have authority to spend up to $100 per transaction, $1,000 per day, and $50,000 per month. It needs to track against these limits in real-time. Current payment systems do not expose this level of granular control.

Timeline and Adoption

Agentic commerce is not imminent for most businesses. Consumer adoption of capable AI agents is still in early stages (2026). Enterprise adoption is further ahead. A fintech company might enable agents to initiate transfers. A business intelligence platform might enable agents to execute reconciliations. But broad merchant adoption of agentic commerce will take several more years.

The practical advice: understand what agentic commerce requires, but do not over-invest in support today. Include architectural flexibility so that adding agentic support does not require rewriting payment logic. The orchestration layer approach enables this. When you are ready to support agentic commerce, add it to the orchestration layer without touching the rest of your system.

---

Evaluating New Payment Rails: The Decision Framework

New payment methods and rails emerge frequently. Real-time payments, stablecoins, CBDCs, open banking payments, and others all present opportunities and risks. Your decision to adopt should be based on a clear framework rather than hype.

The Four Dimensions of Rail Evaluation

Evaluate new rails on four dimensions: merchant demand, consumer adoption, regulatory clarity, and integration complexity.

Merchant demand reflects whether your customers want to offer the new rail. If you are a payment processor serving merchants, ask: are merchants asking for this? Are they losing sales because we do not support it? A merchant serves customers in a market that prefers a payment method. If competitors offer it and you do not, merchants will switch processors. Merchant demand is the strongest signal for investment.

Consumer adoption reflects whether customers want to pay using the new rail. Even if you build it, if consumers do not use it, the conversion impact is zero. Real-time payments are experiencing strong consumer adoption in some markets (India's UPI, Brazil's PIX) because they are simpler and cheaper than cards. Stablecoins have adoption in specific niches (international remittances, traders) but not mainstream consumer adoption. CBDC adoption depends on regulatory mandates and consumer trust, neither of which is certain.

Regulatory clarity matters because regulatory uncertainty creates risk. If you invest in supporting a rail and regulators ban it (or significantly restrict it), you waste the investment. CBDC adoption depends entirely on central bank policy. Stablecoin regulation is in flux. Real-time payments have clear regulatory frameworks in most developed markets. Open banking payments have regulatory approval (PSD2) in EU and are expanding elsewhere. Evaluate regulatory risk explicitly.

Integration complexity reflects how hard it is to add the rail to your infrastructure. Card integration is well-understood by thousands of processors. New rails often require custom integration or rely on a single processor for access. Integration complexity adds cost and ongoing maintenance burden. If a rail is easy to integrate (many processors support it, clear APIs, good documentation), adoption is lower-risk. If a rail requires custom integration with a single provider, adoption is higher-risk.

The Decision Matrix

Plot new rails on a matrix of merchant demand (y-axis) versus regulatory clarity (x-axis). Adopt immediately for rails with high demand and clear regulation (real-time payments in most developed markets). Adopt cautiously for rails with high demand but regulatory uncertainty (stablecoins, CBDCs). Delay or skip rails with low demand or high uncertainty.

---

The Orchestration Layer as an Insurance Policy

An orchestration layer is not just an operational tool. It is an insurance policy against being locked into a single processor or payment method. It creates flexibility that protects your business as the landscape evolves.

What Orchestration Enables

An orchestration layer enables three critical capabilities. First, processor switching without rewriting business logic. If your current processor fails, raises prices, or loses capability, you can switch to another processor by changing orchestration rules, not by rewriting payment code. The switching cost is days, not months.

Second, selective routing based on business logic. You can route high-value transactions to processors with higher security standards. You can route international transactions to processors with better coverage. You can route transactions with specific risk profiles to fraud-resistant processors. This routing happens at runtime, based on rules you control.

Third, new payment method adoption without core system changes. When a new payment rail becomes important (stablecoins, CBDCs, real-time payments), you add it to the orchestration layer. The layer handles the technical details. Your core payment code does not change. Your business logic does not change. The integration burden shifts from central to peripheral.

Orchestration Layer Architecture Patterns

Three common patterns for implementing an orchestration layer. The gateway pattern wraps a single processor API with a standardised interface. Multiple gateways can then be swapped. The adapter pattern maintains multiple processor integrations and uses business logic to choose which to use. The router pattern sits between business logic and processors, making routing decisions based on transaction attributes.

Most companies start with a single processor (no orchestration needed). As scale or business complexity increases, they build orchestration using one of these patterns. The gateway pattern is simplest (wrap one API, make it easy to swap wrappers). The adapter pattern is most flexible (support multiple processors simultaneously). The router pattern is most powerful (complex routing logic).

The Cost-Benefit Analysis

Building an orchestration layer requires engineering effort. Estimated cost is 4 to 12 weeks depending on complexity and your current codebase. The question is whether the benefit (flexibility, reduced vendor lock-in) justifies the cost.

The benefit is highest for companies that: process payments in multiple geographies (different processors excel in different regions), support multiple business models (which may have different processor requirements), operate at scale (switching costs dominate if even a single percentage point effective rate reduction justifies the investment), or anticipate significant changes to payment methods in the next few years.

For early-stage companies with a single processor and single business model, orchestration is premature. Start with a single processor and build abstraction later when complexity justifies it. For scale-stage companies (especially if processing payments in multiple regions or supporting multiple payment methods), orchestration should be on the roadmap within the next 12 months.

---

Network Tokenisation Migration: The Timeline and Priorities

Network tokenisation is a standards-based replacement for traditional card data storage. Instead of storing the card number (PAN), you store a token unique to that cardholder-merchant-device combination, and only that token works for that combination. This eliminates the security risk of stolen card numbers being reused at other merchants.

Network tokenisation is also called device tokenisation when the token is specific to a device (Apple Pay, Google Pay), and network token when it is specific to a merchant and a payment method stored at that merchant.

The Mandate Timeline

Card networks (Visa, Mastercard, American Express) are mandating migration to network tokenisation. The soft deadline is October 2025. The hard deadline for certain transaction types is October 2026. By 2026, most card networks will require network tokens for recurring transactions and unscheduled transactions unless specific exemptions apply.

This affects most payment systems. If you store card data (even encrypted) for recurring payments, you need to migrate to network tokens. If you rely on card data for 3D Secure verification, you need to migrate to network token authentication.

Implementation Priorities

Network tokenisation is not a one-time migration. It is a multi-year effort with phases. Phase one (2024-2025): support network tokens for new transactions. Your payment processor should support this. Ensure your integration can handle network tokens alongside traditional PAN storage. Phase two (2025-2026): migrate existing recurring transactions from PAN to network tokens. This is operationally complex because it requires co-ordinating with your processor and with customers to re-authenticate. Phase three (2026 onwards): retire PAN storage and rely entirely on network tokens.

The complexity depends on your current architecture. If you store PAN directly, migration is harder. If you use a payment processor that handles tokenisation, migration is simpler (the processor does the work). If you use network-level tokenisation (Apple Pay, Google Pay), you are largely unaffected because those already use network tokens.

The timeline for your business depends on your payment method mix. Companies relying heavily on recurring transactions (SaaS, subscriptions) need to prioritise network tokenisation quickly. Companies processing primarily one-time payments have more time.

---

ISO 20022 Readiness: Understanding the Standard and When It Matters

ISO 20022 is an emerging global standard for financial message exchange. It replaces older standards like SWIFT MT formats (for cross-border payments) and domestic payment standards (like ACH, SEPA). ISO 20022 provides richer, machine-readable payment information, enabling better fraud detection, straight-through processing, and reduced errors.

What Is Changing

ISO 20022 adoption is happening gradually. The US Federal Reserve announced plans to support ISO 20022 messages on the FedWire service (used for high-value bank transfers). SWIFT is adopting ISO 20022 for cross-border payments. Most developed countries are planning domestic payment network upgrades to support ISO 20022.

From a business perspective, ISO 20022 enablement is relevant if you process cross-border payments or high-value institutional payments. If you process consumer credit card transactions, you are not directly affected. If you process B2B transfers or moving money between financial institutions, you need to be aware of ISO 20022 because your processor or bank will require support.

Implementation Timeline

ISO 20022 implementation for most payment corridors is targeted for 2025 to 2027. Implementation is typically led by payment networks and banks, not merchants. If you use a payment processor or banking partner, they will handle ISO 20022 support. You likely do not need to build it yourself.

The practical action: understand whether ISO 20022 applies to your payment flows (usually only cross-border or institutional payments). If it does, ensure your processor has a roadmap for ISO 20022 support. If it does not, continue with current standards and revisit when industry adoption is broader.

---

Building Your 2028 Payments Architecture: The Target State

What should your payments architecture look like in 2028 to be ready for the shifts that are coming? The target state has five characteristics: multi-rail capability, orchestration abstraction, real-time settlement support, regulatory flexibility, and agentic commerce readiness.

Multi-Rail Capability

Your infrastructure supports card, real-time payments, open banking, wallets, and emerging methods. You do not support all methods everywhere. Instead, you support the methods your customers demand in the regions they operate. The orchestration layer makes adding new methods a configuration change, not an engineering change.

Orchestration Abstraction

Your core payment code does not know which processor handles a transaction. The orchestration layer makes that decision based on transaction characteristics, business rules, and provider capabilities. Swapping processors requires changing configuration, not code.

Real-Time Settlement

You support instant settlement for payment methods that enable it (real-time payments, wallets with instant settlement). You use settlement speed as a competitive differentiator for certain customer segments.

Regulatory Flexibility

Your architecture supports compliance with evolving regulations. PSD3 requirements can be added through configuration changes to your compliance layer. CBDC support (when and if you need it) can be plugged into your orchestration layer.

Agentic Commerce Readiness

Your API supports delegated authentication, machine-readable pricing, and programmable spending controls. You do not require consumer authentication for every agentic transaction. Instead, you support upfront delegation with ongoing limit controls.

---

The 12-Month Roadmap: Sequencing Improvements

Knowing the target state is useful. Getting there is a multi-quarter effort. Here is a realistic roadmap for the next 12 months, assuming you are starting with a single-processor, single-payment-method infrastructure.

Months 1 to 2: audit and baseline. Understand current infrastructure, processor relationships, transaction mix, regulatory compliance status, and engineering time spent on payments operations. Identify key gaps relative to the target state.

Months 3 to 4: multi-rail assessment and proof of concept. Evaluate which new payment methods are most important for your customer base. Run a proof of concept with one new method (open banking, real-time payments, or stablecoins). Understand integration complexity and customer adoption.

Months 5 to 6: orchestration layer design and planning. Design an orchestration layer that abstracts your current processor from business logic. Plan phased migration from direct processor integration to orchestration.

Months 7 to 9: orchestration layer implementation and rollout. Implement the orchestration layer. Migrate your core payment flows to use the layer. Verify functionality against your existing processor before adding new processors.

Months 10 to 12: new payment method integration. Add 1 to 2 new payment methods through the orchestration layer. Test multi-method routing. Deploy to production. Gather usage data on which methods customers prefer.

At month 12, you have transformed your payments architecture from single-processor to multi-rail with orchestration. Further improvements (additional payment methods, processor redundancy, agentic commerce support) can be sequenced over the following 12 months based on customer demand and business priorities.

---

Measuring Success: Metrics That Matter

Your future-proofing efforts succeed or fail based on whether they actually create flexibility when needed. Measure success using three metrics.

Time to Add a New Payment Method

Before orchestration, adding a new payment method requires weeks of engineering. After orchestration, it should take days (adding the new provider to the orchestration layer, writing adapter code for that provider, testing). If time to add a new method has not decreased significantly, your orchestration layer is not providing value.

Processor Switching Cost

Before orchestration, switching processors requires rewriting business logic. After orchestration, it requires changing configuration. Measure whether a processor switch can be executed without touching your core payment code. If it cannot, your abstraction is insufficient.

Adoption of New Payment Methods

A future-proof architecture creates optionality. The question is whether you exercise that optionality. Are customers using the new payment methods you add? What is the conversion impact? If you add a new method and it goes unused, investigate why. Either the method does not fit your customer base, or you did not market it effectively. Use this feedback to improve decisions about which methods to prioritise.