The Ulabase Kit

Sign-up, sessions and checkout each take several steps.

Signing up is a POST, an email, a verification link that lands on a different origin, a redirect carrying a token in a URL fragment, and a token to store. A session is a JWT that expires in fifteen minutes and has to be renewed before it does, from a timer that survives a backgrounded tab. A checkout is a redirect to Stripe, a return to a page that knows which order came back, and a webhook that may arrive after the customer does.

The kit handles those flows against your service’s sign-up and Stripe features. It has no dependencies of its own and works with any framework.

Each adapter wraps the core: the same functions, exposed the way that framework expects state to arrive. Payments have their own API, apart from auth: a subscription loads on sign-in, reloads when the user switches team, and stays untouched when the service has no stripe feature.

Each adapter installs the core as a dependency. Each package’s README has the exact line.

Angular, in app.config.ts:

React, near the root:

Vue, in main.ts:

In all three the session is restored once at start-up, before the first guard runs, so a page reload keeps a signed-in user where they were. Until then initializing is true: show a spinner while it is.

Accounts: register, verify, login, logout, checkSession, getUserInfo, renewToken, forgotPassword, resetPassword, changePassword, updateProfile. The flows of Sign-up and login, with the redirects and token deliveries already handled.

Teams: getTeams, switchTeam, createTeam, listTeamMembers, updateMemberRole, removeMember, and the invitation half: invite, getInvitation, activate, acceptInvite, resendInvite. Switching team issues a new token, since the team is a claim in the token.

Consents: acceptConsents, for accepting terms and privacy policy. Use it with Guards, which make acceptance mandatory on the server, where the client cannot skip it.

Payments: getPlans, createCheckoutSession, openBillingPortal, getSubscription, waitForSubscription, and seat licences with getLicenses / grantLicense / revokeLicense. For a shop with one-off orders: getCatalog, createOrder, getOrder, waitForOrder, readOrderRef. You need no Stripe.js and no publishable key: every Stripe page is hosted, and the kit gives you its URL to navigate to. See Stripe billing for the service side.

The customer’s browser usually comes back to your site before Stripe’s webhook does. waitForOrder waits for the webhook, and when it is late it rejects with a WaitTimeoutError, so you can show "still confirming" for a payment that has not failed.

Cart: lines, quantities, subtotal and persistence, ready for any shop. The logic is pure and takes the lines it works on, and each framework wraps it: useCart() in React and Vue, RhCartService in Angular.

orderItems is the cart in the shape createOrder takes. Names, prices and pictures stay out: the service reads them from its own catalog. The chosen options go with the order, as the line’s metadata. A reference like tee-classic/yellow-l says which row of the catalog was bought; the options give the seller "yellow, L" in separate fields.

The cart works without a session: it needs no AuthConfig and no auth provider, so visitors can fill a basket before they sign in. It becomes an order at createOrder, which needs a config. It lives in localStorage, so a reload keeps it; pass a storageKey when two of your apps share an origin.

Errors are thrown as an ApiError, { status, message }, with the server’s own message in it.

register sends whatever you give it. If the service’s users collection has a JSON Schema, extra fields are validated against it; if it has none, the server silently drops them and still answers 201. If a profile field never appears, this is the usual cause.