Feature request: I would like to be able to offer a subscription which lasts for one period only. At the end of that period:
The user should be removed from the subscription’s Discourse group (which I don’t think happens with current one-time payments).
No further payment should be taken.
Possible solution? The Discourse Subscriptions plugin should allow setting the iteration attribute of a subscription schedule. I found this in the Stripe documentation, on the Subscription Schedules API page:
Setting the length of a phase
The interval of a price determines how often to bill for a subscription. For example, a monthly interval is billed every month. Phases have an iterations attribute that you use to specify how long a phase should last. Multiply this value by the interval to determine the length of the phase. If a subscription schedule uses a price with a monthly interval and you set iterations=2, the phase lasts for two months.
…
Completing a schedule
Subscription schedules end after the last phase is complete. At this point, the subscription is left in place and is no longer associated with the schedule. If you want to cancel a subscription after the last phase of a schedule completes, you can set end_behavior to cancel.
No, unfortunately there were too many idiosyncrasies and missing features with this plugin. I don’t know whether it’s been changed since my question, though.
Please reach out if there are any other pain points you have with this plugin. I think I am aware of most, but there are still some parts that I would like to know more about. For example I would like to learn more about your perception of the campaign feature. Is there someone here who has used it?
I’m using the campaign for betterstreets.nz. It is okay, but quite inflexible. I set it up 9 months ago, and it is still rolling on (albeit extremely slowly!).
My biggest issue is that I can’t currently have folk simply donate X amount; instead, they must subscribe yearly.
Also, it is presented in those same terms - i.e. by month. That makes the amounts just weird, and isn’t really the way most people think for a campaign: from zero to X as an absolute amount. Even if presented as yearly it would be much better.
The banners are okay (top for discovery pages and bottom for topics), but aren’t very customisable. It would be nice to make them bigger or smaller so as to fit in with the rest of the site (e.g. other banners / footers).
Once dismissed by a user on a device, it would be nice to be able to force them back on occasionally, or have them shrink to a much more discrete thing (but still be present until the person has donated).
I see. I signed up to your forum to verify that and I understand what you mean.
Maybe it would be good to not make them dismissable at all? They don’t seem very intrusive and offer valuable information even to people that already donated. It gives the community a common goal and the donors deserve to be recognized for contributing.
There are many ways to create banners in Discourse. Which method do you use currently?
Something I recognized: I was not aware it was possible to donate to your endeavor until I signed up to the forum. As we know the biggest part of the audience will be passive readers and only a small minority will decide to register.
So it seems like a good idea to show the campaign banner to not logged in users as well. I am sure there are many people that would like to donate but are not active / registered members currently.
In betterstreets.nz, I only use the banner that is part of the campaign bit of the Subscriptions plugin. Its presence inhibits me from adding other banners!
I do use other banners in other sites though.
Totally agree - but only if it was super clear and easy for them to do so!
I can’t remember the Stripe jargon, but the whole plugin revolves round their old way of doing things (which allows credit card only) rather than the new way (which allows a wide variety of payment options).
Cancellation is described in a confusing way (from memory, it is cancellation of auto renewal but seems to be described as immediate cancellation).
Also it would be great if a subscription could be made at the same time as registering for the forum. At the minute the two-stage process isn’t ideal for all scenarios.
I sucessfully solved the one time subscription with a time interval by add a new metadata (“recurring:0/1”) in price object. And when you try to create a subscription with price[:metadata][:recurring]==“0” I will set the cancel_at_end value = true in Subscription object.
Then when you create a one time price, you still need to choose a interval (year, month, day, week), but you should not check the “recurring” box.
And when a user subscribe it, the backend will create a recurring subscription which will end at the end date. User will not need to cancel renewal by them self.
you also need to add the stripe webhook secret to the discourse instance (as the plugin setting “webhook secret”). You can find it in the code sample on the right in the webhook creation form on stripe.
I made a short video to give an overview of the data structures and how they connect to the Discourse data structures:
pretty much agree with this, but it should be fixed now. You can configure anything you want in stripe with this (payment methods / taxes / pricing table etc) and it should all work.
The plugin just manages the connection between Discourse users and stripe customers and the creation of products, plans, etc is completely done in the stripe dashboard.
There can still be bugs though. If you see anything please report.
So this is a fork that you are planning to submit as a PR request for the official plugin once it is a bit more polished? If so - brilliant!!! And thank you for your good work and energy on this!
If so, I’ll give it a go shortly. It will take a bit of messing around with to test it fully, of course.
This is only necessary for a development instance that runs locally on your computer. For example you can see in the video my discourse instance runs on localhost:4200 which means it runs on my computer.
If you want to recreate this exact environment you can follow this guide:
Because the stripe server cant reach the localhost:4200 address on my local network it is necessary to run this command to relay the webhook requests that come from the stripe server.
If you want to try this on a server that is connected to the internet you can follow the webhook configuration of the official tutorial: Discourse Subscriptions
Please don’t install it (yet) on an instance that already has live customer data and the old version of the discourse subscriptions plugin installed. Try it on a second staging server, because the two versions will be in conflict.
Thank you very much for testing this! It will also enable visitors that don’t have an account yet to buy a plan. They will be automatically invited to the discourse instance and have the appropriate group memberships once they paid.
I’ve got a relatively quiet live site (betterstreets.nz) with only 3 customers including me from an essentially failed previous experiment. I’d be quite happy testing it there, removing the previous plugin and its data if necessary (although I’d need a hand with the correct Rails console command). Would I still have a conflict in that case?
