Stripe has made transactions for my SaaS business so painless. I recently learned that I have customers with different currencies and it's not even something I had to consider or account for. Yeah their API is a little bit... bloated for simple needs since they're covering for many different use-cases, but their superb documentation, clean dashboard UX, and relatively low fees really make the value offering huge.
Overall I'm really not surprised at the valuation. Stripe is one of the best products/services out there.
Please also make using Elements with Stripe.js v3 fully optional.
We finished migrating to SCA-enabled payment flow not few days ago. Apparently, you can't create a PaymentMethod instance without using Elements and we don't have the time (nor do we see any practical need) to redo the frontend with them. So the end result is a Frankestein-style frontend that uses the v3, but with a fair share of v2 methods, because it's the only way to retain all the functionality we had prior to the migration (e.g. saving the card info for future use). This was a bit of nasty surprise to be honest. Migrating to the v3 basically breaks existing systems in a non-trivial and expensive to fix way... and the migration is mandatory because of SCA.
According to [1] it is required and there's no other (documented) way to do it.
Ditto for stripe.createToken() [2].
In fact, there's no word in the docs on how to feed raw card data into the v3 at all.
So we had no choice but to use Stripe.card.createToken() from the v2, but then also use stripe.handleCardAction() from the v3 for confirmation... it's a mess. What did we miss?
beware of PCI compliance requirements [0] but you can either create a payment method explicitly [1] or include the card details when handling a card payment [2] `{payment_method_data: {card: {…}}}`
I am aware of [0], but unless I'm missing something neither of the methods allows creating a payment method on the client and then passing its ID to our backend to be executed and set up for 'future use'.
That's the flow we had with the v2 and that's what we can't replicate with the v3.
We do want to optimize for those simple needs. Which parts do you think are bloated? Would love to hear how we can de-bloat. (Feel free to email me at edwin@stripe.com too.)
Not OP but I've used the Stripe API extensively (I know it nearly end to end due to implementing one of the framework client libraries) and to me the parts that come to mind if I think "bloat"/"unintuitive" are SKUs, Coupons, and most likely what GP is talking about the new payment intent APIs, even though I don't think there's a real way you could implement them any better given the PSD2 requirements.
By far Stripe has the cleanest experience of all. I wish you'd treat your APIs more like amazon treats theirs though, that is to say: no private internal-only APIs; I should be able to reimplement the Stripe Dashboard in my own app if I so wanted (just like how the AWS console only uses public APIs). That'd also make for some cool potential projects like a Terraform plugin for Stripe.
Feel free to reach out if you like, email on my profile.
> ... most likely what GP is talking about the new payment intent APIs, even though I don't think there's a real way you could implement them any better given the PSD2 requirements.
Yes, definitely this.
Payment intents is so much more complicated and convoluted than the previous "Charges" API. Stripe went from one of the easiest bits of my app to develop to one of the most difficult, to the point where I'll admit it even temporarily killed my motivation to work on my app solely due to Stripe's API. I stopped working on the checkout process just to take a break and work on other parts of the app and it pains me to think about even touching the checkout flow again even though I know I have to in order to release my app.
For any real app that's beyond the most trivial case you're likely going to be stuck using the "manual" payment intents workflow. Just figuring out which method to use was a huge ramp up of difficulty vs the old Charges API.
I went as far as even emailing their support for advice and even they weren't able to give me a straight answer. Their primary advice was to recommend not using it and instead use their new Stripe-hosted checkout system (which will not work for most people since it's so limited) or continue using the old Charges API and lose out on payments due to authorization issues that will come with not being able to deal with the new user verification strategies that are required by some banks and cards.
Like you I have no idea how to implement it any better, it's just the reality of the situation of the world we live in today but the bar has certainly been raised to consider accepting payments with Stripe now.
Upvotes don’t show on HN, so let me first say this is very much like our recent experience.
If those from Stripe who are reading this would like a hopefully constructive suggestion, may I suggest here the same thing I suggested to your support team?
Right on the front page of your documentation site (https://stripe.com/docs) you have a step-by-step walkthrough for setting up a basic subscription the old way.
If you follow through that process using one of the test cards for the new SCA behaviour (4000002500003155, say) you will see that the API effectively fails at a couple of points along the way.
Presumably either integrations need to do something extra at those points to take into account what needs to happen for SCA, or integrations need to follow different steps in the first place so they don’t run into those problems.
Either way, an equivalent step-by-step walkthrough showing how to use Stripe.js, the API and webhooks to set up a simple subscription in an SCA-compatible way would have been very helpful.
Yep, I came across the Payment Intents stuff - holy crap, it's complicated, and the documentation actually isn't great - it's good for details of API calls and such, but not for explaining what the hell you actually need to do, and why.
I also upgraded our Stripe API version recently, as a result of the new SCA regs - the whole experience was really frustrating! It felt like it should have taken me 4 hours max (test time inclusive), but it ended up taking me 5 days - the docs were just... not good.
This all seems very un-Stripe like, and TBH has me a little worried.
> This all seems very un-Stripe like, and TBH has me a little worried.
Well, I brought this up, but for what it's worth, as a user who's been thinking about this for a long time, I don't know how they could have done it any better given the new regulations and good support for payment methods that aren't credit cards.
Hrm, I've seen most who migrate spend a similiar time to your estimate. I know you've already migrated, but I'm really sorry it took that long, and I'd really like to hear where we can improve the docs. Would you mind emailing dev-feedback@stripe.com (and feel free to CC edwin@stripe.com).
[Not the GP, but 100% in agreement with them, except that we abandoned updating our integration.]
I'd really like to hear where we can improve the docs.
IMHO, the fundamental problem is that as the data model and API have become more complicated, the explanatory documentation has become less coherent. It feels like jumping around a Wiki now.
More specifically, we couldn’t find anything to show us the big picture of how SCA actually works with Stripe’s system. We also couldn’t find useful end-to-end walkthroughs with code samples to learn by example, hence my suggestion in the other comment you replied to. Lacking a frame of reference from one source or the other, all the detailed documentation about Stripe.js and APIs doesn’t help very much, because you don’t know what you need to look up in the first place or how anything fits together.
This was compounded in our case because after spending considerable time swapping messages with Stripe support, in which we did explain that we’d read all of your documentation and we did also describe our (very simple) existing subscription set-up process in terms of specific Stripe.js and API calls, the responses were just boilerplate references to documentation pages we’d already read. Of at least five different people from Stripe who replied to me over more than two weeks, not a single message mentioned any specific function in Stripe.js or the API or any specific webhook, despite several explicit requests and sending specific details on that level from our side at Stripe’s request.
To put this in perspective, please consider that when we first integrated with Stripe, it took one Stripe.js call, usually one API call and one webhook to tokenize card details, set up a Customer and Subscription with that card, and then act on each successful payment. I wrote that code myself in less than an hour, and I think it was described start-to-finish on no more than two or three pages on Stripe’s documentation site.
At the risk of making this comment antisocially long, but with the suspicion that we have not been the only ones following this path, I’ll describe what happened this time instead. The first of several links I was sent by Stripe support in one of those emails went to a page about saving card details for later (https://stripe.com/docs/payments/cards/saving-cards-after-pa...). Within just the first step of that page, there are at least six different concepts we hadn’t previously used in our integration that were mentioned, most of them without any sort of introduction, definition or link. Some of these are clearly very important concepts in SCA world, like a new PaymentIntents API and distinguishing on-session from off-session payments. OK, so we need to learn about those. Off we go to the API documentation, where we do find PaymentIntents, which in turn refers us immediately to the PaymentIntents API explanatory page (https://stripe.com/docs/payments/payment-intents/creating-pa...). This gives us a general idea of what PaymentIntents do (remember, when we integrated before, you didn’t even have concepts like Invoices in your API) but then starts talking about manual and automatic confirmation. So before we’ve finished reading the introduction on that page, we already have two more new concepts, and there’s a third link to a comparison between them, but that refers to one-time payments and we’re trying to set up a subscription, so now we’re jumping context and don’t know whether what we’re reading is actually relevant to our use case or not.
That last paragraph could continue for literally several more days of finding our way around, often going in circles. We’ll later be confused by the difference between PaymentIntents and SetupIntents, several similarly named but apparently quite distinct functions in Stripe.js v3 that might replace the old call to create a token, the difference between a source and a payment method, which actions happen synchronously and which are or might become asynchronous in the new world of PaymentIntents and SCA, and many other such questions. We’ll also wonder how any of this fits in with things like Dunning, which was the other big improvement we had hoped to make back when we first started reading about the latest APIs and contacted Stripe support for advice. One important thing you’d notice by the end of the story is that at no point did we ever discover what triggers step one on that very first documentation page to start with — is it a replacement for the old tokenization using Stripe.js, a replacement for the old Customer.create API call, something we have to do in addition to those things at some point?
This comment is already far longer than I had intended, but I hope that gives you some idea of how the current documentation and support systems are not working as well as they used to, from the perspective of a long-time Stripe merchant just trying to update their integration to the new APIs to maintain the equivalent of functionality we already had.
If I were tasked with improving the docs then I would start with an exercise to identify all of the explanatory pages for the new PaymentIntents API, SCA migrations, Dunning, and anything else related. Then I’d get someone, preferably someone who doesn’t already intimately understand how SCA works and Stripe’s API, to go through and highlight every concept or technical term that hasn’t yet been explained before it’s used. I suspect that would identify many points of potential confusion, but with several recurring themes. Next, I’d take a step back, look at how SCA works, look at how the Stripe data model and new APIs work, determine which are the foundational concepts that keep coming up but haven’t been explained first at the moment, and then write a one-page introduction to the big picture and how these concepts fit together. That is the key page that is completely missing at the moment. And then ideally, I’d go from there straight to the kind of walkthrough mentioned elsewhere, showing how to set up a subscription or a one-off charge using the new Stripe.js, APIs and webhooks with reference to the main concepts from that overview page. From that starting point, there is a frame of reference, and the more detailed explanatory pages and full API specs might make more sense to someone starting an integration essentially from scratch with little prior knowledge.
I'm glad I wasn't the only one who had issues with the "support circle".
Usually Stripe is on the ball but I dunno, I had a very non-productive back and forth with them. Non-productive in the sense that it took a long time to get anything that was in response to my initial email and that in the end I didn't learn anything I didn't know before I sent the first email.
Their first couple of replies just tried to get me to use their hosted checkout even though I mentioned needing coupon codes early on which is not supported by that. I also included a super detailed explanation of my workflow (bullet points, using headers, in depth break down of everything) and it was clear their hosted checkout was no way possible to use -- not even the automatic payment intents was viable due to the lack of validation I had to do server side when using automatic PI. Manual PI with a million hoops to jump through or forfeiting sales with Charges was the only option.
It really felt like the support person didn't read the request. It felt like they skimmed it for 5 seconds for keywords (or maybe this was algorithmic) and then made a copy / paste suggestion from a script just to make sure they hit a daily quota of "emails answered". It took a number of these until I started to get responses back from someone who sounded like they read the initial email.
I'm thankful Stripe exists but the worst possible thing you can ever do in support besides ignoring a customer is having the customer spend 45 minutes writing the most detailed request for help possible and then getting a canned response that was already deemed not able to be used in the original email that was sent. It's just in your face proof that support didn't even read it. Then you have to spend 5 back and forth emails over a week just repeating what you wrote in the first email.
I wish multi-billion dollar companies hired support people who cared as much about the company as the CEO. I guess this is why solo devs and smaller teams tend to offer the best support -- simply because the person answering emails is the person running the business or is massively invested in it.
If it’s of interest, our recent experience and the impression it created were very similar. We also somehow seemed to wind up with two or possibly three concurrent discussions going on, possibly because my initial contact went unanswered so I wound up chasing. We still use my business email address as our point of contact with Stripe, so if you look for chris.newton in your tracker, you should find all of the relevant discussions.
I just want to follow up with after emailing edwin, I was put in contact with someone who is on a different level than the support team I've talked with originally.
We got in touch late Friday so a resolution wasn't made (not enough time), but it's clear he spent more than 1 minute skimming the support message and it felt like he really put in serious effort to help me in my specific situation. I think everything will be crystal clear in the end after a couple of emails (and these aren't just repeating emails, it's to deal with moving forward with new info after implementation).
I wish this type of support was the default. It never would have happened without this post on HN happening. There's a lot of value in having in depth emails about specific problems because it leads to documentation improvements that benefit everyone (plus it makes your paying customers happy on the spot because they got help using your product).
I wonder whether that might also be what the last person from Stripe support meant when they mentioned sending us to some sort of specialist. Unfortunately by that point we’d already spent more than two weeks going back and forth with numerous people replying but no actionable advice, so we declined and made other arrangements. However, I did also send them some notes similar to my comments here, so perhaps the negative experience in our case could at least be helpful for improving their documentation for others in the future.
I had this exact experience recently too! Stripe was so easy at first so my estimate to upgrade was only a day, but the number of concepts and the muddled way they’re introduced meant day after day I was still working out if I really needed a payment intent, what would getting charge authority look like, do I even need any of this since I’m not doing business in Europe (in the end no, I migrated to the ‘old’ charges api, which the token api used to be). It ended up taking 5 days and causing quite a bit of angst with my cofounder due to a customer deadline
Combined with Stripe not refunding merchant fees, which was what triggered me to rewrite the payment process to delay processing until the last possible moment and making our own customer facing process more complicated, my most recent experience was less magical (like it was the first time) and more like dealing with a giant bank
I really like products like connect, and the original front end SDK (elements feels like overreach), but if someone hungrier came along they’d definitely get a look in
Yes, I feel Stripe has lost its edge with the new APIs. Interesting to hear 'demotivating' used as that's how I felt for a while. I needed many requests with Stripe support and could see the docs changing each time I returned to the task.
The interesting one for me is the way the client triggers the transaction, and the server has to asynchronously process that. I'm pretty sure I'm still having dreams at night about all the edge cases and whether I've truly covered them. Others are probably a more "that seems to work" style of development.
I was really happy with my idempotent IDs before....
I agree with everyone else re Payment Intents. I started using them in "beta3" last December(?) and did my last "upgrade" to PaymentIntents (really a full replacement of the Stripe integration) 2 weeks ago.
As others have said, the documentation is the major issue. PI takes time to understand, particularly if used to the old way. The documentation is improving but still a mess. Code examples miss steps, and I only made progress when I found this page: https://stripe.com/docs/payments/payment-intents/web-manual which 2 weeks ago wasn't clearly linked in the documentation (and https://stripe.com/docs/payments/payment-intents/migration where I kept ending up had contradictory code for the last stages). The split between automatic and manual confirmation isn't helpful.
Like others, each integration took longer than the 1 day I expected. I resorted to reading the API documentation at times to work out which JS method I needed - something I don't normally need with Stripe! handleCardPayment() vs handleCardAction() vs createPaymentMethod()... there's so many code snippets floating around in the docs for contradictory flows.
If Stripe really want to improve matters, a "What do you want to do?" wizard that asks questions like "When do you want to confirm?" and "Do you need to store the card?" and produces the right code snippets at the end would be helpful.
I also feel Stripe has dropped the ball in Europe. I was consulting with a client with not-insignificant turnover, and I recommended they switch to Stripe. The sales team took a week to reply to his enquiry, then didn't answer the questions but returned a boilerplate response. And this went on. It's not a good impression and made me look bad. I'm going to be less open to recommending Stripe to existing, established businesses now.
4-6 years ago Stripe was a shining example of a motivated sales and support team. Now - old and painful-to-integrate competitors like SagePay are doing better. Or shudder Braintree, who have arrived with discounted rates, terrible documentation, but an easy-to-drop-in JS widget for all payment methods.
Second that for having all of the API be public. Being able to purge test data via API in a single call is long overdue too and would be a delight compared to the process now - sign in and navigate to the delete page and wait however many hours it takes to finish deleting records individually or silently crash. During this time the API credentials are blocked too.
It would be really nice if there was a freeze on breaking API changes that amount to tweaking grammar too.
Yeah I wonder why the purge-test-data job is blocking and long-running. I suspect it's just low priority to fix it, but I imagine it would be doable to "unlink" the user's entire "test database", provision a new one, and wipe the old one in the background whenever convenient (and not even necessarily the same day).
I'm pretty nostalgic, so I do miss the old Charges API sometimes. But Charges assumed payments were binary—and we all know they're most definitley not. This also doesn't help with the new SCA regulations that started rolling out last Saturday (https://stripe.com/sca).
We've built Payment Intents to be future-proof. It tracks your customer's checkout flow, actually provides logic for retrying payments (subscriptions!), and also triggers authentication when necessary—so you'll meet SCA requirements.
Many have told us this has been pretty easy (and improved conversion too), so I'm really sorry that you got unhelpful advice earlier. (Would be great if you could forward that to me: edwin@stripe.com.)
I agree that Payment Intents is a lot more complicated than Charges - it's like a snowball effect where a small amount of extra complexity in an underlying API (SCA) gets exaggerated into ever more complexity with each API that added on top of it.
By the time it gets to our implementation it's horrible and occasionally (2% of the time?) we get a payment attempt that the client has handled and submitted to our server but isn't in succeeded state. We temporarily fix this by redirecting them back to the payment page but this time in 'Charges' mode. Which seems to work about 50% of the time
I wonder how much of this complexity is necessary - inevitable given SCA - and how much is because of Stripe's desire to support DD / bank-based payment methods in one integration. I guess we will see if, once SCA becomes widespread, other payment processors have simpler integrations...
Speaking of SCA, I really don't understand the motivation - it's not like higher fraud rates were hurting consumers, since those costs were borne by the merchants. My suspicion is that it is in the interest of card-alternatives like Sofort to add some friction to card payments, after all if every customer has to visit their bank for authentication anyway, why bother with a card payment at all?
That said, it is infuriating that after wasting all that time re-developing, SCA doesn't seem to have gone live at all. It reminds me of GDPR - the law abiding god-fearing types spend weeks worrying about compliance, disrupting their business; whereas the cowboys just take no notice - and get away with it.
It seems to be how the EU rolls: sweeping changes with terrifying penalties and sudden deadlines followed by minimal or selective enforcement.
Would be interesting to have an entirely separate 'Getting' section for folks on-boarding for first time just getting a handle on basics. Potentially even going as far as new 'Simple' APIs. Mention all the caveats up-front and direct them to documentation if they need more functionality. I'd imagine it would speed up adoption.
You can delete all of your test data by clicking a button in Settings > Data (/account/data). We also recently launched a feature that lets you delete multiple customers at a time, and hope to expand that to more different types of objects soon!
> I recently learned that I have customers with different currencies and it's not even something I had to consider or account for.
If your customers are at all price-sensitive, you might want to give this a little more consideration. Banks and payment processors always offer "We handle currency conversion for you! How convenient!", and they pretty much always do it by charging several times the normal conversion fee (in the form of converting at an extraordinarily unfavorable exchange rate).
I hate merchants who use those services; I have a credit card that will pay you in any currency and only charge me a 1% conversion fee. Please charge me in your currency, not my currency.
Please charge me in your currency, not my currency.
We did that initially, but you do discover a few downsides fairly quickly.
One is that if you also price in your (the vendor’s) currency, for any sort of recurring subscription or repeat purchase, exchange rates can cause noticeable and possibly surprisingly large changes in what your customers pay from one time to another. Naturally this is viewed favourably by your customer if the rate has moved one way but less so if it went the other.
Another is that not everyone’s cards charge as little as a 1% conversion fee. If you’re charging a typical consumer subscription of say £10 per month from here in the UK, some customers could easily wind up paying several pounds more by the time you add in the percentage and flat fees that some card providers seem to be charging for foreign currency transactions.
And finally, some people have never travelled much abroad and don’t really understand how things like currencies, exchange rates and conversion fees work at all. You’ll get someone who has signed up at £10/month, with the amount and currency clearly displayed at every step of the process, who will then email you to ask why they were charged $14.63 instead of the $10 they agreed to. Sometimes there isn’t much you can do at this point, no matter how much you try to explain that $10 and £10 are not the same, and that their card company has added a hefty surcharge for the conversion, and that this would have been explained in the credit card terms (which they probably never read) and isn’t something you have any control over as the merchant.
It’s a tricky area, because there’s usually nothing in it for a merchant to push a customer who does know what they’re doing and does have good terms into paying via the less favourable currency. On the other hand, if you start to provide explicit options for this sort of thing so each customer can choose for themselves, you risk making your payment process more complicated and losing conversions due to analysis paralysis. As ever, there’s not really a single “right answer” when you’re dealing with customers with very different arrangements on their side that you can’t even detect.
>their API is a little bit... bloated for simple needs
I used Stripe about 7 years ago. I used it because their APIs were simple and PayPal etc. was complex and bloated.
It seems that this cycle repeats throughout b2b startups. Is there now an opportunity to create yet another simple lightweight API but one that doesn't cover all use-cases?
Is there now an opportunity to create yet another simple lightweight API but one that doesn't cover all use-cases?
I think so.
One of my businesses has used Stripe since they launched in the UK, around the same time we were launching ourselves. Like many others, we appreciated the straightforward API, excellent documentation and easy integration. I’ve been happy to recommend Stripe personally on many occasions since then.
Recently, we were trying to update that original integration to take into account the new SCA rules that came in across the EU last weekend. Unfortunately, after reviewing Stripe’s current documentation site in its entirety and other SCA-related material, followed by a lot of discussion with Stripe’s support team, we were still struggling to understand the model of how SCA fits in with Stripe’s current API. That left us unclear about the structure that our integration needed in terms of Stripe.js, the API and webhooks. Essentially, after a lot of effort, we still didn’t really know where to start, and inevitably there came a point where it wasn’t viable to continue and we had to look at other options.
Of course Stripe has grown a lot more than we have in those intervening years and it’s understandable that their data models and APIs will have become a lot more complicated to meet the needs of their wider target audience. But sadly, the simple API, clear documentation and top-notch support that made them so attractive originally do seem to have been casualties along the way.
Given that SCA seems to be causing a lot of bother across the whole industry in Europe, to the point that several EU member states seem to be deferring its implementation because so many people aren’t ready for it despite years of advance notice, it does feel like there’s an opportunity for someone to disrupt the online card payments market in Europe now with a back-to-basics approach that is enough to meet the new regulatory requirements. One interesting question is whether it will actually be another card payment service that does so, given that a lot of other payment methods are popular in various European countries and some of them do have significant advantages including fewer complications due to SCA. We live in interesting times, as they say.
I am considering migrating from Braintree to Stripe.
It does look better, but I find some of the praise a bit too rosy. For example, the whole invoicing setup makes US-specific assumptions which are largely invalid where I operate (EU, specifically Poland), and I wonder if their recurring billing can be used without invoices. Also, there is no SAF-T (JPK FA in Poland) reporting for invoices, which means I can't even legally use their invoicing. Their E-mail templates are not customizable, which in my case makes all of their E-mail functionality useless. Then the PSD2 SCA (3d-Secure) flows seem to be hastily added and there is no good overview in the documentation (Braintree suffers from the same problem).
It still looks like the best option I have, though.
Yea, I'm pretty cool with this IPO as the company has built into filling quite a good niche while also putting pressure on MasterCard/Visa to clean up their monopoly softened act. I hope they find good success in the long term!
Edit: Oh please ignore my blindness, I didn't realize this was just a pure valuation announcement.
where does it say this is an ipo?
from the article: "Founded in 2010, Stripe is middle-aged by Silicon Valley standards, but Mr. Gaybrick and Stripe president John Collison said it had no plans to go public. "
I had the unfortunate opportunity to integrate with Adyen around 2016-2017 and it was super painful. The API didn't make much sense to me and the documentation was hard to navigate and understand. It all looked very rough and rushed to the market.
Granted it was "a long time ago" but I can still remember the pain.
Had a very similar experience around that same time. However, Adyen provided much nicer built in reporting features than Stripe at the time which made Finance happy.
Overall I'm really not surprised at the valuation. Stripe is one of the best products/services out there.