Zero-Cost Built-in Orchestration: How One Roof Eliminates the Markup

// THE PRICING PROBLEM

Pure-play orchestration is a separate line item on top of acquiring

The dominant model for payment orchestration today is the pure-playplatform: a vendor whose product is multi-acquirer routing, but whose business model requires the merchant to bring their own acquirer relationships. The platform sits between the merchant's application and the acquirers; the merchant pays the platform a fee, and separately pays each acquirer their processing fee.

Concretely, a merchant on a pure-play setup is paying:

• Acquirer processing fees — interchange + assessments + acquirer markup, on each transaction. Same as any direct-acquirer integration.
• Platform fee — either per-transaction (typically 5–15 basis points on processed volume) or a flat platform fee with per-transaction marginals.
• Implementation cost — integration time, vault migration, ongoing API maintenance.

For a merchant doing $10M annual processed volume at 10 bps of platform fee, that's $10,000 per year in pure orchestration markup — money flowing to a vendor that doesn't touch the underlying acquirer relationship. At $100M, it's $100,000. At enterprise scale, this becomes a meaningful negotiated line item.

The platform fee isn't inherently unreasonable — the pure-play orchestrator built the routing engine, the vault, the decline-code intelligence, the failover logic. They deserve to be paid for that work. The question is whether the work has to be a separately-priced line item, or whether it can be built into the acquirer cost structure directly.

// THE STRUCTURAL ANSWER

When orchestration and acquiring share a roof, the markup disappears

The alternative model — call it acquirer-plus- orchestration— is one where the same operator owns both the orchestration platform and the acquirer relationships it routes across. The merchant signs one contract, gets one settlement record, sees one set of fees. The acquirer's rate card includes the orchestration cost; there's no separate platform line item.

This is structurally cheaper for the merchant for a specific reason: the orchestration cost is now internalto the operator. The operator can amortize the routing engine, the vault, and the platform engineering across the acquirer-spread margins it's already collecting. The merchant pays interchange-plus rates; orchestration comes free as a property of the platform, not as a stacked fee.

This is also where the “zero-cost” framing comes from. Not zero processing cost — interchange and scheme fees are paid no matter what model you're on. But zero orchestration cost: no per-transaction platform fee, no flat platform retainer, no per-rule configuration tax. The orchestration is just how the acquirer network works.

// THE REQUIREMENT

This only works if you actually own the acquirer relationships

The acquirer-plus-orchestration model has a hard prerequisite: the operator has to be a real acquirer-side participant, not a reseller or a pure technology vendor. That means real direct relationships with tier-1 acquiring banks, real underwriting capability in-house, and real settlement infrastructure on the bank side of the wire — not just a clever routing layer in front of someone else's acquirer.

Most pure-play orchestrators can't do this because they aren't licensed for it. The acquirer-licensing requirements (PCI-DSS Level 1, scheme membership, KYC/AML infrastructure, capital reserve, regulatory posture) are non-trivial. Building a routing engine on top of someone else's acquirer relationships is engineering-bounded; becoming an acquirer-side operator is bank-relationship and capital-bounded.

For Von Payments, this is the structural advantage: VON is the acquirer network — 6+ tier-1 acquirers under our merchant of record, plus the specialty acquirers wired in for vertical underwriting. VORAis the orchestration layer on top of those relationships, owned and operated by the same entity. The platform fee doesn't need to exist because the orchestration is amortized into the acquirer margins we're already collecting.

// WHAT IT MEANS FOR THE MERCHANT

The practical difference in the contract

The difference between pure-play and acquirer-plus- orchestration shows up in three places on the merchant contract:

• One rate card vs. two. Pure-play: an acquirer agreement with each downstream processor, plus a separate platform agreement. Acquirer-plus: one rate card covering everything, with orchestration as a property of the platform rather than a fee.
• One settlement vs. many. Pure-play: each acquirer settles to the merchant separately; reconciliation has multiple settlement records per cycle. Acquirer-plus: one settlement record from the operator, with the routing detail visible in reporting but invisible in cash flow.
• One underwriting review vs. multiple. Pure-play: each acquirer underwrites separately; the merchant has to clear KYC / AML / vertical review with every relationship. Acquirer-plus: one underwriting review for the operator's network, with the operator mapping the merchant to specific acquirers behind the scenes.

