When pulling up a users subscriptions a 500 might occur if we don't find
their plan. If your account happens to have over 100 plans this can be
the cause of the 500 error. This change adds pagination when fetching
plans form stripe, so that we fetch them all.
https://meta.discourse.org/t/problem-with-500-error-with-subscriptions/360808?u=blake
When using the Stripe Pricing table for one-off purchases
(non-subscriptions) the webhook was encountering an error because it was
expecting subscription information which does not exist for one-off
purchases. This fix addresses that issue ensuring that no errors occur,
that users are added to the appropriate group, and that uses can see
their purchase on the billing page.
Instead of deleting customers on cancel we will now update the
subscription status to canceled. This way we can have some visibility on
which users have canceled.
* add new route for card update
* create backend route
* update label
* basic functionality working
* ran rubocop
* added rspec tests for functionality
* make payment_method param compulsory
* fixed js linting
* improve client side error handling
* improve server side error handling
* improved update card page UI
* improve button UI for user subscriptions page
* give feedback to user about save status
* remove heading from last column
* fix padding on edit/delete buttons for update table
Co-authored-by: Blake Erickson <o.blakeerickson@gmail.com>
Duplicate payments were showing up in the discourse ui for users. Actual
transactions in stripe were not being duplicated. This fix ensures that
when parsing the api response we don't append any duplicates. Added a
duplicate entry to the specs to test for this.
I do think there can be some improvements made to this controller
endpoint, but I'd like to save those for a different and larger PR and
just get this fix out first.
The code in the plugin needed a dramatic cleanup. This refactor collapses the Plan/Product/Subscription controllers on the backend into one new controller: `SubscribeController`.
This reduces N+1 calls to the back end during the subscription process and simplifies use of the code.
I've also removed a bunch of dead code and refactored some logic into methods for easier readability. No feature/functionality changes in this commit; only refactoring. However, refactoring will allow for implementation of better anonymous user handling, so this is largely a foundation to enable making that change.
Previously, when a user canceled a subscription, the access would revoke
immediately on Discourse vs. at the end of the billing period. This
commit changes the behavior to remove membership at the end of the
billing period using Stripe's `cancel_at_period_end` attribute on the
Subscription object.
This commit now requires the setup of webhooks for subscription
processing to occur correctly.
Building off the foundation of using the Prices API, this PR adds the ability to create a one-time purchase plan for any product, which then can add a user to the specified plan group.
Some things to be aware of:
One-time purchases cannot have trials.
One-time purchases use the Invoice API instead of Subscriptions. Invoices are created then charged immediately.
Users should receive emails for these invoices directly from Stripe just like subscriptions.
Stripe has a newer API called Prices where you can create a price for any product and it can either be recurring or one-time. The easy part is existing Plans work with the Prices API by passing a Plan ID, but objects are returned in the slightly-different Prices API object format.
This commit is a refactor to the new API to handle the data in its new form, and lays the foundation for a one time payment plan to be added to any subscriptions product.
Blake Erickson