Routeweiler

Routeweiler is an async Python HTTP client (await routeweiler.get(url)) that intercepts 402 Payment Required responses, works out which payment protocol the server is asking for, signs and sends the payment client-side, and retries the original request — so the calling code just sees a 200. It currently normalizes four distinct, mutually incompatible payment rails behind one interface: x402 (EVM, USDC on Base/Ethereum), L402 (Bitcoin Lightning, BOLT-11), MPP-Tempo (Tempo-chain stablecoin), and MPP-SPT (Stripe's Shared Payment Token for card rails). Routing between them is policy-driven — you can allow, deny, or preference a rail per URL pattern, network, or amount, and it picks the cheapest available quote.

The real value is standards fragmentation: x402 (backed by the Linux Foundation's x402 Foundation, with Visa, Stripe and Google as members) and Lightning Labs' L402 are two live, competing specs for the same HTTP 402 mechanism, and Tempo and Stripe SPT add two more. An agent developer who wants to hit paid endpoints regardless of which rail they picked currently has to hand-roll support for each. Routeweiler collapses that into one client call and one Funding object per rail, which is a legitimate integration-cost saving. Its custody model is also worth crediting on its own terms: keys are supplied by the caller (Account.from_key(), an LND client, a wallet signer) and never transmitted or stored by Routeweiler — the only thing that persists is a local SQLite trace of what was paid, when, and on which rail, with spend caps enforced by a BudgetEnvelope that makes overspend within a single process structurally impossible rather than policy-enforced after the fact.

There is no company. The site, docs and SDK are the work of one developer, Nikolaos Schoinas, published under an individual GitHub account (github.com/nikoSchoinas/routeweiler-python-sdk) with Apache-2.0 licensing. The privacy policy names no legal entity and no jurisdiction. The 'Users' page on the marketing site describes hypothetical personas (agent platforms, inference services, finance/ops teams) rather than named customers or case studies — there is no independent evidence yet of production adoption.

The repo has 31 stars, 1 fork, 3 open issues and 301 commits as of this check. It's actively worked on — the most recent commit was July 26, 2026 (hardening macaroon parsing, fixing retry-without-repaying bugs) — but the last published PyPI release is v0.1.2 from May 25, 2026, about two months behind the GitHub main branch, and the package is explicitly at beta/pre-1.0 status. A query against the OSV vulnerability database returned no known advisories for the routeweiler PyPI package, and GitHub shows no published security advisories — but the repo also has no SECURITY.md and no evidence of a third-party security audit, which matters more here than for a typical library because this one signs financial transactions.

The docs and product page assert that because Routeweiler never custodies funds or transmits private keys, this 'keeps Routeweiler outside money-transmitter and CASP regulatory scope.' That is the maintainer's own legal interpretation of the architecture — there is no independent legal opinion, regulator guidance, or audit cited to support it, and we found none in our own search. Whether a non-custodial payment-routing library actually falls outside money-transmitter licensing in a given jurisdiction is a real, non-trivial question that a team relying on this for anything regulated should have their own counsel confirm rather than take from the vendor's docs.

Free and open source under Apache 2.0 — pip install routeweiler, no paid tier, no hosted service to subscribe to. There is nothing to disclose or hide on pricing because there is no pricing; the cost to a buyer is entirely the underlying rail fees (on-chain gas, Lightning routing fees, Stripe processing) plus their own integration time.