11 — Rails, routing, reconciliation
One interface over every rail you need, with routing, FX and reconciliation solved rather than deferred.
Every payment rail has its own cut-off times, failure modes, return codes and reconciliation format. Teams that integrate them one at a time end up with the differences leaking into product code, and a reconciliation process that is somebody's spreadsheet.
We build the abstraction that holds: rail adapters behind one interface, routing that accounts for cost, speed and success rate, an FX and pricing engine, and reconciliation as a first-class system rather than a month-end task.
Common questions
What is payment orchestration?
A layer that routes each payment across multiple providers or rails based on cost, speed, success rate and availability, behind one interface. It matters most at scale, where a percentage point of authorisation rate or a basis point of cost is material, and where single-provider dependency is a business risk.
Why is reconciliation treated as an afterthought so often?
Because it produces no demo. Reconciliation only becomes visible when volumes make manual matching impossible, by which point the data needed to automate it was never captured. Designing the ledger and the rail adapters to emit reconcilable records from day one costs very little; retrofitting it costs a great deal.
How should FX spread be handled in a payment flow?
Quoted before the payment with an explicit validity window, held against a hedged position, and recorded so the realised spread can be reconciled against the quoted one. Systems that price at settlement rather than at quote transfer market risk to the customer invisibly, which is both a commercial and a conduct problem.
Next capability
Fintech MVPs
Bring us the hard part.
Forty-five minutes with the people who would actually run the build.