Hi have you solved this problem?
2 Likes
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.
1 Like
I’ve just noticed that the substance of my feature request is mentioned here too:
1 Like
I’m working on this feature for the subscription plugin. I hope it works.
2 Likes
Good luck! We’d find it super helpful too for several use-cases - especially one-off events.
I’m pretty sure this has hit the ‘rule of three’ by now.
1 Like
There will be an update to the subscriptions plugin soon that addresses this.
It will also resolve the tax issues: Automatic_tax.enabled for Discourse Subscription plugin
and enable other payment methods. How can I customise the discourse-subscription plugin?
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? 
4 Likes
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).
2 Likes
Thank you very much for this feedback!
This is very helpful.
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.
Great feedback so far! 
2 Likes
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!
1 Like
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).
I added quite a few topics about the plugin a while back. Many got no replies, so it’s good to hear you are working on the plugin now. Edit: here’s a link – Search results for 'tags:subscriptions @Jonathan5' - Discourse Meta
2 Likes
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.
2 Likes
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.
However, I found that I cannot delete the products I create. see Cannot delete products on Discourse Subscriptions - #2 by Jonathan5
正在上傳: image.png…
this is my problem, I cannot delete the products. Sho
uld I delete them on stripe?
1 Like
Losing track of these mixed topics! Good luck with it all. I haven’t tried the plugin for ages so can’t really help, sadly.
2 Likes
This topic has become rather muddled. It’s not immediately obvious to me how I can untangle it cleanly. 
Though I would suggest that everyone tries to stick to one issue/feature per topic so they’re easier to follow and keep track of. 
2 Likes
if you want you can try out the updated code you can check out the branch from this PR:
you will have to run the stripe cli locally to relay the webhook messages. This is the command to use:
stripe listen --forward-to http://localhost:4200/subscriptions/hooks --api-key yourapikey
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.
3 Likes
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.
Where do we run this? In the server as root, or within the docker container? And do we use our instance URL before /subscriptions/hooks?
And just to make sure that I’m doing the right thing, is this what we install instead of the official plugin?
git clone https://github.com/spirobel/discourse-subscriptions -b "feature/rework-admin-page"
1 Like
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.
2 Likes
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?
Hey, that’s seems to be very good!
Can I try it deleting the official first? I mean, it’s OK for try on production and stripe test network?