Subscriptions: convert Subscription model to use djstripe

[agjohnson]

Once we have djstripe added again, we'll want to start thinking about moving our logic to use djstripe. The easiest piece to update first might be our Subscription model. We aren't doing any real magic here, besides our handling of subscription state.

A few notes:

• The logic around how we interpret Stripe's subscription state is a little confusing to follow, because Stripe makes this harder than it should be. Namely, we have to use a Trial plan to create a trial period, and we manually cancel subscription state with application code when we determine the trial period to be over.

• We need to monitor this heavily. Any changes to subscription flow need to be monitored on a weekly basis, both in Sentry and in Stripe (see the daily view of new trials and daily view of MRR)

• We have had a few transient issues with id lookup on Stripe and organization/subscriptions missing ids. These errors likely are going away with this change. But see also a few related Sentry issues around Subscriptions and id lookup:

  • Sentry issue: READTHEDOCSCOM-9HZ
  • Sentry issue: READTHEDOCSCOM-8T5
  • Sentry issue: READTHEDOCSCOM-9N3
  • Sentry issue: READTHEDOCSCOM-5Z6

[stsewd]

Djstripe allows you to attach a subscriber to the Customer object (defaults to User https://dj-stripe.dev/reference/settings/#djstripe_subscriber_model-settingsauth_user_model), but we have stripe customers attached to organizations and users (gold), so we could just add that field in the models manually, this is start by adding a stripe_customer field to our organization/gold model (same as stripe_id).

readthedocs.org/readthedocs/organizations/models.py

Lines 90 to 95 in b0ae8f8

	stripe_id = models.CharField(
	_('Stripe customer ID'),
	max_length=100,
	blank=True,
	null=True,
	)

readthedocs.org/readthedocs/gold/models.py

Line 52 in b0ae8f8

stripe_id = models.CharField(max_length=255)

And slowly migrate all mentions of Organization.subscription to Organization.stripe_customer.subscription, we can start by using the new relationship to display the subscription information at https://github.com/readthedocs/readthedocs.org/blob/main/readthedocs/subscriptions/templates/subscriptions/subscription_detail.html.
We will keep updating our current models till we have completed migrated.

Another approach could be to have an intermediate model with a generic foreign key, something like:

class Subscriber(models.Model):
    object = GenericForeignKey()
    customer = models.ForeignKey(stripe.models.Customer)

this way we have the same model for all type of subscribers, and we could attach some metadata if required.
But I think the first approach is enough for now.

[agjohnson]

@humitos ☝️ You're probably the best resource here

[humitos]

I'd go with the first approach as well. Generic foreign keys are usually too complicated/ambiguous. It seems the first approach covers exactly what we need and it's simpler.