Payment orchestration vs building routing in-house: costs and trade-offs

Most engineering teams can build a payment router. The first version is often a few hundred lines: pick a provider by country and currency, call its API, and fall back to another provider on an error. The question a head of payments or CTO actually faces is different: what does it cost to own that layer for the next three years, as providers, markets and card network rules keep changing?

This article sets out what an in-house routing layer has to include, where the ongoing cost sits, a worked build-versus-buy example, and when each choice makes sense, including hybrids. How orchestration differs from a single gateway is covered in payment orchestration vs payment gateway, and what to ask vendors is in our payment orchestration RFP questions.

What does an in-house routing layer have to include?

Much more than routing rules. Once a second provider is live, every part of the payment stack needs a version that works across providers and gives one answer.

Component	What it does	Ongoing work
Connectors	Payment, capture, refund, payout and status calls per provider	Provider API versions, new methods, new markets
Status mapping	One status model across providers	Each new provider and each API change
Decline-code normalisation	Maps each provider’s codes to retry and cascade decisions	New codes, scheme changes
Retries and cascading	Moves soft declines and technical failures to another route	Card network retry limits and fees
Idempotency	Stops a timeout from charging or paying twice	Every new flow
Webhooks	Receives, verifies, deduplicates and orders events	Signature schemes, endpoint upgrades
Token vault	Stores card numbers so any provider can be charged	PCI DSS assessment, key management
Reporting and reconciliation	Approval by provider, settlement matching, fees	New report formats per provider
Payouts	Refunds, seller payouts and their failures	Payout rails per country
Monitoring	Alerts on approval drops, latency and outages	On-call rota

Our guides on webhooks and idempotency and adding a second PSP cover several rows in detail. The point here is the right-hand column: none of it is finished at launch.

Why does connector upkeep never end?

Because each provider changes its API on its own schedule, and some retire old versions. Your connectors have to move with them.

Adyen’s documentation is explicit. It releases only major versions of its Checkout API, moves older versions through active, inactive, deprecated and end-of-life states, and gives merchants 2 years to upgrade once a Checkout API version is deprecated. At end of life Adyen stops support, and its documentation says payment processing can be suspended at any time.

Stripe pins behaviour to an API version, which protects you from surprise changes but makes upgrades a project. Its documentation recommends specifying the version on each request rather than relying on the account default, and notes that server-side SDKs in strongly typed languages such as Java, Go and .NET are fixed to the API version current when the SDK was released. Stripe’s SDK support policy refers to two major API releases a year, in March and September. Upgrading webhooks means creating new endpoints, receiving every event twice while both are active, and switching processing from old to new without losing events.

Multiply that by every provider you connect, in every market. A team with four providers is tracking four release calendars, four deprecation notices and four webhook formats, before any new market is added.

What do retry and cascading rules have to respect?

Card network limits, which carry fees and change over time. Cascading a soft decline to a second provider is useful; retrying without limits is penalised.

PayPal’s summary of the rules, updated in May 2026, sets out the current position:

Network	Rule	Fee for excess retries
Visa, soft declines (Categories 2 to 4)	20 retries in 30 days	USD 0.10 domestic, USD 0.25 cross-border
Visa, hard declines (Category 1)	No retries	Same fees
Mastercard, soft declines	Thresholds of 10 retries in 24 hours and 35 in 30 days on the same account, merchant and amount	Fee per excess retry, for example USD 0.50 in the US
Mastercard, advice codes 03 and 21	Do not retry	Fee if retried within 30 days and declined again

An in-house layer must count attempts per card across all providers, not per provider, read merchant advice codes, and stop at the right code. Our article on soft and hard declines lists which codes deserve a second attempt.

How does a token vault change your PCI DSS scope?

It puts your own systems at the centre of it. To charge a saved card through any provider, someone has to hold the card number, and if that is you, the vault and everything that can reach it is in scope.

The PCI Security Standards Council’s tokenization guidance says any system component that can be used to retrieve card numbers must be protected according to PCI DSS, and that the card data vault often presents the most attractive target for attackers, so controls beyond PCI DSS may be warranted. It also says tokenization does not remove the need to maintain and validate compliance; it can only reduce the number of systems in scope.

