Support for subscription products and payment models.
We don't want to store payment information, so support will need to be for existing payment providers that offer a subscription / stored payment service (such as Recurly).
Subscription profile
Billing Interval
day
week
semi-month
month
year
Billing Cycles
terminate subscriptions after a xx of billing cycles.
Timespan
Begin
End Date
Infinity
Free Trial
Time the subscriber is allotted on the plan for free. The paid subscription will begin at the end of the trial period.
Setup Fees
A one-time charge processed at the time of sign-up.
Select payment service per profile
Assign "subscription profile" to products on product edit/management.
Glad to see you're looking subscription/membership scenarios. We've also been looking at implementing a separate Membership Collection. The same model can generally be used for both online and offline subscriptions/memberships. The term "Billing Cycle" can be confusing, as some organizations use it in reference to rolling memberships versus a static membership calendar. Where you have a static calendar, there can also be an issue related to pro-rated payments.
Additional terms: Semi-annual and quarterly, although not frequently used.
Use of roles to assign subscriptions. This works well if the purchaser is the one using the membership. We have use cases, though, where users are purchasing for other family members or entire families, or for businesses, etc. So we're thinking of it as a fielded relationship, an edge more like a graph database that links the membership to the user(s), although this would probably work in conjunction with an assigned role...still trying to figure some of this out.
@aaronjudd commented on Wed Mar 04 2015
Support for subscription products and payment models. We don't want to store payment information, so support will need to be for existing payment providers that offer a subscription / stored payment service (such as Recurly).
Subscription profile
ROLE
toUSER
on subscription purchase.@pomaking commented on Thu Mar 05 2015
Glad to see you're looking subscription/membership scenarios. We've also been looking at implementing a separate Membership Collection. The same model can generally be used for both online and offline subscriptions/memberships. The term "Billing Cycle" can be confusing, as some organizations use it in reference to rolling memberships versus a static membership calendar. Where you have a static calendar, there can also be an issue related to pro-rated payments.
Additional terms: Semi-annual and quarterly, although not frequently used.
Use of roles to assign subscriptions. This works well if the purchaser is the one using the membership. We have use cases, though, where users are purchasing for other family members or entire families, or for businesses, etc. So we're thinking of it as a fielded relationship, an edge more like a graph database that links the membership to the user(s), although this would probably work in conjunction with an assigned role...still trying to figure some of this out.
@RobertLowe commented on Sun Aug 30 2015
Instead of Recurly, and since Stripe is mentioned on #99 it would probably be best to target Stripe Subscriptions first.
@rymorgan commented on Mon May 08 2017
Need more requirements. Cart? Orders? PDP? Would love a basic user story to make the this an issue that ready for design.
@zenweasel commented on Tue Feb 13 2018
Closing to Review roadmap