Tutorials

Using Lemon Squeezy for SaaS subscriptions with Makerkit


The Makerkit template is based on the model where users pay at the moment when they get value from the service: i.e., they're free to sign-up without friction but will be able to subscribe to a plan once in the application. So you can restrict your users from the primary value of the service until they subscribe, and it's totally up to you when that is.

It's also possible you could want your users to subscribe and pay for your service upfront: this can be valuable, for example, if you're offering a one-off service, like generating a logo or something similar that could involve operational costs to you.

In this recipe, I want to show you how we can accept a one-off payment with Stripe during the onboarding flow, such that you can receive a payment before the user is redirected to the private area of your application.

## How to accept payments upfront with Makerkit and Stripe

To do so, we need to add this main change: update `with-app-props` to redirect users to checkout if they don't have a valid subscription or payment in their organization.

We will add the following lines of code **before returning the props**:

```tsx filename=with-app-props.ts
if (!organization) {
  return redirectToOnboarding();
}

if (!organization.subscription) {
  try {
    const organizationId = organization.id;
    const customerId = organization.customerId;

    // for simplicity, we will use the first price ID in the configuration
    const priceId = configuration.stripe.plans[0].stripePriceId;

    // return to the app home after checkout
    const returnUrl
       = `${ctx.req.headers.origin}/${configuration.paths.appHome}`;
    
    const { url } = await createStripeCheckout({
      returnUrl,
      organizationId,
      priceId,
      customerId,
    });
    
    return {
      redirect: {
        destination: url,
      }
    };
  } catch {
    return {
      redirect: {
        destination: '/500',
      }
    };
  }
}
```

Additionally, we want to change the `mode` to `payment`. To do so, open the file `` and edit the following line:

```tsx filename=lib/stripe/checkout/create-checkout.ts
const mode: Stripe.Checkout.SessionCreateParams.Mode = 'subscription';
```

And change it into the following:

```tsx filename=lib/stripe/checkout/create-checkout.ts
const mode: Stripe.Checkout.SessionCreateParams.Mode = 'payment';
```

