Capability-based routing is a payment routing method that sends each transaction only to providers technically and contractually able to process it, meaning the right card brand, currency, payment method and features, before any cost or performance ranking applies. A routing engine keeps a capability matrix per provider and merchant ID covering items such as 3-D Secure 2, network tokens, stored credentials and partial capture, plus contractual limits on merchant categories, volume or country. Ranking by price first sends payments to providers that cannot handle them, wasting checkout time and polluting decline data. When only one provider qualifies there is no fallback, so the matrix also maps concentration risk.
What is capability based routing
It is the filtering layer of a routing engine. A merchant or payment orchestration platform keeps a capability matrix for every connected provider and merchant ID, then removes the ineligible ones from the candidate list for each transaction. Whatever survives is passed on to cost, approval-rate or load-balancing rules.
How does capability based payment routing work
Take a subscription renewal: a SEK 349 charge on an American Express card, using a stored network token, flagged as a merchant-initiated transaction. The merchant has three acquirers. Acquirer A does not accept Amex. Acquirer B accepts Amex but cannot process network tokens. Acquirer C supports both, plus SEK. Only C is eligible, so the renewal goes there regardless of price.
The same logic exposes a weakness. When only one provider qualifies, there is no fallback: if C times out, the renewal fails. Capability matrices show where a merchant has single points of failure that a simple provider count hides.
Payment routing by provider capabilities: what the matrix holds
Technical capabilities include supported card brands and alternative payment methods, presentment and settlement currencies, 3-D Secure 2 support, network tokens, recurring and stored-credential flags, partial and delayed capture, refund windows, Level 2/3 data, and payouts to cards.
Contractual capabilities are just as binding. An acquirer may accept travel but exclude gambling (MCC 7995) or crypto purchases (MCC 6051), cap monthly volume per merchant, or serve only merchants established in certain countries. Sending a restricted transaction to such an acquirer is a contract breach even if the API accepts it.
Why capability checks come before cost
If a router ranks by price first, the cheapest provider may reject a payment it was never able to handle, returning an "unsupported currency" or "invalid transaction" error. That burns time at checkout, triggers an unnecessary retry, and pollutes decline statistics with failures that have nothing to do with the issuer. Cost-aware routing only produces sensible savings when it chooses among providers already confirmed as eligible.
Keeping capability data current
Providers add payment methods, drop currencies and change risk appetite without changing their API. A matrix configured once and never updated fails quietly, usually noticed only when approval rates for one segment collapse. Mature setups pair static configuration with provider health monitoring, tracking error codes per capability so a provider that stops handling, say, Apple Pay tokens is removed from that route automatically. For a buyer assessing a payment business, the matrix is also a quick map of concentration risk: capabilities available through only one acquirer contract are revenue that depends on one relationship.