Thanks to everyone here who took a chance on us in the beginning and shared helpful feedback over the years! How to serve startups/developers more effectively at scale is still the main thrust of our product focus. We've fixed and improved a lot of things since we launched here in 2011, but we also still have a lot of work to do. (Both "obvious things we want to fix" and "new functionality we want to build".) I always appreciate hearing from HN users (even if I don't always have time to respond): patrick@stripe.com.

For anyone thinking about what they should work on: I started building developer tools when I was 15 and "tools for creation" is still, IMO, one of the most interesting areas to work in.

It's not just their documentation, Stripe's versioning, backwards compatibility support, and fast improvements probably make it the single best API I've ever worked with.

I have new projects that use the latest and greatest Stripe API and features, but also older projects that use their 5 year old APIs, and both work without a hitch.

I completely agree - I consider Stripe the gold standard for an API. Best I've ever used.

At least you get some cash back from expenses.

I sometimes get asked by customers if we take PayPal. I tell them truthfully "no, it's just too much trouble".

It doesn't seem like "better developer experience" is much of a moat, but based on how bad the competition is - year after year - it sure seems to be. I wonder what other services could be "disrupted" the same way.

I was able to accept donations in all the ways I wanted:

  - using Netlify (free hosting, includes lambda)
  - custom amounts
  - one-time payment or recurring
  - form on my own site

https://github.com/revddit/revddit/blob/master/lambda-src/do...

https://github.com/revddit/revddit/blob/master/src/pages/com...

For one of the first SaSS products I ever worked on, I (naively) chose Amazon payments. Within six months, Amazon introduced backwards incompatible changes. Six months later, they did it again. For another project I started 5 years ago, I used Stripe. We're still using the same 5 year old API and it works perfectly, even though Stripe has added new features and bells and whistles in their newer versions. Their commitment to backwards compatibility is probably the best I've seen of any fast moving API.

I documented how I implemented Stripe for the SaaS I run quite extensively at https://blog.checklyhq.com/our-stripe-billing-implementation...

The distinction between high risk consumer sales & B2B low risk sales is not drawn by Stripe.

I took what Stripe Support told us very literally, and we ceased using DigitalOcean and one other service since their only recurring billing options were Stripe.

We don't want to break Stripes ToS or do wrong by our clients, hence our contract-less, B2B only, monthly prepaid business model. Apparently this is too high risk for your company?

Thus, a blanket ban on Telecom and anything vaugely related (like ISPs). Certain flagship clients like Twilio get a pass, but smaller players like SignalWire, Telnyx, Teli, etc do not.

The Ubiqiti forums are also littered with ISPs that signed up with Stripe (since Ubiquiti integrates with them) used it for a few months w/o chargebacks or any fraud, but got an email one day saying they were not allowed to use Stripe. Appeals are consistently rejected or go unreplied to.

I emailed Edwin at Stripe 4hrs ago, have not heard back from him.

When I asked Stripe Support about servicing VoIP companies last year they referred me to the prohibited businesses section and said:

"Historically we have seen that the telecommunications industry is one with too high of a likelihood of customer chargebacks. These need not necessarily be chargebacks in fact; the likelihood of potential chargebacks is also a deciding factor in our deliberations."

Stripe is one of the few successful silicon valley companies that provided a service of real value, with enormous efficiency gains, upfront pricing, and don't screw over people as part of their business model. They may have "disrupted" the online payments market in SV parlance, but they didn't actually disrupt anything, they found a nascent but fast-growing market (online payments), and built a product targeted just for it.

Mastercard and Visa are each worth 10X as much as Stripe. Stripe is one of the few unicorn companies that's probably under-hyped.

https://news.ycombinator.com/item?id=3053883

https://news.ycombinator.com/item?id=3054726

Developers rightly praise Stripe's API documentation, but their approach to versioning and backwards compatibility is a gold standard that is not sung enough. What other fast-moving startup that constantly tweaks and changes their APIs also provide backwards compatibility with their earliest versions?

Stripe understands that handling payments is critical, scary, and hard to get right. When a company builds a payment solution that works, there is strong resistance to mess with it. The fact that Stripe is so backwards compatible means that they do not have to.

Thank you for the t-shirt and the most enjoyable ctf I had a chance to play!

I love the copy on Stripe's website. Who wrote it?

Godspeed.

It's not available at Stripe's home page. Would you mind sharing it? Thx

So yes, it is available on the home page - it's the most important thing there!

I build cannabis tech.

Its reall stressful when doing over $1 million in sales in a month and it’s literally all freaking cash and we have to spend hours even with a counting machine counting $20 bills.

Please tell me what your plan is to support legal cannabis.

Thanks

Take for example all thecredit unions in OR, CO, CA

Like north bay credit union in santa rosa.... their requirwments list for opening an account is RIDICULOUS!!

Other companies want either 3% of your deposits or $3,000 a month for a checking account whichever is higher.

Other banks AND companies will cancel your account if you even have the word “canna” in your name.

Ive literally sat there looking at $160,000 in cash with bills needed to be paid and no way to pay the bills...

You know how fun it is to go to seven different post offices with four employees in tow to buy as many money orders as you can so you can pay bills, such as a $25,000 software bill?

The problem is with their libraries, sandbox and testing tools. Also, their support is a complete and utter clusterfuck.

But the API is OK.

Can't wait for Stripe to integrate PayPal as one of the options. Seems unlikely to happen, but I keep my fingers crossed.

I built opalang.org many years ago - introducing a mix of functional programming, strong static typing for the web, fixing the independence mismatch between client/server/db etc. in 2009, and although we were not able to make it a big success, I'm still spending all my time in this area and am convinced that there is a lot to fix.

Then I found stripe. What a treat. Everything was documented and the documentation itself was both readable and didn't go in endless circles like the paypal ones. The error messages were helpful. And every api endpoint had an example, which is hugely helpful: HUGELY! All the other API developers out there can learn from this: you can't underestimate the value of having a working example. Not only that but the testing is much easier in stripe, and there's no need for a bunch of seperate accounts and sandboxes that don't make sense.

Oh and did I mention that the variables describe themselves: the first 3 or 4 letter of an ID says what it is (subscription or etc). Genius! It's little things like this which make Stripe stand out orders of magnitude above the rest of all the APIs in the world.

I hope you guys rule the marketplace for payment processing and wish you all the success you deserve.

Stripe's success in payment processing sends a clear signal to the Paypals and API developers of world: If you're producing an API that sucks, it creates an opportunity for someone else to come eat your lunch. :)

For a lot of merchants it's not a matter of switching to Stripe.

It's using Stripe but also including PayPal as an option because a huge percentage of buyers want to use it to pay for things -- especially 1 time purchases of digital goods.

About 40% of my course sales are through PayPal.

