Discourse Subscriptions

Yes as long as Stripe is set up to cancel subscriptions after failed charges AND you have webhooks set up correctly, it will work as expected.


I think I see, so maybe this:

should be something like

Also, it’s a little confusing that the OP is owned by @rimian, especially since the plugin is now official and he’s not @team. I think it’d be better if it were owned by you, or perhaps @system as some topics are, or perhaps a @discourse user should own #official things.


I would have if I were sure that I understood. :wink:

OK. Done.

This moves this from a bug/feature problem with the plugin to a user error.

I’m hoping to have a test site using this plugin up in the next week or two. . .


The only way to do this right now is with the rake subscriptions:import task. This was built to handle an edge case after a refactor, though I’m open to additions. #pr-welcome!

Plans should be able to be deactivated in the edit screen.

Yes - it will cancel at the end of the subscription period. This is only valid for recurring items, though. If a one time purchase is refunded, group access will need manual removal.


@ajmuir @pfaffman it’s not 100% ready yet. I have some feedback to implement on the PR and have been focused on other things. Will be merged this week though!

It’s on the list!


I believe we have the subscriptions showing correctly now.

We will update the Stripe>email. Anything else to consider?

@justin we believe we might have a working subscriptions:procourse_import. Could you please have a look?

Notes & Questions

  • Notice in Ryan’s user view above, it says his subscription is $80 / month, but in fact it’s $80 / year. Pretty sure Stripe has it right, as our users only get billed annually. Any ideas as to why it says / month?

  • Throughout testing, these rake files always run twice when we execute them. Any idea why that might be happening?

  • We will squash commits before doing a PR.

This should be pulled from the recurring.interval field in the Stripe subscription.

Mind having a look here to see what Stripe’s returning?

I’m not sure - I’d have to dig around myself or have one of the engineers here take a look.

subscription[:items][:data][0][:price][:recurring] returns:

  "aggregate_usage": null,
  "interval": "month",
  "interval_count": 12,
  "trial_period_days": null,
  "usage_type": "licensed"

That would seem to indicate the subscription was created with a monthly interval vs annual from what I can tell. Maybe it was created incorrectly by Memberships?

These were all created by procourse_memberships, yes. I guess with the "interval_count": 12 it means the same thing.

In Stripe:

Looks as if Memberships only worked in months

I’m sure Memberships was using an older Stripe API reference, so this might be the shortcoming here. If Stripe is billing correctly, probably nothing to worry about.

I don’t think it’s a good use of time to make modifications to this plugin to accommodate the few cases Membership was used.

1 Like

Ok. Please let us know if you can think of anything that should be tested. I guess Cancel is the only function? When Subscriptions renew they will reflect in the Discourse Subscriptions screen correctly since we are always pulling live Stripe data?

There is a list of currencies that can be selected during pricing plan creation.

It uses a dropdown list format, with predetermined AUD, CAD, EUR, GBP, USD, INR, BRL values

Is it possible to select a currency outside of this list? My community will predominately be from a single location and they will appreciate the availability of a local currency i.e SGD

It is not at this time, as it has to be programmatically added to the plugin. If you’re up for a PR, I’d happily accept one (as long as it’s a currency accepted by Stripe).

1 Like

I was wondering if there was a stripe api call that would get all the currencies. (Not that I’m offering at this point…)

1 Like

That is an interesting thought. Also TIL:

Number().toLocaleString(undefined, {style:"currency", currency:"EUR"})

gets you the currency symbol from the abbreviation.

That might be a reasonable way to get around needing to have manually added currencies. However, there are a lot of currencies.


For folks who do not need access to all these currencies, it would carry a lot of UX overhead to load them all in. Not sure of the best approach yet on this one.

Yup. That’s a lot.
Maybe a site setting for “extra currency”? or default-currency? I for one am not willing to deal with accepting payments in multiple currencies…

1 Like

Hey Kim (hope you’re well), curious how this goes for you and what snags you might still be experiencing (and picking up our convo from last year at some point if time allows).

Thanks for reaching out, @NickMilo. We think this PR is ready and just needs to be reduced to a single commit. Let us know if you see any issues or things you’d like cleaned up.

1 Like