Skip to main content

Two ways to initialize

createRouterFromEnv (recommended) reads process.env, validates every value up front, and throws a single RouterConfigError listing every problem at once. Protocols toggle on by presence: x402 when the CDP key pair is set, MPP when MPP_SECRET_KEY is set (at least one is required).
lib/router.ts
createRouter(config) takes an explicit RouterConfig: use it for custom networks, multiple payees, non-standard assets, or anything the env entry point doesn’t expose. It runs the same validation.

Core

x402

Auto-enabled when both CDP vars are set.
Creating the router kicks off a background fetch of the facilitator’s supported payment kinds, including during next build. With missing or placeholder CDP keys you’ll see [x402] facilitator /supported failed, using hardcoded baseline in build logs. That’s a graceful fallback, not a fatal error.

MPP

Auto-enabled when MPP_SECRET_KEY is set. For local development, mint a throwaway keypair where payee and operator line up:

KV store

Without a KV store, this state lives in per-process memory. On serverless or multi-instance deployments, a wallet that paid on instance A is treated as unpaid on instance B, so pay-once-then-replay routes charge users twice. Attach a KV store before production traffic.

Plugin hooks

Pass a RouterPlugin to observe the request lifecycle. All hooks are optional and fire-and-forget: they never delay the response.

Debugging with onAlert

The router reports internal warnings (failed payment verification, simulation failures, misconfiguration) through onAlert. With no plugin registered these are silently dropped, so a logging plugin is the fastest way to see why a request failed: