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.)
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.
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.
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....
Could you forward one or two of those to me? edwin@stripe.com
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.
We're working on a walkthrough that'll help with this now. Stay tuned.
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.
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.
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.
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.
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.
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
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.
It would be really nice if there was a freeze on breaking API changes that amount to tweaking grammar too.
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.)
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.
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!
Thanks for the feedback, keep it coming :)
I thought I saw someone running around in there.