By the way if anyone reading is curious, that new PayPal refund policy goes into effect October 11th 2019 (you probably got the User Agreement email to notify you of this too if you're a merchant).

> Stripe supports the ability to refund charges made to your account, either in whole or in part. If the original charge underwent currency conversion, the refunded amount is converted back using the same process. There are no fees to refund a charge, but the fees from the original charge are not returned.

[1]: https://stripe.com/docs/refunds

Almost no matter what Stripe does from here, that they disrupted the PayPal monster (and the rest), will always reserve them a place in my developer heart. It really was an atrocious experience; there's pre-Stripe and post-Stripe.

Nevermind, Braintree was acquired by Paypal in 2013.

Razorpay. It’s also a YC company. I think of it as essentially an India-focused Stripe clone, with UPI, netbanking, etc.

Around 10 years ago I had the pleasure of setting up payments with a French bank: instead of a web API we had to use an opaque binary installed on our server. In terms of setup it took many weeks and several in person meetings to get approved. There was a (big) setup fee and a (not so small) monthly subscription. And then of course transaction fees.

In Japan for startups targeting foreignland it was even worse: only PayPal supported payments in anything other than JPY! [2] Interestingly it seems that with Stripe Japan everything coming from outside of Japan goes through USD. I have many customers being charged in EUR, and on our end we of course get JPY. So I would expect an EUR/JPY transaction to occur in the middle, yet oftentimes the USD/EUR exchange rates ends up leaking on our customer receipts... I wonder how it works behind the scene...

[1] https://tomotcha.com for those interested.

[2] Maybe banks were offering this service directly, but for what was only an experiment at the time, I was expecting the setup cost to be prohibitive (at least in time, if not in money).

We charge in USD, we pay for services in USD, but with Stripe we can get payouts only in our local currency. This leads to us losing twice on pointless currency conversions to the tune of 10-15% of the volume. It's been an ongoing headache for several years now and the only response from Stripe to all our asking to fix this has been that "it will be passed to the respective team."

But I thought I would just set up stripe here in NZ just now and it was... wonderful! I just needed to offer business info and it's ... done? There is nothing else to worry about?

For the conversion itself, we automatically convert from whatever currency you've accepted the payment in, then send it to your JPY bank account. The conversion rate is the average of whatever people are buying and selling the currency at that hour, but some financial institutions add a small markup on top of that along the way.

This is on top of my head, but I will forward you the relevant and exact information.

The reason here is because Stripe wants to mitigate exposure to non-USD price fluctuation, e.g. if EUR dives against the dollar. Many companies do (or should do) some version of this rebalancing, e.g. FB cited on an earnings call last year that they lost a large amount due to forex fluctuations.

When I started my company (since acquired) in 2012, Stripe was so game changing I flew from Australia to the US to open a bank account so we could use it. While we could incorporate in the US online, we had to turn up in person at a bank to open an account.

The only alternatives in Australia at the time were PayPal, which had outrageous fees and a terrible experience for recurring SaaS billing, or a merchant account with a bank which was going to require a $30k deposit.

It cost me $750 to incorporate a US entity, $1250 for airfares and hotel (oh to remember SF was that affordable!!). I stayed at Hotel Whitcomb, which conveniently has a Chase branch right next door, and 1 day later we had a US bank account and could turn on our Stripe integration. We didn’t look back.

I love Stripe Atlas, because I intimately relate to the problem, and wish we had it in 2012.

My last wire transfer was "cancelled" by their anti-fraud people, and after calling them and identifying myself extensively, I was told that I am to show up at my local branch with two forms of ID. Yes, the same two forms of ID that they've already seen. Kind of difficult if you are out of the country.

American banks are something else entirely.

Overall I'm really not surprised at the valuation. Stripe is one of the best products/services out there.

You're right. We're fixing this. Stay tuned.

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.

* SCA = strong customer authentication

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?

[1] https://stripe.com/docs/stripe-js/reference#stripe-create-pa...

[2] https://stripe.com/docs/stripe-js/reference#stripe-create-to...

[0] https://stripe.com/docs/security#validating-pci-compliance

[1] https://stripe.com/docs/api/payment_methods/create#create_pa...

[2] https://stripe.com/docs/stripe-js/reference#stripe-handle-ca...

That's the flow we had with the v2 and that's what we can't replicate with the v3.

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.

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

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

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 :)

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.

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.

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?

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.

The world of software APIs breathes in and out in waves of complexity.

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.

Edit: Oh please ignore my blindness, I didn't realize this was just a pure valuation announcement.

It also was total garbage developer friendliness wise ~5 years ago.

Granted it was "a long time ago" but I can still remember the pain.

Personally I think stripe is close to worth - as another commenter put it - half of goldman sachs. The recent launch of loans, credit card issuing, etc are all bets or exercises that put stripe in an incredible position to build platforms for financial capabilities.

We're used to winner-take-all when it comes to these unicorns, but I'm not convinced it will stay that way. With many of these service niches, there's a ton of money to be made and enough needs / feature differentiation for competition.

Square's market cap is $25B today on the public markets with a 2019 estimated net revenue of $4.5B and almost $100B in transaction volume. I don't have any insight into Stripe's numbers, though I'd guess it's probably not 40% more than that? Willing to be surprised of course, it's a great company.

