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: