5 ms·

A good first question to ask about a data model is, "where does the data live?" In general, we think it's a good idea to make Stripe the "one true source" f

by base 8y ago

A good first question to ask about a data model is, "where does the data live?" 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. Our company went the opposite way, we have our own model and we abstract stripe as a payment option supported. Recently with the same model we were able to add Paypal and other country specific payment methods.

ElBarto 8y ago
Agreed. > 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.
- kwindla 8y ago
  "Suicidal" might be a little strong. :-) 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.
  - ElBarto 8y ago
    What happens if you lose access to Stripe or they shut down? 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.
- intothev01d 8y ago
  Yea. Customer and billing isn't something good to hand over to another system you don't control. As a payment processor and API though, Stripe is great
- riku_iki 8y ago
  > a third party payment processor as "one true source" seems suicidal for small product/shop/site with no strong core competence in billing it may be wise versa..
intothev01d 8y ago
Couldn't agree more. Reading over it's tied to Stripe and their implementation, not even any sort of abstracted interfaces. Vendor lock-in isn't a good plan and to your point, make it easier to add another payment system when needed. Good choice
- spookthesunset 8y ago
  > Vendor lock-in isn't a good plan 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!
  - nicodjimenez 8y ago
    I think it really depends on the situation. Low level functionality (eg payments api) is more generic than high level functionality (billing cycles, dashboards, handling failed payments, etc) and therefore more likely to have a solution which will completely solve your problem.
  - WrtCdEvrydy 8y ago
    Spoken like someone who hasn't had a vendor disappear and have your entire implementation on their platform vanish.
smahs 8y ago
+1 I recent saw a couple of cases of small companies who chose to depend on Stripe for managing their payment data to save cost on initial development. As a result, their operations staff struggled between Stripe's admin panel and their internal tools even to answer simple user questions. 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.
james_s_tayler 8y ago
Question: did you plan the abstraction by looking at multiple providers first then figuring out the abstraction that would work well for all of them or did you just look at Stripe and luckily come up with an abstraction that also worked for other providers? I'm encouraged by your success of this model. I'm currently struggling with the 'billing system as source of truth' model.
- base 8y ago
  We used other payment gateways before Stripe. 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.
stickfigure 8y ago
I've done it both ways. 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.
- kowdermeister 8y ago
  As a solo developer on a project which needs flexible payment options (also t-shirts) that's why I need to pick a payment solution that supports paypal besides other methods. Paddle looks like the service I need on the long run: https://paddle.com/solutions/saas/ https://paddle.com/solutions/saas/
- nik736 8y ago
  Why though? I am using Braintree for cards and paypal and it's a breeze.
- noah96 8y ago
  Out of interest, why did you go down the avenue of hacking together your own system to handle subscriptions? Surely you've limited yourself like you've said you have to build out every time you want to attach another payment method like paypal - Is this not more expensive than looking into a Merchant of Record handling these complexities for you?
  - stickfigure 8y ago
    There must be some sort of miscommunication here. My (SaaS) subscription system is vanilla Stripe without abstraction. My (single-purchase, tshirt) system was an abstraction across Stripe and PayPal. I can only imagine the elevated pain of abstracting across multiple subscription systems. Ouch.
chrismorgan 8y ago
(Please don’t use two-space indentation preformatting for quotes. Use a `>` prefix possibly combined with asterisks for italics.)
gregoriol 8y ago
There is a very nice implementation of this called KillBill: it's a self-hosted invoicing system that can connect to many payment providers like Stripe/Paypal/... 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.

by base 8y ago

ElBarto 8y ago

Agreed. > 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.

kwindla 8y ago
"Suicidal" might be a little strong. :-) 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.
- ElBarto 8y ago
  What happens if you lose access to Stripe or they shut down? 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.
intothev01d 8y ago
Yea. Customer and billing isn't something good to hand over to another system you don't control. As a payment processor and API though, Stripe is great
riku_iki 8y ago
> a third party payment processor as "one true source" seems suicidal for small product/shop/site with no strong core competence in billing it may be wise versa..

intothev01d 8y ago

Couldn't agree more. Reading over it's tied to Stripe and their implementation, not even any sort of abstracted interfaces. Vendor lock-in isn't a good plan and to your point, make it easier to add another payment system when needed. Good choice

spookthesunset 8y ago
> Vendor lock-in isn't a good plan 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!
- nicodjimenez 8y ago
  I think it really depends on the situation. Low level functionality (eg payments api) is more generic than high level functionality (billing cycles, dashboards, handling failed payments, etc) and therefore more likely to have a solution which will completely solve your problem.
- WrtCdEvrydy 8y ago
  Spoken like someone who hasn't had a vendor disappear and have your entire implementation on their platform vanish.

smahs 8y ago

+1 I recent saw a couple of cases of small companies who chose to depend on Stripe for managing their payment data to save cost on initial development. As a result, their operations staff struggled between Stripe's admin panel and their internal tools even to answer simple user questions. 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.

james_s_tayler 8y ago

Question: did you plan the abstraction by looking at multiple providers first then figuring out the abstraction that would work well for all of them or did you just look at Stripe and luckily come up with an abstraction that also worked for other providers? I'm encouraged by your success of this model. I'm currently struggling with the 'billing system as source of truth' model.

base 8y ago
We used other payment gateways before Stripe. 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.

stickfigure 8y ago

I've done it both ways. 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.

kowdermeister 8y ago
As a solo developer on a project which needs flexible payment options (also t-shirts) that's why I need to pick a payment solution that supports paypal besides other methods. Paddle looks like the service I need on the long run: https://paddle.com/solutions/saas/ https://paddle.com/solutions/saas/
nik736 8y ago
Why though? I am using Braintree for cards and paypal and it's a breeze.
noah96 8y ago
Out of interest, why did you go down the avenue of hacking together your own system to handle subscriptions? Surely you've limited yourself like you've said you have to build out every time you want to attach another payment method like paypal - Is this not more expensive than looking into a Merchant of Record handling these complexities for you?
- stickfigure 8y ago
  There must be some sort of miscommunication here. My (SaaS) subscription system is vanilla Stripe without abstraction. My (single-purchase, tshirt) system was an abstraction across Stripe and PayPal. I can only imagine the elevated pain of abstracting across multiple subscription systems. Ouch.

chrismorgan 8y ago

(Please don’t use two-space indentation preformatting for quotes. Use a `>` prefix possibly combined with asterisks for italics.)

gregoriol 8y ago

There is a very nice implementation of this called KillBill: it's a self-hosted invoicing system that can connect to many payment providers like Stripe/Paypal/... 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.