Build vs buy: should you build payment orchestration in-house?

Single provider vs in-house build vs orchestration platform

Why does the build vs buy question come up?

Most teams start with a single provider. The build vs buy question comes up later, usually when a second provider is needed for a new market, a backup route, or a payment method the first provider doesn't support.

The comparison table on this page compares the three options on the points that usually decide the choice.

What does building payment orchestration in-house involve?

An in-house orchestration layer is a product of its own. It's not one integration, it's a system that sits between your checkout and every provider behind it.

Provider connectors. Each provider has its own API, authentication, error format, webhook model and sandbox quirks. A connector has to cover authorization, capture, refunds, voids, status checks and webhooks, and it has to keep working as the provider ships API versions and deprecates old ones. Every new provider adds another connector to build, test and monitor.

Routing and cascading rules. Routing decides which provider gets a transaction: by country, currency, card type, amount, payment method or provider health. Cascading decides what happens after a decline: whether the payment can be retried through another provider, and under what conditions. Doing this safely means knowing which declines are retryable, avoiding duplicate charges, and respecting authentication results such as 3-D Secure.

Tokenization and PCI DSS scope. If you want to route the same card to more than one provider, you need a way to hold card data that isn't tied to a single provider. That usually means a token vault, and handling card data directly can widen your PCI DSS scope significantly. Many in-house projects either take on that scope or stay locked to provider-specific tokens, which limits how much routing flexibility they actually get.

Webhooks, reconciliation and reporting. Every provider reports in its own format, on its own schedule, with its own status vocabulary. To answer simple questions like what your approval rate by provider was last week, you need to normalize statuses, match settlement files to transactions and build one reporting model across all of them.

When does building in-house make sense?

Building can be the right call when payments are a core part of what you sell. That could be when you need routing logic tied closely to internal data no platform can access, or when you already run a dedicated payments engineering team with compliance experience. It also makes sense when you'll only ever use a small, stable set of providers and don't expect that to change.

If your team already maintains a card vault and passes PCI DSS assessments as part of normal operations, the marginal cost of building orchestration on top of that is lower than for a team starting from scratch.

When does an orchestration platform make sense?

Buying usually makes sense when payments are critical but not your product. Typical signals are listed below.

A platform turns provider integration from an engineering project into configuration, as long as the provider you need is supported. Check that before committing.

• You need a second or third provider for redundancy, new markets or local payment methods.
• Your engineers spend more time maintaining provider integrations than building features.
• You want routing and retry rules your payments or operations team can change without a code release.
• You need one reporting view across providers.
• You don't want to own a card vault and the compliance work that comes with it.

What hidden costs do teams underestimate?

Connector maintenance. The first version of a connector is the cheap part. The ongoing cost is API version changes, new mandatory fields, changes to authentication requirements, sandbox outages and edge cases that only show up in production. That work never ends, and it grows with each provider.

Decline-code normalization. Every provider returns declines differently. To cascade safely and to measure approval rates fairly, you need a mapping from each provider's codes to a common model: soft vs hard decline, retryable vs final, issuer vs provider vs technical. Getting this wrong leads either to lost revenue (not retrying recoverable declines) or to risk (retrying declines that shouldn't be retried).

Compliance and audits. Holding card data, logging requests and responses, and managing access to payment data all come with obligations. Logs need masking, access needs role-based controls, and auditors need evidence. These requirements land on whoever owns the layer; the exact obligations depend on your setup.

What is the hybrid path?

You don't have to pick a pure option. A common middle ground is to use a platform for the commodity parts (connectors, tokenization, webhooks, normalized reporting) and keep the business-specific parts in your own hands: routing rules, retry policy, which providers handle which traffic, and how risk decisions feed into routing. Your team gets control over the logic that differentiates you without carrying the infrastructure that doesn't.

When you evaluate platforms with this approach in mind, ask the questions below.

• Can we export our tokens and data if we leave?
• Can non-engineers change routing rules safely, with an audit trail?
• Are decline codes normalized across providers?
• Can we see raw provider requests and responses when debugging?
• How are new providers added, and who maintains the connectors?

How does OrsunPay fit?

OrsunPay is a payment orchestration platform that connects you to licensed PSPs; it does not process or hold funds itself. Merchants keep their own provider contracts and connect their own PSP accounts through one integration; smart routing and retries (cascading) are live, and unified reporting sits on top. RiskCogs, OrsunPay's anti-fraud module, adds risk signals before a transaction is routed.

If you're weighing build vs buy, talk to us about which providers you use today and where you want to go. For the basics, start with our guide to payment orchestration.