When subscription logic first gets added to an app, it usually starts in the most convenient place: the frontend. The browser handles the UI, initiates checkout, reacts to redirects, and often ends up carrying more responsibility than it should.
That approach works early on, but it creates a structural problem. The browser is a useful interface layer, but it is not a reliable trust boundary for payment-sensitive decisions.
I recently reworked my application so billing and authentication flows no longer depend too heavily on browser-trusted state. Instead, authenticated billing operations now run through server-validated routes, session transport is tightened in production, and subscription state is synchronized through reconciliation and webhook-driven updates rather than optimistic UI assumptions.
The goal was not to “make the app secure” in some absolute sense. The goal was to make the system more correct, more defensible, and easier to reason about when authentication and billing state diverge.
The Problem With Client-Shaped Billing Flows
A lot of billing implementations become frontend-heavy by accident.
It usually happens through a series of reasonable decisions. The client starts checkout. The client handles the redirect back. The client updates plan state immediately. The client becomes the first place subscription state is interpreted.
The problem is that those are not equivalent events.
A redirect is a user experience event. It is not proof that the local application state is correct. Once money and account access are involved, that distinction matters.
The more billing state depends on browser timing, browser assumptions, or optimistic UI updates, the harder it becomes to trust the system when something goes wrong.
The Architectural Shift
The main change was simple: the browser should request billing actions, but it should not be the authority on billing outcomes.
That led to a cleaner model:
In this model, the browser handles interaction, the server validates identity, the billing provider confirms commercial state, the database records entitlement, and webhooks correct subscription drift over time.
This was the real shift. The browser stopped acting like the system of record for billing state.
Why This Boundary Matters
When billing logic sits too close to the browser, a few failure modes become common. Stale UI state gets mistaken for real entitlement. Redirects are treated as successful activation. Provider and app state drift apart. Billing correctness becomes harder to audit. Failures become harder to localize.
Moving billing behind server-validated flows does not remove complexity. It moves that complexity into a more appropriate runtime.
That is an important distinction. Good architecture is not about having less logic. It is about putting logic in the right place.
How I Actually Made the Change
I made the change in four parts.
1. I moved billing-sensitive actions behind authenticated server routes
Instead of letting the browser directly coordinate plan reads, billing management, and checkout logic, the client now talks to server-controlled endpoints.
That matters because billing routes should not trust arbitrary browser state. They should first prove who the caller is.
A simplified pattern looked like this:
export const authenticateUserRequest = async (req: ApiRequest, res?: ApiResponse) => {
const session = await resolveSessionFromApiRequest(req);
const userSupabase = createUserScopedSupabaseClient(session.accessToken);
const { data: profile } = await userSupabase
.from('profiles')
.select('account_status')
.eq('id', session.user.id)
.maybeSingle();
if (profile?.account_status === 'suspended') {
throw new HttpError(403, 'This account is suspended.');
}
return {
supabase: userSupabase,
user: session.user,
};
};
This was the first important boundary correction. Billing routes no longer relied on the browser to define the user context.
2. I tightened session handling in production
The next step was to stop treating session transport as an afterthought.
In production, the app now treats session cookies differently and ties that behavior to secure deployment conditions.
A simplified example:
const getIsSecureCookie = (): boolean =>
process.env.NODE_ENV === 'production' || process.env.VERCEL_ENV === 'production';
That lets the application issue cookies with stricter attributes such as Secure, HttpOnly, and SameSite=Lax.
This does not solve security on its own, but it does narrow the attack surface around authentication and session transport. More importantly, it aligns production auth behavior with the sensitivity of the billing flows it protects.
3. I stopped treating checkout redirects as proof of subscription activation
A user returning from checkout does not automatically mean the app’s local billing state is correct.
That is why I added reconciliation after the return flow.
The idea was simple. The user starts checkout. The billing provider handles payment. The user returns to the app. The app triggers reconciliation. The server verifies provider-side state. Local entitlement updates only after verification.
A simplified request looked like this:
const response = await fetch('/api/plan?view=reconcile', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
credentials: 'include',
body: JSON.stringify({ customerSessionToken }),
});
That extra step matters because return URLs are UX signals, not trust anchors.
4. I added webhook-driven subscription synchronization
Even reconciliation on return is not enough by itself.
Subscriptions change over time. Renewals happen. Cancellations happen. Revocations happen. Those events should not depend on the user actively sitting inside the billing page.
That is where provider webhooks became important.
The backend flow became:
This made provider events part of the architecture instead of pretending the frontend was the primary coordinator of subscription truth.
A Typical Billing Read After the Change
Once the redesign was in place, even a plan or billing read followed a different shape.
A simplified version looked like this:
if (view === 'billing') {
const { supabase, user } = await authenticateUserRequest(req, res);
const customerState = await fetchProviderCustomerState(user.id);
const subscriptionSummary = customerState
? resolveSubscriptionSummary(customerState)
: null;
sendJson(res, 200, {
billing: {
hasActiveSubscription: subscriptionSummary !== null,
status: subscriptionSummary?.status ?? null,
recurringInterval: subscriptionSummary?.recurringInterval ?? null,
currentPeriodEnd: subscriptionSummary?.currentPeriodEnd ?? null,
},
});
}
The point is not the exact implementation. The point is the decision flow: authenticate first, query provider state on the server, normalize the result, and return a constrained response to the client.
That is a stronger model than letting the browser infer too much.
Why HTTPS and Secure Cookies Matter Here
This change also made HTTPS more meaningful.
It is important to be precise here: HTTPS does not magically stop JavaScript attacks, and it does not replace XSS prevention.
What HTTPS does do in this architecture is protect session-bearing requests in transit, support secure cookie behavior in production, and reduce the chance of sensitive auth transport being treated casually.
So the right claim is not that HTTPS solved frontend security.
The right claim is that HTTPS and secure cookies became part of a larger design where auth and billing moved into server-validated flows.
What This Solved
This redesign improved a few things immediately.
It reduced how much billing logic depended on client state. It made the server responsible for validating identity before billing operations ran. It created a clearer distinction between interaction state and entitlement state. It also made debugging easier, because failures became easier to trace to one of a few boundaries: session validation, provider interaction, reconciliation, persistence, or webhook delivery.
Most importantly, it changed the browser’s role from authority to requester.
That is the right direction for any application where subscription state controls access.
What It Did Not Solve
This kind of redesign should not be overstated.
It did not eliminate XSS, authorization bugs, bad secret hygiene, broken webhook verification, environment drift, or incorrect sandbox/live billing configuration.
What it did do was establish a stronger foundation: less browser authority, clearer trust boundaries, more reliable billing state, and better separation between interaction and decision-making.
That is a meaningful architectural improvement even though it is not a complete security story on its own.
Closing Thought
The biggest lesson from this change was that billing is not just a payments feature. It is a trust-boundary problem.
Once I started treating it that way, the architecture became much clearer. The browser initiates. The server validates. The provider confirms. Persistent state records entitlement. Webhooks correct drift over time.
That model is harder to get wrong than a client-heavy billing flow, and it scales much better as the application becomes more real.
Top comments (1)
I've seen a lot of 'Quick Start' guides suggest handling the subscription state update directly in the frontend redirect. While it's fast to build, I'm curious: has anyone else run into race conditions or 'stale state' issues using that approach? How do you handle your webhook reconciliation?