Ask a payment team what they want from AI, and routing is usually the first answer. It’s the right instinct. Routing is the one decision in the payment flow that repeats millions of times, carries direct revenue consequences, and is still made by rules a human wrote months ago.The instinct goes wrong at the next step. Teams treat intelligent payment routing as something to switch on, when it’s something a stack either can or cannot support. A model that chooses between providers learns from the record of what those providers did. If that record is inconsistent across the stack, the model learns the inconsistency. In our 2025 study of 672 payment stacks worldwide, 58.5% of businesses still run payments through disconnected providers and tools, and only 11.7% have reached the point where payment operations adapt to changing conditions. That’s the real constraint on AI in payments right now, and no model solves it.Where your routing sits on the 5-level ladderRouting capability builds in a fixed order. Each level depends on the one below it.Static rules encode what you already know. Payment cascading turns a decline into a second attempt through an alternative provider. Least cost routing selects the cheapest eligible path and has gained regulatory support in markets such as Australia, where the central bank has pushed for broader merchant access to it. Performance-based routing reacts to how providers behave this week rather than how they behaved at integration. Predictive routing scores each transaction individually.The order matters because every level produces the data the next level consumes. Cascading generates the paired outcomes (route A failed, route B succeeded) that make performance comparison meaningful. Performance-based routing produces the labeled history a model trains on. Skipping to prediction means training on a dataset your stack never generated.What most stacks are missingThree gaps stop routing intelligence more often than model quality does.Decline codes are not normalized. Every provider returns its own vocabulary. One reports a generic ‘do not honor’ where another distinguishes insufficient funds from a fraud-rule hit. Until those are mapped to a single scheme with a clear soft/hard split, "approval rate by provider" is comparing measurements taken with different instruments. This single gap does more damage than any other, because it corrupts both the training data and the evaluation.Route history is thin where it matters. A model needs outcomes at the level it makes decisions: card country, BIN range, method, provider, amount band, and whether the attempt was a retry. Many stacks hold this data across several dashboards with no shared identifier, so the joined history exists in theory and nowhere in practice.Cost sits in a different system from the outcome. Approval and cost are optimized by different teams on different reporting cycles. A model that never sees cost will happily route to the most expensive acquirer to gain half a point of approval, and nobody will notice for a quarter.None of this reflects poor work by payment teams. It reflects how stacks grow: a provider added for a new market, another for redundancy, a third for a local method. Our maturity data shows 37.1% of businesses now manage five or more providers, and organizational ownership lags behind that complexity, with only 41% having a dedicated payment manager or team. Among businesses processing over 500k transactions, that figure rises to 73.1%, which tells you when the problem becomes impossible to ignore.4 data inputs intelligent payment routing needsBefore evaluating vendors or models, check whether your stack produces these four things.Normalized decline codes. Map every provider response to one internal taxonomy with two axes: soft versus hard, and retryable versus terminal. Without this, cascading retries hard declines and burns issuer goodwill, while the model learns that certain providers "fail more" when they are simply more descriptive about failure.Per-route outcome history with sufficient density. Define your routing segments explicitly, then check volume per segment per week. Segments with a handful of transactions cannot support a prediction; they belong under rules.True cost per route. Scheme fees, interchange where you see it, provider markup, FX spread, and the cost of a retry. Least-cost routing and approval optimization pull in opposite directions, and you cannot balance them if one side is unmeasured.Context and risk signals at decision time. 3D Secure outcome, customer tenure, whether the card has succeeded before, attempt number, time since the last attempt. These carry most of the transaction-level signal that separates prediction from a rolling average.Where prediction beats rulesThe strongest objection to intelligent payment routing comes from experienced Payment Managers, and it’s largely correct: a well-maintained rule set, plus cascading, captures most of the available gains. Rules are explainable, auditable, and adjustable in an afternoon. A model that improves approval by a fraction of a point, while no one can explain a specific decision to the risk team, is a poor trade.Two factors decide the boundary.Data density. Prediction earns its place where a segment sees enough volume for the model to separate signal from noise and seasonality. Across the long tail of local methods and small corridors, rules remain more reliable, because there is nothing to learn from.Explainability requirements. Where a routing decision must be defended to compliance, finance, or a provider, deterministic logic wins. Keep those flows on rules deliberately rather than by omission.Prediction does three things rules struggle with. It sets retry timing per transaction instead of applying one fixed interval. It chooses between three or more genuinely comparable routes, where a human would pick arbitrarily. And it detects provider degradation from the shape of declines hours before a threshold alert fires.What happens when a model optimizes approval rate aloneIn our 2026 study of 112 Payment Manager job descriptions across 15 countries and 19 industries, approval rate was the most-cited KPI by a wide margin, at 14.1% of all mentions, ahead of payment success rate and processing cost, each at 6.7%.That ranking is reasonable for a scorecard and dangerous as a target for an optimizer. Point a model at approval rate alone, and it will find approval wherever it lives, including on routes that cost more, carry higher chargeback exposure, or concentrate volume with one acquirer to the point of creating a dependency.Define the objective as net contribution per attempt: expected approval multiplied by transaction margin, minus routing cost, minus expected chargeback and refund cost. Then set guardrails on each component so no single term can be traded away: a cost ceiling per segment, a maximum share of volume per provider, a chargeback threshold that pulls a route out of rotation automatically.A 6-step rollout that keeps you in controlBaseline for 90 days. Record approval rate and blended cost per segment under current rules. Without this, any later improvement is unattributable.Normalize decline codes before anything else. This is unglamorous mapping work, and it’s the step that determines whether the rest is worth doing. Run it against historical data too, so your training set and your live traffic speak the same language.Run the model in shadow mode. Let it recommend while rules still execute. Log both decisions. After a few weeks, you will see where the model agrees, where it diverges, and whether the divergences would have been right.Split traffic on your densest segments only. Not on the whole book. Pick two or three high-volume corridors, hold the rest on rules, and compare against the baseline over a full billing cycle rather than a good week.Set guardrails before scaling. Provider volume caps, cost ceilings, a mandatory deterministic fallback when the model is unavailable, and a kill switch any operator can use without a deployment.Review on a fixed cadence. Weekly: cases where the model and rules disagreed, with outcomes. Monthly: thresholds, segment definitions, and whether any long-tail segment has grown dense enough to move from rules to prediction.Most of this work is infrastructure rather than data science, which is why it usually stalls in stacks where routing logic, provider data, and cost data live in different places. Consolidating them is the point of a payment orchestration platform: one normalized transaction record across every provider, and routing rules that a payment manager can change without a release window. Corefy's routing and cascading engine evaluates over 100 attributes per transaction, including custom metadata, which means the segment definitions above are configuration rather than an engineering project.What to take awayRouting intelligence is limited by the quality of your transaction record, not by the sophistication of the model available to you.Normalized decline codes are the prerequisite. Every other input depends on them being right.Match the method to the segment: prediction where volume is dense, rules where it is thin or where decisions must be explained.Optimize net contribution per attempt, with guardrails on cost, concentration, and chargebacks.Prove the gain in shadow mode and on split traffic before it touches the whole book.Yes#PaymentRoutingDenys KyrychenkoCo-founder & CEOCorefy27 Aug, 2026