9 ms·
Implementing API Billing with Stripe
- eruci 8y agoThis is unnecessarily complicated. That's why I handle all subscriptions with PayPal.
- detaro 8y agoHow does PayPal handle granular billing like this?
- eruci 8y agoSimple. Send the customer to PayPal with a subscription request, the amount and customer id. They activate the subscription and pay. Get that id back via IPN after each new subscription. Deliver the service. Done!
- detaro 8y agoHow 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.
- base 8y agoPaypal has APIs that support that. Example: https://developer.paypal.com/docs/classic/express-checkout/ec_set_up_reference_transactions/ https://developer.paypal.com/docs/classic/express-checkout/e...
- zlib 8y agoPayPal subscriptions are fixed amounts.
- sbr464 8y agoThanks 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.
- ceejayoz 8y ago> I’m curious why there is an even number of cents requirement on stripe’s end? Likely to prevent floating point screwups.
- digitaltrees 8y agoI built a prototype for health care last week. Daily is awesome. Keep it up!
- base 8y agoA 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 agoAgreed. > 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 agoWhat 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.
- 8y ago
- eleclady 8y agoI 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.
- aboutruby 8y agoThey often offer either the simple option or the custom-built option basically: - Stripe Checkout (https://stripe.com/docs/checkout https://stripe.com/docs/checkout) vs implementing your custom credit card form and using the API directly (https://stripe.com/docs/charges 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 https://stripe.com/docs/connect/accounts
- mduvall 8y agoHi 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 https://stripe.com/docs/payments/checkout
- enraged_camel 8y agoUnrelated: can you guys please provide a native way to pause subscriptions? I find all the recommended methods in your docs hellish.
- servercobra 8y agoThis 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!
- kwindla 8y agoYeah, 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.
- servercobra 8y agoAgreed, 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?
- kwindla 8y agoNo, 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.
- 8y ago
- klaudius 8y agoStripe 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.
- femiagbabiaka 8y agoI'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?
- LeonM 8y agoI'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 https://www.mailhardener.com
- warent 8y agoIt 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!
- kwindla 8y agoI'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. :-)
- rsp1984 8y agoAnd 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).
- warent 8y agoI 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
- arthurcolle 8y agoYou 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 ;)
- benologist 8y agoI have something just about ready to launch that tries to do this. My goal is to make creating web apps as simple as blogging is when you use WordPress. https://userappstore.com/public/2-powered-by-dashboard.png https://userappstore.com/public/2-powered-by-dashboard.png https://github.com/userappstore/dashboard https://github.com/userappstore/dashboard I am putting the finishing polish and fixes on a platform and marketplace using this software, just working on the final integration tests that verify it all works together.
- iDemonix 8y agoI know it's not specific to Stripe, but it seems there are products out there like ChargeBee that cover a lot of the use case.
- homero 8y agoStripe was much more complicated than it seemed. At the end i used Chargebee which did a lot of the work. A lot of things were abstracted away and i got a much better admin panel and can change payment processors anytime.
- pplonski86 8y agoMaybe noob questions, but how to do tests with stripe API? For example, how to write a test for plan upgrade? From what I remember there can be set testing env in stripe but the shortest subscription time was 1 day, so how to use it in automatic tests?
- harrisonjackson 8y agoWe disable live API interaction w/ stripe in our tests and use hardcoded response values. You can use a library to do this or patch the stripe sdk - depending on the language/framework you are using.
- bdibs 8y agoJust create a stub with the possible responses.
- ezekg 8y agoYou should never write tests against a live API. Always mock APIs and handle what happens when e.g. they send a 501 response, etc. Stripe has testing libraries in Ruby and other languages which are very easy to use.
- jwr 8y agoI so wish Stripe would stop ignoring a number of countries and make their billing available there (Poland is an example). I am stuck with Braintree and it is not a happy ride.
- stfu_bitch 8y agoAAAAYYYYY GO FUCK YASELF
- stevoski 8y agoStripe's "getting started" documentation, as well as this article, show us how easy it is to get started with Stripe - if you ignore the existence of taxation. The article is completely missing any mention of tax, be it sales tax or VAT. This is my biggest complaint of Stripe. For a lot of us, we live in countries where we simply _have_ to start collecting and remitting tax from the very first customer.
- kowdermeister 8y agoI've seen way too many "just copy these 5 lines" and you are good to go. With payments this is never that simple.
- noah96 8y agoMakes sense - I guess it's just an unclear emphasis on their offering which essentially is taking that work off your hands. What would you prefer to see?
- kowdermeister 8y agoA checklist of cases that I might not thought of. I would group example code around different use case and not around API endpoints. For example Braintree is good in that sense: https://developers.braintreepayments.com/guides/recurring-billing/overview https://developers.braintreepayments.com/guides/recurring-bi... I know it's not a payment gateway's responsibility, but some further handholding on tax and VAT, invoicing issues would be handy.
- james_s_tayler 8y agoAgreed. It's much more like "just handle these 50 edge cases and you're good to go."
- sudhirj 8y agoThat's what I'm stuck with as well. Paddle.com has this covered really well, but they have a long way to go in terms of API quality and breadth. Stripe has indicated that they're working on it, but no timeline yet: https://www.indiehackers.com/forum/stripe-onboarding-integration-feedback-0b79bd319f?commentId=-LHEhdwWdPs4Gkylr_a2 https://www.indiehackers.com/forum/stripe-onboarding-integra...
- Kiro 8y ago> Usage data needs to be sent to Stripe continuously. There's no way to submit usage data to Stripe after the end of a billing period. I don't understand how this is supposed to work when you're sending in aggregated data. How can you know before the period has ended?