Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Implementing API Billing with Stripe

daily.co

Post reply on HN
Print view View original

21–30 of 84 posts

Re: Implementing API Billing with Stripe

#21

Post by intothev01d »

base wrote: post #8

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 meth…

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

Re: Implementing API Billing with Stripe

#22

Post by kwindla »

ElBarto wrote: post #16
base wrote: post #8

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 meth…

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.

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

Re: Implementing API Billing with Stripe

#23

Post by intothev01d »

ElBarto wrote: post #16
base wrote: post #8

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 meth…

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.

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

Re: Implementing API Billing with Stripe

#24

Post by smahs »

base wrote: post #8

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 meth…

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

Re: Implementing API Billing with Stripe

#25

Post by rsp1984 »

And here's your startup idea: Build a complete and configurable front-end to Stripe Billing that does all the hard work behind the scenes and lets existing Stripe users "upgrade" to billing without the implementation pain.

I've researched something like this some months ago and couldn't find anything that had the quality and features we needed. I'm sure lots of companies would pay for a solution like this (my company included).

Re: Implementing API Billing with Stripe

#26

Post by warent »

LeonM wrote: post #19

I've just finished a Stripe integration[0]. Given Stripe's developer first reputation I thought this would an easy job that wouldn't take more than a couple of days. Boy was I wrong! In the end, it took me about 3 weeks. Small disclaimer here, I was implementing Stripe Billing, not Stripe Payments. The Billing suite is a lot more complicated compared to the Payment suite. Nonetheless I took me a really long time to f…

It didn't take me nearly as long to implement Stripe Billing (a couple of days) but that's because all they can do is sign up for my one subscription plan, cancel, and update their card.

There are surprising edge cases that crop up. For example, canceling a subscription and then restarting it is actually somewhat painful.

But yes, their documentation is stellar!

Re: Implementing API Billing with Stripe

#27

Post by kwindla »

LeonM wrote: post #19

I've just finished a Stripe integration[0]. Given Stripe's developer first reputation I thought this would an easy job that wouldn't take more than a couple of days. Boy was I wrong! In the end, it took me about 3 weeks. Small disclaimer here, I was implementing Stripe Billing, not Stripe Payments. The Billing suite is a lot more complicated compared to the Payment suite. Nonetheless I took me a really long time to f…

I'm a Stripe fan, so my perspective on this is that Stripe has done an incredible job making "easy things easy," and a pretty good job making "hard things possible."

There are things I'd love to see added to the Stripe Billing APIs (some of which I mentioned in the article), but I have a really healthy respect for the amount of good work that's gone into the design of an API that, as you say, touches just about every part of a potential customer/payments workflow.

Stripe's API has consistent naming, a clean design of the core data objects, consistent data formatting and request patterns, good dashboard tools for seeing what's happened in requests and webhooks, and great documentation. All of which are non-trivial, and basically none of which any of the other "name brand" APIs I've used in the last year or so do. :-)

Re: Implementing API Billing with Stripe

#28

Post by warent »

rsp1984 wrote: post #25

And here's your startup idea: Build a complete and configurable front-end to Stripe Billing that does all the hard work behind the scenes and lets existing Stripe users "upgrade" to billing without the implementation pain. I've researched something like this some months ago and couldn't find anything that had the quality and features we needed. I'm sure lots of companies would pay for a solution like this (my company…

I had a similar impression when I was implementing Stripe for my business. It seems like there's a lot of boilerplate and heavy-lifting that I would have preferred to just abstract away using some existing service instead of spending the hours on getting it working in a way others probably already have.

Would you be open to sharing your thoughts on how you'd like something like this to work? I might be interested in giving it a shot. My email address is hello@wyatt.engineer

Re: Implementing API Billing with Stripe

#29

Post by ElBarto »

kwindla wrote: post #22
ElBarto wrote: post #16

Earlier quoted context omitted.

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.

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

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.

Re: Implementing API Billing with Stripe

#30

Post by arthurcolle »

warent wrote: post #28
rsp1984 wrote: post #25

And here's your startup idea: Build a complete and configurable front-end to Stripe Billing that does all the hard work behind the scenes and lets existing Stripe users "upgrade" to billing without the implementation pain. I've researched something like this some months ago and couldn't find anything that had the quality and features we needed. I'm sure lots of companies would pay for a solution like this (my company…

I had a similar impression when I was implementing Stripe for my business. It seems like there's a lot of boilerplate and heavy-lifting that I would have preferred to just abstract away using some existing service instead of spending the hours on getting it working in a way others probably already have. Would you be open to sharing your thoughts on how you'd like something like this to work? I might be interested in…

You put in all the effort to put up a cypher to unlock your email address on your profile and then just give away the gold in one fell swoop ;)
Post reply on HN