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

51–60 of 84 posts

Re: Implementing API Billing with Stripe

#51

Post by nicodjimenez »

kwindla wrote: post #48
joshgachnang wrote: post #35

Earlier quoted context omitted.

Agreed, making the plans hard to modify definitely makes sense, but then I feel like I need another abstraction on top of Stripe. Have you come across any good ways for handling this?

No, haven't seen anything. Everything looks like a hammer, of course, but to me this just feels like a general software engineering thing, if that makes sense -- building an abstraction on top of a library service. Our plan is to evolve the plans literal in our code into this abstraction (it already kind of is). Next step is probably to add something a little like feature flags, but we're still thinking this through.

Is there any downside to just using the payments api and not use any of the other stripe features? Subscriptions can be implemented manually right?

Re: Implementing API Billing with Stripe

#52

Post by james_s_tayler »

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…

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.

Re: Implementing API Billing with Stripe

#53

Post by mduvall »

aboutruby wrote: post #18
eleclady wrote: post #11

I found Stripe usage quite complicated. It felt like they were handling very complex use cases at the expense of simpler ones (which are probably the majority). It's one of those things where once you're already "in the know", the simple use cases are in fact simple to implement. But sifting through the massive and complex API set, with outdated and partial documentation/examples all over the internet, it's very diff…

They often offer either the simple option or the custom-built option basically: - Stripe Checkout ( https://stripe.com/docs/checkout ) vs implementing your custom credit card form and using the API directly ( https://stripe.com/docs/charges ) - Standard, Express, Custom options for Stripe Connect (e.g. take money from someone and give it to someone else): https://stripe.com/docs/connect/accounts

Hi from Stripe!

We are currently working on a new version of our Checkout product[0] and would love feedback. We are working on making the simplest drop-in integration to get up and running on Stripe, and we support Stripe Billing! Send me any thoughts you have (matt at stripe).

[0] https://stripe.com/docs/payments/checkout

Re: Implementing API Billing with Stripe

#54

Post by kwindla »

nicodjimenez wrote: post #51
kwindla wrote: post #48

Earlier quoted context omitted.

No, haven't seen anything. Everything looks like a hammer, of course, but to me this just feels like a general software engineering thing, if that makes sense -- building an abstraction on top of a library service. Our plan is to evolve the plans literal in our code into this abstraction (it already kind of is). Next step is probably to add something a little like feature flags, but we're still thinking this through.

Is there any downside to just using the payments api and not use any of the other stripe features? Subscriptions can be implemented manually right?

Yes, subscriptions can be implemented manually. We did that two years ago before Stripe had the full “Billing” API.

One big win you get with Billing, though, is automatic generation of invoices each subscription period. It’s nice not to have to write that code, and the automatic invoices tie in nicely to a few other things Stripe can do better than we can, like automatic retries of payments that fail.

Re: Implementing API Billing with Stripe

#55

Post by chrsstrm »

kwindla wrote: post #50
chrsstrm wrote: post #39

Earlier quoted context omitted.

You're right, their documentation is great and the API is nice to work with, but you are forced to do things their way. I was recently working with Billing and ran into a pretty big issue: A customer on a recurring plan upgrades to a more expensive plan. As long as the customer has a valid source on file, the upgrade is processed. Stripe's default is to adjust the payment to be collected and charge it on the next inv…

Our experience is that manual invoices are charged right away. I wonder what's different about our setups? The only thing I can think of off the top of my head is webhooks that aren't responding, which would delay the invoice closing. But I think that would make the delay 72 hours, rather than 24.

I misspoke, it's 1 hour, not 24. Can be found here [0]. Regardless, the upgrade happens _before_ the customer is charged, so unless you put a hold on your system and wait for that invoice to close, you're still giving them access before they've paid (Stripe's system will shown them as having the new upgraded plan before the invoice closes). And with the charge re-tries and back-off they use, if your webhooks aren't listening and reacting, you've still opened up your product to a user who hasn't paid for up to days at a time. I would be very interested to know how you got yours to close instantly, if it is doing that.

[0] https://stripe.com/docs/billing/invoices/subscription#genera...

Re: Implementing API Billing with Stripe

#56

Post by chrsstrm »

mahmoudimus wrote: post #47
chrsstrm wrote: post #39

Earlier quoted context omitted.

You're right, their documentation is great and the API is nice to work with, but you are forced to do things their way. I was recently working with Billing and ran into a pretty big issue: A customer on a recurring plan upgrades to a more expensive plan. As long as the customer has a valid source on file, the upgrade is processed. Stripe's default is to adjust the payment to be collected and charge it on the next inv…

Why can't you just charge the card directly?

That defeats the entire purpose of using the Billing product. Best I could come up with is to auth the source for the amount and see if it is accepted, then let it die by not capturing. But then you have customers who complain about being double charged.

Re: Implementing API Billing with Stripe

#57

Post by WrtCdEvrydy »

spookthesunset wrote: post #46
intothev01d wrote: post #21

Earlier quoted context omitted.

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

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

Spoken like someone who hasn't had a vendor disappear and have your entire implementation on their platform vanish.

Re: Implementing API Billing with Stripe

#58

Post by kwindla »

chrsstrm wrote: post #55
kwindla wrote: post #50

Earlier quoted context omitted.

Our experience is that manual invoices are charged right away. I wonder what's different about our setups? The only thing I can think of off the top of my head is webhooks that aren't responding, which would delay the invoice closing. But I think that would make the delay 72 hours, rather than 24.

I misspoke, it's 1 hour, not 24. Can be found here [0]. Regardless, the upgrade happens _before_ the customer is charged, so unless you put a hold on your system and wait for that invoice to close, you're still giving them access before they've paid (Stripe's system will shown them as having the new upgraded plan before the invoice closes). And with the charge re-tries and back-off they use, if your webhooks aren't l…

You're right, it's not synchronous! I looked back at our development notes and it seems like we were seeing about 15 minutes, generally, between creation of the manual invoice and finalization/payment. But that was using our test, not production Stripe API keys, and was a fairly small set of anecdata. I don't have better data because we ended up not rolling out any features that required manual invoice generation.

Re: Implementing API Billing with Stripe

#59

Post by stickfigure »

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…

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.

Re: Implementing API Billing with Stripe

#60

Post by chrismorgan »

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…

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