Why I'm no longer using Stripe Transcript, AI Summary & Key Points

00:00 When it comes to building SAS products, one of the most important components is the ability to accept payments. Whilst you could roll your own payment provider, this is in fact a terrible idea. Instead, it's a much better idea to use a third-party service with some of the more popular ones being PayPal, Square, and of course, Stripe. Stripe is perhaps the most popular payment provider out there, and [snorts] for good reason.

00:27 Not only does it have a fantastic developer experience, but I would argue it pretty much sets the trend on how a payment provider should work. And because Stripe has both high reliability and a fantastic service, it's pretty much the deacto standard payment provider most developers will use. This was certainly the case when it came to my own personal experience, having used Stripe now for almost 10 years.

00:53 That is until I ran into a few challenges about a couple of months ago. These challenges ended up causing me to move over to a new payment provider, one that has not only managed to help me solve these issues, but I think I'm going to be using for the foreseeable future. This provider is Polar.sh, which has been recently growing in popularity with more and more people migrating over.

01:17 But this begs the question of why? Well, ultimately, like most things in software development, it depends. For some people, like myself, there's a good reason to move over, but for others, migration might not actually be the best choice. Therefore, in order to answer the question of why people are migrating over, let's take a quick moment to talk about what Stripe provides, as well as perhaps more importantly, what it does not.

01:43 As I mentioned before, Stripe is likely the most popular payment provider out there. But what exactly does a payment provider do? Well, a payment provider is the service that sits between your business, your customer, and the financial institutions, aka a bank. They handle all of the heavy lifting of securely processing credit cards, debit cards, and digital wallets, making sure the money leaves your customer's account and lands in yours.

02:10 In practice, this means they deal with things like fraud protection, encryption, PCI compliance, and settlement so that you don't have to build all of that infrastructure yourself, which would not only take a lot of time, uh, but it would be incredibly expensive. In addition to this, Stripe also provides a wide range of features and functionality that go beyond raw payment processing, leaning towards more business logic.

02:31 These include things such as managing customers, setting up and handling subscriptions, generating invoices, sending receipts, and issuing refunds. Not only this, but there's also some really amazing integrations when it comes to getting Stripe added to your project with perhaps my favorite one being the plug-in for better or enabling you to easily add payments into your products through Stripe in a matter of minutes rather than hours.

02:57 All of this makes Stripe more than just a payment processor. Instead, you can consider it more as a financial infrastructure platform, enabling us developers to focus more on building and shipping our products without needing to worry about the complexities of handling payments. So, given all this, why then did I decide to move away? Well, whilst Stripe does provide an awful lot of functionality, there's a couple of important things that it doesn't handle, which when done by one's self can take up quite a lot of time

03:28 with perhaps the biggest one, at least for myself, being related to sales tax. Now, to be fair, Stripe does provide you the ability for automatic tax collection when it comes to the relevant sales tax for your customers, which can be both enabled and configured, provided you've registered for sales tax in that jurisdiction and have provided Stripe the relevant tax ID.

03:52 Additionally, Stripe will also let you know when you need to register for sales tax for a specific jurisdiction. Typically, whenever you've exceeded a certain sales threshold for that location, which in some places is quite high, uh, but in others, not so much. Despite providing both of these useful features, when it comes to sales tax, there's unfortunately one feature that Stripe doesn't provide.

04:14 Tax remittance. This is the process of reporting and paying these collected taxes to the relevant tax authority. Uh before I go on, this probably needs to be said. I'm not a tax professional and I'm not a legal expert. Instead, I'm just a software developer YouTuber sharing my own experience. If you need legal advice or tax advice, then I recommend speaking to an actual tax expert.

04:40 >> [snorts] >> If there's any major amendments to the information that I share in this video, then I'll add them in the description down below, like I do with all of my content. Okay, so when it comes to selling online digital products, sales tax can be a little complicated. This is because the rules for sales tax typically apply based on where your customer is located rather than where your business is based.

05:00 So, for example, if someone in Germany makes a purchase, then you need to comply with the German/EU VAT laws. In many jurisdictions, you only need to register and remit once you pass that country's sales threshold, which can be in the hundreds of thousands. Uh, but in places like the EU and the UK, if you're located outside of them, this threshold is effectively zero, meaning that tax applies from your very first sale.

