Implement additional recurring payments (besides membership dues)

[wrought]

Stripe API Research: It seems there are lots of different options to adapt the existing Stripe integration to enable users to pay an additional regular fee for use of a sudo room locker.

1. First of all, Stripe actually supports multiple subscriptions for a given user since Subscriptions and Plans are first-class API objects.
   1. Drawback: This generates multiple recurring invoices, each of which could be started and charged at different times. There are some alternatives below.
   2. Additionally, Plans can be generated on the fly, so for each user, we can create a unique plan based on whatever costs they have incurred and the rates they wish to pay.
      1. Imagine filling out a form selecting: (a) membership dues amount and (b) check-boxes for additional fixed fees (e.g. locker). The total is summed and submitted to Stripe as a new plan, to which the user is subscribed and pays on a recurring basis.
      2. Creating a Plan and creating a Subscription to subscribe the user to the newly created plan is documented in this tutorial as well.
2. Importantly, 1. above does not reflect how the Stripe integration currently works in sudo-humans. Currently, at /~user/payment the user is presented with a list of Plans, from which the user can choose one and submit their new subscription. The user is also able to update or cancel their subscription. In order to maintain how the Stripe integration currently works, we would create new plans that matched all the existing plan options, but with varying locker fees.
   1. Drawback: This would create way too many options (especially unnecessary or seemingly redundant ones)! I don't see there being a strong reason to keep things the way they are...
3. There are yet other ways to Change the Amount Billed, but most of them are not recurring and would require some action by the user or the sudo-humans application to add to the user's existing subscription--each month (or whatever interval).
   1. Except, one clever work-around is to hack the Plans object by creating a $1 plan and using the Quantities object to easily build custom membership contributions for each user (tacking on extra costs such as with checkboxes as described above):
      • "As another example, if the amount each customer pays can vary greatly, you could end up with too many plans to address all possible cases, and yet still need to create new plans for new situations. Alternatively, you could create a $1 plan and subscribe each customer to the appropriate quantity, thereby creating virtual $5 plans, $8 plans, $17 plans, and so forth."

Proposal: Given my research and evaluation, I think we should replace the current Stripe integration with the option described in 3.i. above:

1. Deprecate the old Plans.
2. Create $1 Plans that vary by payment period (weekly vs monthly vs annual, etc)
3. Utilize the Quantity parameter to build the user's selected payment plan into a recurring membership rate of their choice.
4. Further increase the Quantity value based on whatever additional fees, services, etc.

Alternatively: The otherwise most comprehensive solution (but perhaps also cumbersome) would be based on 1. above—to allow users to create multiple subscriptions depending on what they want to contribute and whatever additional fees they incur through services, etc.

Note: Both of these options (proposal & alternatively) have a drawback of obfuscating the different costs because the invoice will only reflect a final tally. Perhaps that's okay, though!

[wrought]

@Juul what do you think about using the $1 + Quantity hack? It seems like it will make our stripe integration robust to the lockers-fee use case as well as any other fees...

ping @substack in case you have thoughts too

[buzzaz]

Gang it seems the $1 + Quantity hack (the option described in 3.i. above) is the one that makes the most technical sense. Yet how do we distinguish between people who wish to contribute cash (or are able to,) and those who cannot or do not intend to contribute cash? That's possibly a greater concern than the technical issue, which is essentially solved with this approach.

[wrought]

As far as I'm aware, right now we haven't implemented any features in sudo-humans for accounting for non-recurring online payments. I'm going to open two new issues to figure these out:

1. 41 Flow and Data for Recurring Payments Form

2. 42 Improving User Experience for Contributing $ to Sudo Room via Payments or Offline