There are a couple of pain points. Their invoicing is just a hot mess, if invoicing is a requirement for you I'd evaluate that very carefully. And they don't really have any sort of proper test system, which is pretty unbelievable. I do most of my testing in production using discount coupons, but 100% discount coupons can only be used with orders for a single item, so I can't test orders for 10 licences in any very useful way.
I dealt with their contract conditions by just ignoring them and crossing my fingers :-)
Still, all that said, there's nothing in this offering from Stripe that would tempt me to change. I'm also lucky in that I managed to negotiate a good rate from them when their model was switching to B2B (from Mac app sales, which the App Store killed). If you have any further questions, feel free to email me.
Edit: one other thing I like is that they use Currency Cloud to transfer funds to me, which give a much better exchange rate than a simple bank transfer and means that my local banks don't stiff me to receive a foreign transaction.
They fixed this a little while back. There's now a fully independent sandbox environment: https://developer.paddle.com/getting-started/sandbox
Personally, they've mostly been very good. The product works, it was very easy to set up and it does everything out of the box, and it's made sales tax & accountancy almost completely disappear.
I have occasionally run into issues or bugs, and their API is a bit of a mess, but nothing show stopping and their team has been reasonably responsive and sorted everything out very reliably. That's noticeably got better & faster recently, I think they're beefed out their support team a lot in the last year or so.
If you're selling a new product as a substantial business, I think they're good but there are other options to look at too and there are tradeoffs (5% is high, you could probably do your own customer accountancy etc in house).
If you're a solo dev/small indie, or just getting started though I think it's a no-brainer. It's just so much quicker & easier than doing everything yourself.
Quite a few, but to give an example from high on the list, it appears that a SaaS company would warrant that software sold through Paddle is always bug-free, accept unlimited liability via the related indemnification requirements if it isn't, and yet have no right participate in or even know about any relevant process if something goes wrong. That's a toxic combination and hardly looks like a healthy basis for a mutually beneficial business relationship.
Other concerns related to the considerable flexibility Paddle appear to give themselves in terms of how they represent, price and provide access to whatever is being sold, again apparently without necessarily requiring the consent or possibly even the knowledge of the underlying provider. We're unclear about how much this might be necessary because of merchant of record legal model, but it has little to do with what we'd actually want to use Paddle for or why we'd choose them over other services for collecting payments.
For context, this is a new business but run by a team who have collectively founded multiple others before. Several of us are very much over wasting time and effort on the mechanics of taking money from our customers and complying with whatever rules accompany that. Obviously fees charged by a payment service do matter, but a moderate difference there is still insignificant to us if the service we use can offer enough flexibility for our needs and easy integration, and otherwise takes on as much of the mechanical implementation and regulatory burden as we can shift.
What happens if Paddle are faced with a customer who is getting snotty about a bug and threatening litigation in an expensive jurisdiction? Paddle apparently have the right under their terms to settle that dispute on whatever terms they wish and then pass the entire cost on to the developers. There doesn't appear to be anything requiring those terms to be reasonable nor anything close to what the developer themselves would have had to offer in their own home jurisdiction or if they'd been selling directly to the customer on reasonable terms. As far as we could see, Paddle don't even have to notify the developer that any of this is happening, they can just send the bill at the end.
If anyone from Paddle is reading this and would like to explain publicly why that isn't an existential threat to every SaaS business using their service and what their terms actually mean, that would be very interesting to read. Maybe something like the above scenario would never actually happen. As I mentioned before, I've heard nothing but positive comments about Paddle from various people I know who actually use it. But in that case, there's no need for such one-sided terms, and it's better for everyone if the legal documents say what you really mean instead.
The FastSpring terms don't appear to create the same risks for us that we identified in connection with Paddle's terms as I mentioned above.