None of these are pure wins — the pure-play model offers something the acquirer-plus model can't match: full transparency into which acquirer is processing which transaction at which rate. For enterprises that want to negotiate acquirer rates individually, the pure-play model preserves that optionality. For most merchants who just want the approval-rate lift and the rebill reliability without the back-office complexity, acquirer-plus is structurally simpler and structurally cheaper.

// WHERE EACH MODEL FITS

The decision framework

A rough rule of thumb:

1. If you're under $5M annual processed: Either model works, but the acquirer-plus model wins on total cost of ownership. The pure-play platform fee starts mattering at scale; below $5M, the operational complexity of running two relationships is the larger cost.
2. If you're $5M–$50M with a specialty vertical: Acquirer-plus is almost always the right choice. The vertical-specialty underwriting fit matters more than the marginal acquirer-rate negotiation, and the integrated orchestration unlocks approval rate without the platform-fee math.
3. If you're $50M+ with an in-house payment team: Either model is defensible. Pure-play gives the team direct visibility into each acquirer relationship; acquirer-plus gives them one operational relationship to manage. Pick based on whether acquirer-rate negotiation is something your team actually does, or something that lives on a wish list.
4. If you need multinational, cross-currency, or tier-2 regional acquirers:Pure-play platforms with the widest acquirer footprint sometimes have relationships that acquirer-plus operators don't. At that scale the platform fee is worth paying for the footprint. Until you're actually operating at that scale, though, the footprint difference is theoretical.

// THE OBJECTION

'But the platform fee is small'

A common counter-argument: 5–15 bps of platform fee is small relative to total payment cost (interchange + scheme + acquirer markup typically runs 200–300 bps), and quibbling about a small line item misses the bigger picture. Approval-rate lift from multi-acquirer routing is worth far more than the platform fee.

That's right — and also beside the point. The argument isn't “you should choose payments based on saving 10 bps.” The argument is that you can get the same approval-rate lift, the same multi-acquirer routing, the same vault, without the platform fee at all — by picking an operator whose business model doesn't require it. The 10 bps isn't the headline benefit; the simpler contract structure and the bundled underwriting are the headline benefits. The fee elimination is a bonus.

Put differently: if a pure-play orchestrator and an acquirer-plus operator both deliver the same approval-rate lift, the same reliability, the same chargeback program, and the merchant fits both models — pick the one that doesn't charge a platform fee. The pure-play platform has to justify the fee with something the acquirer-plus can't deliver (broader footprint, deeper customization, more granular rate negotiation). If it can't justify the fee, it's collecting it because the merchant didn't know there was an alternative.

// PUTTING IT TOGETHER

What 'built-in' actually delivers

The built-in orchestration model is a specific architectural choice, not a marketing position. It delivers:

• Multi-acquirer routing — same as a pure-play platform: BIN-aware primary selection, real- time failover, decline-code-aware retry.
• Network-tokenized vault — Visa Token Service + Mastercard MDES, owned by the operator, valid across the routing graph.
• Specialty-vertical underwriting — for the verticals where mainstream acquirers decline, the operator routes to specialty acquirers in-network rather than punting back to the merchant.
• Unified reporting + settlement — one ledger, one reconciliation record, one chargeback program, regardless of which acquirer actually processed the transaction.
• One contract, one underwriting review, one rate card — no separate platform fee line item.

That's the basket of features most merchants are buying when they evaluate orchestration. When you can get the basket without the platform fee, the choice is usually obvious — assuming the operator's acquirer footprint fits your vertical and your scale.

For routing engine specifics, acquirer network details, and the full platform-evaluation framework, follow the cross-links. If you're shopping orchestration right now and want to compare a built-in model side-by-side with whatever pure-play you're looking at, talk to underwriting— we'll walk through the math for your specific volume.