Introduction

Payweave is a unified, fully-typed TypeScript SDK for Stripe, Paystack, and Flutterwave — one client, any provider, with subscriptions, metered usage, and webhook handling built in rather than bolted on.

One SDK, every provider — woven together.

The problem

Wiring up payments usually means:

• hand-rolling fetch calls against each provider's REST docs, one provider at a time,
• copy-pasting webhook verification snippets (and frequently getting signature validation wrong),
• writing your own subscription/plan bookkeeping and database schema by hand, and
• doing it all again the moment you add a second provider, a database, or usage-based billing.

Payweave collapses that into one config object and one client.

Why Payweave

• One client, every provider. Configure one or more of Stripe, Paystack, and Flutterwave under createPayweave({...}) and get a single, fully-typed client — see Getting started.
• Two surfaces, no lock-in. Provider-native calls (Surface A) when you want full control; a normalized unified layer (Surface B) when you want portability. Every response carries raw.
• Billing that persists. Bring your own database and get plan()/feature() definitions, subscribe(), sync(), metered check()/report(), and idempotent webhook-driven state updates — see Database, Plans & features, and Metered usage.
• Webhooks as a first-class, security-critical citizen. One endpoint verifies and normalizes events from every configured provider — correct signature scheme per provider, raw-body verification, constant-time comparison, fail-closed. See Webhooks.
• A CLI that ships with it. payweave init | push | listen | status scaffolds a project, migrates + syncs plans to your providers, relays webhooks locally, and validates your setup — see CLI.
• Money that can't drift. The unified layer always uses integer minor units; provider adapters convert so you never fat-finger a decimal.
• Typed errors that tell you whose fault it is — yours (validation/auth), the customer's (declined), or transient (network/5xx). See Errors & retries.
• Tiny SDK footprint. ESM-only, zod is the SDK's only runtime dependency, Node ≥ 20.19.

Status

Pre-release. Stripe, Paystack, and Flutterwave v3 (provider-native resources + webhooks), the unified layer, the database layer (sqlite, Postgres, MongoDB, Drizzle), plans/features/metered usage, and the CLI are implemented and tested. Still landing: the MySQL and Prisma database adapters, Flutterwave v4's resource surface (auth + webhooks are in place), and live provider contract tests.

Two API surfaces

Payweave deliberately exposes both:

• Surface A — provider-native. Every endpoint from the provider's official docs, 1:1, with the provider's own field names. This is what makes it credible as "the official SDK" for each provider. See Providers.
• Surface B — unified. A smaller set of high-traffic operations (checkout, verify, refunds, transfers, banks) with identical signatures across the providers that support them. See Unified layer for the exact capability matrix.

Head to Getting started to install and initialize your first client.