Quickstarts

Each quickstart sets up exactly one component of the SubEtha flow; a complete payment needs the three runtime roles running against the same stack, which the local end-to-end tutorial walks through in order.

Not sure where to start? Begin with Start here to understand the roles and concepts, then follow the local end-to-end tutorial to see the complete flow before choosing a role-specific quickstart.

Pick your role

• Payer — TypeScript — pay for HTTP resources from Node.js with the official x402 client (x402Client + wrapFetchWithPayment) and the @subetha/x402-scheme plugin.
• Payer — Python — pay from Python with the subetha package: SubethaClient, an operator-configured SpendingPolicy, and the quote / pay / report workflow.
• Provider — charge for an HTTP API behind 402 Payment Required with the official x402 Express middleware and the @subetha/provider scheme plugin, against a separately running facilitator.
• Facilitator — build and run the settlement daemon from source, validate its config, and start it against the local stack. Its optional participant-scoped payment history surface is documented in the payment history reference.

Before you start

Every quickstart assumes the mental model from Start here and the flow vocabulary from How SubEtha uses x402 v2: a request is answered with a 402 offer, the payment makes it accepted (the resource is served), and settlement finalizes later, asynchronously — the two states are never the same thing.

On the reproducible path these quickstarts and the tutorial follow, paying end-to-end runs against the local zERC20 stack (anvil on chain 31337, the deployed contracts, an indexer, and a prover) from the product repository’s canonical runbook — docs/RUNNING-THE-STACK.md. The tutorial sequences all of it.