The standard also moves. PCI SSC retired PCI DSS v4.0 on 31 December 2024, leaving v4.0.1 as the only active version, and the future-dated requirements introduced with v4.0 took effect on 31 March 2025. An in-house vault means owning that change cycle too. If cards sit in a third party’s vault instead, check that you can move them: our article on card token portability explains what transfers between providers.

Worked example: build versus buy over three years

Example figures, for illustration only.

An online electronics retailer processes 5 million card payments a year across four providers in six countries. The cost of people is an assumption, not market data: EUR 10,000 per person-month, fully loaded. The build team also runs payment operations; the buy case needs one person for that.

Cost line (EUR)	Year 1	Year 2	Year 3	Three years
Build: engineering, 6 people in year 1, then 3	720,000	360,000	360,000	1,440,000
Build: vault security and PCI DSS assessment	150,000	150,000	150,000	450,000
Build: hosting and monitoring	60,000	60,000	60,000	180,000
Build total	930,000	570,000	570,000	2,070,000
Buy: platform fees, 5 million payments at EUR 0.04	200,000	200,000	200,000	600,000
Buy: integration, 2 people for 4 months	80,000	0	0	80,000
Buy: payment operations, 1 person	120,000	120,000	120,000	360,000
Buy total	400,000	320,000	320,000	1,040,000

Over three years, buying costs EUR 1,030,000 less in this example. The comparison shifts with volume: the buy case’s steady-state cost is EUR 120,000 plus EUR 0.04 per payment, against EUR 570,000 for the build. The two meet at 11.25 million payments a year (EUR 450,000 divided by EUR 0.04). Above that, building is cheaper to run, although the larger first-year cost still has to be recovered.

The table leaves out two things that often matter more than either total: the months before the in-house layer is live, and any difference in approval rates between the two. Put your own figures and fee quotes into the same table before deciding.

When does building make sense, and when does buying?

It depends on volume, the number of providers and how standard your flows are.

Situation	Leaning	Why
Very large volume on one or two providers	Build	Per-payment fees outweigh a small, stable team
Unusual flows no vendor supports	Build	Customising a platform can cost more than owning the code
Payments are your core product	Build	The routing layer is a competitive asset
Several markets, each with local providers	Buy	Connector count and upkeep grow with every market
Need for a second provider within months	Buy	Time to the first live payment is shorter
Small payments team	Buy	Upkeep competes with product work

Buying has real costs too. You pay fees that grow with volume, you depend on the vendor’s uptime and its connector roadmap, and switching later is a project of its own. Reduce that dependency in the contract: uptime commitments, connector delivery times, a price review clause and the right to export saved cards on exit. Our guide to how many PSPs per market helps size the provider count that drives this decision.

What hybrid options exist?

Most merchants end up somewhere between the two. Common patterns:

• Direct integration for the largest provider, orchestration for the rest. The highest-volume route avoids per-payment fees; new markets come through one API.
• Orchestration for new markets only. The existing integration stays; expansion does not wait for engineering.
• Orchestration for payouts. Payout rails vary by country even more than payment methods do.
• Your rules, bought connectors. You keep routing logic in-house and buy the connections underneath.

Each split adds an interface between two systems, with two sets of statuses to reconcile. Keep the boundary simple, and document which system is the source of truth for each payment.

What are the common mistakes?

• Costing only the first release. Most of the cost is upkeep: provider API versions, new markets and network rule changes.
• Counting retries per provider. Card network limits apply per card across all routes, so a cascade can breach them.
• Underestimating the vault. Holding card numbers puts the vault and every system that can reach it in PCI DSS scope.
• Comparing build cost with the vendor’s headline price. Include integration, operations, provider fees and exit costs on both sides.
• Ignoring vendor dependency. A bought layer is a critical supplier; negotiate exit terms and card export before signing.
• Building for one market, then expanding. A router designed for one country often needs a rewrite when the second arrives.

How does Omno help compared with building in-house?

Omno can replace most of the in-house layer: one API in front of many PSPs, routing and PSP eligibility by country, method, currency, customer group and customer verification level, cascading to the next provider in the rule when one is unavailable or rejects the request, saved cards tokenized in a PCI DSS compliant environment, webhooks as the source of truth and routing-decision logs for every attempt. You still sign and manage contracts with the providers you route to. The payment orchestration page covers the integration.