.png)
Own the router, rent the rails.
You have a payments project and a date. The real question is not “orchestration or not.”
It is who owns the router when the processor changes. Who owns it when settlement does not match. Who owns it when you need a second rail without starting over.
Three ways to do this
Buy a hosted orchestration product. You integrate to their cloud. They own the routing product. Your processor deals often sit inside their commercial setup.
Build it yourself against one processor. Your team wires one vendor deep into the product. It works for a while. Then the processor changes, and you pay for the migration again.
Own the router, rent the rails. You keep the processor contracts. You keep the spread. The software runs in your perimeter. You pay a fixed price to build it, then a monthly fee to run it so exceptions have an owner after go-live.
That last one is what we do. We are an ISV. We are not a PSP. We never sit in the flow of funds.
Side by side
| Hosted orchestration | Build in-house (one processor) | Client-owned layer (us) | |
|---|---|---|---|
| Who owns the routing product | Vendor | You (and whoever still knows it) | You (instance, config, data) |
| Processor contract | Often mediated | Yours, but hard-wired | Yours, behind an interface |
| Second processor | Their product roadmap | Another project | Wired into every build |
| Flow of funds | Depends on the vendor | Yours | Yours. We never hold money |
| Cutover with a date | Their services | Your team’s capacity | Fixed-price Build scoped to the date |
| After go-live | Their SaaS ops | Your on-call | Run: exceptions, connectors, next rail |
When hosted orchestration is the right buy
You want multi-PSP card routing fast. You do not want to hire a payments team this quarter. You are fine with a vendor cloud. Security and procurement already clear SaaS like that.
If that is your constraint, start with those products. This page is not a smear.
When one-processor builds hurt later
The first integration works. Settlement is “good enough.” Then the processor changes. Or finance wants unmatched items with an owner. The people who knew the edge cases have left. The second migration costs as much as the first because nothing was pulled out into a layer.
If you already need the interface to talk to many vendors, you are past the single-processor design. The choice is whether that multi-vendor layer is yours or rented.
What you own vs what you rent
Rails are processors and bank connections: cards, EFT/PAD, Interac e-Transfer, whatever you need. You rent those through contracts you hold.
The router is the software that picks a path, records the attempt, posts the ledger where cash moves, and shows unmatched items. Own that if you expect more than one processor change.
Build is fixed price, milestone invoiced. Cutover, ledger, reconciliation, or a provider-agnostic interface.
Run is monthly, per account, after Build. Exceptions queue with a named owner. Connector updates. Next processor without another greenfield. Ask for the current ladder. We do not invent a public price here.
Partner fees. If a processor pays us a referral or integrator credit, you hear it before we recommend them. Your payments margin stays yours.
What we have actually done
We have built money-movement systems for payment companies themselves. That includes a multi-year delivery relationship with Nuvei. That is engineering history. It does not make us a processor.
Beniplus moves about $1M a month through an integration and ledger we built. We moved them from manual EFT file uploads to Zum Rails. Reconciled per member to the provider record.
Paramount Commerce work, when we mention it, is past tense. We do not claim they are a current paying client on this page.
We never hold your money. We never register as a payment provider. There is nothing to unwind on the money side if you replace us.
Checklist before you pick
- Who holds the processor contract after go-live?
- Can you add a second processor without another discovery project?
- Does the layer run in your perimeter or a vendor cloud?
- Who owns unmatched settlement items?
- Is Build fixed price, or open-ended staff aug?
- Are referral or integrator fees disclosed before a processor is recommended?
- If you fire the vendor, what do you still own: code, config, data, event log, provider agreements?
If you want to hold the contracts, own the instance, design in a second processor, and give exceptions an owner, you want a client-owned layer. Not a hosted router. Not a single-processor rewrite.
Who this is for
You already decided to rebuild something in payments. You have a date. Processor to replace. Rail to add. Ledger that will not balance. Or a payment feature that moves volume and earns the platform nothing.
Tell us what you are integrating and the date it has to land.