Most of the payment stuff happens with the payment gateway vs the plugin. The plugin sends the subscription and customer info to the gateway and the gateway handles the recurring charges.
So I guess that means that Paypal, e.g. reminds the subscriber to renew and subsequent calls to Paypal tells ProCourse, e.g. a subscriber failed to renew, at which point ProCourse would remove the subscriber from the privileged group. About how it works?
Generally yes. It may be different in some detailed aspects per payment gateway as each have their own requirements. In most cases I believe it’s failed payment means cancelled membership.
A plugin we were imagining for our small membership of 200:
- Members pay with Paypal, Zelle, paper check, etc., with payments showing up directly from those sources.
- We would create a simple web screen listing out all members, where the treasurer can click a button next to the name to add 365 days to a membership expire date (using the API?).
- Plugin sees that membership expire date is > today and moves member to the paid group, giving the member Discourse rights to see privileged content.
- Once the membership expire date is < today + 30 we start sending a weekly PM reminder to renew.
- If the membership expire date ever becomes < today the plugin moves members out of the privileged content group.
To build this basic functionality, would it make any sense to fork this plugin as a starting point? For example, does the model part of this plugin extended the model to hold member expire dates and otherwise set up basic tasks that fire to check for member status on intervals?
We currently use Memberful, but total fees are running us ~10%, making us wonder if we could write such a plugin once and start accepting fee-free sources of payments, like Venmo and the like.
Can you explain that list bit for me? Do you mean those payments show on the user profile or in their respective user panels?
This would require the Discourse side to manage the subscription details. Right now, it uses the recurring settings to create subscriptions at the gateway. So that information isn’t on Discourse at all right now. You could do this but it would be at the gateway.
If there is ever a failed payment or the payment lapses for some reason, the plugin removes users from the group. So basically, if there’s any question about whether or not they should have access, it removes them.
I’m generally opposed to forking things like this. Especially when it’s a plugin that’s still being developed.
But since this is a plugin, it’s also easy to create a secondary plugin that depends on it and add your functionality there.
Yep. It’s possibly to set up systems to do this type of thing but it’s the fees and such that usually add up more than anything. Thus, ProCourse Memberships.
It’s manual. So Paypal notifies our treasurer of a payment, and we’re small enough to know who that is in Discourse to turn on a 1-year subscription giving full member rights. If the one paying dues has not done a Discourse signup yet, I suppose we send them an invite at that time.
Gotcha. Yeah, we’re really interested in using Discourse to do the reminding and then more steps in the workflow, like contacting an expired member to see why they left. Again, our use case is small (~200 members) and those who pay dues know each other in the real world, some over the course of decades. It’s low volume, high touch.
For now, when we subscribe to a membership level, we receive a private message (and I like the fact that we can customize the text), do you think it would be doable to send an email too, ideally with the invoice?
I guess it’s more difficult to add something like this, but I think it would be a nice feature
On a new signup, they should get two PMs. One is the welcome PM. The second is a receipt PM for the payment. Is that second one not delivering?
The PM works correctly, I just thought it would be nice if the receipt was sent via email too
The plugin follows the Discourse methodology of sending PMs and only sending the email if the user isn’t on the site. So it will send the email if they’re not on the site.
But this is a similar situation to the welcome email that discobot sends. It WILL email the user if they aren’t on the site but it rarely does because the PM is generated as part of the authenticating the user the first time.
Currently, we don’t have plans to add to this. So if you have a business case for it I’m all ears.
That’s understable, thanks for your reply!