05:24 Once this threshold has been crossed for a jurisdiction or immediately when it comes to the EU/UK, then you need to register with the relevant tax authority and report and pay taxes periodically, typically every quarter. This involves filling out the sales information for that location in a timely manner, otherwise you'll incur a penalty, and then followed by paying the relevant amount in tax, meaning that you also need to set this aside for each sale that you make.

05:51 Stripe does have a paid service that you can use to simplify some of these tasks. Uh but I'll talk more about that in a couple of minutes. Additionally, in some jurisdictions, there's other rules to abide by. For example, in the EU, you have to provide a VAT invoice for every sale that you make, which Stripe doesn't do for you, at least not for free.

06:11 If all of this sounds like a hassle, then you're correct. It absolutely is. So much so that many solar developers like myself would rather not do this. Fortunately for those who don't, there is a solution through services like Lemon Squeezy, Paddle or Polar.sh. All three of which are known as a merchant of record or MO for short. Moss are services that work in a similar way to Stripe.

06:38 Uh basically allowing you to manage payments, customers, products, subscriptions, etc., etc. However, unlike Stripe, they have one major difference. [snorts] These services act as the official seller or merchant when it comes to any sales, i.e. the merchant of record, which is what gives them their name. This basically means that your customers are legally buying from this service rather than buying from your own business, and the platform then pays you the sale amount minus a service fee.

07:09 Uh, basically, you can think of it like a proxy for any of the sales that you make. Whilst this might seem like a weird double hop, it actually provides some benefits when it comes to selling digital products. This is because the platform itself assumes the legal responsibility of the sale, which means they're responsible for handling refunds, credit card disputes, and most relevant to my needs, collecting and remitting sales tax for different jurisdictions, which is what makes them so appealing for anybody who wants

07:36 to outsource this tedious task. Of course, these platforms don't do this out of the kindness of their heart, and they take a percentage of the sale as their operating fee. This percentage amount varies depending on each provider, but can range anywhere from 4% all the way up to 10. Now, this may seem like a lot, and yeah, to be fair, the 10% fee is kind of high, but when you consider that Stripe's fee is 2.9%, then if you're on the lower end of this spectrum, say 4%, this only ends up becoming about a 1.1% additional

08:08 fee. For some people, this additional fee to not have to worry about tax compliance is going to be worth the cost. However, there are some other drawbacks of using an M to be aware of beyond this additional fee with the most major one being that there's a higher chance it'll cost your customers more. This is because, as I mentioned before, you only need to collect sales tax in a jurisdiction once you've passed a certain sales threshold, which in some places can be quite high.

08:35 This means until you exceed those thresholds, then you don't have to charge tax to your customers in those locations, which means that they'll technically end up paying less for your product and therefore it'll likely increase your sales. However, by using an MO, then there's a greater likelihood that the sales threshold for a location has been exceeded due to the aggregate of sales that they make, which means your product is either going to have to cost more or you yourself are going to have to eat those additional

09:04 costs. This means depending on where you're selling that by using an M straight away, it may actually be a net negative, especially if you're willing to put in the effort to just handle sales tax in the few jurisdictions that you need to initially. This was actually one of the main reasons I decided to forego using an M initially and instead decided to just use Stripe and handle tax remittance by myself.

09:27 However, this ended up being quite a lot more work than I originally thought it would. For starters, it often took weeks or sometimes months to register with a new jurisdiction. And once I was registered, then deadlines to remit taxes came about pretty quickly, which given my time management issues, I would often end up missing and would be subsequently fined.

09:49 Perhaps the biggest thing I was concerned about, however, is I was starting to cross even more thresholds, which meant that the amount of work I would need to do to remain tax compliant was only going to increase. >> [snorts] >> Therefore, I decided that this sort of paperwork really isn't my cup of tea, and instead, I'd much rather spend my time both building and creating.

10:07 So, I decided to outsource this and migrate over to another solution that would allow me to buy back some time. But which one to move to? One thing to note is that Stripe actually does provide a paid tax service called Tax Complete, which is fulfilled by their partner Taxually. This service does handle some tax registrations and filings for you, although it's not exactly what I would call comprehensive.

