pc

In these matters, I always try to keep in mind that technologies aren't themselves disruptive; customer choices are. It'll be interesting to see what customers choose in the years to come.

Does that imply that some day users would be able to pay using Tempo?

I don't think that customers or businesses should see Tempo very much. In the success case, Tempo is a platform like SWIFT or ACH that others employ behind the scenes to orchestrate transactions. "Decentralized, internet-scale SWIFT" isn't exactly the right analogy (there are clearly lots of differences), but it's not totally wrong either.

Why are businesses finding crypto easier/faster/better?

Yeah, I think this is the natural follow-up question. The answer differs a bit based on the use-case, but there are a few common reasons:

* Instant on-chain transfers avoiding trapped liquidity. If you're transferring money from financial institution A to institution B, and the transfer takes a day, you're either slowed a day in taking the next step or you have to somehow cover that float. Depending on your movements and their predictability, that can require big buffers.

* Fees that are lower than cards. Card payments are instant, which is often valuable (and superior to many bank transfers), but card transactions are also expensive relative to stablecoins. (And while card authorization is instant, settlement is not.)

* Reliability. This sounds funny, but, when sending money between countries, there are many more manual processes involved at the associated financial institutions than one might think. Money is frequently just... lost, and humans are required to hunt for it. (We see this all the time at Stripe.) Crypto is punishing if you make a mistake, but, if you do things correctly, reliability is all-but guaranteed.

* Fewer currency conversions. Wholesale FX for major currencies is very cheap, but minor currencies can have bigger spreads, and the actual fee incurred by a regular customer (e.g. with their bank) can be significant. Stablecoins often make it possible to skip conversions that would otherwise happen.

* Access to USD-based functionality. The US is the world's most sophisticated financial services market. Having a stablecoin means "having an on-chain asset", but it also typically means "having a USD asset", and a lot of major parts of the ecosystem (e.g. US equities and credit markets) primarily, or only, deal with US dollars.

Acknowledging the obvious, a reflexive answer frequently invoked here is "it's regulatory arbitrage", but I think this is some combination of misguided and incurious as an explanation. First, stablecoins are now formally regulated in the US (with the GENIUS Act) and in Europe (under MiCA), so their use is now very explicitly regulated. Secondly, it implicitly assumes that the only reason one would seek an alternative to the traditional ways of doing things is because someone is doing something illegitimate. I think this usually indicates a lack of understanding of the challenges, complexities, and costs associated with high-volume cross-border money movement. Indeed, and somewhat ironically given the claim, one of Bridge's large customers is the US government.

There are lots of crypto skeptics on HN (and we ourselves were disappointed with crypto's payments utility for much of the past decade), so it might be interesting to share what changed our mind over the past couple of years: we started to notice a lot of real-world businesses finding utility in stablecoins. For example, Bridge (a stablecoin orchestration platform that Stripe acquired) is used by SpaceX for managing money in long-tail markets. Another big customer, DolarApp, is providing banking services to customers in Latin America. We're currently adding stablecoin functionality to the Stripe dashboard, and the first user is an Argentinian bike importer that finds transacting with their suppliers to be challenging.

Importantly, none of these businesses are using crypto because it's crypto or for any speculative benefit. They're performing real-world financial activity, and they've found that crypto (via stablecoins) is easier/faster/better than the status quo ante.

Not a lack of commitment -- we just don't want to pre-announce the specifics.

We will definitely keep it.

There's a lot of online fraud. We invest a ton in Radar, our payment surfaces, etc., to keep this as invisible as possible to businesses. (We don't always succeed, of course. But, despite the growing sophistication of the fraudsters themselves, we do generally get better every year.)

I knew Kyle in college. He was extremely smart, kind, patient, and friendly. (He was a few years ahead of me; I was a random Irish freshman who had just shown up.) Looking back, he's one of the people who inspired me to get into startups. While we never ended up working together, it wasn't for lack of trying on my side -- everyone said he was phenomenal, and I tried hard to persuade him to join Stripe in the early days.

That comment made my day -- thanks :-)

It's kind of you to say that, and people at Stripe certainly try very hard, but there's plenty that's broken or that we're trying to figure out at scale... I don't think those claims are true.

I genuinely don't know why there are fewer instances today, and the question at the bottom is literal rather than rhetorical. (I don't even know whether there are fewer instances today -- maybe they're just happening in less legible domains, or something.)

