You shipped subscriptions last month. Everything worked in staging. Then your first real customer paid, your webhook endpoint had a blip, and they spent 20 minutes locked out of a product they just bought. You fixed it manually, told yourself it wouldn’t happen again, and moved on.
Then it happened again.
If you’re building a SaaS product on Stripe, you usually start with a simple idea: a customer pays, and your app gives them access. In practice, it rarely stays that simple.
Most Stripe subscription setups depend on webhooks to keep your app in sync with billing activity. Stripe’s own docs say most subscription activity happens asynchronously and should be handled through webhook events. That works at the start. But as your product grows, webhook-based billing often turns into a fragile sync layer sitting between Stripe and your product. You end up handling retries, duplicates, out-of-order events, price ID mappings, and plan logic spread across your codebase.
This is where many SaaS teams hit the same wall. Your billing system stops being a source of truth and becomes a stream of events you need to reconstruct.
In this post, we’ll break down the two biggest issues with a typical Stripe-based SaaS billing setup:
- Webhooks create an eventually consistent billing system
- Plans and feature access often get hardcoded around Stripe price IDs
1. Stripe Webhooks Are Asynchronous, So Access Is Never Truly Instant
Stripe uses webhooks to notify your app about subscription changes, payment failures, renewals, cancellations, and other billing events. Stripe explicitly recommends using webhooks for subscription activity because so much of it happens asynchronously.
That means a payment succeeding does not automatically mean your product state is updated in the same moment.
A typical flow looks like this:
- Customer completes checkout
- Stripe creates or updates billing objects
- Stripe sends an event to your webhook endpoint
- Your server verifies the signature
- Your handler processes the event
- Your database is updated
- Your app finally grants or removes access
That extra layer is where things get messy.
Common Stripe Webhook Issues Teams Run Into
Out-of-order events
Stripe does not guarantee event ordering. A later event can arrive before an earlier one, so your code cannot safely assume sequence. We’ve seen teams spend days debugging access issues that turned out to be nothing more than events arriving in the wrong order.
Duplicate delivery
Stripe documents that webhook endpoints can receive the same event more than once. If your handlers are not idempotent, duplicate emails, duplicate provisioning, or incorrect credit updates can happen.
Retries and delayed state changes
If your endpoint fails or is temporarily unavailable, Stripe retries undelivered events for up to three days. Three days is a long time for a customer to be locked out, or worse, to have access they shouldn’t have.
Signature verification problems
Stripe signs webhook payloads and requires signature verification. Common failures happen when request bodies are modified before verification, which is easy to do accidently in middleware.
What This Means in Real Life
This is why SaaS teams end up seeing support tickets like:
- “I paid, but I still don’t have access.”
- “I upgraded, but the old limits are still showing.”
- “The subscription was canceled, but access is still active.”
- “We retried an event and now the credits are wrong.”
The core problem is not that Stripe webhooks are broken. The problem is that webhooks turn billing state into an async sync problem. Instead of asking one system “What can this customer use right now?”, your app is trying to rebuild that truth from event delivery.
2. Stripe Price IDs Often Push Plan Logic Into Your Codebase
The second big problem shows up after your first few plans.
Stripe models pricing through products and prices. In theory, that sounds clean. In practice, many SaaS teams end up with code that looks like this:
if (subscription.priceId === "price_123") {
allowProjects = 5;
allowApiAccess = false;
}
if (subscription.priceId === "price_456") {
allowProjects = 50;
allowApiAccess = true;
}
Now your pricing model is no longer just in Stripe. Its buried in your app.
Why Hardcoded Price ID Mapping Becomes a Problem
Every pricing change becomes an engineering change
Add a new plan. Change a feature limit. Launch annual billing. Introduce a region-specific package. Grandfather old customers. Suddenly you are updating Stripe objects, mapping new price IDs, changing business logic, testing billing flows, and shipping a deploy. What should be a product decision becomes a two day engineering task.
Price IDs are not business-friendly
Your product team thinks in terms like Starter, Pro, Growth, API Credits, Unlimited Seats. Your app ends up thinking in terms like price_1Qx.... That makes billing logic harder to read and harder to maintain. Ask any developer who inherited a Stripe integration six months after it was built.
Plans and entitlements drift apart
Stripe’s entitlements feature lets you map features to products and update customer access based on subscription status. But your product still needs to act on that state correctly, so you have not actually removed the provisioning problem, just moved it.
Experiments get slower
Pricing should be something your growth or product team can adjust quickly. But when plan rules are coupled to Stripe IDs in code, even simple packaging changes become release work.
This is why many teams eventually realise: price IDs are payment objects, not a complete pricing system.
3. Why This Gets Worse in Usage-Based and AI Products
The more dynamic your monetization is, the more painful the architecture becomes. And if you’re building an AI product in 2026, your monetization is almost certainly dynamic.
Consider a typical AI SaaS setup where users buy credit packs, hit usage limits mid-session, and get different feature access based on their current balance. A webhook-driven system has to:
// On every API call, you're doing something like this
const customer = await db.customers.findOne({ stripeId });
// Is this credit balance fresh? When did the last webhook fire?
// Was there a duplicate? Did the retry already process?
if (customer.credits > 0 && customer.planStatus === 'active') {
// maybe allow the request... probably
}
That “probably” is the problem. You are making access decisions based on state that might be minutes or hours behind reality.
Stripe’s hosted pricing table does not support usage-based pricing models and has product and interval limits. That matters because modern SaaS products often need:
- Feature gating per plan
- Credit balances that update in real time
- Usage limits checked before compute runs, not after
- Dynamic plan packaging
- Overrides and grandfathering for existing customers
Once you need those things, a webhook-driven sync layer plus hardcoded price ID mapping becomes very hard to manage cleanly. Most teams end up bolting on a seperate entitlements service, which means you now have three systems to keep in sync instead of two.
4. What Teams Actually Want Instead
Most SaaS teams do not want to build more billing code. They have a product to ship.
What they actually want is a system where:
- Plans are defined in a dashboard, not in code
- Features and limits are managed outside the codebase
- Access checks are real-time, not eventually consistent
- Billing and entitlements stay in sync automatically
- Pricing changes do not require deploys
- There is one source of truth for what a customer can access right now
That is the shift from event-driven billing glue to real-time monetization infrastructure.
5. Stripe Is Still Great, But This Is Where Teams Outgrow the Default Setup
Stripe is excellent at payments and billing primitives. None of what we’ve described is a criticism of Stripe. Subscription integrations by design rely on webhook handling, product and price management, and provisioning logic in your own system. That is fine when your setup is simple. It becomes painful when billing needs to control your product in real time.
This is the gap Kelviq is built for.
Instead of wiring access control through webhook handlers and raw Stripe price IDs, Kelviq acts as the real-time source of truth for plans, entitlements, and usage.
Before Kelviq, a plan check looks something like this:
// Webhook handler
app.post('/webhooks/stripe', async (req, res) => {
const event = stripe.webhooks.constructEvent(req.body, sig, secret);
if (event.type === 'customer.subscription.updated') {
const sub = event.data.object;
const planFeatures = priceIdMap[sub.items.data[0].price.id];
await db.users.update(
{ stripeId: sub.customer },
{ features: planFeatures }
);
}
res.sendStatus(200);
});
// Then somewhere in your app
const user = await db.users.findOne({ id: userId });
if (user.features?.apiAccess) {
...
}
With Kelviq, you ask one question directly:
const access = await kelviq.entitlements.check({
customerId: userId,
feature: 'apiAccess',
});
if (access.granted) {
...
}
No webhook handler. No price ID mapping. No stale database state. No wondering if the last event was a duplicate.
So instead of asking:
- Did the webhook arrive?
- Did we process it already?
- Is this the latest event?
- Which price ID maps to which feature set?
You ask one question: what can this customer access right now?
Final Takeaway
Stripe webhooks are not the problem by themselves.
The real problem is the architecture they push many SaaS teams toward. Async state sync, duplicate and out-of-order event handling, manual retry recovery, hardcoded plan mapping, feature access logic tied to Stripe price IDs, and pricing changes that require deploys.
That setup works for an early-stage subscription flow. It does not age well once billing becomes part of your product logic.
If your team is spending more time syncing billing state than shipping product, you don’t just have a payments problem. You have a source of truth problem.
See How Kelviq Works
Kelviq gives you a real-time monetization layer on top of payments. No webhook-dependent access control. No hardcoded price ID mapping. No deploys for every plan change.
FAQ
Do Stripe subscriptions require webhooks?
For most SaaS setups, yes. Stripe’s subscription docs say most subscription activity happens asynchronously and should be handled with webhooks or other event destinations.
Why is my Stripe webhook delayed or not firing?
The most common causes are endpoint timeouts, failed signature verification, or Stripe’s retry backoff kicking in after an earlier failure. Stripe retries for up to three days, but your customers won’t wait that long. Check your endpoint logs first, then look at the Stripe dashboard event log to see if events are being sent but failing on your side.
Can Stripe webhooks arrive out of order?
Yes. Stripe says event ordering is not guaranteed, so your webhook logic must not depend on strict sequence.
Can Stripe send duplicate webhook events?
Yes. Stripe documents that your endpoint can receive the same event more than once, so handlers should be idempotent. This is one of the most common sources of billing bugs in production.
What happens if a Stripe webhook fails?
Stripe retries undelivered events automatically for up to three days, and also provides a guide for manually processing undelivered events. But the gap between failure and retry can leave customers in the wrong state for a long time.
Do Stripe price IDs need to be stored in code?
Not necessarily in code, but your integration must pass and manage Stripe product and price IDs somewhere. Most SaaS apps end up mapping plan behavior to those IDs inside app logic, which becomes hard to maintain as your pricing evolves.
Does Stripe Entitlements remove the need for app-side provisioning?
No. Stripe Entitlements helps map features to products and determine when to provision or de-provision access, but your system still needs to enforce that access correctly. Its a step in the right direction but not a complete solution.