The real question being asked here is: "Is Stripe's valuation likely to hold up when they go public one day?"

Can Lyft develop their own payment tech because they only transact in the US and Canada, and global transactions are where things get complicated?

I like most things about Stripe, but Shopify is also growing like crazy, has an awesome founder, and provides the only alternative to Amazon right now and is valued at $35B.

IMO costs are the worst reason to pick one of these providers at scale. They're all operating with a very similar cost basis, so you know they can each more or less match eachother, and if you come in with sufficient scale they'll offer custom pricing. Their costs are determined by the payment networks and their ability to mitigate risk and fraud. Stripe got a rep for being willing to match anyone even if they lost money in the process.

I haven’t used the two products, but is Stripe 50% better than Adyen? Why would I use one versus the other? How easy will it be for Lyft to develop its own payment technology?

I don't think "better" matters in current valuations. Nor does comparison to competitors really matter too much to the valuation - what matters are the revenue streams and potential for future earnings. So the number of current clients, and prospective clients, seems more relevant.

> How easy will it be for Lyft to develop its own payment technology?

Depends what you mean here. Any of these large companies are going to have their own merchant accounts (or should) processing payments for them. Stripe needs to either 1) take out the bottom of the market, which is what I thought they are competitors were doing and/or 2) come in cheaper and/or more convenient than maintaining your own payment services and such, which I think they do in some cases.

Adyen's MarketPay fee varies depending on payment method and is about 1-5% + 12¢ per transaction. I've contacted them to ask what one could expect for MC and Visa, but Amex and Discover are 3.95%, so I imagine similar. No mention of any other fees.

So for smaller dollar transactions (~$5), Adyen appears to be cheaper. Also, they support ACH, which Stripe does not.

sources: https://stripe.com/pricing https://www.adyen.com/pricing/full-list

Previously it was super simple to add dynamic card payments to a site - just drop the JS in, make a call to your server and then call Stripe from your server. Done. And it's all done in a popup on the same page (so no context switching UX for the user).

Now it seems they've killed the simplicity of that in favour of a more PayPal-like experience - where the user gets pushed out to the Stripe website to checkout. And it becomes more complex to implement too - due to everything being async and webhook based. At this point I think Paypal might actually be easier to implement for a certain class of simple one-off payments (although their sandbox servers are cripplingly slow).

I'm a little bit skeptical of this change because I think it's partially a strategic play by Stripe (with the smokescreen of SCA-compliance + Apple Pay support) to become more of a user-facing online "wallet", rather than just a behind-the-scenes payment processor.

If you remember the previous version, your customers used their saved card within Checkout. The new version of Checkout lets your customers use whatever payment method is easiest for them, and wherever it is. That's why we're big fans of things like Apple Pay (some have seen a conversion increase of 250%!), local bank payments in Europe, or even saved cards in Chrome (rolling out now).

From its inception, Checkout was designed to be the fastest way to accept payments, and I think it's now faster (and even faster for customers). You can just drop in a single line of code—and that code doesn't have to be server-side. :)

But isn't that what you just described? Saving your payment details to Stripe (as opposed to just entering your card details like a standard payment processor). Stripe is now essentially a wallet where you store your payment details.

Was it a necessary change to push users out to Stripe to save their payment info? What differentiates that from what was there previously. Was it that the CC info was stored per-domain, rather than per customer across all sites?

To be clear, I think it could be an improvement for a lot of cases - just potentially not mine in particular!

> Checkout was designed to be the fastest way to accept payments, and I think it's now faster

Here's a pretty common scenario that definitely just got more complex to implement: dynamic pricing + instant fulfilment (i.e. selling digital goods online).

So that instantly rules out the "No server-side code" approach. Here's what had to be done in the old version:

1. Import checkout.js

2. User clicks pay + fills out details on Merchant site

3. Merchant js makes a call to Merchant server with Stripe token

4. Merchant server calls Stripe to charge the token

Now:

1. Import checkout.js

2. User clicks pay

3. User has to wait for loading spinner while a Stripe session is generated on the Merchant backend and passed to checkout.js

