Integraph

Troubleshooting billing

Common billing scenarios that look wrong — what's actually happening and what to do about it.

My entitlements didn’t update after I subscribed

What’s actually happening: There is always a small delay between Stripe confirming the subscription and our backend receiving the webhook that provisions entitlements. The billing tab polls a second time about three seconds after Checkout returns, specifically to catch this. If your entitlements still haven’t updated after ~10 seconds, one of the following is true:

  1. Your JWT is stale. Entitlements are checked against the claims in your JWT. Refresh the page to force a fresh token.
  2. The webhook was delayed or dropped. Rare, but it happens. Check the Stripe dashboard → Developers → Webhooks for the relevant event; if the delivery shows a retry state, our backend will catch up automatically.
  3. The subscription is in a non-active state. Open the billing tab; the subscription status bar shows the current state. Anything other than active or trialing (e.g. incomplete, past_due) means entitlements will not be provisioned until the state clears.

The webhook handler is the single path responsible for writing entitlements — there is no polling or reconciliation job. If the webhook never fires, entitlements never update. For debugging, the Stripe dashboard’s Events view is the most diagnostic place to look: it shows whether the event was even created, and if so whether webhook delivery succeeded.

Webhook delay after creating a subscription

What’s actually happening: Stripe delivers webhooks asynchronously, typically within a second or two but sometimes longer during periods of platform load. Our UI’s three-second delayed refetch is a heuristic, not a guarantee.

If you want to know with certainty whether the webhook was delivered, the Stripe dashboard shows the delivery status per event (under Developers → Webhooks → [your endpoint] → Events). A pending_webhooks > 0 value means Stripe has not yet successfully delivered to all endpoints; once it drops to zero, your entitlements should appear on refresh.

If you’re seeing consistent delays beyond 30 seconds, check the dev / prod monitoring — it’s more likely to be an incident on our side than a one-off Stripe delay.

Why is my org showing Stripe Checkout instead of the modify modal?

What’s actually happening: The modify modal only opens when the org has an active or trialing subscription. If your org has a Stripe customer ID but no active/trialing subscription — for example because a previous subscription was cancelled and the period has ended, or because a trial ended with no card on file and the subscription was paused — the app correctly treats the next subscribe as a new subscription, not a modification. So it opens Checkout.

A paused subscription is the most common cause now that trials no longer collect a card up front (see Subscriptions and trials). A paused subscription is not billable, so it does not appear on the billing tab and the endpoint below reports no subscription — which is why Checkout opens rather than the modify modal.

The fix is always the same: complete the Checkout flow. Once the new subscription is active, subsequent changes go through the modify modal as normal. There’s no way to “restart” the old subscription — Stripe does not support un-cancelling a subscription whose period has already ended.

If you think the org does have an active subscription but Checkout is opening anyway, check the billing tab’s status bar: it reads the subscription state from the same endpoint the modify/Checkout decision uses, so if the bar shows “no subscription” the decision was correct given the backend state. From there, look at the Stripe dashboard for the customer to understand what actually happened.

”I thought I cancelled but I’m still being charged”

What’s actually happening: Cancellation is scheduled for the end of the current billing period, not immediate. If your subscription renewed the day before you clicked Cancel, you will still be charged for that renewal, and the cancellation will take effect at the next period end (a month away). The billing tab banner shows the exact date access will end.

See Cancelling and reactivating for the full semantics. If you want to recover the charge, you’ll need to request a refund through support — our UI does not expose refunds.

”I cancelled during the trial but I was still charged”

What’s actually happening: This should not happen. Cancelling during a trial schedules cancellation at the trial end date, and Stripe does not charge during trials. If you were charged after cancelling during a trial, something went wrong — collect the invoice PDF and open a support ticket. Do not assume it’s working-as-designed.

”I subscribed personally, then my employer subscribed the org, and now I’m paying twice”

What’s actually happening: You’re not paying twice in the sense that you have duplicate Stripe charges — each subscription is its own Stripe customer and each charges only its own customer. But if both your personal subscription and the org grant you the same tool, you do have two entitlements for one use case, which means your personal sub is probably redundant.

The fix is either:

Going forward, Account Settings → Billing will show both subscriptions’ grants clearly, with the foreign-org grant read-only, so this situation is easy to spot.

”My colleague has access to a tool I didn’t grant them”

What’s actually happening: Remember that entitlements are the union of all sources. Your colleague has access because some subscription they belong to grants it. Open Organization Settings → Billing and expand their row — the per-member view shows every grant and its origin, including grants from personal subscriptions and from other orgs they belong to. You will see one of:

  • A row you granted from this org — revocable.
  • A row marked “from personal subscription” — you cannot revoke this; it’s theirs.
  • A row marked “from [Other Org]” — you cannot revoke this; it’s controlled by the other org’s owners.

If you specifically want to prevent a user from using a tool through your org, remove them from the org. Entitlements from other sources will still allow them to use the tool, but not as a member of your org.

”I updated my card but the subscription is still past_due”

What’s actually happening: Updating the card attaches a new payment method, but Stripe still has to retry the outstanding invoice. Retries are automatic but can take a minute or two to fire. The subscription will move from past_due back to active only after the retry succeeds.

If the retry hasn’t fired after ~5 minutes, one of the following is true:

  1. Stripe has exhausted retries and marked the invoice uncollectible. In this case the subscription moves to unpaid and you need to pay the invoice manually from the Stripe-hosted invoice page, or contact support.
  2. The new card also failed. Check the payment method widget for an error state; the card might have been rejected by Stripe during attach.
  3. There’s nothing wrong and Stripe is just slow. Wait longer.

None of these are common but all three are worth checking before opening a support ticket.

When to contact support

Almost everything above is self-diagnosable from the billing tab and the Stripe dashboard. Contact support when:

  • The Stripe dashboard and our UI disagree about the subscription state.
  • You see a LogCritical error about an orphaned payment method (this would surface in monitoring, not on your screen — but if support asks, that’s the phrase to search for).
  • You’ve been charged for a cancelled-during-trial subscription.
  • You want a refund.

For everything else, the self-serve UI should be enough. If the docs are missing a scenario you actually hit, file a docs issue so we can add it here.