Payment Routing

What Is Payment Routing?

Payment routing is the mechanism that determines how a transaction travels from sender to recipient through an intermediary network. Every payment system that involves more than a direct connection between two parties needs routing: the process of choosing which intermediaries, channels, or processors will handle the transaction.

In the context of cryptocurrency, path-finding algorithms on the Lightning Network select a sequence of nodes and channels to forward a payment. In traditional finance, payment routing refers to how a payment processor selects which acquirer, card network, or rail to use for a given transaction. Both domains share the same fundamental challenge: moving value efficiently through a network of intermediaries.

How It Works

Payment routing differs significantly between Lightning Network pathfinding and traditional payment orchestration, but both optimize for similar goals: minimizing cost, maximizing reliability, and reducing latency.

Lightning Network Routing

On the Lightning Network, routing a multi-hop payment involves finding a path through a graph of payment channels. Each node in the network maintains a local view of the channel graph, built from gossip protocol announcements that share channel existence, capacity, and fee policies.

The routing process follows these steps:

1. The sender queries its local channel graph for a path to the receiver
2. A path-finding algorithm evaluates candidate routes based on fees, timelock requirements, and estimated success probability
3. The sender constructs an onion-routed packet that encrypts routing instructions for each hop
4. Each intermediate node decrypts its layer, forwards the HTLC, and the payment progresses toward the receiver
5. If any hop fails (insufficient liquidity, offline node, expired timelock), the sender records the failure and retries with an alternative route

Path-Finding Algorithms in Practice

All major Lightning implementations use variants of Dijkstra's shortest-path algorithm, but each applies different cost functions and probability models to estimate which routes are most likely to succeed.

LND uses a bimodal probability model that estimates the likelihood of a channel having sufficient liquidity based on the assumption that channel balances tend to cluster near the extremes (mostly full or mostly empty). CLN uses a minimum-cost flow approach that optimizes across the entire route simultaneously. LDK applies bounded liquidity scoring with logarithmic penalties that increase as payment amounts approach known channel capacities.

# Simplified route cost calculation
# Total cost = base_fee + (amount × proportional_fee) + risk_penalty

route_cost = sum(
    hop.base_fee_msat
    + (amount_msat × hop.fee_rate_ppm / 1_000_000)
    + risk_penalty(hop.success_probability)
    for hop in route
)

# Risk penalty penalizes uncertain channels
# Lower probability = higher penalty = less likely to be chosen

Mission Control and Learning

Lightning routing improves over time through a feedback mechanism known as mission control (a term originating from LND). After each payment attempt, the sender records whether each hop succeeded or failed. This historical data feeds back into future routing decisions.

When a payment fails at a specific channel, mission control records a failure timestamp and the amount that was attempted. Future routing attempts penalize that channel for a decay period, gradually restoring its reputation as time passes. This creates a system where each node builds a personalized view of network reliability based on its own payment history.

Multi-Path Routing

For larger payments that exceed the capacity of any single channel, multi-path payments (MPP) split the transaction across multiple routes. The sender divides the total amount into smaller partial payments, each routed independently through different paths in the network. The receiver reassembles them using the shared payment hash.

MPP routing adds complexity: the algorithm must find a set of paths whose combined capacity meets the total amount, while minimizing the aggregate fees across all paths. This is a harder optimization problem than single-path routing because splitting decisions interact with each other.

Traditional Payment Routing

In the card payment ecosystem, routing determines which acquirer and card network process a given transaction. Payment orchestration platforms evaluate multiple factors for each transaction:

• Acquirer selection: choosing the processor with the highest authorization rate for the card type, geography, and merchant category
• Network routing: directing transactions through the optimal card network (Visa, Mastercard, local schemes) based on interchange fees and acceptance rates
• Fallback cascading: automatically retrying failed transactions with a different processor or network before returning a decline to the customer
• Cost optimization: balancing interchange-plus and blended pricing across providers

Modern orchestration platforms like Spreedly, Primer, and Gr4vy use machine learning models trained on millions of transactions to predict which routing decision will yield the highest approval rate at the lowest cost for each individual transaction.

Multi-Rail Routing

As the payment landscape diversifies, routing increasingly spans multiple payment rails rather than a single network. A multi-rail routing engine might evaluate whether to process a given payment via card networks, ACH, real-time payments (RTP), stablecoins, or Lightning based on the transaction's amount, geography, speed requirements, and cost sensitivity.

For example, a cross-border payment might route through stablecoin rails to avoid correspondent banking fees, while a domestic point-of-sale transaction routes through the local card network for speed and familiarity. This multi-rail strategy reflects a broader trend toward treating all payment methods as interchangeable rails selected dynamically by routing logic.

Use Cases

Lightning Routing Nodes

Operators who run routing nodes on Lightning earn fees by forwarding payments through their channels. Effective routing depends on strategic channel placement, competitive fee policies, and sufficient inbound and outbound liquidity to handle payment flow.

Merchant Payment Optimization

Large merchants use payment orchestration to route millions of transactions daily. By dynamically selecting processors and networks, they can increase authorization rates by 1 to 3 percentage points and reduce processing costs significantly: outcomes worth millions in annual revenue for high-volume businesses.

Cross-Border Commerce

International payments benefit most from intelligent routing. A payment from a European customer to a US merchant might route through a local European acquirer to avoid cross-border interchange premiums, or through a stablecoin rail to eliminate FX spreads entirely.

Risks and Considerations

Liquidity Uncertainty

On Lightning, the fundamental challenge of routing is that channel balances are private. A sender can see that a channel exists with a given capacity, but not how that capacity is distributed between the two endpoints. This means routing decisions are based on probabilistic estimates rather than certain knowledge, and payments may fail partway through a route, requiring retries.

Channel Jamming

Channel jamming attacks exploit routing by sending payments that intentionally lock up liquidity along a route without completing. This can degrade routing reliability for other users and reduce the effective capacity of the network. Proposed mitigations include HTLC endorsement and upfront fees for forwarding commitments.

Centralization Pressure

Routing algorithms naturally favor well-connected, high-liquidity nodes because they offer the highest probability of successful payment forwarding. This creates a centralizing tendency where a small number of large routing nodes handle a disproportionate share of payments, raising concerns about censorship resistance and single points of failure.

Routing Complexity and User Experience

For end users, routing complexity is a significant source of friction. Failed payments, route-not-found errors, and the need to manage channel liquidity all stem from the channel-based routing model. This is one of the key problems that newer Bitcoin Layer 2 designs address.

How Spark Simplifies Payment Routing

Spark takes a fundamentally different approach to value transfer that eliminates routing entirely. Instead of payment channels that require pathfinding through intermediaries, Spark uses a statechain-based architecture where ownership of a virtual UTXO (vUTXO) is transferred directly between parties through a cooperative signing protocol.

In this model, there is no graph of channels to navigate, no multi-hop forwarding, and no liquidity constraints along a route. A payment on Spark is a direct transfer of ownership, not a series of forwarded HTLCs. This eliminates routing fees, removes the need for inbound liquidity management, and makes payment reliability deterministic rather than probabilistic.

For a detailed comparison of these two approaches, see the Lightning vs Spark glossary entry and the Lightning Network routing deep dive.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.