Point-to-point vs orchestrated payment integration
Why corridors break at #3 or #4 — and how to migrate without a big-bang rewrite
Almost every payment platform starts with point-to-point integration, and almost every one that scales eventually regrets it. The pattern is not wrong — it is wrong past a certain corridor count, and the failure is so predictable you can practically schedule it. This piece is about recognising the breaking point early, and migrating off it without the big-bang rewrite everyone fears.
What point-to-point actually is
In a point-to-point model, each banking partner, rail, or provider is wired directly into your core platform. Partner A has its own integration code in core; partner B has its own; each integration point carries that partner’s specific message formats, quirks, retry behaviour, and error handling, embedded directly where your business logic lives.
For corridor #1, this is the fastest possible path, and choosing anything more elaborate would be over-engineering. The trouble is structural and only visible later.
Why it breaks at #3 or #4
Point-to-point fails for a reason that compounds:
- Couplings multiply. Every new partner is another direct connection threaded into core. The complexity is not additive; the interactions between integrations grow faster than the count.
- Blast radius grows. A change to one partner’s integration — a new field, a changed status code — risks rippling into unrelated flows, because the integrations share core rather than being isolated.
- Knowledge concentrates. The handful of engineers who understand how the connections interlock become a bottleneck, and a key-person risk.
- Velocity inverts. Early on, each corridor ships faster than the last as the team learns. Past the breaking point it reverses: each corridor ships slower, because more time goes to defending what exists than building what’s new.
That inflection — usually around corridor #3 or #4 — is the signal. When adding a corridor starts taking longer instead of shorter, the architecture, not the team, is the constraint.
What orchestrated integration replaces it with
The orchestrated model inserts two layers between core and the outside world:
- A canonical model + adapters. Core speaks one internal language for “a transfer.” Each partner gets a thin adapter that translates between the partner’s interface and the canonical model. A partner’s quirks stay sealed inside its adapter; core never sees them.
- An orchestration layer. Above the adapters, routing logic decides which partner or rail handles each transaction, with failover and retries handled centrally and safely.
The result: adding a corridor becomes “write one bounded adapter,” not “modify core again.” The blast radius of any partner shrinks to its adapter. And routing, reliability, and reconciliation are solved once, centrally, instead of re-implemented per integration.
Point-to-point vs orchestrated, side by side
| Point-to-point | Orchestrated | |
|---|---|---|
| First corridor | Fastest | Slower (build the layer) |
| Each additional corridor | Slower over time | Cheaper over time |
| Blast radius of a change | Spreads into core | Sealed in an adapter |
| Routing / failover | Per-integration, ad hoc | Central, consistent |
| Key-person risk | High | Lower |
| Right for | Corridors #1–2, tiny stable sets | Any growing corridor mix |
How to migrate without a big-bang rewrite
The fear that keeps teams on point-to-point too long is the rewrite — pausing the roadmap to re-architect everything at once. You do not have to, and you should not. Use a strangler pattern:
- Define the canonical model first. Agree your internal representation of a transfer before touching any integration.
- Wrap the next new corridor as an adapter. Don’t migrate the old ones yet — build the next corridor the new way. This proves the pattern with zero risk to existing flows.
- Introduce the orchestration layer for the new corridor only. It routes one corridor at first.
- Migrate existing corridors opportunistically. Each time a point-to-point integration needs significant change anyway, rebuild it as an adapter instead. The old architecture is “strangled” gradually, corridor by corridor, with no flag day.
- Retire core’s direct couplings last, once everything routes through the canonical layer.
Done this way, migration rides alongside the roadmap rather than blocking it, and each step delivers value on its own.
The decision
If you are at corridor #1 or #2, point-to-point is fine — don’t over-build. If adding corridors is getting slower, you are past the breaking point, and the strangler migration above is cheaper than the rewrite you are afraid of — and far cheaper than staying point-to-point to corridor #10.
This is the migration FreySoft has run in production, building and maintaining orchestrated corridors for WorldRemit (now Zepz) across 130+ countries and 70+ currencies at 100,000+ transactions a day. The pattern scales; point-to-point does not.
Planning the migration as part of a broader corridor strategy? See “How fintechs actually add new payment corridors,” or talk to our payments team.