4. User is pushed out to Stripe website to pay + fills out details

5. Stripe backend calls Merchant webhook

6. Customer redirected to Merchant

7. Merchant server must check with Stripe to see if session was completed and customer has successful purchase.

Overall - that's a more complicated flow for the Merchant to implement, with more room for things to go wrong.

And it's not technically true that the flow will always be faster for users - if the customer had CC details saved in the old version, the flow would have been faster for them (less async calls + no redirect to Stripe).

For a certain segment of Merchant, I think there are definite improvements - but for the one-person operation selling software - PayPal is now the easer to implement option.

The whole revelation of stripe was that if a customer was sitting there with a credit card, they just put it there into the same screen and it was done. It was the other crappy products that forced you out into a merchant gateway then back again

I'm never going to send retail customers out a payment gateway with someone else's brand/colors/html, mostly because it's just too confusing to introduce more concepts at that critical stage when they're about to actually make the payment

This is one of the concerns we have with SCA. By the nature of the additional authentication steps, they are necessarily hosted off-site in some situations. Handing your customer off to some other service in the middle of your payment flow and hoping they make it back is the only choice you have. It seems likely that this will reduce conversions, just as anything else that lengthens or complicates the payment flow usually does. What we don’t really know yet is how much difference it will make in practice.

Is this a necessity though? Couldn't they just enter the 2FA code in the same manner that they enter their card details on the merchant site? i.e. After entering their card details, it will just prompt them for more info if necessary.

I don't think I've seen a unicorn get this much love from developers

Yes, dev love is a big part of what allowed Stripe to become stripe, but it's probably not a good indicator whether Strip is worth $1B or $10B or $35B.

Why doesn't Stripe want to become a public company?

It’s a question of whether you want to discount your own risk or hold it. IPOing allows you to price your risk and sell some of it off. But if you’re a long term investor there’s a good chance you value your risk higher than the market, which means you’ll lose money in the long term by selling it.

It also depends on your other investment opportunities. If you have other places to invest, then your money has a high time value and you’re paying more “interest”, so-to-speak, on the risk. If you don’t have anywhere better to park your money then the time value is very low and holding that risk is cheap.

There are other factors as well, like government limits on buying other assets, that could make a private investor want to hold.

If you do not need to raise money there are limited reasons to go public, however you have much stricter reporting requirements, and general things you cannot do anymore since you are publicly traded, not to mention hostile takeovers, etc. Dell's story is a great example why you want to go public / go back private.

https://www.forbes.com/sites/connieguglielmo/2013/10/30/you-...

Sure it does. You can't do an IPO in a day. A company starting the process now risks having the recession start before the IPO goes live.

From what I've seen Stripe mostly has customers that are selling non-essential services and luxury goods. They'd be far more likely to suffer during a recession than Visa. I mean, Visa does around 1,700 transactions per second on average [1] and handled over 2 trillion dollars in a single quarter last year [2]

[1] https://hackernoon.com/the-blockchain-scalability-problem-th...

[2] https://www.digitaltransactions.net/visa-surpasses-2-trillio...

My main question then is how do you create liquidity for employees? Unclear if these rounds include secondary offerings for employees.

An IPO would have been one way to fund it, but likely would have involved a lot of financial scrutiny along the way, which would probably distract them from the main point of raising the funds.

A bold move which will hopefully work out for them and not overvalue the company before they attempt to go public later on.

I feel this valuation is well-deserved. I rarely feel that way nowadays. This company will be around and still relevant a decade from now. I'd love to see them challenge the dinosaurs in the financial sector.

I dunno man.

- Goldman is profitable but the employees extract most of it via compensation.

- Goldman has to rewin their business every year. Very little recurring revenue and they are one recession from imploding.

- You can’t really compute valuation on a very small investment. It’s not like the entire float is trading, and the small investment (relative to valuation) can have all kinds of liquidity preferences and special rights.

EDIT: wanted to mention that my impression is that they're a great company, just not worth $35B.

Haven't they weathered a fair few recessions already?

Stripe is the better product.

