Build a subscription membership site with Stripe, Auth0, and Webflow Cloud

This guide covers how to build a fitness membership site in Webflow where only logged-in, paying members can access premium content like workouts, programs, and coach notes.

Webflow handles the design and hosting, while Auth0 manages login, Stripe handles subscriptions, and a lightweight serverless worker keeps membership status in sync via Stripe webhooks. Gating logic on the front-end checks both login and an active subscription flag before showing protected content.

Note: An alternative to the custom-built solution proposed in this guide is to use an off-the-shelf tool like Outseta or MemberStack. Though less customizable, Outseta gives you embedded auth, payments, gated content, CRM, email, and help-desk capabilities right inside Webflow Designer. Meanwhile, MemberStack offers flexible no-code gating and Stripe-powered membership control using data attributes—perfect for quick setups without a backend layer.

System architecture

The architecture keeps Webflow for design and content delivery while delegating identity, billing, and subscription state to external services. A small worker bridges Stripe and your authentication layer, allowing the site to gate content based on subscription status.

• Webflow front-end – Hosts public pages (Home, Pricing, Login) and members-only pages (Workouts, Programs, Dashboard). Authentication and gating are run via custom JS embedded in the site.
• Authentication – Auth0 Authentication manages sign-up/login and issues JSON Web Tokens (JWTs). A custom active flag in the user profile or JWT claims indicates if a subscription is paid up.
• Billing – Stripe handles subscription products, recurring payments, payment Links for checkout, and provides a Customer Portal for self-service account management.
• Worker – A serverless function receives and verifies Stripe webhooks, such as checkout.session.completed or customer.subscription.updated. It also updates the active flag in the datastore and stores mappings like user_id, stripe_customer_id, and subscription status.
• Datastore (worker) – Optional store (Firestore, KV) for mapping users to Stripe customers and recording last processed event IDs for idempotency.
• Redirects & environments – Stripe success URL → /dashboard while cancel URL → /pricing. Use separate Stripe keys, webhook endpoints, and datastore configs for development and production.

Authenticate users and track membership status

Before you can decide whether to show a workout or a paywall, you need to know two things: who the user is, and whether they’ve paid.

We use Auth0 Authentication for both. It issues a WT on login and can store an active flag in a custom claim or Firestore record. This keeps the access check local to the browser—fast and independent of Stripe’s API.

Start by loading the Auth0 SDK site-wide using Webflow’s custom code feature.

On the front-end, each protected page runs a check:

<script>
document.addEventListener("DOMContentLoaded", async () => {
  // Initialize Auth0 SPA client
  const auth0Client = await createAuth0Client({
    domain: "YOUR_DOMAIN",
    clientId: "YOUR_CLIENT_ID",
    authorizationParams: {
      redirect_uri: window.location.origin
    }
  });
</script>

From there:

• Login and logout – Provide a form or modal that calls auth0Client.loginWithRedirect() for sign-in, and auth0Client.logout() to log out. Add “Log in,” “Log out,” and “Manage subscription” links in your nav.
• Identifiers – Every user should have a uid, email, and, after their first purchase, a stripe_customer_id. The active flag lives alongside those.
• Mapping to Stripe – Let Stripe create the customer record during checkout. When your worker receives a checkout.session.completed event, write the customer ID back to the datastore profile.
• Email sync – If a user changes their email in the datastore, update Stripe too with the update customer API so the Customer Portal login works without hiccups.

On the front-end, each protected page runs a check:

let token;
  try {
    token = await auth0Client.getTokenSilently();
  } catch (err) {
    // No JWT → force login page
    window.location.href = "/login";
    return;
  }

  const payload = JSON.parse(atob(token.split(".")[1]));

  const isActive = payload["https://yourapp.com/active"];

  if (!token) {
    // Case 1: No JWT at all
    window.location.href = "/login";
  } else if (isActive === true) {
    // Case 2: Paid user → Allow page to load
    document.body.style.display = "block";
  } else {
    // Case 3: JWT exists but subscription inactive
    window.location.href = "/pricing";
  }
});
</script>

1. No JWT? Send them to /login.
2. JWT present with active=true? Show content.
3. JWT present but inactive? Send to /pricing.

If you want extra safety, add a “Refresh access” button that calls a worker endpoint to re-pull subscription status from Stripe and update claims.