The discussion revolves around including tax breakdown in subscriptions payment invoices on Discourse. marc2 found that the invoice sent by Stripe does not include the tax breakdown despite activating the “Include tax in price” option.
As a temporary fix, marc2 added the automatic_tax: { enabled: true} flag to the Stripe API, which seems to work. pfaffman considers this solution acceptable and suggests making a PR to add the feature to the plugin.
However, anderer points out that there is already a feature request for this issue. The solution proposed by marc2 may not be feasible for hosted instances of Discourse, as SteveRueck and Stephen explain that users typically do not have SSH access or the ability to edit the app.yml file.
SteveRueck and pfaffman discuss the limitations of hosted instances and the possibilities of making changes through theme components, but note that the current issue is on the Rails side.
I’ve set up a membership subscription, and it works fine. However in Stripe, I’ve activated the “Include tax in price” option where it will use the currency to determine if tax is included or excluded.
When testing, the invoice that is sent to my customer does not include this tax breakdown. This is a showstopper. Is it possible to configure things so the invoice sent from stripe includes the tax breakdown?
Thanks
As a temporary fix to get it working, I’ve added the flag Stripe API Reference - Invoices to app/controllers/discourse_subscriptions/subscribe_controller.rb
Added:
automatic_tax: { enabled: true}
see below:
transaction =
::Stripe::Subscription.create(
customer: customer[:id],
items: [{ price: params[:plan] }],
metadata: metadata_user,
trial_period_days: trial_days,
promotion_code: promo_code_id,
automatic_tax: { enabled: true}
)
I believe I can run with this fix for a while, and then when it is eventually added as a feature, I can swap it back to the original. I need to consider this before I go live to make sure it isn’t going to be a big pain later.
Any thoughts on why this is a bad idea if I need it working before it is an official feature?
Seems OK to me.
You can make a PR to add the feature to the plugin.
Until/unless that’s accepted, you can use a template to modify the code in the plugin inside the container after it’s been cloned. But a better idea might be to just clone the plugin.
There is already a feature request - without solution yet
If I understand this correctly, I am not able to use this solution if I have a hosted instance of Discourse running, right?
Hi Steve, I’m a total newbie to Discourse, but if you can install plugins from any GitHub repository by updating the app.yml file and running /var/discourse/launcher rebuild app, then it should work.
Hosted instances of discourse don’t typically give users ssh access, not can they edit the yml files. That’s all taken care of by their host and the plugins they have access to are set as part of the hosting package they pay for.
Correct. I’ve hosted my instance by Discourse itself and I can only use the “official” plugins and on them, I am not able to change some code (except for CSS on some).
You can’t change plugins, but much more then css can be changed in a theme component. You can change pretty much anything in the ember front end.
The current discussed here is on the rails side, however.
That’s what I meant.