Difference between revisions of "Subscriptions"
| (2 intermediate revisions by the same user not shown) | |||
| Line 13: | Line 13: | ||
* Yearly. This is triggered when the UTC year changes. | * Yearly. This is triggered when the UTC year changes. | ||
Regardless of the selected frequency, the subscription module checks consistency daily. So if a payment window is skipped for whatever reason, be it because the server is offline at that point in time or the payment gateway is unavailable, the consistency check the following day will get everything back in line. | Regardless of the selected frequency, the subscription module checks consistency daily using an [[Automations|Automation]]. So if a payment window is skipped for whatever reason, be it because the server is offline at that point in time or the payment gateway is unavailable, the consistency check the following day will get everything back in line. | ||
= Failure modes = | = Failure modes = | ||
When a subscription payment fails, the subscription is marked as inactive immediately. Note that this failure exclusively originates from the user's | When a subscription payment fails, the subscription is marked as inactive immediately. Note that this failure exclusively originates from the user's payment method - if there is an internal failure on your site with for example the connection to the gateway, this deactivation will not occur. | ||
= Subscription Payment = | |||
When a subscription is billed, it will create a Payment object and clone all of the entries on the subscription over to the payment. An event, Subscription.CollectUsage, is then also triggered, which can populate this payment with any quantities or additional products as necessary in the case of a "payment after usage" project. Note that usage tracking is not currently handled as part of the payments module as it is often going to be very project specific. | |||
Latest revision as of 15:31, 17 November 2022
This article is part of a series on the payments module. Subscriptions are a mechanism for obtaining repeat payments on some well defined schedule, typically monthly. Subscriptions are capable of billing for any number of "product quantities" either ahead of usage or after it.
Gateways
Subscriptions support any payment gateway which permits tokenised payments. Currently the default implementation includes Stripe.
Schedule Frequencies
Subscriptions currently support 3 typical frequencies:
- Monthly. This is triggered when the UTC month changes.
- Quarterly. This is triggered when the UTC month divided by 4 changes.
- Yearly. This is triggered when the UTC year changes.
Regardless of the selected frequency, the subscription module checks consistency daily using an Automation. So if a payment window is skipped for whatever reason, be it because the server is offline at that point in time or the payment gateway is unavailable, the consistency check the following day will get everything back in line.
Failure modes
When a subscription payment fails, the subscription is marked as inactive immediately. Note that this failure exclusively originates from the user's payment method - if there is an internal failure on your site with for example the connection to the gateway, this deactivation will not occur.
Subscription Payment
When a subscription is billed, it will create a Payment object and clone all of the entries on the subscription over to the payment. An event, Subscription.CollectUsage, is then also triggered, which can populate this payment with any quantities or additional products as necessary in the case of a "payment after usage" project. Note that usage tracking is not currently handled as part of the payments module as it is often going to be very project specific.
