Subscriptions

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.