Implementing API Billing with Stripe • Hacker News Board

Re: Implementing API Billing with Stripe

#11

Post by eleclady » Tue, Apr 02, 2019, 7:17 PM UTC

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 difficult to get into. Every single example starts with "this is not production ready..." And the official docs are difficult to piece together into an "E2E best practices" setup.

Not saying there is a better solution, just that as a competent dev with a simple use case, I found Stripe overly complex.

Re: Implementing API Billing with Stripe

#12

Post by joshgachnang » Tue, Apr 02, 2019, 7:17 PM UTC

This was a really interesting article, thanks for writing!

At my last startup, we used our DB as the single source of truth. I think using Stripe as the source of truth like you suggest would have alleviated a lot of our issues keeping things in sync.

My biggest pain point though was around managing features on the client side. We had a bunch of different plans from lots of iterating (and customers coming from different sources that had similar but slightly different experiences), so it became hard to decide "should I allow the user to see this feature/do this action?". I haven't yet seen a great way to handle that. The plans literal here looks like a great starting point though!

Re: Implementing API Billing with Stripe

#13

Post by ceejayoz » Tue, Apr 02, 2019, 7:18 PM UTC

sbr464 wrote: post #3

Thanks for sharing. I’m curious why there is an even number of cents requirement on stripe’s end? I’m also not a fan of the quantity 1 line item rollup, although I understand the workaround. For the customer receiving the invoice, it makes it harder to breakdown the invoice in an automated way, since the detail info is moved to a text block.

> I’m curious why there is an even number of cents requirement on stripe’s end?

Likely to prevent floating point screwups.

Re: Implementing API Billing with Stripe

#14

Post by klaudius » Tue, Apr 02, 2019, 7:20 PM UTC

Stripe is touted as 'developer-friendly', but it's not all it's cracked up to be. I think PayPal is underrated here.

- Stripe's list of prohibited businesses is much larger than PayPal's. They are not business-friendly.

- PayPal is available in over 200 countries. You can accept payments in many countries Stripe is not available in.

- On PayPal you can start accepting payments immediately, no need to submit complex business docs.

- PayPal is easier to setup (Paypal.me link, buttons, send via email etc.) and has lower fees for small transactions.

- People might be more comfortable buying from a relatively unknown site when they are using trusted 3rd party provider like PayPal.

Re: Implementing API Billing with Stripe

#15

Post by femiagbabiaka » Tue, Apr 02, 2019, 7:27 PM UTC

klaudius wrote: post #14

Stripe is touted as 'developer-friendly', but it's not all it's cracked up to be. I think PayPal is underrated here. - Stripe's list of prohibited businesses is much larger than PayPal's. They are not business-friendly. - PayPal is available in over 200 countries. You can accept payments in many countries Stripe is not available in. - On PayPal you can start accepting payments immediately, no need to submit complex b…

I'm eternally amazed at the rate of speed at which any HN comment section derails into off-topic nonsense. What does this have to do with the linked article? Is it possible to do what's described in the article with PayPal?

Re: Implementing API Billing with Stripe

#16

Post by ElBarto » Tue, Apr 02, 2019, 7:30 PM UTC

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.

Re: Implementing API Billing with Stripe

#17

Post by eruci » Tue, Apr 02, 2019, 7:30 PM UTC

base wrote: post #10

detaro wrote: post #7

Earlier quoted context omitted.

How does that match the use case here, with billing per minute? If the user has to confirm each subscription, you can't efficiently create new subscriptions for e.g. each call. You also can't know beforehand how much you'll need to bill. If you're at the end of the month sending a single "here's everything" request, I fail to see how that's different from what's described in the article.

Paypal has APIs that support that. Example: https://developer.paypal.com/docs/classic/express-checkout/e...

Exactly my point. PayPal also makes it extremely simple for fixed amount monthly subscriptions - which is my use case. I do use Stripe, but not for subscriptions. This is the reason why.

Re: Implementing API Billing with Stripe

#18

Post by aboutruby » Tue, Apr 02, 2019, 7:35 PM UTC

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

Re: Implementing API Billing with Stripe

#19

Post by LeonM » Tue, Apr 02, 2019, 7:36 PM UTC

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 figure out all the special cases such as: renewing a card, switching to a different payment method, up/downgrading a plan, multiple currencies, etc.

At some point you'll be almost finished with the integration and only then do you find the need to implement webhooks for certain asynchronous payment methods (especially needed when you are in Europe). Once implemented, webhooks give you endless new workflows to handle, and many race conditions between your frontend and backend. So it constantly feels like one step forward and two steps back.

I don't think it's Stripe's fault though that my implementation took so long. Stripe's documentation is pretty solid. It's just that billing touches just about every part of your stack (frontend, backend, database, testing, tooling, accounting) and it's painful if you find out you have a bug that caused you to over/undercharge a customer. You need to take your time to get it right.

[0] shameless plug: https://www.mailhardener.com

Re: Implementing API Billing with Stripe

#20

Post by kwindla » Tue, Apr 02, 2019, 7:48 PM UTC

joshgachnang wrote: post #12

This was a really interesting article, thanks for writing! At my last startup, we used our DB as the single source of truth. I think using Stripe as the source of truth like you suggest would have alleviated a lot of our issues keeping things in sync. My biggest pain point though was around managing features on the client side. We had a bunch of different plans from lots of iterating (and customers coming from differ…

Yeah, I definitely feel your pain regarding iterating on plans and features.

Stripe explicitly makes it hard to modify most aspects of Stripe-level plans after they are created, which definitely is the right call because user expectations about recurring payments need to remain stable. But that means you have to build your own plan->feature mapping to manage a proliferation of plans, if you do any experimenting with or evolution of your pricing.