Switched to Paddle
Hola everyone,
After reading many recommendations here and elsewhere I completed the switch to Paddle for subscriptions and payments for https://www.dynablogger.com.
So far I was using Chargebee for the subscriptions backed by Stripe and PayPal for payments. With Paddle everything is easier as I just need an account with Paddle, and Paddle taxes care of taxes for me which is the most important thing - I only have a few paid users still, but I don't want to deal with taxes and I heard of some people who have seen their application for VAT MOSS denied, so I am not willing to risk. Accounting is also cheaper and easier because I will only receive one single reverse invoice per month.
For now I am happy with the integration, although it was more complicated than I thought because I had to make it possible for Chargebee and Paddle to coexist until everyone transitions to the new payment system (I sent them an email about this; I wish I didn't have to ask them to resubscribe).
I know that many here use Paddle already. What has your experience been so far? I am hoping that I won't have problems with Paddle because I'd rather not touch payment stuff again!
It's a bit tricky, isn't it?
(I'm currently facin challenges trying to initiate checkout from my backend. Paddle seems more in favor of using their JS frontend API. But still, the tax handling is charming.)
It's not too difficult to integrate but testing is limited. Paddle doesn't have a test environment and you can only specify a webhook per account to receive notifications in your app. So if you have say dev/staging/production environments, you either keep test data in your single account and use some proxy to forward events to the correct environment, or you create test accounts, which is what I did. Is that what you did too?
Also they don't support test cards.... so you need to test with real cards.... You can use 100% discount coupons to avoid payments when doing an order the first time for an email, but upgrades trigger payments anyway so you'd have to refund money to yourself for test transactions. The thing is that they always verify the credit card data that you provide, so because of a lot of test transactions my personal card was blocked and I had to call the bank :D
For the integration, I open the checkout when doing a new order or to update payment method, and that's done with the overlay checkout triggered with js. Then I handle pausing/resuming/cancelling/switching to another plan from my app directly using the API. Works pretty well.
So yeah, there are some limitations concerning testing coming from something more polished like Chargebee, but not having to deal with tax is the most important thing for me :)
True, testing is tricky. You need to deploy your webhook before the full payment functionality in order to test.
Also, verifying paddle's p_signature locally in a unit test isn't possible because they don't document how to create this yourself (which is understandable, so that it can't be faked). Thus, I now have code in my webhook to deteckt whether it's run by a unit test in order to skip verifying p_signature. Feels dirty.
But that's all much better than handling the gazillion (European) tax specialities. Way better.
To be honest this is a part of my app I didn't have a clear idea of how to test with automated tests, so I skipped it for now. Not happy about it because I usually test as much as possible, so I will have to look into it again.
It It might make sense to test test that you always return 200 (OK) to paddle, but log smething for yourself in case erroneous messages come in.
(To start somewhere.)