PSPs build payment orchestration layers to govern all their merchants at once. The architecture coordinates five core layers: acquirer/MID portfolio management, merchant-configurable routing, risk-aware routing, white-label tenant isolation, and cross-acquirer settlement. When teams skip risk-tiering or multi-tenancy during initial design, acquirer-to-merchant assignments remain manual operational bottlenecks. Building these five layers into a unified custom payment orchestration platform transforms fragmented acquiring relationships into a scalable and automated multi-tenant product.
Most PSPs already route across a handful of acquiring banks, but which acquirer and MID a given merchant lands on is still a manual call made by whoever knows the portfolio best. That call means the PSP itself has to manage an acquirer/MID portfolio, tier routing against underwriting risk, and expose merchant-facing controls without exposing that portfolio. Left manual, that knowledge never scales past the handful of people who hold it, and routing stays a support task instead of a merchant setting.
That gap gets more expensive to ignore as the market grows. The payments industry generates roughly $2.5 trillion in annual revenue from about 3.6 trillion transactions worldwide, and the 2025 McKinsey Global Payments Report frames the industry as increasingly fragmented across competing regional and infrastructure models. At that scale, ad hoc acquirer management stops being a workable shortcut and starts being a liability. Staying ahead of that fragmentation means treating orchestration as the PSP’s own architecture rather than a feature merchants ask for.
Why PSP-Side Orchestration Is a Different Architecture Problem Than Merchant-Side Orchestration
The distinction between payment gateway vs payment orchestration starts with scope and multi-entity control. While a standard gateway simply processes transactions for a merchant, orchestration abstracts routing logic across multiple endpoints, and for a PSP, that abstraction operates at a fundamentally different scale.
A merchant’s orchestration layer routes one business’s transactions across gateways that business chose. A PSP’s orchestration layer routes hundreds of merchants’ transactions across a portfolio of acquiring banks and MIDs the PSP itself manages commercially. Routing decisions for a PSP aren’t just about approval rate and cost. They also have to respect each merchant’s risk tier, underwriting status, and which acquirers will accept that merchant’s vertical. Consequently, a PSP’s orchestration layer requires multi-tenancy, risk-tiered routing, and acquirer-portfolio management as core architectural pillars.
This shift toward direct risk ownership mirrors the industry trade-off Bain & Company identifies one level up in how platforms structure their payments partnerships. Bain’s analysis of European SME commerce platforms notes that a full payments-facilitator model means the provider itself manages onboarding, risk, and settlement directly, at the cost of heavier compliance and technology investment than lighter partnership models. Risk ownership and architectural ownership move together at the platform level, which is why a PSP cannot treat risk as an afterthought once the routing engine has already made its decision.
Oleksandr Boiko
Delivery Director at SPD Technology
“A PSP that treats its acquirer portfolio the way a merchant treats a gateway list is solving the wrong problem. A gateway list is something you set up once and leave alone. An acquirer portfolio is commercial infrastructure the PSP has to keep managing, for hundreds of merchants who never even see it.”
The Five-Layer Architecture for a PSP’s Payment Orchestration Layer
The table below summarizes the core architecture. Each layer requires a specific design decision, skipping any of them keeps your routing manual instead of self-service.
Layer | Responsibility | Key Design Decision |
|---|---|---|
1. Acquirer & MID portfolio | Manages the PSP’s own acquiring bank relationships and available MIDs as routable inventory | Acquirers and MIDs modeled as configurable entities with eligibility rules, not hardcoded per merchant |
2. Merchant-configurable routing | Lets merchants influence routing without exposing acquirer credentials or portfolio details | Self-service routing rules exposed through the platform’s own API/dashboard, abstracted from acquirer specifics |
3. Risk-aware routing | Ties routing eligibility to each merchant’s risk tier and underwriting status | Underwriting/risk data feeds the routing engine directly, not as a separate manual override process |
4. Multi-tenancy & white-labeling | Isolates merchant data and configuration while presenting a branded experience per merchant | True tenant isolation at the data layer, not just UI-level branding on a shared backend |
5. Cross-acquirer settlement | Unifies settlement, reconciliation, and interchange data across every connected acquirer | One normalized settlement ledger mapping every transaction to its acquirer-specific reference and terms |
Layer
1. Acquirer & MID portfolio
2. Merchant-configurable routing
3. Risk-aware routing
4. Multi-tenancy & white-labeling
5. Cross-acquirer settlement
Responsibility
Manages the PSP’s own acquiring bank relationships and available MIDs as routable inventory
Lets merchants influence routing without exposing acquirer credentials or portfolio details
Ties routing eligibility to each merchant’s risk tier and underwriting status
Isolates merchant data and configuration while presenting a branded experience per merchant
Unifies settlement, reconciliation, and interchange data across every connected acquirer
Key Design Decision
Acquirers and MIDs modeled as configurable entities with eligibility rules, not hardcoded per merchant
Self-service routing rules exposed through the platform’s own API/dashboard, abstracted from acquirer specifics
Underwriting/risk data feeds the routing engine directly, not as a separate manual override process
True tenant isolation at the data layer, not just UI-level branding on a shared backend
One normalized settlement ledger mapping every transaction to its acquirer-specific reference and terms
Layer 1: Managing a Portfolio of Acquiring Banks and MIDs
This is the foundation layer, and it’s the one most PSPs are still missing even after they’ve onboarded several acquirers. The three problems below come from treating acquirer choice as a portfolio-management discipline rather than a series of one-off decisions.
Modeling Acquirers and MIDs as Routable Inventory
Most PSPs start by hardcoding acquirer choice into merchant onboarding: a new merchant gets assigned to whichever acquirer the onboarding rep favors that week. That works until the portfolio grows past a handful of relationships. The alternative is representing each acquirer relationship and its MIDs as a configurable entity, so the routing engine queries that model instead of reading a hardcoded assignment. Attributes worth modeling are accepted verticals, risk appetite, geographic coverage, processing limits, and scheme certifications. That shift turns acquirer selection into a query against structured data instead of a decision that lives in someone’s head.
Acquirer Onboarding and Capacity Management
Adding a new acquirer relationship should mean registering it in the portfolio model. If onboarding a new acquirer requires touching the routing engine’s internal logic, the portfolio model isn’t doing its job. The model also needs to track capacity per acquirer, since routing that ignores capacity will overload one relationship while others sit idle, especially as a handful of large merchants can quietly saturate a single acquirer’s limits.
Acquirer-Level Failover
An acquiring bank outage or a sudden restriction on a specific vertical affects every merchant routed through it. The portfolio layer needs to support reassigning affected merchants’ routing eligibility quickly, a portfolio-management problem before it’s a technical-failover one. A pure technical failover retries a failed transaction against a backup gateway. Acquirer-level failover has to update which acquirers are eligible for a whole segment of merchants first.
Layer 2: Merchant-Configurable Routing Without Exposing the Portfolio
Merchants want control over how their transactions are routed, but building that flexibility is a design challenge. Whether this layer succeeds comes down to three questions: what merchants can configure, what they can see, and what happens if they do nothing.
Per-Merchant Routing Rules vs. Per-Transaction Rules
A PSP’s routing engine operates at two levels. Global logic governs how transactions move across the entire portfolio, which acquirers are eligible for which verticals, how cost and approval rate get weighted by default. Per-merchant preferences sit above that logic for merchants who want more control, such as one that only wants acquirers certified for its specific card scheme mix. Global logic should change rarely, per-merchant preferences need to be adjustable without touching every other merchant’s rules.
Exposing Control Without Exposing Acquirer Details
Merchants who want to influence routing shouldn’t need to know which acquirer or MID actually handles their traffic. The merchant-facing API or dashboard should let them express preferences, such as cost priority, regional preference, payment method coverage, without ever surfacing acquirer names or MID-level detail. The acquirer portfolio is the PSP’s own commercial asset, and exposing it would let merchants reverse-engineer which acquiring relationships the PSP depends on. For example, a merchant can choose to prioritize approval rates for European cards and get that exact routing behavior without ever learning which acquirer actually processes the payment.
Default Routing Tiers for Merchants Who Don’t Customize
Most merchants will never open a routing settings page. The architecture has to assume that and build sensible default routing tiers, grouped by vertical and risk level, so merchants who never customize anything still get routing that’s optimized rather than whatever acquirer happened to onboard them first. Getting these defaults right matters more than the self-service layer, since defaults determine routing quality for the majority of the merchant base.
Layer 3: Risk-Aware Routing Tied to Underwriting
Not every acquirer accepts every merchant vertical or risk profile. A high-chargeback merchant, or one in a vertical several acquirers won’t touch, may be eligible for only a subset of the PSP’s portfolio, and the routing engine needs to know that before it optimizes for cost or approval rate at all.
Underwriting and risk-scoring systems need to feed merchant risk tier directly into the routing engine’s eligibility rules, ideally in real time as a merchant’s risk profile shifts. For example, a sudden chargeback spike should immediately trigger re-tiering in the routing engine, rather than waiting for a scheduled monthly review. Routing also has to respect payment processing compliance restrictions per acquirer and jurisdiction, encoded into the same eligibility model.
Deloitte‘s payments-industry outlook points toward adaptive, AI-driven risk frameworks, dynamic, real-time fraud and identity signals instead of static rules, as the direction underwriting-linked systems are heading, the same kind of real-time feed a PSP’s routing eligibility rules depend on.
For the compliance and PCI-scope dimension of a routing architecture like this, see our guide on payment gateway compliance and security.
Layer 4: Multi-Tenancy and White-Labeling
Multi-tenancy is the layer most likely to get shortcuts early, since a branded UI on a shared backend looks like tenant isolation until merchant count grows. The three design aspects below determine whether that shortcut turns into a rebuild later.
True Tenant Isolation vs. UI-Level Branding
Skinning a shared backend with a merchant’s logo is not multi-tenancy. Genuine tenant isolation separates each merchant’s data, configuration, and routing rules at the data layer itself, so one merchant’s settings or history can never leak into another’s view, the same secure payment best practices bar PSPs already hold themselves to elsewhere in the platform. UI-level branding scales fine for a handful of merchants, then breaks down as merchant count grows, because the underlying data model was never built to keep tenants apart.
Branded Dashboards and Reporting per Merchant
Merchants expect to see their own transaction status, settlement data, and approval rates, ideally under the PSP’s brand or white-labeled under their own. That reporting layer should pull from the same underlying orchestration data every internal team uses, filtered by tenant, rather than maintaining a separate pipeline for merchant-facing views, which avoids the drift that happens when two pipelines calculate the same numbers differently over time.
API Design for Merchant Self-Service
The merchant-facing API should be a distinct, stable surface from the internal routing and acquirer-management API. When the PSP adds, removes, or reconfigures an acquirer behind the scenes, merchant integrations built against the self-service API shouldn’t need to change. Conflating the two APIs means every internal acquirer change risks becoming a breaking change for merchants who integrated against implementation details never meant to be public.
Layer 5: Settlement and Reconciliation Across Acquirers
Each acquirer settles on its own schedule, in its own report format, under its own interchange and commercial terms. Without a unified layer, reconciling merchant payouts against acquirer settlements means comparing reports from several acquirers by hand.
The fix is one normalized settlement ledger mapping every transaction to both its merchant and its acquirer-specific reference, so payout calculation and acquirer-level reconciliation run off the same source of truth instead of two processes that occasionally disagree. Interchange and fee differences also need to be decomposed per transaction, so the PSP can see its actual margin per acquirer relationship.
Build Sequence and Engineering Effort for a PSP Orchestration Layer
The build sequence follows a dependency chain, and each layer depends on something the previous one built.
Phase | Timeline | Relative Engineering Cost |
|---|---|---|
1. Acquirer & MID portfolio model | 3-5 weeks | Medium — mostly data modeling, but touches every downstream layer |
2. Basic routing engine with default tiers | 4-6 weeks | Medium — rules-based routing before adding risk or ML sophistication |
3. Risk-tier integration with underwriting | 5-8 weeks | High — depends on how real-time the existing underwriting/risk system is |
4. Merchant self-service layer + tenant isolation | 6-10 weeks | High — API design and data isolation both need to be right from the start |
5. Unified settlement & reconciliation across acquirers | 6-10 weeks | High — scales with the number of connected acquirers and their reporting formats |
Phase
1. Acquirer & MID portfolio model
2. Basic routing engine with default tiers
3. Risk-tier integration with underwriting
4. Merchant self-service layer + tenant isolation
5. Unified settlement & reconciliation across acquirers
Timeline
3-5 weeks
4-6 weeks
5-8 weeks
6-10 weeks
6-10 weeks
Relative Engineering Cost
Medium — mostly data modeling, but touches every downstream layer
Medium — rules-based routing before adding risk or ML sophistication
High — depends on how real-time the existing underwriting/risk system is
High — API design and data isolation both need to be right from the start
High — scales with the number of connected acquirers and their reporting formats
PSP Orchestration Architecture Readiness Checklist
This checklist maps the eight decisions covered above onto a single self-assessment. Check off what’s actually built today, then read the interpretation below against the pattern of checked and unchecked rows.
-
Acquirers and MIDs are modeled as configurable entities. Note: Adding a new acquirer relationship is a configuration change.
-
Merchants can express routing preferences with acquirer-level details kept hidden. Note: The PSP’s acquirer portfolio stays a protected commercial asset.
-
Default routing tiers exist for merchants who never customize routing. Note: The majority of merchants who won’t self-configure get optimized routing.
-
Merchant risk tier and underwriting status feed the routing engine’s eligibility rules directly. Note: High-risk merchants are only routed to acquirers that accept their profile.
-
Merchant data and configuration are isolated at the data layer. Note: The platform scales safely as merchant count grows, with tenant data kept separate.
-
The merchant-facing API is a stable, independent surface. Note: Merchant integrations keep working when acquirers are added, removed, or reconfigured internally.
-
Every transaction maps to one internal record across every acquirer. Note: Settlement and reconciliation run off one ledger.
-
Interchange and acquirer fee differences are decomposed per transaction. Note: The PSP can see actual margin per acquirer relationship.
SPD Technology Expertise: Building Orchestration Infrastructure for PSPs
Our team has built payment facilitation operations and compliance infrastructure for payment facilitators and platforms managing large merchant portfolios, including automated onboarding across risk and compliance checks and risk-based underwriting at scale.
Merchant Portfolio Onboarding at Scale: Aggregated Merchant Portal
Our client, Blackhawk Network, needed to onboard a large volume of merchant businesses onto its aggregated merchant network, but onboarding required manual OFAC, EIN, and SSN compliance checks alongside manual lead handling that couldn’t scale. We built an aggregated merchant portal that automated the compliance-check pipeline and Salesforce lead routing.
The value we delivered is over 8,000 US businesses onboarded in two years, with onboarding time cut from seven days to under 24 hours, a sevenfold reduction. That automated pipeline is direct proof for the risk and compliance data Layer 3’s routing eligibility rules depend on.
Risk-Based Underwriting at Scale: Fraud Detection & Risk Management
Poynt needed to underwrite high volumes of merchant applications without manual bottlenecks that delayed onboarding or admitted fraudulent accounts. To meet this demand, our engineers built an automated fraud detection and risk-management engine capable of underwriting applications at scale.
Our efforts resulted in more than 5 million applications underwritten in a single year, with the merchant termination rate doubled through true-positive fraud detection with machine learning, across a partnership that ran more than five years. This is the same underwriting-to-routing integration described in Layer 3.
Long-Term Full-Cycle Payment Processing Architecture: Poynt
In another project, Poynt asked us to help them create a full-cycle payment processing platform, covering processing, settlement, and third-party integration, built around PayFac economics rather than a traditional acquiring model. So, we created an all-in-one omnicommerce payment processing system in five months over a partnership that ran more than five years. The company was later acquired, and our team was retained post-acquisition. This is the same settlement-coordination problem Layer 5 solves across multiple acquirers.
Key Takeaways
- A PSP’s orchestration layer routes many merchants’ transactions across a portfolio of acquiring banks and MIDs the PSP itself manages commercially. It is not the same architecture problem as a single merchant routing across a few gateways it chose.
- Routing eligibility for a PSP has to be filtered by merchant risk tier and underwriting status before it’s optimized for cost or approval rate, since not every acquirer will accept every merchant’s vertical or risk profile.
- Exposing merchant-configurable routing without exposing the PSP’s acquirer portfolio requires a distinct merchant-facing API layer, abstracted from the internal acquirer-management system.
- UI-level branding on a shared backend is not multi-tenancy. Genuine tenant isolation at the data layer is what lets a PSP’s platform scale safely as merchant count grows.
- Adding a new acquirer relationship should be a configuration change against a portfolio model, not a development project.
- Settlement and reconciliation across acquirers only becomes tractable once every transaction maps to one internal record regardless of which acquirer processed it.
In short: PSP-side payment orchestration is a portfolio-management and risk-tiering problem before it’s a routing-technology problem.
FAQ
How is a PSP’s payment orchestration layer different from a merchant’s orchestration setup?
A PSP’s layer routes hundreds of merchants’ transactions across a portfolio of acquiring banks and MIDs it manages the commercial relationships for, not a handful of gateways one business chose. Routing decisions have to account for each merchant’s risk tier, underwriting status, and which acquirers will even accept that merchant’s vertical. A merchant-side layer can treat every acquirer as equally available; a PSP’s layer needs multi-tenancy, risk-tiered routing, and acquirer-portfolio management built in from the start.
What is MID portfolio management in payment orchestration?
MID portfolio management in payment orchestration means representing every acquiring-bank relationship and its MIDs as configurable entities, each with attributes like accepted verticals, risk appetite, geographic coverage, and processing limits, that the routing engine can query directly. Without it, acquirer choice gets hardcoded into merchant onboarding, and adding a new relationship turns into a development project instead of a configuration change. Good portfolio management also tracks capacity per acquirer and supports quick reassignment of merchant eligibility if an acquirer has an outage or restricts a vertical.
How does merchant risk tier affect payment routing at a PSP?
Risk tier determines which acquirers are even eligible for a merchant before the routing engine optimizes for anything else. A high-chargeback merchant, or one in a vertical certain acquirers won’t accept, may only be eligible for a subset of the portfolio. Underwriting systems need to feed that tier directly into the routing engine’s eligibility rules, ideally in real time as a merchant’s profile changes, since a chargeback spike should trigger re-tiering rather than waiting for a scheduled review.
What does multi-tenancy mean for a PSP’s orchestration platform?
Multi-tenancy means isolating each merchant’s data, configuration, and routing rules at the data layer. Genuine isolation is what lets a platform scale safely as merchant count grows, since one merchant’s settings or history can never leak into another’s view. It also means the merchant-facing API stays a distinct, stable surface from the internal acquirer-management API, so merchant integrations don’t break when the PSP reconfigures an acquirer behind the scenes.
How long does it take to build a PSP-grade payment orchestration layer?
A staged build typically takes 24-39 weeks across five phases: acquirer/MID portfolio model (3-5 weeks), basic routing engine with default tiers (4-6 weeks), risk-tier integration with underwriting (5-8 weeks), merchant self-service layer with tenant isolation (6-10 weeks), and unified settlement and reconciliation (6-10 weeks). The portfolio model comes first because routing and risk-tiering depend on a structured model of which acquirers and MIDs exist to route to.
How much does it cost to build a PSP-grade payment orchestration layer?
Cost scales with which of the five layers already exist. The portfolio model and a basic rules-based routing engine are medium-effort builds. Risk-tier integration, the merchant self-service and tenant-isolation layer, and cross-acquirer settlement are each high-effort, since they depend on how real-time the existing underwriting system is and how many acquirer relationships and reporting formats need to be unified.
Can a PSP let merchants customize their own payment routing rules?
Yes, but the architecture has to let merchants express preferences, cost priority, regional preference, payment method coverage, without ever exposing which acquirer or MID handles their traffic, keeping the acquirer portfolio a protected commercial asset rather than exposed infrastructure. Most merchants won’t configure anything, so the platform also needs sensible default routing tiers by vertical and risk level, so merchants who never touch the settings still get optimized routing.