10:33 The cheapest plan is $90 a month with the next plan up being $430. The $90 a month plan only covers two global registrations per year, which also have additional fees and only provides four global filings. Uh, remember in the EU you have to file four times a year anyway. So unless I'm misunderstanding what this provides, it wouldn't cover all of the EU and the UK.

11:00 You would still have to do some of this yourself. So I determined that this option was a non-starter and instead I would have to use an M. Therefore, I decided to do some preliminary research on the three services that I mentioned before, Lemon Squeezy, Paddle, and Polar.sh. Each of which come with their own percentage fee and on boarding requirements.

11:20 In the end, the one that I decided to go with was polar.sh. SH for a few different reasons. The first of which being out of the three, Polar has the lowest fee at only 4%. [snorts] In fact, they describe themselves as the cheapest M on the market. The second main reason is that Polar, in my opinion, has the easiest onboarding process, allowing you to get up and running accepting payments before needing to be reviewed, which will come after your first few sales.

11:47 The third major reason is that it also provides many quality of life features such as having great integrations with the languages and frameworks that I use, fantastic developer documentation, and also having the ability to set benefits such as Discord invites, GitHub repository access, and even file downloads. So, I decided to migrate over, which ended up being a lot easier than I originally thought it would.

12:12 In order to do so, I initially decided to do a proof of concept using Go, adding in Polar.sh alongside of Stripes so that I could easily switch between the two when testing. To do so, I needed to make a few changes to my database schema. And in order to do so without accidentally breaking prod, I needed a way to be able to fork my production data into a new database branch so that I could test it properly.

12:36 Fortunately, I was able to easily achieve this thanks to my Postgres provider and the sponsor of today's video, Neon. In case you're unaware, Neon has been my go-to Postgres provider now for just over a year. And it's perhaps my favorite way to easily deploy a database instance for either development, testing, and of course, prod. The reason for this is because it provides some incredible features that make using Postgres an absolute joy.

13:00 For [snorts] example, if I want to spin up a new database instance for a new project, I can do so using the following CLI command, which will produce a connection URI for me to use. Perhaps my favorite feature, however, is the ability to fork an entire database, including all of its data, into a new branch almost instantaneously. Again, when it comes to the CLI, you can do this using the following neon branch command, passing in the project that you want to fork.

13:28 This feature allows you to effectively test against prod without any of the associated risks, which makes it not only exceptionally useful when migrating payment providers, but also really useful in the modern era of Agentic AI, both when it comes to review apps, but also in helping to prevent any ambitious LLMs for accidentally dropping prods. In addition to all of this, Neon also comes with an incredibly generous free tier, which makes it a great option if you want to experiment with a Postgres database for your new

13:56 project, especially if you're thinking of trying out Polar. So, if that sounds interesting to you and you want to try out Neon for free, then make sure to use my link in the description down below. A big thank you to Neon for sponsoring this video. Okay, so in order to migrate over to Polar from Stripe, the first change that I needed to make was to migrate all of my existing tables and columns to have a prefix of stripe underscore.

14:20 This enabled me to be able to segment the existing columns by platform, which meant I could add new ones in and they wouldn't be conflicting. Because when it comes to go, I like to use SQL C, then this is easy enough for me to make the change throughout the code, as I had compile time checking to make sure that I hadn't left any previous references to the non-p prefixed columns.

14:38 Once I had confirmed that the changes were working, I then merged these in. Next, it was time to add in support for polar.sh. Fortunately, for the most part, Polar works very similar to Stripe. So, the majority of the changes were setting up a similar schema and business logic as what I had already defined. However, that being said, there are a few key differences between the two platforms to be aware of.

15:03 The first and most major one is when it comes to the concept of both products and prices. Both Stripe and Polar provide an entity type called a product which is used to represent what it is that the customer is purchasing. This product can be anything you want from a simple course all the way up to a different product tier such as a pro plan. Each product then has an associated price, which on both platforms can either be a one-off fee, so a one-time purchase, or you can set this up to be a periodic payment plan, so a

