Integraph

Troubleshooting billing

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

“Save Changes” is greyed out and I can’t reach checkout

Almost always a missing tax location. Checkout will not open until your workspace has one, because without a country we cannot work out what tax you owe — and quoting a total we could not stand behind would be worse than asking for the field. The billing tab shows the reason directly beneath the tool list, with the country selector immediately above it. Set it and the button enables.

Two things that are not the cause, and are worth ruling out before you go looking further:

  • An existing subscriber changing plan is never blocked by this. Adding or removing a tool on an active subscription goes through the modify flow, not Checkout, so it does not need a tax location and the button stays enabled.
  • The subscription state still loading greys the button out for a second or two after the page opens. If it enables on its own, that was it.

I don’t recognise the charge on my statement — it says LINK.COM*

That is us, and it is correct. Link, a Stripe service, is the merchant of record on most Integraph subscriptions and top-ups: it takes the payment, calculates and remits the tax, and issues your tax invoice, so Link’s name is what reaches your bank. The full descriptor is LINK.COM* INTEGRAPH, and the receipt and invoice Link sends you name Integraph as the supplier of the software.

The amount should match an entry in the Invoices list on your Billing tab. Check there before disputing the charge with your bank: a chargeback ends your access for the period it reverses (see Cancelling and reactivating), and it is far slower to unwind than a support ticket.

If the amount matches nothing on the Billing tab, or you have never held an Integraph subscription, contact support before doing anything else.

My VAT or ABN number isn’t on the tax invoice

The Tax ID field is hidden by default. In Checkout, tick I’m purchasing as a business first — a Business name and Tax ID pair appears beneath it, and that is the only place the number can be entered. If Checkout has already completed without it, contact support rather than resubscribing; the number can be added to the customer record for future invoices.

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 fast path for writing entitlements, and a background reconciliation job re-derives them from Stripe roughly hourly as a backstop. So a dropped webhook self-corrects within the hour rather than never — but if you are waiting on a subscription you just paid for, the webhook is what makes it immediate. 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 a previous subscription was cancelled and the period has ended, the app correctly treats the next subscribe as a new subscription, not a modification. So it opens Checkout.

A paused subscription is different, and no longer opens Checkout. A paused subscription is not billable, but it is not “no subscription” either — it still holds your tools and any discount. The billing tab now shows it as paused and refuses both Checkout and the modify modal, because starting a fresh Checkout would create a second subscription alongside it and bill you twice. Add a payment method instead: that resumes the paused subscription and restores access. Pausing is uncommon, because a card is collected at checkout; it generally means the card was removed before the trial ended (see Subscriptions and trials).

For the cancelled case the fix is to 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. For the paused case the fix is to add a payment method, which resumes the subscription you already have; do not start a new Checkout.

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.

”My tools stopped working and I never cancelled”

What’s actually happening: Access to paid features ends when the payment covering the period you are in has been reversed — refunded in full, or charged back. The subscription itself stays active in both cases, so the billing tab can still show an active subscription while the tools are locked. The next successful payment restores access on its own.

The case that surprises people is the two-step one: a partial refund does not stop access, because the period is still partly paid for — but if the remainder is then charged back, every cent has been returned and access for that period ends. Neither step reverses the whole charge alone; together they do. The same applies in the other order.

If a dispute you raised is later resolved in your favour, the suspension is lifted automatically as soon as the outcome reaches us — there is nothing to re-purchase. The exception is a charge that was already refunded to you in full, where the money is back with you regardless of the dispute.

See Cancelling and reactivating for the full rules. If you believe none of this applies to you, collect the invoice PDF and open a support ticket rather than assuming it is working as designed.

”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.