My last company processed >$100MM/yr of tshirts, split between Stripe and PayPal. Stripe was wonderful; PayPal was hell. It required a lot of engineering effort to build and maintain the system, even as simple purchases (no subscriptions). But if you're selling impulse buys online, PayPal is required.
Current company is B2B SaaS, smaller team, and I said "no freaking way" to PayPal. Built the subscription system around Stripe. Lack of PayPal has probably cost a few sales but our pace of development is much faster, and the new features we're able to roll out (like a referral program) move the needle more.
If you go the "straddle multiple billing systems" route, expect to dedicate one fulltime engineer to billing for the life of the project. That may be reasonable for a team of 10, but it's death for a team of 2.
I can only imagine the elevated pain of abstracting across multiple subscription systems. Ouch.
Paddle looks like the service I need on the long run:
I scan recent invoice history periodically to keep Credits up to date. Payouts are via PayPal masspay. Spends (using credit balance to offset their SaaS bill) are created on the invoice.created webhook, which adds a corresponding negative line item to the invoice.
I considered doing everything in Stripe - you can add pending invoice items instead of credits and payouts, then 'spends' are just the natural processing of bills - but it would have been very difficult to get analytics (eg, total outstanding payout liability).
Eventually, when they decided to streamline their payment and billing operations on their own tools, due to historical data on Stripe servers, they built a custom presentation layer on top of Stripe APIs. They ended up spending pretty much the same time and effort as they would have done by managing the business flows on their own systems and storing all the data on their DBs and using Stripe just for processing payments. Worse yet, they still depend on Stripe for stuff like reporting.
> In general, we think it's a good idea to make Stripe the "one true source" for as much of your customer and billing data as possible.
Customer and billing data are mission critical and as such having a third party payment processor as "one true source" seems suicidal, frankly.
We have Stripe handle the actual payments and nothing else.
Like most things in engineering, you can move the tradeoffs around to optimize for different use cases.
The "one true source" approach allows you to avoid writing logic to keep data in sync between your customer records and Stripe's systems. It also implicitly pushes you to think about how to store enough data in Stripe that the Stripe dashboards become your interactive way of managing and viewing customers. Those are both big enough wins that I do think it's the right approach to take for lots of folks who are just spinning up charging for a product, and for relatively simple recurring revenue use cases.
If you need to use multiple payment processors, or you need to have a complex view of your customer and lifecycle, then it's not the right approach.
Engineering is one thing but it must never trump strategic business thinking. Sometimes the cleverer engineering option is a business death trap.
Any solution that puts your balls into someone else's hands is suicidal.
for small product/shop/site with no strong core competence in billing it may be wise versa..
I'll take vendor lockin over being locked into a bunch of homebrew garbage that some former developer managed to sucker the entire company into creating because of "vendor lockin". So many times engineers come up with fears about "vendor lockin" and forget how easy it is to lock the company into an unsupported, half-baked homebuilt product that has nothing to do with the company's core business.
I've seen it with reporting and analytics, I've seen it with frameworks, I've seen it with deployment systems, build systems and configuration management systems. I've seen it with payment systems, crappy half-baked hybrid cloud implementations, database provisioning systems and more. All in the name of "avoid vendor lock-in".
Being locked into your own garbage-tier product that has nothing to do with your business sucks. If stripe kicks the bucket, you won't be the only person in that boat and there will be a path forward. Know what is worse? How about when the only developer who can support your crappy half-baked payment system leaves the company? Which stack overflow article will show how to get out of that mess? Talk about vendor lockin! You locked yourself into your own mess!
Stripe might leave the servers online in a half broken state for a few weeks, but they will not answer tickets or phone calls about critical issues if they've decided to can a product.
https://www.pymnts.com/news/partnerships-acquisitions/2018/s...
I'm encouraged by your success of this model. I'm currently struggling with the 'billing system as source of truth' model.
We built the abstraction around the requirements for our business model, although after some iterations it became similar to the model used by Stripe (customers, sources, plans...). We support saved payment options and on them we do recurring billing and one-stop payments.
A user for us can have multiple sources and a source is a saved external card or payment method, in the case of Stripe a source is a combination of the Stripe customer id and Stripe source token.
Most payment gateways support some kind of token that represents a saved card or similar on which you can do a charge.
It's really nice to be in control of the invoicing, without having to implement it ourselves, and of course not depend on only one provider. It also has support for taxes with plugins.