s2Member with Stripe and GST (tax)

Hey guys,

We are moving from PayPal to Stripe (finally).

The client has currently got GST set up somewhere within PayPal, so that any purchases from within Australia will have a 10% GST included in the subscription cost. I’m not exactly sure of the setup but was told I didn’t need to worry about s2M’s taxation because it was handled within PayPal. Now with Stripe,

E.g. if a user in AU purchases a $29 subscription, they will in reality be paying $26.36 + $2.64 GST. If a user anywhere else purchases a $29 subscription, they will be paying $29.

Now with Stripe I’ve been tasked with sorting out the GST in the same way. s2M has the country-specific tax rates (great) but it’s added to the listed cost rather than being included in the listed cost. Stripe Orders API seems the same.

So, looking for advice on how I could achieve the same setup: tax is included for AU payments, zero tax for anyone else, but the total is always constant for both.

Stripe itself doesn’t do this sort of thing. You need to connect your Stripe account to another service like Octobat, Quaderno, or Taxamo. Or you could instead try the direct integration between Quaderno and s2Member: http://support.quaderno.io/article/69-integrating-with-s2member

Cheers Tim,

Having not taken this path before, do you (or others) recommend any over other options?

I think Taxamo uses the Orders API and so can’t deal with taxing recurring payment profiles…well that’s what my reading turned up earlier today. Octobat looks like it could be a fit, though.

I don’t fully understand the integrations. What am I missing?

  1. Subscription cost, country location (and other details) from s2M pro-form
  2. All details passed on to Stripe
  3. Stripe passes only the necessary stuff on to Octobat
  4. Octobat determines tax rate based on location and generates the actual charge for the customer
  5. ???
  6. Customer completes transaction on-page via Stripe checkout pop-up?

And we’re then left with billing statistics within both Stripe and Octobat…? But Stripe would have crude billing data (like total cost maybe) whereas Octobat would show us the tax breakdowns etc.?

Am I even sorta kinda close? Haha.

Tom, that’s not quite the process. This is it:

  1. You set the price using s2Member.
  2. Customer pays that price.
  3. All details are passed to Stripe (you must set Stripe to collect what you need; it doesn’t collect everything by default), which registers a charge on the card equal to the price set.
  4. Details are passed to Octobat or Quaderno, which then work out the proportion of the price already paid that must be designated as VAT or GST.
  5. Octobat/Quaderno sends out an invoice to the customer with the total price being that paid via s2Member/Stripe, but with a breakdown showing how much of that is VAT/GST.

So then, yes, this is right: [quote=“totld, post:3, topic:2831”]
Stripe would have crude billing data (like total cost maybe) whereas Octobat would show us the tax breakdowns etc.
[/quote]

In other words, you can do this the American way (which is s2Member’s default) of working out a price, and then adding tax (which would then be passed through the above system, resulting in an Octobat/Quaderno invoice with that amount of tax itemized). Or you can do it how pretty much every other country does and just charge a price inclusive of tax, so you just let Octobat/Quaderno work out whatever that tax amount is.

The latter is obviously much more flexible. It does have one disadvantage, though, in that it doesn’t tell the customer up-front how much tax s/he’s paying. Some countries require that. I don’t know about Australia, but it doesn’t sound like you were doing that with PayPal, so it shouldn’t matter.

1 Like

Thanks again Tim!

I think that all actually makes sense to me which is nice.

This is what’s happening now, so this is what we will be after again. The tax legalities I’m leaving to the client who seems quite sure all we need to do is charge GST from other Australians and everyone else’s purchases are tax-free.

The GST is set-rate so any purchase can have its GST determined working backward from the total paid amount.

Appreciate the breakdown Tim and feeling more confident to stick with Stripe moving forward. So far it looks like the best option by a mile and I wish I’d looked into it earlier.

1 Like

Mind that you cannot use the Stripe country information - without changing s2member sourcecode due to a bug. You will have to use the pretty awful 3 step checkout - with address information asked for AFTER customer enters his credit card data in the popup. Closes the popup - then enter the address. I lose about 50% of customers in the third step!

UI is really impossible. Also some antivirus like Kaspersky Internet Suite (though also others) will block Stripe payments if browser is Firefox or Internet Explorer.

Most small companies outside EU decide to give a ■■■■ to VAT laws - but legally if you’re company is based in a OECD country like Australia and most other developed nations you have to charge EU and Russia VAT. Soon also India, Japan, New Zealand and more - you will need to independent proofs of location - best way is to ask for address, and use quaderno.io - it’s IMHO better than octobat. I went from my own plugin via octobat to quaderno.io - quaderno.io really is the best solution.

Hey Felix,

Wow…that sounds pretty terrible to be honest. The whole reason I was moving to Stripe was its apparent ease of use from both ends. Something like “it is easy to integrate and easy for customers to use” in s2M KB.

Now you’ve got me second-guessing the whole lot! Surely there is a better method than that clunky 3-step checkout you mentioned to get a country location. I don’t think the client will let that one slip by, it seems like a disaster for sales.

How is anyone using Stripe for sales via s2Member if this is the required setup? I take it you’re no longer using Stripe…?

I’d hate to have to turn back toward PayPal at this stage, it has been regularly problematic and seems their IPN stuff is about to go in the trash anyway. Stripe seemed like the knight in shining armour until your post haha.

For anyone else who has this same question - I’m not quite completely done with implementing the live Stripe forms, but have tested extensively with Stripe and Octobat test data.

Anyway, it works fine! The Stripe Checkout pop-up collects location info as well as CC info all at once (not in the convoluted way mentioned above) and it’s a breeze compared to PayPal’s setup IMO.

Octobat allows me to include GST within any invoice paid by an AU user, just like I wanted. Would recommend to anyone wanting to achieve automated tax (either inclusive or exclusive) with Stripe on recurring payments.

however the country information you gather in the Stripe form is broken! So yes you pay some country tax - but likely to the wrong country (or you changed the sourcecode to have s2member not overwrite the country the user entered).
(check for the cities the user entered - it will usually be easy to find out there are not in the country that the user entered).

e.g. if you have australia as default - and a user from U.S. checks out - it will wrongly indicate to be in australia too.

All I can say is that I tested repeatedly with various country inputs (in Stripe Checkout) and various test credit cards from those countries, and it worked as it should every time.

I’ll be keeping an eye on our transactions as real users begin to use the new gateways. For now though, all my first-hand experience with the tests have showed that Octobat will apply the country-specific tax rules exactly as we want it to.

So to any future readers of this thread that are in my position, just test the platforms and see for yourself. If it all blows up in my face I’ll come back and update this thread :slight_smile:

well maybe latest version fixed it? there is nothing about it in the release notes - bug itself is still open on github too. I will give it a try in a couple of weeks when I have time. Used to be broken since it’s possible to set it up (so nearly 2.5 years)