Skip to content

AI-native SaaS Launch OS

Private beta — see exactly what exists today

Your SaaS billing, entitlements and access —
on the providers you already use.

Connect the Paddle account you already have. Paycux keeps the catalog, plans, entitlements and usage limits, and hands checkout, portal and cancellation to your provider. It does not process payments or hold funds.

Built on the billing providers and infrastructure you already run

Stripe · test and live keysPaddle · sandbox and live keysKeycloak · one realm per environmentOpenBao · provider secretsPostgreSQL · row-level tenant scopeNATS · event transportStripe · test and live keysPaddle · sandbox and live keysKeycloak · one realm per environmentOpenBao · provider secretsPostgreSQL · row-level tenant scopeNATS · event transport

Available today

A control plane,
not a payment processor

Everything below exists in the API and the console right now. It is the whole list — planned products are marked as planned wherever they appear on this site.

Developer-first design

A small, explicit HTTP API

No SDK to install. Your application calls a handful of JSON endpoints with the Keycloak token your user already holds; your team uses the console or the same API behind a session cookie.

JSON everywhere. Validation failures answer 400 INVALID_INPUT; every error has a named code.

Idempotency-Key on usage events and checkout sessions, so a retry never double-counts or double-sells.

Three identities that are never mixed: dashboard session, end-user realm token, provider webhook signature.

Provider API keys are verified with a read-only call, stored in OpenBao and leased per request — never returned or logged.

Projects and environments, each environment with its own Keycloak realm and its own provider connections.

Every catalog, membership and lifecycle write lands in the workspace audit ledger.

1# Record usage and get an allow/deny decision.
2# Realm token = your application user's Keycloak access token.
3curl --request POST "https://api.paycux.com/v1/usage/events" \
4 --header "Authorization: Bearer <realm access token>" \
5 --header "Idempotency-Key: 7f1c1e4a-usage-2026-09-03-0001" \
6 --header "Content-Type: application/json" \
7 --data '{
8 "projectId": "<project id>",
9 "environmentId": "<environment id>",
10 "realmId": "<realm id>",
11 "billingAccountId": "<billing account id>",
12 "meterKey": "api_calls",
13 "quantity": 1,
14 "occurredAt": "2026-09-03T10:15:00.000Z"
15 }'
16
17# 200 — UsageDecision
18{
19 "allowed": true,
20 "reason": "WITHIN_LIMIT",
21 "consumed": 1,
22 "limit": 10000,
23 "eventId": "<event id>",
24 "duplicate": false
25}

Catalog and entitlements

Plans, prices and limits,
versioned and never deleted.

Define products, plans, prices, features and meters per environment. Map each plan to a price on your own provider connection. Archive what you stop selling — subscriptions that already exist keep working.

Catalog · workspace v2Example
starterEUR 0 / month
seats · 3api_calls · 10,000exports · 1
growthEUR 4,900 minor / month
seats · 25api_calls · 250,000exports · unlimited

Illustrative keys and limits. Each plan maps to a price on your own provider connection; checkout sells the highest unarchived version.

Entitlement limitsper plan and feature, projected onto every subscription and re-projected on renewal
Usage decisionsone idempotent call per event, answered with WITHIN_LIMIT, LIMIT_EXCEEDED, NO_ENTITLEMENT or SEAT_REQUIRED

Organisations and members

Your users' organisations, your team's workspace

End users create organisations and invite colleagues through the API. Your team manages its own workspace — members, roles, invites, export and deletion — from the console.

Organisation lifecycleImplemented
  1. 1POST /v1/billing/organizationsEnd user creates an organisation and becomes its owner
  2. 2POST …/organizations/:id/invitesOwner invites a colleague; the token is shown once
  3. 3POST /v1/billing/invites/acceptInvitee accepts with a matching verified e-mail
  4. 4GET /v1/environments/:id/organizationsYour team sees members and pending invites, e-mails masked

End users create an organisation and become its owner

Invites are single-use tokens, stored only as a hash, expiring after 7 days

Acceptance requires the same verified e-mail — mismatches fail closed

Your team sees masked e-mails and can revoke a pending invite

Workspace owners and admins manage members; removing one revokes every session

Workspace export is secret-free JSON; deletion has a 30-day cancellation window

Where this is going

Planned, and labelled as planned

The product pages on this site describe capabilities Paycux intends to build — hosted sign-in, SSO, directory sync, roles, audit streaming and more. None of them exist yet, none can be switched on, and every one of those pages says so at the top.

Paycux is in private beta. Approved workspace plans and launch prices are published on the pricing page.

Keep your provider. Add the control plane.

Create a workspace, connect a Paddle test key, define a plan, and send your first usage event.