Introducing Route402 — an x402 facilitator router
A multi-tenant router that lets you integrate x402 once and route requests by policy and facilitator capability, without pushing routing logic into your app.
- infrastructure
- payments
- x402
The short version
Route402 lets you integrate x402 once, then route requests across multiple enabled facilitators based on policy and capability support. Your app stays simple, and your payment operations stay flexible.
x402, in plain terms
x402 defines a standard handshake for paid requests. It gives clients and facilitators a common shape for verify and settle flows so you do not need custom glue for every provider.
That standardization is great. The hard part starts when you have more than one facilitator or need deterministic routing by supported request fields.
The real problem
Teams end up baking routing decisions into the app: which provider to use for a scheme, network, asset, amount, payee, or endpoint; how to handle one verification failure; and how to avoid double-settling. That logic does not belong in product code, but it tends to accumulate there.
What Route402 is
A multi-tenant router that sits between your app and upstream facilitators. Your app talks to Route402 as if it were a single facilitator. Route402 makes the routing decision.
The key proposition: integrate once, then route every request based on deterministic rules and supported capabilities.
What you can route on
- Policy rules over the current DSL fields:
scheme,network,asset,amount,payTo, andendpoint. - Capability checks: do not send a request to a provider that cannot support it.
- Verification fallback: if the selected facilitator's verify request errors, Route402 can try one alternative enabled facilitator that supports the request.
- Sticky settlement: keep settle decisions consistent to prevent double-settling.
Ruleset language (simple, readable, deterministic)
Rules are a tiny YAML DSL. Order matters, first match wins, and there is always a default.
default: "thirdweb-prod"
rules:
- name: base-usdc
when:
all:
- eq: [network, "base"]
- eq: [asset, "USDC"]
then:
use: "cdp-base"
This lets you express business policy in one place without baking routing logic into your app.
Why it matters
- Resilience without rewriting your app.
- Faster onboarding of new facilitators and new networks.
- Safer settlements and fewer operational surprises.
- Clear audit trails for what happened and why.
Common use cases
- Route one endpoint or payment recipient to a selected facilitator.
- Route USDC on Base to one facilitator, everything else to another.
- One fallback attempt when a facilitator's verify request returns an upstream error.
- Select a facilitator for a deterministic subset of supported request fields; the current DSL does not provide weighted or percentage canary routing.
Operational basics
Route402 includes access control, encrypted credential storage, and routing logs so you can manage it like infrastructure instead of app logic.
Links
Closing
Route402 is the switchboard for x402. Keep your app simple, keep your options open, and let routing be a policy decision instead of a code change.
Contributors
Fenwei Bian is a software developer in her thirties who spends her working hours in pull requests and her weekends with her hands in soil or sawdust. Years of open source on GitHub taught her that names are interfaces: a good one is clear, honest about what it does, and kind to whoever has to use it next.
She gardens because it rewards patience and punishes wishful thinking, and she does woodwork because a joint either fits or it doesn't. Both habits show up in how she writes about naming — measure twice, check the source, and don't sand over a rough spot and hope no one notices.
For Namefi she writes about how domain markets actually move, the practical trade-offs of tokenizing and flipping names, and picking a domain you'll still be glad you own in twenty years.
Victor Zhou is a technology founder and standards editor focused on digital identity and trust. He founded Namefi, edits Ethereum Improvement Proposals, and previously led smart-contract architecture work at Google Labs.
His work sits at the intersection of naming, ownership, and the systems people use to establish identity online. That perspective makes him especially interested in the way names move between personal meaning, public recognition, and digital infrastructure.
For Namefi, Victor edits and writes about domains as durable digital identity: how names become ownable onchain assets, how tokenization changes custody and trust, and what naming can learn from the systems people use to establish identity online.