fix(admin): don't hit Stripe for admin-granted subscriptions#1721
Open
giladresisi wants to merge 2 commits into
Open
fix(admin): don't hit Stripe for admin-granted subscriptions#1721giladresisi wants to merge 2 commits into
giladresisi wants to merge 2 commits into
Conversation
Admin-granted subscriptions store the user id in Organization.paymentId (not a real `cus_...` customer), so every billing path that fed paymentId to Stripe threw "No such customer". Guard them all to skip Stripe when there is no real `cus_` customer: - getCharges returns no charges for any non-`cus_` paymentId. - prorate returns a zero price (it fires on billing-page load per plan card, which was the main source of error logs). - checkDiscount / applyDiscount return false (no coupon to offer/apply). - finishTrial returns early (nothing to finish). - /billing/portal, /billing/cancel and /billing/cancel-subscription reject with a clean 400 instead of a Stripe error (the UI also hides their buttons). Also on the display side: /self exposes `hasStripeCustomer` (paymentId starts with `cus_`), and the billing page only renders the "Update Payment Method / Invoices History" button (which opens the Stripe billing portal) when it is true. Admin-granted and never-subscribed orgs have no real customer, so the button is hidden and the portal is never reached. Validated by impersonating an admin-granted account (paymentId = user id): the billing page now loads with no Stripe error logs (previously flooded by the per-plan prorate call), and the Update Payment Method button is hidden. A real `cus_` subscriber still sees the button and the portal opens normally. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Contribution-checker quality warning Heuristics that flagged:
If this is a genuine contribution, please add detail to your PR description and tighten the diff scope before reviewers look at it. |
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
checkDiscount returned a pending Promise (always truthy), so the eligibility guard in applyDiscount never fired: any cus_ customer hitting POST /billing/apply-discount got the retention coupon unconditionally, and customers with no active subscription crashed on currentUserSubscription.data.id. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Contributor
|
Can you please elborate what is admin granted subscriptions? |
This comment was marked as duplicate.
This comment was marked as duplicate.
Collaborator
Already resolved & clarified internally |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Admin-granted subscriptions store the user id in
Organization.paymentId(not a realcus_...customer), so every billing path that fedpaymentIdto Stripe threw "No such customer" — the per-planproratecall on billing-page load was flooding the error logs.getCharges/prorate/checkDiscount/applyDiscount/finishTrialnow skip Stripe for any non-cus_paymentId (empty charges / zero price / no coupon / no-op)./billing/portal,/billing/canceland/billing/cancel-subscriptionreject with a clean 400 instead of a Stripe error./selfexposeshasStripeCustomer, and the billing page only renders the "Update Payment Method / Invoices History" button when there is a real customer.Validated by impersonating an admin-granted account (billing page loads with no Stripe error logs, portal button hidden) and a real
cus_subscriber (button shows, portal works).Split from #1668.
🤖 Generated with Claude Code