I wanted to raise the issue of having plans into settings.py vs. having a Plan model, and find out if hardcoding plans was an explicit design decision and why that decision was made.
Why? Well, on the app I'm building, users are able to create multiple sites and each site may be on a different pricing tier. In an ideal world, Stripe would support multiple subscriptions per user and these tiers would just be Stripe plans that the user is subscribed to for each site in my system. But Stripe doesnt, and their recommended workaround is a giant hack:
https://support.stripe.com/questions/can-customers-have-multiple-subscriptions
This removes a lot of the ease-of-use that Stripe is supposed to provide and forces you to add a bunch of extra code to make things work (i.e., prorating, the signal to calculate line items and send them off to Stripe).
If plans in django-stripe-payments managed were models, you could dynamically generate Stripe plans as needed (in my case, basic-2_pro-3 for users that have 2 sites on the Basic plan and 3 sites on the Pro plan). This would be a far simpler solution (with much less room for error) than to have to manually prorate and add line items to an invoice.
An added benefit is that plans could be more segmented (i.e., You could have a plan available only to a certain subset of users or groups) and those plans could be added without having to deploy the entire codebase.
Obviously this will require some discussion, but I would be absolutely willing to put in the work to make it happen if it's something you're open to.