Two systems, two records of the same user
The auth side knows who logged in. The billing side knows who paid. Webhooks land out of order, and the reconciliation code that keeps the two agreeing is yours to write and yours to debug.
A user's login and their subscription share one tenant model, so a paying customer never gets locked out and access never outlives a failed payment.
You run it yourself, and the data stays in your Postgres. It's a public beta from a small team, MIT licensed, with the source on GitHub if you want to read it before you trust it.
New to ReliPay? See how the operator panel works
No per-MAU meter · MIT licensed · the source is on GitHub
Most teams wire an auth provider to a payments provider with hand-written webhooks. Then the two records disagree: a paying customer gets locked out, or access lingers after a payment fails. Keeping them in sync is the part nobody wants to own.
The auth side knows who logged in. The billing side knows who paid. Webhooks land out of order, and the reconciliation code that keeps the two agreeing is yours to write and yours to debug.
Per-MAU meters assume a single product. Ship a second app that shares users, and you pay twice for the same people, plus a per-seat charge for your own team.
Identities, subscription history, and webhook receipts sit inside the vendor. Exporting them is possible on paper and painful in practice once you have real volume.
When a user's agent wants to check their plan or recent payments, the usual answer is a static admin key with full access. There's no scoped, read-only way to hand it just the account it's allowed to see.
ReliPay is a self-hostable service that keeps auth and billing in one tenant model, so a user's login and their plan don't drift apart. You bring the payment processor and keep your own account; ReliPay keeps the data, the panel, and the SDKs in your infrastructure.
`docker compose up` boots the API, Postgres, Redis, and the panel. The same image runs in production, and the Postgres is yours.
A Tenant owns one or more Applications. Login and subscription state share that model, so a paid customer doesn't get locked out and access doesn't outlive a failed payment. Every row carries `applicationId`.
Stripe, PayPal, and Razorpay sit behind one `BillingProvider` interface, set per Application. You change a config value, not your billing code. Provider-specific fields live in `metadata`.
A built-in MCP server lets an agent read account, plan, and payment data over scoped OAuth 2.1, read-only. Connect Claude, Cursor, or Claude Code to a live instance instead of handing out an admin key.
ReliPay does auth and billing. It doesn't ship a CRM, an email blaster, or a feature-flag service. Pair it with the tools you already run.
Run the whole stack yourself with one docker compose command. No per-MAU meter, no per-seat fee, unlimited Applications, Tenants, and end-users. The Postgres is yours. A hosted plan is on the way for teams who'd rather not run infra.
Free to self-host (MIT licensed) · public beta
Run the whole stack yourself. The recommended path today.
No per-MAU meter; the Postgres is yours
Try NowSelf-host with a named support contact and roadmap input.
For teams that need a named contact
Get in touchPrefer not to run the infra yourself? A hosted plan is on the way. See hosted pricing.
If yours isn't here, ask through the contact form. This page gets updated from real questions.
Public beta. Self-host, the SDKs on npm, and the API are available today. The hosted plan isn't open yet; join the hosted waitlist. v1.0 finalizes hosted pricing. The license is settled: MIT.
Public beta
ReliPay is in public beta. If you'd rather not glue two vendors together and reconcile them by hand, run it yourself or read the source first.
Public beta · run it yourself today · the source is public