Subscription Product / Payment Support (OCC-59)

[jeffolmstead]

Subscription products / payments allow a product to be sold over time and should have ability to continue indefinitely, have a defined end date, or allow for canceling.

The subscription framework should be agnostic to the selected payment gateway while also recognizing only some payment gateways allow tokenization. There may be an interface that payment providers would implement to validate they support a tokenization payment model.

General architecture would be Subscription Plans and Subscription Products.

Subscription Plans

• Interval: Picklist of Day, Week, Month, Year
• Frequency: integer
• Maximum Occurrences: integer (leave blank for unlimited)
• Number of Days for Trial Period: integer (use 0 for no trial period)
• Notification Interval: Picklist of None, Day, Week, Month, Year (notifications fire off workflow event in advance of charging)
• Notification Period: integer (how many "Notification Interval" do you want to have in advance of the charge event to fire off workflow)
• Grace Interval: Picklist of None, Day, Week, Month, Year (assuming a payment is unfulfilled, what is the period before the subscription is automatically canceled)
• Grace Period: integer (how many "Grace Interval" do you want to have in advance of the failed payment before cancelling subscription)

Subscription Product

• Really this is just a "SubcriptionPart" that allows you to select a Subscription Plan (defined above)

By default, the Subscription simply continues on with the pricing as it was fixed in time at the Order, it does not recalculate pricing along the way.

Jira issue

[Piedone]

By default, the Subscription simply continues on with the pricing as it was fixed in time at the Order, it does not recalculate pricing along the way.

This is very important: Here we need to resist an attempt to DRY and load the corresponding pricing details on the fly, because changes to those shouldn't affect ongoing subscriptions.

For issuing the subscription, it should be noted that depending on the payment provider's capabilities, there can be two approaches:

1. The payment provider attempts the subscription periodically and notifies the app about the results via a webhook. This means that the configuration of the subscription should be sent to the payment provider.
2. The app attempts to issue the charge periodically.

If possible, the first approach would be better, since that's what surely works with all cards (including MFA with 3DS2). I'm not even sure that the second approach is in line with regulations.

[Piedone]

Also, we'd need to allow users to change their subscription: e.g. change between monthly and yearly payments, and subscription tiers.

[MikeAlhayek]

Another benefit from relying on the provider to handler subscription, is other apps can also hook in the event. For example, OC App, sends a request to create a customer then create a subscription, other app can act on the subscription request.

[sarahelsaig]

Here we need to resist an attempt to DRY and load the corresponding pricing details on the fly, because changes to those shouldn't affect ongoing subscriptions.

Never resist an attempt to DRY. :) The Order's line items already have baked-in prices for the same reason, so you can always use the first order as reference if necessary.

[Piedone]

A better term would have been "normalization of the data" that we should resist :). But great then!

[sarahelsaig]

It came to my mind that if the automatic payment from the payment provider's side fails or the subscription is removed from their end, we should still generate a "pending" order and send a mail to the customer. Same in case of payment providers without subscription support. This ties into #345 because right now you can only pay during checkout.