That said, I'm somewhat skeptical of the safety argument, which I often hear. For example, 60 workers were apparently killed during the construction of the World Trade Center[0] -- 4x more deaths than occurred during the construction of the Empire State Building. Nor is it a priori clear to me that safety and speed would necessarily be in opposition -- maybe better planning causes both more safety and more speed, for example. I'd certainly be interested in a more comprehensive investigation of this question.

I'm also somewhat doubtful of cost-of-labour explanations. Wouldn't it be rational for some organizations to pay a lot more to get people to work longer hours if that's all that's going on? (It would almost certainly be cheaper to do that than to have the project take twice as long in total.) And why did many of the instances enumerated on the page happen in relatively high cost (for the time) locations, like New York, DC, and San Francisco, rather than in cheaper places?

I do believe that state/military intervention clearly plays some role in a few, but there are certainly plenty of examples of remarkably slow military projects, and many of the projects on the page have nothing to do with the military. (Empire State Building, Golden Gate Bridge, Boeing 747, NYC Subway.)

So, I haven't found a satisfying explanation, and I'd be curious to read other analyses or diagnoses.

[0] https://en.wikipedia.org/wiki/Construction_of_the_World_Trad...

Yep. Until very recently, we weren't able to support businesses selling crypto. (The regulatory details are complex.) We're now rolling out support and this page is basically about that change.

I genuinely have no idea what situation you’re talking about (not saying we didn’t screw up, though — I preemptively apologize assuming we did!), and a bunch of the narrow claims above aren’t true (we aren’t YC LPs, Sequoia made its own decisions without any suggestions from us on Finix, etc.), but I really would appreciate an email so I can figure out what happened.

I’m trying to not overstate my certainty. I have no idea what situation OP could be describing, and I have no recollection of anything along those lines, but I don’t want to definitively state that nothing like it happened over our decade of operation without knowing more about what’s actually being alleged.

We obviously never intentionally ghost companies, “mine them for information”, etc. The ecosystem is small and we wouldn’t be able to invest in and acquire companies if we didn’t have a reputation for good behavior. (And we’ve invested in dozens.) But maybe some communication got dropped in some particular case or something? I don’t know.

I don’t think some of the claims in this comment are true or in good faith. (We obviously don’t control HN or YC or journalists. If or when my comments on HN are ever ranked highly, it’s because they’re upvoted. The internal claims about Stripe are also inconsistent with the data around things like retention. Etc.)

All of that said, I’d appreciate hearing from any founders who feel mistreated as part of an acquisition process. We make a fairly significant number of acquisitions and have never heard this directly before.

I'm sorry; that's bad. Can you email me with details so that we can investigate what happened? (patrick@stripe.com; others welcome to do so too.)

More than 10,000 people have interviewed at Stripe so far this year, so "several sigma bad" still happens to an unfortunate number of people. That said, we want those who interact with Stripe to come away having been treated professionally and respectfully, and our recruiting team cares about fixing our process failures. On behalf of Stripe, I apologize.

Yes, well said. Heroku was an inspirational product when we were starting out.

If money could buy taste, a lot of the world would look better than it does. Culture isn’t a function of dollars, and we’re very lucky to have many people at Stripe who just really, really want to do great work.