In the private markets "valuation" is a term that just means "someone bought a couple shares at this arbitrary price, here are the value of the other millions of shares at that same arbitrary price". Although the effects on all shareholder's balance sheets are real and useful, it is just broadcasted for marketing and hype.

In the public markets "marketcap" is the same term.

And finally, older public companies have low price to equity ratios because the hype has fizzled and they are predictable. It doesn't mean anything. Its not enough inputs alone for you to decide what the rest of the market will do.

They're at $25b.

How is $35b justified?

Once, my co-founder @Ilan Abehassera sent me a link to an article about Stripe on Techcrunch:

I signed up to Stripe, within minutes I was able to charge my own credit card through a CURL bash call, everything was clear, recurring payment perfectly handled, discount, etc etc. And this was at the very beginning of Stripe. Then I had to come up with why we should quickly switch from Paypal to Stripe.

Anyway, very good memoery, you definitely set the standard for how an API should be designed and I can't thank you enough for that!

I'm excited to see what the future holds for them.

(BTW, if you didn't see, we have a $59 device too. We're also working on supporting more.)

You could have a test account in less than an hour, and be ready to process real transactions in less than a week.

Stripe has plenty of competition, most of which have been around longer. You could argue that Stripe have a better API and that certainly has value.

Panama, Central America. I signed up for the email notification - years ago :)

Congrats and best of luck!

How's that possible? At this valuation they aren't looking at acquisition, right? VC aren't investing to the tune of $250mm (in this round alone) without an exit strategy, right?

What exit strategy if not IPO?

I have no plans to buy ice cream, but that doesn't mean I'll never buy ice cream. In fact, it's highly likely I will buy ice cream at some point.

It seems that people are more interested in cornering markets than in creating exciting new things. The valuation doesn't surprise me because that's how you corner markets, by first building a huge pile of money.

They don't need to tap public markets to raise money. And investors are likely OK holding off on liquidity if the valuation continues to rise.

Going public typically requires a significant amount of effort across the company, which can reduce focus on other initiatives key to growing the business.

It's not necessarily the same price you'd get on the public markets, but it can help give employees some liquidity.

If their fundamentals growth slowed to rates resembling the regular market, then sure, but as is, all a company with that growth rate might need is let tenured employees add, say 5% of their equity to the round so they can get a bit of liquidity to keep them quiet.

I'd rather take 2x whatever today than 0x nothing when the company folds tomorrow/in a month/in 5 years never having gone public.

This makes total sense. Stripe is driving the example for OSS for all countries to follow.

Thank you Stripe Co-founders. I appreciate your work and effort to bring GH where it is today.

There is a paywall link for more details. I'm curious to know what they are looking to challenge (especially given the rave reviews that Stripe gets here at HN)

Source?

https://www.jotform.com/blog/is-stripe-psd2-compliant/

Linda Scott of Silicon Dales in the U.K. uses Stripe and isn’t surprised that the payment processor is in compliance. “We have found Stripe to be proactive and open around legislative changes.”

https://www.paymentssource.com/news/stripes-next-step-is-bui...

Stripe hasn't exactly been in the news for lawsuits or controversy, unlike AirBnB.

You’ve provided articles that Stripe is compliant, which is fine, but nothing there indicates that Airbnb isn’t compliant.

What regulations specifically is Airbnb breaking that Stripe isn’t?

https://www.wired.com/story/inside-airbnbs-guerrilla-war-aga...

https://www.epi.org/publication/the-economic-costs-and-benef...

Second link: Still not in non-compliance with regulation, this is a story about lobbying.

Third link: Still not breaking any current regulations, it's about lawmakers considering regulating the business in the future.

Still looks like Airbnb is compliant with current regulations. Same as Stripe.

However, I will move the goalposts to rephrase my original point- AirBnB appears to operate in an environment that has more regulatory challenges, especially new ones, than Stripe, which operates in banking, which while regulations-heavy, which doesn't seem to be moving at nearly the same clip. And so my original point about AirBnB's problems still holds- the consequences of dealing with more lawsuits and having to spend more on lobbying.