fix(billing): ovehaul stripe billing config handling DEV-1342 #6553
+278
−195
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.
🗒️ Checklist
#Support Docs Updates, if any<type>(<scope>)<!>: <title> DEV-1234Front endand/orBack endorworkflow📣 Summary
Overhauls handling of Stripe billing portal configurations for more control over product options in the Stripe portal.
💭 Notes
The end goal here was to enable us to have some more nuanced rules for when to apply a customer's requested plan change (see related task DEV-1225). We also want to restrict which products on the Stripe portal are listed as upgrade/downgrade options for a given user based on their current subscription.
Our previous code relied on us using one default portal configuration and then creating new configurations with different product offerings (sometimes on the fly in the code). This resulted in us creating large numbers of portal configurations that are difficult to manage. With this PR, we will operate with a small, predetermined set of configs on the portal. The billing portal view code checks a user's current subscription and requested price (if any) to determine which config should be used.
Unfortunately, portal configurations are not handled by djstripe. Ideally I think we would want to add a db model for these and keep them synced with Stripe. But that would be more time intensive. For now, we will select configs based on hardcoded slugs matching their metadata.
👀 Preview steps