The second time we rebuilt our payment routing, I finally understood what went wrong the first time.
We thought we were picking a vendor. We were actually making an architectural commitment – we just didn't know it.
The comparison spreadsheet showed transaction fees and uptime SLAs. It said nothing about who'd be holding our settlement float, what currency risk we were inheriting, or what it would actually cost to switch rails two years into production, once our entire ledger design had quietly grown around that first decision.
When we had to rebuild, the team called it tech debt. I disagreed. Tech debt is what happens when things get sloppy. This was a strategic architectural choice that got made by the procurement function, in a vendor meeting, with a spreadsheet.
Wrong people. Wrong moment. Wrong framing.
What Rail Selection Actually Determines
Choosing a payment rail is not a vendor comparison. It is a series of architectural commitments made simultaneously – most of them invisible at the time.
Settlement architecture. Who holds the float? For how long? Under what conditions does it move? Your ledger design is built around the answers to these questions whether you realize it or not. Change the rail and you change the answers – which means you change the ledger.
Currency and FX exposure. Every rail has a position on currency. Settling in USD through one rail is not the same as settling in USD through another. The FX conversion points, the timing, the counterparty risk – all of it is inherited when you choose a rail and largely invisible until you've been running long enough to see it compound.
Reconciliation design. At low volume, reconciliation is manageable regardless of how the rail works. At scale, the structure of your reconciliation logic is tightly coupled to how the rail structures its data. Switching rails at volume means rebuilding reconciliation – a project that is rarely scoped into the original cost estimate of the switch.
Failure surface. When the rail goes down – and it will – what is the blast radius? For a platform with multiple rails and smart routing, it is a degraded experience. For a platform with a single rail and no routing logic, it is a platform outage. That blast radius was chosen on the day you chose the rail. Most teams don't realize they made that choice.
If this rail goes down for 24 hours in 18 months, when we are processing 10× today's volume, what breaks and who does it affect?
If you can answer that question clearly and the answer is acceptable, you have made an informed architectural decision. If you cannot answer it, you are making a vendor decision and calling it a product decision.
Why Teams Get This Wrong
The procurement frame dominates early-stage decisions because the costs of the architectural frame are deferred. The pricing table is in front of you now. The reconciliation rebuild is eighteen months away. The settlement float problem shows up at a level of volume you have not yet reached. The blast radius question feels hypothetical.
It is not hypothetical. It is scheduled. The question is only whether you will be the one who decided what it looks like, or the one who discovers it.
We rebuilt payment routing twice. Both times the failure mode wasn't the vendor. It was us treating a strategic architectural choice like a commodity procurement decision.
If you're evaluating payment rails right now – are you making a vendor decision, or an architectural commitment you won't fully understand for another two years?
Both are true. Only one is on the agenda.