How to build seat-based pricing in Laravel with Stripe (step-by-step, 2026)

If your SaaS charges per member, seat-based pricing should be driven by one source of truth: active billable seats in your app. Stripe quantity is then a synchronized projection of that number.

Quick answer

Use this flow:

1. Define what counts as a billable seat.
2. Persist seat count in your domain model.
3. Sync Stripe subscription quantity when seat count changes.
4. Guard against race conditions with idempotent updates and webhooks.

Step 1: define billable seat rules

Before coding, lock these decisions:

• Does the owner count as a seat?
• Are pending invites billable?
• Do suspended members count?
• Is there a minimum seat floor?

Write these rules into product docs so billing and support stay aligned.

Step 2: model seats in your domain

Represent seats at the workspace or team level:

• workspace_members table (or equivalent)
• member status fields (active, invited, suspended)
• role fields if different roles affect billing

Your billable-seat query should be deterministic and testable.

Step 3: map seats to Stripe quantity

On subscription-backed plans:

• compute billableSeatCount
• set Stripe subscription item quantity = billableSeatCount
• enforce plan-specific minimums or caps if needed

If you support base + seats, store base plan pricing separately and let quantity control variable usage.

Related reading: Laravel Cashier Stripe setup for SaaS billing

Step 4: trigger sync on membership lifecycle events

Update quantity when:

• member invited and accepted,
• member removed,
• role/status changes affecting billable status,
• workspace merged or archived.

Batching frequent changes (short debounce windows) can reduce noisy Stripe updates.

Step 5: webhook safety and reconciliation

Use Stripe webhooks as a source of billing event truth:

• verify signatures,
• store event ids for idempotency,
• reconcile app state when webhook and app actions diverge.

Run a periodic reconciliation job to compare internal seat counts against Stripe quantity and auto-correct drift.

Edge cases teams forget

• Pending invites counted accidentally as billable.
• Removed users still billed due to delayed sync.
• Concurrent membership edits causing quantity race updates.
• Plan downgrade not enforcing seat limits early.

Test plan (minimum)

1. Add member -> quantity increments once.
2. Remove member -> quantity decrements once.
3. Concurrent adds/removals -> final quantity matches expected active seat count.
4. Failed Stripe update -> retry and eventual consistency path works.
5. Webhook replay -> idempotency prevents duplicate state changes.

Practical recommendation

Start with a simple, explicit seat model and keep sync logic centralized in one billing service layer. Avoid spreading quantity update calls across controllers and UI handlers.

If you want this architecture out of the box, review SaasForgeKit Pro and compare editions in pricing.

FAQ

Should I bill invited users before acceptance?

Usually no. Most teams bill only active accepted members to reduce billing disputes.

Do I need immediate sync on every member change?

For most products, yes. If your app has high membership churn, short batching windows can reduce API chatter while preserving accuracy.

Is seat-based pricing worth it for early-stage SaaS?

Only if your product is team-centric from day one. Solo-user products are often better served by flat plans initially.

Continue with implementation

• Read the documentation
• Review architecture references in blog
• Evaluate the full stack on the starter kit page