Most SaaS founders think payments and access are the same thing.
They're not.
A customer pays.
A payment succeeds.
And somehow the user gains access to features.
At first, this feels simple.
As products grow, it becomes one of the most important architectural decisions you'll make.
This is where entitlements come in.
And surprisingly, most SaaS products already use entitlements without realizing it.
Why this matters
Imagine a customer subscribes to your Pro plan.
What happens next?
Most founders would answer:
The customer now has access to Pro features.
But that's not actually what happened.
The payment itself didn't grant access.
The payment created a set of permissions.
Those permissions determine:
- What features are available
- Which APIs can be used
- How much usage is allowed
- Which limits apply
- What the customer can actually do
Those permissions are called entitlements.
What are entitlements?
An entitlement is a permission granted to a customer.
It represents access to something inside your product.
Examples include:
- Access to a premium feature
- Access to an API
- Access to a higher usage limit
- Access to AI models
- Access to team collaboration features
A simple example:
| Plan | Entitlements |
|---|---|
| Free | Basic Chat |
| Pro | Chat + Image Generation |
| Growth | Chat + Images + Video Generation |
The payment purchases the plan.
The entitlements define what the user receives.
Payments are not access
One of the most important concepts in SaaS architecture is:
Payment is not access.
Many early-stage products directly connect Stripe subscriptions to feature checks.
For example:
if (customer.subscription === "pro") {
allowAccess();
}
This works initially.
But eventually creates problems.
What happens if:
- The payment webhook is delayed?
- A refund occurs?
- A dispute happens?
- You grant access manually?
- A customer receives promotional credits?
Now your payment system is directly controlling your application logic.
That coupling becomes difficult to maintain.
How SaaS entitlements actually work
A healthier architecture separates three concepts:
- Payments
- Entitlements
- Access Checks
The flow usually looks like:
Payment
↓
Entitlements
↓
Access Control
A successful payment creates or updates entitlements.
The application checks entitlements.
The payment provider becomes one source of information rather than the source of truth.
Subscriptions vs entitlements
Subscriptions and entitlements are often confused.
They solve different problems.
| Concept | Purpose |
|---|---|
| Subscription | Determines what was purchased |
| Entitlement | Determines what is accessible |
A subscription is a billing object.
An entitlement is an access object.
For example:
Subscription:
Pro Plan
Entitlements:
API Access
Image Generation
10 Team Members
Priority Support
One subscription can create many entitlements.
Credits vs entitlements
Another common misunderstanding involves AI credits.
Credits are not entitlements.
They solve different problems.
| Concept | Purpose |
|---|---|
| Credits | Measure consumption |
| Entitlements | Grant permissions |
Example:
A user may have:
- Access to GPT-4
- Access to Image Generation
Those are entitlements.
The same user may also have:
- 5,000 credits remaining
That's consumption.
A user can have credits but no entitlement to use a feature.
A user can have entitlements but no remaining credits.
Both concepts are important.
Feature access and usage limits
Most SaaS products eventually need more than simple on/off permissions.
Examples:
- Maximum API requests
- Maximum users
- Maximum projects
- Maximum storage
- Monthly AI credits
These are also entitlements.
For example:
| Plan | Monthly Credits |
|---|---|
| Starter | 1,000 |
| Pro | 10,000 |
| Growth | 50,000 |
The entitlement defines the limit.
Usage tracking measures consumption against that limit.
Common mistakes
As products grow, entitlement systems often become difficult to maintain.
Here are some common mistakes.
Checking Stripe directly on every request
Many products repeatedly ask:
Is the customer's Stripe subscription active?
This creates unnecessary coupling.
Your application should check entitlements.
Not payment processors.
Hardcoded feature flags
Another common pattern:
if (plan === "pro") {
enableFeatureX();
}
Eventually the business asks for:
- Custom plans
- Promotions
- Temporary upgrades
- Enterprise exceptions
Hardcoded logic quickly becomes difficult to manage.
No entitlement model
Many products track:
- Users
- Payments
- Plans
But never model entitlements explicitly.
This works until access rules become more complex.
Then every new feature requires more custom logic.
Access control becomes easier
A dedicated entitlement layer simplifies access control.
Instead of asking:
What subscription does this user have?
You ask:
Does this user have this entitlement?
For example:
canUse("image_generation")
This creates a cleaner separation between billing and product logic.
Real-world examples
Most successful SaaS products already use entitlement concepts.
Examples include:
SaaS subscriptions
Subscription creates:
- Feature access
- Seat limits
- Storage limits
AI products
Subscription creates:
- Model access
- Credit limits
- Generation permissions
API products
Subscription creates:
- Rate limits
- Request quotas
- Premium endpoint access
Usage-based billing
Payments create:
- Consumption allowances
- Usage permissions
- Feature access
The implementation varies.
The concept remains the same.
Final thoughts
Entitlements are one of the most important concepts in modern SaaS architecture.
Yet many products don't model them explicitly.
A successful payment does not grant access.
A successful payment creates entitlements.
Those entitlements determine:
- Feature access
- Usage limits
- Access control
- Consumption permissions
As products grow, separating billing from access becomes increasingly valuable.
Payments answer "What was purchased?"
Entitlements answer "What can the customer do?"
Learn More
As products become more complex, managing entitlements manually can become difficult.
Platforms such as Licenzy help teams manage:
- Entitlements
- AI credits
- Usage tracking
- Access control
- Usage-based billing
Instead of linking a homepage, consider linking documentation focused on:
- Entitlements
- Access Checks
- Usage Consumption APIs
- Usage-Based Billing
Top comments (0)