Purchase

Effect-first commerce runtime

A provider-neutral billing runtime for Effect applications.

Purchase gives teams one typed commercial layer for catalog authoring, checkout, webhooks, entitlements, credits, refunds, and account activity. The goal is to keep billing logic coherent as products, providers, and operational workflows grow.

Stripe and Paddle stay behind the runtime. SQLite, D1, PostgreSQL, and MySQL-oriented deployments stay with the app.

The application reads snapshots, entitlements, wallet balances, and activity instead of reasoning directly about provider objects.

Why Purchase

Most billing complexity appears after the first successful checkout.

Provider SDKs expose APIs. They do not give product teams one shared commercial model, one workflow runtime, or one durable place to normalize lifecycle behavior. Purchase is aimed at that missing layer.

Surface

One runtime surface for the operational parts of billing.

Purchase is intentionally shaped around recurring product concerns: catalog synchronization, checkout launch, webhook ingestion, projection refresh, credit consumption, refunds, subscription mutations, and portal entry points.

Catalog DSL for subscriptions, one-time purchases, quotas, and credit units

Shared workflow APIs for checkout, webhooks, portals, refunds, subscription mutations, and credits

Typed customer snapshots, entitlements, wallets, and workflow receipts

Node and Cloudflare-oriented runtime direction with SQL-backed state

Reference Next.js app showing auth, pricing, checkout, account activity, and credits consumption

Next steps

Open the walkthrough, then drop into the technical docs.

If you want the fastest path to understanding the system, start with the example app series and then read the architecture, workflows, and deployment pages.