[ElBarto]

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]

"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]

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.

[riku_iki]

> 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]

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