A surprisingly common SaaS anti-pattern looks something like:
if (user.plan === "pro") {
showFeature();
}
It works.
Until it doesn’t.
Add multiple tiers.
Usage limits.
Trials.
One-time purchases.
Organizations.
Add-ons.
API access.
AI credits.
Suddenly payment state and authorization logic are spread throughout the application.
That’s the infrastructure problem I’ve been exploring with PaywallOS.
Payments Aren’t Entitlements
A payment provider answers questions about transactions and subscriptions.
Your application has a different question:
What is this user actually allowed to do?
Those concerns are related, but they aren’t identical.
I think about the architecture as:
Payment
↓
Subscription / Purchase
↓
Entitlement
↓
Resource / Capability
↓
Access Decision
That separation creates a cleaner boundary between billing infrastructure and application authorization.
Why This Matters for AI
The problem gets even more interesting with agents.
Traditional SaaS might ask:
Can this user access FEATURE_X?
An agentic application may need to ask:
Can this user execute ai.generate_report?
Does this account have 10 executions remaining?
Can this agent invoke export.create?
Does this plan allow this model?
Now entitlement infrastructure starts intersecting with capability-based execution.
That’s one reason PaywallOS also connects conceptually with some of the work I’ve been doing on OpenVerb.
OpenVerb asks:
Is this action structurally valid and permitted?
PaywallOS asks:
Does this account possess the entitlement required to access it?
Those are different layers, but they can complement each other.
The Bigger Idea
I don’t think every SaaS developer should have to reinvent entitlement logic throughout their application.
The goal behind PaywallOS is to explore a dedicated infrastructure layer for:
Identity
+
Payment State
+
Entitlements
+
Usage
↓
Access Decision
Checkout is only the beginning of a paywall.
The interesting engineering starts after someone pays.
PaywallOS:
https://paywallos.openverb.org
Top comments (0)