Anyone using Paddle for subscriptions? Experiences?
What's been your experience with integrating with Paddle in terms of reliability and ease of use? Is there any code online that shows how best to handle Paddle's webhooks in terms of tracking subscriptions in your own database (e.g. subscription creation, successful/failed payments, cancellations, refunds)? Any gotchas I should be aware of?
I'm not finding their documentation that clear to be honest and I'm having to experiment by creating subscriptions to figure out how to work with it to add subscriptions into my Chrome extension (https://www.checkbot.io/).
I've been using Paddle for just over a year now. I had to switch from Stripe because of their lack of support in the country I was moving to (South Africa).
Paddle definitely went through a period where their support was lacking and you will see this in a lot of the complaints on Twitter etc. But in the past 3 months, their support has improved drastically. They now normally respond to issues within a couple of hours.
Integrating subscription management was relatively easy, and you can test the webhooks with dummy data so you don't have to create actual transactions. I actually made some changes yesterday to record past due transactions on my side and added a new webhook endpoint in a couple of minutes without much hassle.
Some negatives I've encountered over the past year:
On the positive side:
I'd be happy to help you with any specific subscription integration questions.
Can you go into more detail into how you handle the webhooks? Do you have code to handle each different type of webhook?
Each webhook has different fields that others don't so I'm not seeing a nice way to handle them uniformly. I would prefer to just fetch the subscription from the API whenever a webhook is received but the API doesn't give you access to all the data (like the cancellation URLs).
Yes, I have code to handle all the different webhooks I need. I'm only using
subscription_created,subscription_cancelled,subscription_updated,subscription_payment_failedandsubscription_payment_succeeded.So what I do when a new user creates a subscription, in the callback from the Paddle javascript, I already create the subscription on my side with as many details as I have. Then, when the
subscription_createdwebhook is called, I get thecancel_url,update_urletc. and update my record. For the other webhooks I don't need any of that, just thepassthroughso I can match it to my record.Thanks! What are you doing with the "payment" events? You can tell Paddle to automatically cancel subscriptions after several payment failures so I'm just ignoring those events right now and relying on the "cancel" webhook.
I want to keep things as simple as possible but they're not making it easy. I don't understand why the passthrough, cancel_url and update_url are only available from webhooks. On purchase, I'm doing a fetch from their API to set up the user account just in case their webhook fails but the fetch API doesn't give you access to all the data surprisingly.
I'm using the payment event to send information to ProfitWell for SaaS analytics and I'm also planning on doing my own payment failed notifications via Intercom, so I can switch off the ones from Paddle. I would prefer a little more control over those. For that I need the webhook so I know when to trigger those emails.
Yes, the cancel_url and update_url would be handy if it was in the callback, but the issue is, as explained to me by Paddle, is that the subscription is not always created immediately on their side. They sometimes need to manually approve a subscription if the transactions appears suspicious. So they can't provide the subscription id, etc. in the initial callback.
Yes, it would be nice to have more control of those emails. I was experimenting with Chargebee before and they offer a lot more customisation from their admin interface. Paddle has limited options.
What do you mean about not being able to provide the subscription ID? So when the JS checkout completes, you can use the Paddle.Order.details callback to get the subscription ID and then use that to query their "subscription/users" endpoint to verify the basic subscription details without having to rely on webhooks. You require the webhook from e.g. the "subscription_created" event to get the cancel/update URLs though.
I guess I'm worried if my syncing code has bugs in it there's no easy way to bulk sync all the data from their database to mine because they don't give you enough access to do this with their API.
I contacted Paddle a week ago asking how I can test and there is no such thing as a test environment or dummy data. You test on your live account. Their advice was to create a new account after testing, so the transaction log is clean..
Not ideal but I'm going to create a second Paddle account for testing to keep the production one relatively clean.
Ah yes, ok. What I meant was you could test the webhooks sending dummy data via their webhook testing feature. This is a feature I use when adding a new webhook integration. But for an end to end test you would need to use live data unfortunately.
I've learnt you can just make the price $0 to make sure the data sends correctly.
Then make it the real price as you get closer to launching production. :)
I just finished implementing it for my products. They're not subscriptions though.
So far, I'm not too impressed with Paddle. Here are the downsides I came across:
I'm quite disappointed with Paddle but it seems to be the cheapest option on the market right now. In my case, I only need it for VATMOSS. I'm considering going to FastSpring but they are 0.9% (plus a few cents) more expensive.
@poehah, have you heard of Cheddar's billing API? We support VAT, and I'm pretty confident we'd be a lot cheaper.
Cheddar's core pricing is charging you $0.30 for every transaction you want to send to your payment processor. We also have a flat monthly fee ($99/mo), but if you're a startup with low monthly revenue, I want to let you know we're working on better structuring our pricing so startups don't have to pay that much if they're bootstrapping with low revenue.
I don't think we're talking about the same thing.
Put simply, Paddle acts as a re-seller of my products. The EU VAT regulation states that for each buyer from the EU, I'd have to register the paid VAT in their country. That's a lot of work and Paddle takes care of that for me too. So it's more than just calculating, showing, and collecting VAT. They also do all the paperwork behind it.
Is that something Cheddar also does?
I haven't one this but I don't think so. See https://quaderno.io/resources/eu-vat-guide/mini-one-stop-shop-moss/ .I haven't used Quaderno but they were very responsive when I asked questions of them.
I use FastSpring for this reason.
There has been a lot of talk of VAT MOSS in the past at http://discuss.bootstrapped.fm/t/my-vat-moss-experience-so-far/2497 and related threads
@poehah Thanks for clarifying, that's my misunderstanding. I wasn't as familiar with VAT MOSS until you mentioned that.
VAT reporting is not something that Cheddar does itself. You would have to use a 3rd party tool that has those features, like Avalara's VAT reporting or Quaderno would work with Cheddar.
For full disclosure, I don't know how our customers who collect VAT do their reporting. I know that they use 3rd party tools to calculate the rates, so I'm assuming their reporting is manual or through a 3rd party tool. That's a relatively smaller bunch as the majority of our clients are B2B businesses that I assume use the reverse-charge mechanism, so they don't collect VAT.
Unless your revenue is crazy high that Padde's percentage-based pricing really matters, they're probably your best and cheapest solution instead of using Cheddar and integrating a 3rd party tool.
Thanks for pointing that out!
This comment was deleted 8 years ago
This makes me feel better to be honest. I'm having to email support a lot to get all the details I need because the documentation is lacking.
I considered FastSpring as well but as you say they're more expensive.
I just switched to Paddle. My app is cross platform (mac and windows) C++, so it was, shall we say, challenging to get it to work. But i finally did, i even created an open-source C++ wrapper for it, here's the windows one: https://github.com/davecotter/PaddleCPP-Windows I have made one for mac too, with the same API, i just haven't posted it yet. Mac and windows both work on 32bit despite not having a 32bit SDK on mac (i use IPC and launch a separate process). Let me know if you're interested.
ease of use: the "documentation" is so sparse that it is impossible to implement without lots of back and forth with Paddle, and they often take a week to respond, and THEN they may only partially answer or give a vague answer, requiring yet another round. I know they're doing their best but ... i feel it could be better.
I wrote them about some inter-country EU taxation question quite some time ago, and they didn't return to date. I fear that due to Brexit they could have gotten disorganized. Pinged one last time to see if there's any response.
Sean, have you heard of Cheddar's billing API?
Disclaimer: I'm a part of the team, but I believe our webhooks might be a better and cheaper alternative to Paddle. Take a look and let me know if that's what you're looking for. It looks like we cover what you mentioned.
On the saving money note, we fundamentally charge you based on the number of transactions you generate ($0.30 per transaction + monthly fee), not a percentage of your revenue like Paddle.
It looks like you're pre-revenue, so our full rate ($99/month + $0.30/transaction) is likely a lot. I'll be honest, it's more geared towards startups making 25k in MRR right now, but as I mentioned this in another comment here, we're currently working on a better pricing model for really early startups and bootstrappers.
Thanks. Does Cheddar take care of all EU VAT obligations? One benefit of Paddle is I can just sell without having to worry about filing VAT or any other obligations selling to other parts of the world.
As far as VAT obligations go, most of our European customers use our API's
taxRate,isTaxExempt, andtaxNumberparameters. to support sales tax for different parts of the world.Here's a reference to more information about that.
Several of our customers also use tools like TaxJar or Alvalara to get the specific tax rate per customer and then pass it to Cheddar via the API.
Hi Wes, I would like to integrate Cheddar with my SaaS https://botdelive.com but do you support Azerbaijan as a country? It is not a registered company yet. I would like to know If I'm eligible to use it.
Hey Rufat, I know Cheddar itself can support merchants accounts (a bank account that enables the holder to accept credit cards for payment) from any country, but finding a payment processor for BotDelive is a bit different.
Payment processors are often concerned with where a company banks and where the company is incorporated.
As far as the banking part, it looks like PayPal won’t let people with accounts registered in Azerbaijan receive funds, which is, unfortunately, a pretty strong indicator that few (if any) major payment processors will support Azerbaijan either.
Have you looked at Stripe Atlas for incorporating BotDelive by chance? That would allow you to incorporate in the US and process payments from the US.
Another workaround would be to use Cheddar's External Payments feature. Basically, you'd be able to use Cheddar for all of the billing logic and billing features, but each transaction would automatically be marked as paid because our system would just assume you're settling the payment outside of Cheddar altogether. You could mix that with our transaction hooks to get even more functionality, such as sending notification/webhooks to your accounting software to keep your finances in order.
Does that help?
Hi Wes,
Yes, unfortunately, Azerbaijan isn't a supported country on major payment companies. BotDelive is a self-funded project and unfortunately, I'm currently unavailable to proceed Stripe Atlas. The External Payments won't help me at this time but looks interesting.
Thank you for the detailed answer.
Have a nice day! :)
You're welcome. Best of luck moving forward!
Thank you, you too!
Hi Sean,
well, I have using Paddle.com from the beginning in Bybrand https://www.bybrand.io/en it works well, integration is easy and "alerts" work.
What I do not like is the email notification service, Paddle does not allow you to modify anything, or even stop sending notifications to clients.
The checkou.js is good, but the API, for example, if you want to create own button checkout not is very cool
so it has its limitations.
You mean email notifications when a charge is made? I just tried making a paid daily test subscription and it's looking like it's going to send me a daily email for this which isn't great. My subscription will be monthly or yearly though.
They said they can change subscription prices if I email them. Have you tried this?
Yes, for example. if you as a company want to change the payment message successfully, through Paddle.com - they do not allow it.
Allow only change your logotipo.
I use Paddle for my product, a subscription based one. So far extremely satisfied.
Setting it up was a challenge as mentioned by Marteen, but that's a one-time thing and their support is very responsive.
They have webhooks for everything. It's been a year since we've implented Paddle and never had any issues. The only manual part when it comes to payments are refunds. Other than that I don't worry about new subscribers, failed payments, cancellations etc.
We recently launched a billing panel for our dashboard and thanks to Paddle they can see all the invoices, cancel their subscription or update their payment method.
How do you handle refunds in terms of webhooks, UI and updating your database? There doesn't seem to be a refund API call so you have to do it from the web UI. When you use that and chose to cancel the subscription at the same time, it'll send a "refund" webhook + a cancellation webhook (which could be out of order) but the cancellation date for the latter will be set to the end of the current billing period when you probably want it to be the current time. I'm probably going to add a "refunded" flag to my database and make an added check for that.
The cancel and update subscription web interfaces for users are nice but I can't see any way to get the cancel and update URLs for each user other than through webhooks which is inconvenient if you lose them somehow.
Sorry for not answering. Somehow I had missed your comment.
We're currently handling refunds manually. Luckily we don't have that many (1 or 2 every month), so for now we didn't want to spend much time on that.
They do seem to have a "Subscription Payment Refunded" webhook. Have you tried it?
Regarding the cancellation date, you can downgrade the user the moment a refund is issued and simply set the end of the current billing date to the current time.
For each subscription we store the update & cancel url in the db. The user can go to their billing dashboard (within our app) and either update their payment method or cancel it altogether.
This comment was deleted 7 years ago
Which programming language are you using? There's a verify webhook implementation for Node: https://github.com/avaly/paddle-sdk
This comment was deleted 6 years ago
You can always add a 301 redirect on the old url. We rewrote our product from PHP to Ruby and during the transition we simply redirected the PHP's controller to the Ruby one. Once we were ready we updated the webhook / alert url.
This comment was deleted 6 years ago