15:35 subscription. Where things differ between the two platforms is that in Stripe, a single product can have multiple prices, whereas in Polar, a product can only have a single associated price. Personally, I actually found that I preferred the way that Polar worked when it came to my database schema. This is because when it came to using Stripe, I was having to store both a product ID and a price ID column for each of my products.

15:57 Whereas with Polar, I could just reduce this down to a single product ID, which made my schema even more simple. That being said, one caveat with Polar's approach of having a onetoone mapping of product and price does mean that if you like to use prices to represent multiple tiers of a product, then this doesn't directly translate over. Instead, you need to create multiple products in Polar.

16:19 one to represent each pricing tier. Personally, I think I still prefer this, although it can sometimes mean you've got a lot of different products, even if they're the same one, just with a different price value. In addition to products and prices, another area that Polar simplifies is when it comes to customer references. Both platforms provide an entity type called a customer, which is basically the financial representation of a user that you would find in your own platform.

16:50 When it comes to Stripe, in order to map your own user with the Stripe customer, you'll typically need to use either a lookup table or add a column to your user table, which means you can then reference the customer entity in Stripe for your user later on. When it comes to Polar, however, there's no need to do this as Polar allows you to set a field on the customer called external ID, which you can use to reference the customer instead of the ID that's generated by Polar.

17:15 Therefore, by setting a customer's external ID to the ID of your own internal user, this means you don't need to store the polar customer UU ID inside of a lookup table, which can help to simplify your database schema. The final noteworthy difference between the two platforms is when it comes to ID generation. Polar makes use of UYU IDs, whereas Stripe makes use of prefixed object IDs, uh, which is something I actually prefer.

17:40 Whilst this is a minor implementation detail, it could potentially have an impact when it comes to any foreign key references in your database. However, given the fact that you can store a UU ID inside of a var, then it's likely not going to be too much of an issue. Other than these three differences, the rest of the migration was pretty straightforward and mostly involved changing to use the Polar SDK rather than the Stripe one, as well as setting up a dedicated web hook handler to handle any polar.sh SH events.

18:10 To make the implementation a little easier, I made use of Go interfaces in order to define any custom business logic methods I was using with the Stripe SDK and therefore what I would need to reimplement in order to make it work with Polar. Basically, it sort of acted like a blueprint for what I was needing to build. Then to make testing easier, Polar comes with its own sandbox environment which you can find at sandbox.polar.sh and is able to be toggled between in the SDK.

18:38 This allows you to test that everything is working before going live, which is rather important when it comes to integrating with a payment provider and dealing with both credit cards and real money. Once I was confident that the migration was working when it came to dev, I pushed up the changes to prod and saw my first successful polar transaction come through, letting me know I had successfully migrated over.

19:01 All in all, migrating over my existing project wasn't too difficult. And as I mentioned before, I'm likely going to be using Polar on any future projects for the foreseeable future. Fortunately, because I use Better Orth as my orth provider, then it's incredibly simple to integrate with Polar thanks to its fantastic Better Orth plug-in, which can get you up and running accepting payments in just a couple of minutes.

19:24 The plug-in documentation on the BetterOth web page is pretty comprehensive on how to achieve this. But if you'd like to see a full video where I implement Polar into an existing Better Orth project, then let me know in the comments down below and I'll draft up a dedicated walkthrough showing how to do this. All in all, for myself, migrating away from Stripe to Polar has been a great decision as it's prevented me from needing to spend time dealing with some of the more tedious tasks of shipping software.

19:50 and instead it's allowed me to focus more on creating and building, which really is what I want to be doing. Personally, this is something that I want to be focusing more and more on in the future, opting to have a lowmaintenance lifestyle where instead of spending time trying to do everything, I'm instead investing more in solutions that give me time back.

20:12 This includes using platforms like Polar and of course the sponsor of today's video, Neon, who have allowed me to not need to worry when it comes to setting up and deploying databases to use with all of my projects. If you're interested in giving Neon a go for your own Postgres needs for free, then feel free to use my link in the description down below.

20:30 A massive thank you to Neon for sponsoring this video and enabling me to talk about building software. Otherwise, I want to give a big thank you to you for watching and I'll see you on the next one.