(There is proof that significant financial resources aren't needed to do great work in a lot of personal websites. Most recent example I came across: https://bruno-simon.com.)

I would estimate that roughly 99%–99.9% of cases get resolved without anything on HN. (Per the GP comment, things have already improved 50% since earlier this year and will, I think, improve tenfold by the end of the year.)

Right. It's a hard problem. That said, we think we can get better.

Yeah, good question. First, we aren’t trying to calculate the absolute rate, just relative changes. (The absolute rate would be nice to know but it’s not needed to know whether we’re getting better or worse.) Methodologically, we sample/scrutinize rejections manually and also look at the occurrence of discovered false rejections. But you’re right that there could be some dark matter that we never become aware of.

You don’t have to contact me in particular — you can get in touch with anyone at Stripe. (Or even DM Stripe on Twitter.)

With regard to the last part of your comment — absolutely. This is a final recourse when the system breaks, not a part of the system that we hope you ever have to use.

We definitely still offer live chat support!

My email address is public (patrick@stripe.com). Lots of other people at Stripe also have public email addresses. (Just to be super clear, it’s a bug that you’d have to do this, and I’m sorry about the trouble! But when mistakes happen we do want to have a way to know so that we can fix things.)

(Stripe cofounder.)

Ugh, apologies. Something very clearly went wrong here and we’re already investigating.

Zooming out, a few broader comments:

* Unlike most services, Stripe can easily lose very large amounts of money on individual accounts, and thousands of people try to do so every day. We are de facto running a big bug bounty/incentive program for evading our fraudulent user detection systems.

* Errors like these happen, which we hate, and we take every single false rejection that we discover seriously, knowing that there’s another founder at the other end of the line. We try to make it easy to get in touch with the humans at Stripe, me included, to maximize the number that we discover and the speed with which we get to remedy them.

* When these mistaken rejections happen, it’s usually because the business (inadvertently) clusters strongly with behavior that fraudulent users tend to engage in. Seeking to cloak spending and using virtual cards to mask activity is a common fraudulent pattern. Of course, there are very legitimate reasons to want to do this too (as this case demonstrates).

* We actually have an ongoing project to reduce the occurrence of these mistaken rejections by 90% by the end of this year. I think we’ll succeed at it. (They’re already down 50% since earlier this year.)

Appreciate your feedback. On the first point, limitations on what the secret key can access are coming very soon.

A concrete suggestion: make it possible for businesses to choose whether they have access the raw data, and expose the choice to the end user in the Stripe Identity flow. Ideally, businesses that want the raw data would be subject to security compliance requirements. This is an opportunity for Stripe to be a leader in setting high standards on how this type of data should be handled.

Yes, per GP comment, I think this is a good idea. I suspect we'll do it.

(Stripe cofounder.)

Considering that Stripe was originally known for letting websites accept credit card payments without seeing your credit card number, one might assume that Stripe Identity only allows websites to see the verification result, and not your selfies and scans of your identity documents.

A few points:

- Fundamentally, Identity makes it possible to choose how much of this data traverses / is stored on your servers, just as Stripe did with card numbers.

- There's a basic difference between card numbers and identity verification. With card numbers, you (generally) don't really care about the number -- you just want the payment. With ID verification, however, many businesses have good reason to want more than just the verification result. For example, they are often subject to compliance requirements that mandate that they themselves possess or have access to the raw information. They may need or wish to perform additional checks on their side. Etc.

- The relevant UI in Identity is deliberately very clear on this points in order to avoid the assumption you're stating. The flow explicitly says "Stripe and [Business] may each use your data." Even though an end user might consider it suboptimal for the business to have their data, we still view it as an improvement to the usual status quo, where this data is frequently stored in very ad hoc fashion and without rigorous security protections.

- While many of the businesses initially building on Identity wanted access to the raw information, it may well make sense for us to enable them to restrict themselves in the future. In this world, Stripe could tell their customers that the business doesn't have access to the raw details. (This might even make sense for Stripe payments in the future.) As a philosophical matter, we consider ourselves to serve the business, which means that limiting access to what we consider to be the business's own information feels a bit strange. That said, it might sometimes be in the interests of the business to allow them to limit themselves in this fashion (especially as Stripe's brand recognition among consumers grows).

- There's a separate concern about compromise of the business's credentials leading to inadvertent disclosure of this information (a situation analogous to an S3 bucket key getting leaked). This is of general concern to us in lots of situations, not just with Identity. We have some new functionality on the way here.

It's actually pretty cool (IMO; I'm biased). Drop-in browser-based user authentication that:

* Uses various sophisticated heuristics to detect real vs fake IDs.

* Matches the ID to the human face.

* Detects whether the human face is live or not.

* Dynamically requests more or less information depending on the confidence level.

It also gets better over time based on the attacks and fraud attempts that Stripe itself sees.

There's a lot of cool stuff that uses Paystack on Twitter, e.g.: https://twitter.com/spokenword_lag/status/139677392471373005.... You can search for paystack.com/pay.

That is approximately what we do. (And then we remember any explicit selection that's made.)

Shopify is aggressively and successfully expanding their e-commerce product offering... if you're running a business that sells physical goods, the checkout is one of the simplest parts of the whole thing, and I don't think this will matter either way to them.