Paid Seats in a Team App: Which Members Count Against the Subscription?

Before adding per-user billing to a team app, define a seat. A purchased place, an accepted membership and permission to perform a particular action are different things. Your customer needs to understand both who can use the service and which quantity the business will be billed for.

This guide concerns a licensed-seat subscription for a customer workspace. It does not set contract terms, tax treatment or cancellation rights. Have the responsible commercial and financial reviewers approve the billing policy before the developer automates it.

Choose what the customer is buying

A fictional service lets a business buy capacity for its staff. Does it charge for purchased capacity even when some places are empty, for every accepted member, or for another explicitly defined population? Do not leave that question to whichever user count is easiest to retrieve.

Write down whether administrators, read-only guests, suspended members and external advisers consume seats. These are commercial choices, not conclusions that follow from their role names. Keep the rule understandable enough that a customer can explain the bill from the membership screen.

Stripe's subscription quantity documentation gives a concrete implementation example: a licensed subscription item can carry a quantity, and quantity changes can be made by updating the subscription. That field represents the quantity your integration supplies. It does not discover which of your app's users should count.

Decide when an invitation occupies capacity

An outstanding invitation may never be accepted. Decide whether it reserves an already purchased seat, triggers a capacity purchase or consumes nothing until acceptance. Show that distinction in the administrator view instead of displaying one ambiguous “users” total.

Keep the identity and access rules in the portal invitation workflow. Seat availability does not prove that the person accepting a link is the intended recipient, and payment does not establish their permissions.

Ask for a clear result when the last place is taken while another invitation remains open. The app should follow your agreed reservation or purchase policy, not grant an extra paid seat silently or strand a new member on an unexplained error page. Concurrent acceptance belongs in the demonstration, not merely in the happy-path screenshot.

Separate removing access from reducing the purchase

When a person leaves a customer team, staff may need to remove access immediately. That does not tell the billing system whether the customer wants to keep the empty place for a replacement or reduce the paid quantity.

Specify the two actions independently. A useful interface might explain that access has ended while purchased capacity remains unchanged. If the customer requests a reduction, show the effective date and the resulting capacity. Do not unexpectedly remove another member to force occupied seats below a new limit.

Stripe documents prorations when subscription quantities change. Agree the supported adjustment policy with billing staff and show its actual preview or result. Do not promise an immediate bank refund merely because a seat was removed or a negative adjustment appears.

Make member count and billing quantity reconcilable

The team view should distinguish purchased capacity, occupied places and any invitation reservations your policy uses. Where an update is awaiting provider confirmation, display that pending change separately from the confirmed quantity.

Require staff to trace a discrepancy to the intended workspace, subscription and subscription item. A customer may have several products or subscriptions; choosing the first subscription attached to their billing identity is not an adequate mapping rule.

Stripe also supports quantity transformations that bill in groups, and tiered pricing for other pricing structures. If your offer uses bundles, document what the submitted quantity means and how it becomes billable units. Do not combine incompatible pricing features merely because both appear in the documentation. For a simple first release, an explicitly defined per-seat model may be easier for customers to reconcile than unexplained grouping.

Test membership and money together

Use invented workspaces in your acceptance criteria. Demonstrate an unused purchased seat, an unaccepted invitation, simultaneous attempts to fill the last place, removal of a member without reducing capacity and an explicitly requested quantity reduction.

For each case compare membership, access, reserved capacity, provider quantity and the billing adjustment. Include a provider update whose outcome is temporarily uncertain. Retain the requested change for reconciliation rather than announcing an unconfirmed success or creating a second purchase blindly.

Bring the seat definition and a sample member list to a team-app project discussion. The goal is not a user counter next to a price. It is an understandable contract between paid capacity, actual membership and the customer's next bill.