This repository has been archived by the owner on Jan 2, 2024. It is now read-only.
control: rework subscription and schedule approach #218
Conversation
This file contains 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
This changes the scheduling logic to consider the subscription the source of truth, rather than trying to force the schedule API into being it. The new approach drastically simplifies the ability to reason about how Tier converts a single timeline into the complex beast that is Stripe schedules and subscription schedules because we can now say that: All schedule reads are done through subscriptions via the active subscription's current "schedule", and all schedules are created and updated via schedules. Create: Schedule API creates subscription. Updates: The schedule API updates subscription. Reads: The subscription API shows current state, including current the current subscription schedule This also relaxes constraints for cancel phases. Previous to this commit, cancellations has to go into effect immediately. Now cancel phases may appear in multi-phase schedules where the canceling happens in the future. The new restriction is that they are the last phase. The new "last phase" restriction may be relaxed in the future by canceling the current schedule as it does now, but then create a new subscription schedule, scheduled in the future. This also adds the ability to update default payment information for a stripe customer via OrgInfo. fix static check
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
This changes the scheduling logic to consider the subscription the
source of truth, rather than trying to force the schedule API into being
it. The new approach drastically simplifies the ability to reason about
how Tier converts a single timeline into the complex beast that is
Stripe schedules and subscription schedules because we can now say that:
All schedule reads are done through subscriptions via the active
subscription's current "schedule", and all schedules are created and
updated via schedules.
Create: Schedule API creates subscription.
Updates: The schedule API updates subscription.
Reads: The subscription API shows current state, including current the
current subscription schedule
This also relaxes constraints for cancel phases. Previous to this
commit, cancellations has to go into effect immediately. Now cancel phases
may appear in multi-phase schedules where the canceling happens in the
future. The new restriction is that they are the last phase.
The new "last phase" restriction may be relaxed in the future by
canceling the current schedule as it does now, but then create a new
subscription schedule, scheduled in the future.
This also adds the ability to update default payment information for a
stripe customer via OrgInfo.