Paddle Billing
Paddle Billing is a new set of developer friendly subscription billing APIs with feature enhancements and functionality improvements built to strengthen Paddle’s Merchant of Record platform. This developer-friendly upgrade enables SaaS businesses to support more billing models, and represents a comprehensive step forward in Paddle’s capabilities. It improves your ability to increase revenue, retain customers, and scale operations hassle-free.
[…]
Paddle Billing also features brand new APIs that are built to modern standards and are designed to be simple to use. The APIs have been built to empower our customers, and the API returns are thorough and helpful to outline causes and solutions. This is backed by comprehensive API documentation for a seamless developer experience. You can also attach custom data to every entity within Paddle to keep track of data that matters to you, whether that’s on a customer, a subscription or an invoice.
[…]
Paddle Classic currently supports over 4,000 SaaS sellers around the world, it isn’t going anywhere. It will continue to be a stable, compliant, and secure platform with strong and unwavering support. […] You will continue to get updated payment methods and tax updates as they become available. However, some feature updates will only be available in Paddle Billing only.
There’s more information in the announcement. I’m not sure what to make of this. The focus seems to be on subscriptions, and it’s not clear to me whether any of the longstanding limitations of the Paddle platform have been addressed. Compared with other e-commerce providers, Paddle has always felt to me more like a platform than a solution. It has a very basic/opinionated feature set, with no support for shopping carts, very limited discounts, limited support for licenses, no way to fix incorrect addresses, etc. There’s a powerful API that gives you a lot more flexibility—but then you have to reimplement much of the store yourself. The API was also buggy and under-documented at the time I set up my store. The new API sounds better, but I really want is more features that work out of the box without having to use the API.
Some years ago, FastSpring also bifurcated their store/API, into Contextual and Classic. I stuck with Classic because it was working and I didn’t want to have to reimplement and test my whole store. FastSpring Classic continues to work, but it never got new features such as Apple Pay support. In both cases, I wish they could have brought their existing stores and transaction data along, i.e. support the old features and API within the new system. In both cases, I’ll probably eventually have to rewrite using the new API, not because I actually need anything that the new API offers, but because the customer-facing parts of the old system haven’t been updated.
Previously:
5 Comments RSS · Twitter · Mastodon
@Frank At the time, I think Stripe didn’t handle taxes or host the storefront for you. That may have since changed.
I just went through the process of converting my store from FastSpring Classic to Contextual. I'll give full marks to the support folks at FastSpring who handheld me through the quite long process. Like you, I held on to Classic for a long time because the migration was sketchy, but FastSpring did manage to migrate my store mostly to the new store with a few notable exceptions (Contextual does not support coupon limited by email address or quantity, both of which were features I used). I now have a shiny new popup store, which I think is an improvement overall, and it seems to be working well, but it's really hard to know whether it is better or worse for users, and until I ship the next major version and have to deal with thousands of purchases I wont really know how well it works under load. So the migration seems largely ok now, but it still feels weird to essentially have two stores I now have to think about maintaining (at least until they support those coupon restrictions, which I suspect is forever from now).
@Frank Paddle and FastSpring are Merchants of Record, meaning they are ultimately responsible (and liable!) for all legal, tax etc. stuff. With Stripe, you're the merchant and you're liable.
Stripe now has some limited support for handling of sales tax and VAT, but it's still much more complicated setup and you e.g. have to register with the authorities in the EU yourself, and remit the tax collected, or pay for 3rd party service to handle it. You also have to do accounting for individual sales. With Paddle/FastSpring, they handle all that and accounting-wise, you just sell in bulk to Paddle with a single invoice (well, two, for US and non-US, but that's it) and they then resell.
@Peter Yeah, it seems like both the new FastSpring and Paddle systems (and Apple, of course) are still missing features that eSellerate had 20 years ago.
Just curious… is there a reason you’d choose a service like this over something like Stripe that’s more general-purpose but seemingly more capable than Paddle?