An orchestrator stops paying for itself when routing becomes a source of margin, not a convenience. Early on it is unambiguously worth it: one integration instead of six, faster provider onboarding, no in-house routing logic. The crossover comes when you have enough volume that a few basis points of routing improvement exceeds what the orchestrator charges. And when the routing rules that would capture those points are ones only you can write, because they depend on your customers rather than on generic provider performance.
The signal is not volume by itself, it is how often you find yourself wanting a routing rule the orchestrator cannot express. Route by issuer country and card BIN, retry on a different provider only for specific decline codes, prefer the cheaper rail unless the customer is in a segment where authorisation rate matters more than cost. These are the rules that produce real money and the ones most likely to hit the ceiling of a general-purpose product.
The second signal is data. An orchestrator sits between you and the providers, which means the raw response detail you need to improve authorisation rates arrives filtered through someone else's model. Teams optimising seriously usually find they need the unabridged provider responses, and that is an argument for direct integrations regardless of routing.
The counter-argument is real and underweighted: direct integrations are permanent maintenance. Every provider changes their API, their certification requirements and their settlement formats on their own schedule, and that work never ends. Bringing routing in-house means owning that treadmill for every provider, forever.
The common resolution is hybrid. Direct integrations to the two or three providers carrying most of the volume where the economics justify the maintenance, with an orchestrator retained for the long tail and for fast access to new markets.