For more information [check out the Stripe documentation](https://stripe.com/docs/billing/subscriptions/build-subscription).

If you go this route, you may also want to hide or remove the subscription settings page since the payment is one-off.

With that said, always provide a link for users to go to their Stripe portal to download their receipts and manage their accounts.

Collecting payments upfront


While having teams and organizations is an essential SaaS feature where users can share assets and resources with teammates, not every SaaS needs it.

In fact, many have asked me how to remove organizations and only keep individual users. So, in this recipe, I will write down my thoughts on removing organizations from your project.

There are two main ways to remove organizations:
1. The more challenging way is refactoring the project and removing the code related to `organizations`
2. The second and more straightforward way is to keep `organizations`, while hiding all the related UI. In this way, each user belongs to their organization. This way is more future-proof: if your SaaS will need refactoring for adding teammates to your user's accounts, the code is still there, and you will only need to show it.

Since the first way is highly challenging and will cause problems pulling changes from the latest version, I suggest you try the second solution: we will create organizations behind the scenes for each user, but these won't be shown in the front end. 

Here is the list of changes we need to add:
1. Skip onboarding: automatically create an Organization for the user
2. Remove Organizations dropdown from the headers
3. Remove the "Organization" tab within the settings pages

## Skipping the Onboarding flow

You can change the onboarding flow and add your own steps if you need your users to set up their accounts. The organization, though, **will be created without user input**.

Let's update the `Onboarding` page at `pages/onboarding/index.tsx`. 

The code below represents the first step, and we can simply get rid of it:

```tsx filename=pages/onboarding/index.tsx
<If condition={currentStep === 0}>
  <OrganizationInfoStep onSubmit={onFirstStepSubmitted} />
</If>
```

We can simply leave as shown below:

```tsx filename=pages/onboarding/index.tsx
<CompleteOnboardingStep 
  data={{ organization: `Organization` }} 
  onComplete={onComplete}
/>
```

This will automatically kick off the onboarding API request and create an organization named `Organization`.

## Hiding the Organizations dropdown

To hide the organizations dropdown, we will update the headers of the layout you have chosen to use.

### Sidebar Layout

If you have chosen the sidebar layout, open the component `AppHeaderNoMenu.tsx` and remove the code below:

```tsx filename=components/layouts/sidebar/AppHeaderNoMenu.tsx
<If condition={userSession?.auth?.uid}>
  {(uid) => <OrganizationsSelector userId={uid} />}
</If>
```

### Header Layout

Open the component `AppHeaderWithMenu` and remove the component rendered by the constant `OrganizationsDropdown`:

```tsx filename=components/layouts/header/AppHeaderWithMenu.tsx
<div className={'flex flex-1 items-center space-x-4'}>
  <div className={'hidden lg:flex'}>
    <Logo href={configuration.paths.appHome} />
  </div>

  <div>{OrganizationsDropdown}</div>
</div>
```

## Removing the Settings pages

Finally, we want to remove the settings pages. To do so, we need to first remove them from the settings navigation menu:

We open the component `SettingsPageContainer.tsx` and then remove the organization settings from the `links` array:

```tsx filename=components/settings/SettingsPageContainer.tsx
const links = [
  {
    path: '/settings/profile',
    i18n: 'common:profileSettingsTabLabel',
  },
  // remove the object below!
  {
    path: '/settings/organization',
    i18n: 'common:organizationSettingsTabLabel',
  },
  {
    path: '/settings/subscription',
    i18n: 'common:subscriptionSettingsTabLabel',
  },
];
```

Optionally, remove the pages at `settings/organization`. 

Alternatively, you can automatically redirect them somewhere else using the `getServerSideProps` function on each page:

```tsx
export function getServerSideProps(ctx) {
  return ctx.redirect(configuration.paths.appHome);
}
```

## Updating the Firestore Rules

Finally, remove the rules to create new organizations in Firestore rules. You should only allow to read from them:

```
match /organizations/{organizationId} {
  allow read: if userId() in existingData().members;
}
```

## Final thoughts

That's it! While your application will still create an organization for each user, these do not exist as far as your SaaS users are concerned. In terms of future-proofing, hiding organizations allows you to add them in the longer term if users need a way to share stuff with teammates.

Removing Organizations from your Project


Makerkit uses [Ethereal](https://ethereal.email) for email testing, a neat
service that catches all the email sent from the application.

Ethereal is an incredibly useful during development because it allows us to
freely test the emails sent while testing, especially if we're designing
pixel-perfect emails with MJML.

Another alternative is setting up a fully local SMTP server with [SMTP4Dev](https://github.com/rnwood/smtp4dev) and Docker. This can be preferable if
you prefer not to send data to an external service or if you need to work
offline.

Let's see how we can get it done!

## Running the Docker Instance

To run the SMTP4Dev Docker image, ensure you're running Docker, and then run
the following command:

```
docker run --rm -it -p 3300:80 -p 2525:25 rnwood/smtp4dev
```

We've initialized the HTTP server at [localhost:3300](localhost:3300), so go
ahead and give it a try!

## Configuring Makerkit

Now we have to add the correct configuration to and make a small adjustement
to the codebase.

As we've said, Makerkit uses Ethereal by default: we need to remove that.
Open the file at `src/core/email/send-email.ts` and delete the lines 22-24:

```
if (configuration.emulator) {
  return getEtherealMailTransporter();
}
```

Then, we update the configuration at `src/configuration.ts` with the
following email setup:

```ts
email: {
  host: '0.0.0.0',
  port: 2525,
  user: 'user',
  password: 'pass',
  senderAddress: 'test@makerkit.dev',
},
```

And that's pretty much it! To test that everything works, send an email
using the application by inviting a member from the Members page.

🎉 We now have a fully local email server to test our emails!


Testing emails with a local SMTP Server


Limiting the disk space used by an organization or a user is a popular tier restriction used in SaaS. The reason is simple: the more space your customers use, the more they pay.

In this article, we learn how to keep track of the disk space used in Firebase Storage and how to prevent your customers to go over their plan limits.

## Setting up Firebase Functions

First, we need to setup the Firebase Pubsub emulator by running the following command:

```
firebase setup:emulators:pubsub
```

Now, we need to setup the Firebase Functions emulators:

```
firebase init functions
```

After completing the CLI prompts, you should have a few more files in your project:

```
✔  Wrote functions/package.json
✔  Wrote functions/tsconfig.json
✔  Wrote functions/src/index.ts
✔  Wrote functions/.gitignore
```

Also, it will generate other files such as `tsconfig.json` and `package.json` Let's copy some of the generated commands to the root `package.json`:

```json
"build:functions": "tsc -P functions/tsconfig.json",
"build:functions:watch": "tsc -P functions/tsconfig.json --watch",
"deploy:functions": "firebase deploy --only functions"
```

Let's run the Typescript watcher to build the functions:
```
npm run build:functions:watch
```

If you are using Makerkit, run the emulators with the following command:

```
npm run firebase:emulators:start
```

And that's it! If everything's good, you will see in the console the following output:

```
✔  functions: Loaded functions definitions from source: helloWorld.
```

## Tracking space with Cloud Storage triggers

To track how much disk space a user or an organization is using, we will write a Cloud Storage trigger that receives a request each time an item is uploaded or deleted.

To understand which user (or which organization) is uploading the item, we will look at the path of the file. For example, we know that an organization's folder is at the path `organizations/${organizationId}`.


The simplest Cloud Storage trigger we can write is the following function:

```tsx
import { storage } from 'firebase-functions';

export const onItemCreated =
 storage.object().onFinalize(async (object) => {
  console.log(object);
});
```

Our strategy is the following:

1. Collect the size of the item uploaded
2. Update the user/organization record with the size of each item uploaded
3. Use Storage Security Rules to prevent writes above an organization's quota

### Updating an Organization's record with the item's size

Let's continue writing our function to collect the item's size, and then we proceed to update the Firestore record of the organization by summing the disk space used.

#### Initializing the Firebase Admin

First, we want to initialize the Firebase Admin. Below, it's a simple function to initialize the admin in the emulator:

```tsx
async function initializeFirebaseAdminApp() {
  const projectId = process.env.GCLOUD_PROJECT;
  const options: AppOptions = { projectId };

  const { getApps, getApp, initializeApp }
    = await import('firebase-admin/app');

  if (getApps().length) {
    return getApp();
  }

  return initializeApp(options);
}
```

### Increasing Storage used when an object is uploaded

Now, we can continue writing the logic to increase the storage space counter:

```tsx
import { storage } from 'firebase-functions';
import { getFirestore, DocumentReference } from 'firebase-admin/firestore';
import { AppOptions } from 'firebase-admin/app';

export const onItemCreated = storage
  .object()
  .onFinalize(async (object) => {
    const paths = object.name?.split('/');

    if (!paths || paths[0] !== 'organizations') {
      return;
    }

    // we are aware that the path is /organizations/{uid}/{filename}
    const organizationId = paths[1];

    // convert size to a number
    const size = Number(object.size);

    try {
      // initialize admin so we can access firestore
      await initializeFirebaseAdminApp();
      const firestore = getFirestore();

      // we get the document reference in Firestore
      const documentPath = `organizations/${organizationId}`;
      const organizationRef = firestore.doc(documentPath);

      // get current space used and we sum with the object's size
      const currentStorageSpaceUsed =
        await getCurrentSpaceUsed(organizationRef);

      const storageSpaceUsed = currentStorageSpaceUsed + size;

      // update the Firestore document with the new "storageSpaceUsed"
      await organizationRef.update({
        storageSpaceUsed,
      });

      console.log(`Organization successfully updated`);
    } catch (e) {
      console.error(e);
    }
});

function getCurrentSpaceUsed(organizationRef: DocumentReference) {
  return organizationRef
    .get()
    .then((ref) => ref.data())
    .then((organization) => organization?.storageSpaceUsed ?? 0);
}
```

### Decreasing Storage used when an object is uploaded

The process for decreasing the storage space used is very similar to the above function, with the difference that we need to create a new API function to listen to Storage triggers when an item is deleted.

As you can imagine, the code could be greatly simplified given its similarity, but for simplicity reasons we're showing by repeating the same procedures:

```tsx
export const onItemDeleted = storage.object().onDelete(async (object) => {
  const paths = object.name?.split('/');

  if (!paths || paths[0] !== 'organizations') {
    return;
  }

  const organizationId = paths[1];
  const size = Number(object.size);

  try {
    await initializeFirebaseAdminApp();
    const firestore = getFirestore();

    const documentPath = `organizations/${organizationId}`;
    const organizationRef = firestore.doc(documentPath);
    const currentStorageSpaceUsed = await getCurrentSpaceUsed(organizationRef);
    const storageSpaceUsed = currentStorageSpaceUsed - size;

    await organizationRef.update({
      storageSpaceUsed,
    });

    console.log(`Organization successfully updated`);
  } catch (e) {
    console.error(e);
  }
});
```

## Using Firestore Storage Rules to reject requests above the quota

Now that we know how much Storage space used by each organization, we can accept or reject new file uploads using the Storage Security rules:

```
function isMember(organizationId) {
  if getUserId() in getOrganization(organizationId).data
    .members
}

function getSpaceUsed(organizationId) {
  return getOrganization(organizationId).data
    .storageSpaceUsed
}

match /organizations/{organizationId}/{fileName=**} {
  match /organizations/{organizationId}/{fileName=**} {
    allow create, update: if isMember(organizationId) && getSpaceUsed(organizationId) < 4000;

    allow read, delete: if isMember(organizationId);
  }
}
```

Thanks to cross-service communication, we can access Firestore data from our Storage rules, which makes it easy to write conditions against data in an organization. In this case, we check that the property `storageSpaceUsed` is less than a specific quota.


Limiting the Firebase Storage space used by each customer


The Makerkit SaaS boilerplate offers utilities to easily parse and display content with MDX. In fact, the blog and the documentation the boilerplate offers are generated using these utilities.

It can be useful, for you, to extend your website with a new content source.

For example, this website has 4 content sources:

1. blog posts
2. snippets
3. recipes
4. documentation

In this blog post, we will add a new content source for your application
using utilities already built in the app.

## Content Folder

First, we need to create a folder where to place our content in. Normally,
this can be within your root folder.

For example, let's add a new content source named `interviews` and use
`_interviews` as folder:

```txt file=Structure
- _interviews
  - interview_01.mdx
  - interview_02.mdx
  - ...
```

Let's assume the interview has the following interface:

```tsx
export interface Interview {
  name: string;
  content: string;
  date: string;
}
```

This can be represented in MDX as:

```md filename=interview_01.mdx
---
name: "My Interview about building a SaaS with Makerkit"
date: 2022-08-28
---

Content of the MDX file
```

Now, let's add some logic to:

1. Retrieve all the interview slugs, which we use to generate the static pages
2. Read the data and the content of each interview

```tsx filename=lib/interviews/api.ts
import { readDirectory, readFrontMatter } from '~/core/fs-utils';
import { join } from 'path';

const INTERVIEWS_DIRECTORY_NAME = '_interviews';

const interviewsDirectory =
  join(
    process.cwd(),
    INTERVIEWS_DIRECTORY_NAME
  );

export const allInterviews
  = getInterviewsSlugs();

export function getInterview(
  slug: string
) {
  const fileWithExtension = `${slug}.mdx`;
  const fullPath
    = join(interviewsDirectory, fileWithExtension);

  const file
    = readFrontMatter(fullPath);

  if (!file) {
    return;
  }

  const content = file.content;
  const data = file.data;

  return {
    ...data,
    content
  };
}

function getInterviewsSlugs() {
  return readDirectory(
    interviewsDirectory
  );
}
```

## Generating Static pages from our content source

To generate our content source's pages, we will need to use the special
`getStaticPaths` function that Next.js uses to generate static pages.

In our pages folder, let's create a file at `pages/interviews/[interview].tsx`, and let's add the content to be able to generate our pages:

```tsx filename=pages/interviews/[interview].
tsx
function InterviewPage(
  props: React.PropsWithChildren<{
    interview: Interview;
    content: string;
}>) {
  return (
    <>
      <Head>
        <title>{props.interview.name}</title>
      </Head>

      <Layout>
        <MDXRenderer code={props.content} />
      </Layout>
    </>
  )
}

export function getStaticPaths() {
  const paths = allInterviews.map((post) => {
    const slug = post.slug;

    return {
      params: {
        slug,
      },
    };
  });

  return {
    paths,
  };
}

export async function getStaticProps(
  { params }: { params: { slug: string } }
) {
  const { props } =
    await withTranslationProps();

  const interview =
    getInterview(params.slug);

  if (!interview) {
    return {
      notFound: true,
    };
  }

  const content =
    await compileMdx(interview.content ?? '');

  return {
    props: {
      ...props,
      interview,
      content,
    },
  };
}


export default InterviewPage;
```

Refresh the server each time you add a new MDX file, and navigate to
`http://localhost:3000/interviews/interview_01`.

🎉Yay, we can now read our MDX files in our Makerkit application!


Adding a new MDX content source


Charging a tenant according to the number of users they add is a popular pricing scenario for SaaS.

For example, a SaaS could offer the following subscription plans:

1. A **basic plan** for $9, which allows only one user, and charges an additional 9$ for every 5 users invited

2. A **pro plan** for 29$ per user, which includes 5 users, and charges an additional 29$ for every 5 users invited

In this blog post, we extend Makerkit to implement per-seat billing with Stripe and Next.js.

## How to implement per-seat subscriptions with Stripe?

Stripe's subscriptions use a field called `quantity` which can be used in different ways. In our case, we can use this field to bill a customer's organization based on how many users they invite.

So, if we billed $9 for each new user, we could simply increment the `quantity` field by 1. Stripe also allows us to transform the `quantity` field: for example, assuming we wanted to allow organizations to have 5 users before we increment their billing price, we would use `transform_quantity[divide_by]=5`.

This means that for up to 5 users, the organization will be billed 9$. Instead, between 6 and 10 users, they will be billed $18, and so on.

To learn more about this, check out the [Stripe documentation](https://stripe.com/docs/billing/subscriptions/quantities).

You can also do the same using Stripe's Dashboard. In fact, we can use `Package pricing` as a pricing model, and set a price for *N* number of units:

<Image src="/assets/images/posts/stripe-create-package-subscription.webp" width="1124" height="1414" />

In the above, we're configuring our subscription to charge customers $10 for every five units: in our scenario, **a unit is a member added to the organization**.

## Extending Makerkit to support per-seat subscriptions

By default, the Makerkit SaaS boilerplate does not handle per-seat Subscriptions, so we're going to go deep into the Makerkit code to show you how you can implement it yourself.

The main parts we're going to change are:

1. Creating a price that supports pricing per unit (as seen above)
2. Setting the correct `quantity` field when creating a `subscription`
3. Increasing the `quantity` field of a `subscription` when **members are added**
4. Decreasing the `quantity` field of a `subscription` when **members are removed**

### Adding plan to Configuration

Makerkit has a very simple built-in plan selector generated automatically from the configuration's plans. To test the integration, I created a new plan with Stripe, and I replaced the existing ones using the `src/configuration.ts` file:

```tsx filename=src/configuration.ts
plans: [
  {
    name: 'Per Seat Subscription',
    description: '$10 for each 5 users',
    price: '$10/5 users',
    stripePriceId: 'price_**********',
  },
],
```

Of course, when you create your plan, remember to replace the `stripePriceId` property with the actual ID.

<Image src="/assets/images/posts/stripe-plan-selector-per-seat-subscription.webp" width="1174" height="562" />

When creating a Checkout Session, the user will see the below:

<Image src="/assets/images/posts/stripe-checkout-per-seat-subscription.webp" width="968" height="578" />

### Creating a Subscription

In the Next.js Makerkit boilerplate, a Stripe subscription is created at `src/lib/stripe/create-checkout.ts` when an organization completes a Stripe checkout session.

Below is a snippet that creates a Stripe checkout session for a `subscription`, with `quantity` set to `1`, as defined in Makerkit: we need to update it so that the `quantity` field reflects the number of users added to the organization.

```tsx filename=src/lib/stripe/create-checkout.ts
const mode: Stripe.Checkout.SessionCreateParams.Mode = 'subscription';

// get stripe instance
const stripe = await getStripeInstance();

const lineItem: Stripe.Checkout.SessionCreateParams.LineItem = {
  quantity: 1,
  price: params.priceId,
};

return stripe.checkout.sessions.create({
  mode,
  customer,
  line_items: [lineItem],
  success_url: successUrl,
  cancel_url: cancelUrl,
  client_reference_id: clientReferenceId,
});
```

First, we want to be able to retrieve the number of users in an organization. To do so, let's add a new function `getOrganizationMembers` to the file `src/lib/server/queries.ts`.

```tsx
export async function getOrganizationMembers(organizationId: string) {
  const ref = await getOrganizationById(organizationId);
  const data = ref?.data();

  if (!data) {
    throw new Error(`Organization with ID ${organizationId} not found`);
  }

  return data.members;
}
```

Going back to `create-checkout.ts`, let's update the quantity with the number of users an organization has:

```tsx filename=src/lib/stripe/create-checkout.ts
const members = await getOrganizationMembers();
const numberOfMembers = Object.values(members).length;

const lineItem: Stripe.Checkout.SessionCreateParams.LineItem = {
  quantity: numberOfMembers,
  price: params.priceId,
};
```

Above, we retrieve the current number of members belonging to the organization and assign it as `quantity`.

### Updating quantity when a member is added

Whenever a user is added to the organization, we want to increment the `quantity` field of the subscription, so that Stripe will be able to automatically set the correct billing amount charged to the customer.

This can be done in two places:
- when the invitation is sent
- when the invitation is accepted

In this case, we'll do it when the invitation is accepted. Therefore, we will update the `POST` handler of the `organizations/members` endpoint.

```tsx filename=/src/lib/server/organizations/memberships.ts
async function increaseSubscriptionQuantity(
  subscriptionId: string
) {
  const stripe = await getStripeInstance();
  const subscription = await stripe.subscriptions.retrieve(subscriptionId);

  // As we add only 1 line item during the subscription creation
  // we can safely select the first in the array
  //
  // NB: if you customize the line items, you have to find a different way
  // to select the correct line item!
  const lineItem = subscription.items.data[0];

  if (!lineItem) {
    throw new Error(
      `Subscription with ID ${subscriptionId} has no line items?`
    );
  }

  const currentQuantity = lineItem.quantity ?? 0;
  const quantity = currentQuantity + 1;

  return stripe.subscriptionItems.update(lineItem.id, {
    quantity,
  });
}
```

Now, we need to call the function defined above in the `members.ts` API controller:

```tsx filename=members.ts
if (method === 'POST') {
  const { code } = getBodySchema().parse(req.body);

  // here we retrieve the subscription ID
  const organization = await getOrganizationById(organizationId);
  const subscriptionId = organization.data()?.subscription?.id;

  // we require a subscription ID to invite a user!
  if (!subscriptionId) {
    return forbiddenException(res);
  }

  // we accept the invitation
  await acceptInviteToOrganization({ code, userId });

  // once successful, we increase the quantity of the line item
  await increaseSubscriptionQuantity(subscriptionId);
}
```

<Alert type={'info'}>
  As you can see above, we require a subscription to have an user accept an
  invite. This is sort of normal, since we need to update the quantity. This
  means you may need to lock invites to paying organizations (or other
  strategies to make sure the above works).
</Alert>

When the number of users exceeds 5, the subscription will automatically
increase the monthly amount to $20:

<Image src='/assets/images/posts/quantity-subscription-20.webp'
       width={"2028"}
       height={"548"} />

### Updating quantity when a member is removed

Instead, when a user is removed from the organization, we want to decrease the `quantity` field. To do so, simply define nearly the same function as `increaseSubscriptionQuantity`, but with a clear difference: instead of summing the quantity, we will subtract it by 1.

```tsx
const currentQuantity = lineItem.quantity ?? 0;
const quantity = currentQuantity - 1;
```

Otherwise, **the body of the function will be identical**.

Now, we want to open the file `pages/api/organizations/[id]/members/[member].ts`. Here, we can see a branch where we handle a `DELETE` request, which we use to remove a member from an organization. When this happens, we can update the subscription:

```tsx filename=pages/api/organizations/[id]/members/[member].ts
if (method === 'DELETE') {
  const organizationId = payload.organizationId;

  // retrieve subscription ID
  const organization = await getOrganizationById(organizationId);
  const subscriptionId = organization.data()?.subscription?.id;

  // remove member from organization
  await removeMemberFromOrganization(payload);

  if (subscriptionId) {
    // once successful, we decrease the quantity of the line item
    await decreaseSubscriptionQuantity(subscriptionId);
  } else {
    logger.warn(payload, `Subscription for organization ${organizationId} was not found`);
  }

  logger.info(payload, `User removed from organization`);

  return res.send({ success: true });
}
```

Assuming the number of users in the organization is now 6, the subscription
amount will go back to $10:

<Image src='/assets/images/posts/quantity-subscription-10.webp'
       width={"2084"}
       height={"614"} />

🎉 And that's it! We have now implemented per-seat billing with Stripe and our Next.js API.

## Previewing Invoices

It can be useful to preview the next payment to your customers after (or before) they add a new member, therefore increasing their spending.

To do so, we can use Stripe's `retrieveUpcoming` method to preview the next invoice given a list of subscription items.

```tsx
function previewNextSubscriptionInvoice(
  params: {
    customerId: string;
    subscriptionId: string;
  }
) {
  const proration_date = Math.floor(Date.now() / 1000);

  const subscription =
    await stripe.subscriptions.retrieve(params.subscriptionId);

  // See what the next invoice would look like with a price switch
  // and proration set:
  const item = subscription.items.data[0];

  const items = [{
    id: item.id,
    price: item.price,
    // use "item.quantity - 1" if the member is removed
    quantity: item.quantity + 1,
  }];

  return stripe.invoices.retrieveUpcoming({
    customer: params.customerId,
    subscription: params.subscriptionId,
    subscription_items: items,
    subscription_proration_date: proration_date,
  });
}
```

The [invoice object](https://stripe.com/docs/api/invoices/object) is rich in information that you can display, but the most important may be `subtotal`, which you could display to customers to be transparent about what they will pay.

## Managing Unsubscriptions

When an organization unsubscribes, or lowers to a more restricted plan, you should think about how to handle the fact that the organization may have invited more users than your plan allows.

First, we need to listen to an unsubscription webhook: we actually already
do. If you visit `pages/api/stripe/webhook.ts`, check out the following branch:

```tsx filename=pages/api/stripe/webhook.ts
case StripeWebhooks.SubscriptionUpdated: {
  const subscription = event.data.object as Stripe.Subscription;

  await onSubscriptionUpdated(subscription);

  // YOUR LOGIC GOES HERE

  break;
}
```

Here, we can write the logic to handle what happens when an organization
unsubscribes from a plan. What happens depends on you and how you prefer to
handle it.

## Summary

In this blog post, we have extended the Next.js SaaS Boilerplate so that our SaaS can charge customers based on the number of users they invite to their projects.

To summarize what we have done:

1. We have created a price using the Stripe Dashboard that allows us to charge customers using `Package pricing`
2. When the subscription gets created, we set the `quantity` field based on the current number of members in the organization. In this case, we're assuming the organization starts without a subscription (as is by default).
3. When a member is added to the organization, we **increase** the `quantity` field
4. When a member is removed from the organization, we **decrease** the `quantity` field

Unfortunately, there is more to do to finalize the logic above, and it
really depends on your preferences.

### Final Considerations

To finalize and improve the logic explained above, you have to make a few
choices.

#### Restrict invitations

Should you restrict invites to organizations
with a valid subscription? Probably. Alternatively, when accepting an
invitation, we can check if the organization is within a free quota (ex. 5
users)

#### What happens when an organization unsubscribes?

You may not be able to prevent a cancellation from the Stripe Portal.

Therefore, you may need a way to gate organizations from using more
resources than the plan allows. One of the ways could be to add some logic
to `withAppProps` and check if the customer is on a plan: if not, force
redirect to the subscription page.


Recipes

Recipes to extend Makerkit with popular SaaS use-cases and scenarios