pc

It varies based on the card type, country, and other things. We could expose all of that more directly but the trade-off there is obviously pricing complexity, which we'd like to avoid.

In our analysis in making this change, we saw that this simply makes little difference for the vast majority of businesses. For example, if you're processing $100k/year and refund 5% of your payments (which would be on the high end of normal), it works out to about $12/month.

While refund rate of course is not definitively coupled to the quality of a business, we do see across our portfolio that it is strongly correlated. Given a basket of possible fees (for example, higher fees on Amex, which most other providers have), we prefer the fees that, on the margin, are least consequential for the businesses that are doing the best job of serving their customers.

Having said all of that, none of our pricing is cast in stone, and we always genuinely appreciate feedback, including contrary views.

Yes, we will! (And, while we are trying to make sure we understand the impact of Covid-19 across our lending portfolio, we haven't stopped extending new loans.)

Hi Nick -- I'd love to have us dig in more here to understand this better. Could you email me? patrick@stripe.com.

[In brief, chargebacks/disputes work differently for PayPal payments as compared to credit card payments... I suspect that much of this is mostly a PayPal vs credit card difference. But I want to understand the details.]

Great feedback... thank you. In case it's useful, some context on them:

On (1), we started an FX team this year. (There are a lot of legal complexities here around how the funds move, who has title to what at which moment, and so on.) But we're investing significantly in improving it and it should get better soon. On (2), the core issue is card network pricing rules -- by design, they discriminate on the basis of where the business is located. We happily extend EU fees to all EU legal entities, however, and would be happy to work with you to set that up. On (3), refunds aren't free for Stripe, and we were previously in a position where businesses with a lot of refunds were being subsidized by those who didn't. We want to give this margin away more sensibly.

Still, all the issues you bring up are real and I'd like us to find better solutions.

> Just very high level for those of us who only know "they charge a flat fee and a percent which makes microtransactions hard".

That's pretty much the story :-). And so the questions are then whether we subsidize the transactions, batch them (as you say, though that makes refunds and statement descriptors tricky), get card networks to change their policies, or somehow shift how the payments are made (e.g. encouraging cheaper payment methods).

Good feedback -- thank you. We'll take a look.

Yeah, we don't like the current situation, and this is a topic of ongoing discussion. Credit card network fees make it tricky to do it well but we really want to find a way to make it work.

We've noticed a few things --

- Enterprises pivoting -- brands going direct-to-consumer, malls pivoting to online business models (seriously), and other things like that.

- SMBs going online: see this thread[0] from a French fruit seller, for example, or this thread[1] from a bar in Milwaukee. The restaurant down the street from where I used to live is now running a rapidly-growing online wine club.

- Totally new startups are getting started in response to new needs.

[0] https://twitter.com/FlorentSchmahl/status/125028359535832678...

[1] https://twitter.com/danimalnelson/status/1240004111669460992

Stripe cofounder here. This isn't really new -- it's an extension of our last round (https://www.cnbc.com/2019/09/19/fintech-start-up-stripe-notc...).

That said, we've seen a big spike in signups over the past few weeks. If any HN readers have integrated recently and have feedback, we're always eager to hear it. Feel free to email me at patrick@stripe.com and I'll route to the right team(s).

As always, thank you to the many HNers who are also active Stripe users!

Working on this!

The impact of Covid-19 on many businesses around the world is very sad.

That said, it's less clear to me that the medium-term impact will be pro-incumbent or pro-large company. Big incumbents tend to be less adaptable and to benefit from large fixed cost barriers to entry (e.g. real estate). We're seeing a lot of nimble small businesses migrate to online business models far faster than the behemoths they used to struggle to compete against.

We're still working hard on this. (We just expanded our beta in Bulgaria last week!)

We're focused on a few things --

- Staying secure, reliable, and available for our existing customers. Some businesses in Stripe are seeing huge surges in demand and others are seeing major shortfalls. In either case, we want to make sure we can that we can be relied on to provide flawless service.

- Keeping up with the surge of new customers. A lot of businesses are migrating online and many of the platforms we serve are also seeing significant spikes in signups. So, we're investing a lot of effort in making sure that we can scale effectively there and remove all unnecessary friction. (There's a very active project working on cleaning up our docs and improving the integration experience, for example.)

- Adding support for business models that were previously limited because of bank/card network restrictions. We just launched support for telemedicine last week.

- Figuring out ways to help businesses by enabling access to government programs (e.g. the PPP program in the US). These programs usually haven't thought much about the somewhat unique characteristics of online businesses. We're trying to help government officials understand what internet businesses need. (And, per the comment elsewhere in this thread, we're rolling out our first PPP loans this week.)

Fair :-). "A little" relative to market cap. But, yes, $600M is a staggering amount of money in absolute terms.

Yes!

:-). True.

We've been working with various government agencies behind-the-scenes and are about to pilot our first PPP loans. (Since so many banks have had troubles with the SBA application process, we want to make sure the process is robust and scaleable before deploying anything broadly.) Feel free to email brayden@stripe.com if you're interested in trying it out.

That's right; this isn't new. We just decided that it was prudent to extend the round a little given the economic uncertainty.

I've known him for more than ten years -- we first met when I was a student in college. In my experience, he's always been helpful, kind, and encouraging.

We're actually working on speeding up payouts, for free. They're currently faster than they've ever been and will continue to get faster.

> Stripe has all the power to prevent many forms of fraud and provides this as a service as long as you pay a premium for it in the form of Radar. You have to pay extra on top of the 2.9% + 30c per transaction to get this protection.

Radar's ML-based shield is free for all accounts on standard pricing. See https://stripe.com/pricing#radar-pricing. (We only charge if you want to set custom rules etc.)

Card network requests are comprised of fairly complex ISO 8583 messages. (https://en.wikipedia.org/wiki/ISO_8583.) We now have enough data across Stripe to implement an ML engine to optimize these requests on a per-issuing bank basis. As mentioned in original comment, this helps collect a lot more "free" revenue for our users.

Thank you! A lot still to do.

Yes, per [2], our US refund policies are roughly the same.

You're right! (Though I am.) I edited the comment.

(I'm one of Stripe's cofounders.)

Thanks for the candid feedback. A few quick thoughts --

- This is not a new policy change -- it's been our pricing for all new users since 2017. (The news is that we're now applying this pricing to Stripe's older users, in part as a response to some price increases that the card networks are making.)

- Our policy on refunds is pretty much the same as Braintree's.

- We've added a lot of new functionality to Stripe since we launched in 2011. (The Stripe that launched back then did not support any non-card payment methods, non-USD currencies, non-US users, etc.) The vast majority of new features come with no new fees -- the Stripe package just gets better. For improvements that don't represent discrete new features, the changes can be non-obvious. Our goal is to quietly optimize things so that Stripe integrations continually get better without your code having to change. For example, Radar is far more effective at preventing fraud and chargebacks than it's ever been. Or, last year, we built an ML engine to automatically optimize the bitfields of card network requests. This has already generated an incremental $1 billion of revenue for Stripe users (with no additional cost).

- Testing production flows with fake numbers is tricky. (How should these charges show up for reporting purposes? If we exclude them, that introduces another discrepancy. If we include them, that means you have to then handle the downstream cash discrepancy.) It's not an intrinsically unsolvable problem but we have not yet seen a clean solution that we feel good about. As other commenters point out, making sure they're sufficiently secure is also a challenge.

- While we're proud of our books, I can assure you that the ratio of people working on improving our payments stack to publishing is about 1000:1.

All that said, it's helpful to hear how it seems from your standpoint. We're acutely aware of how much Stripe has yet to do/build. We'll continue to work hard, and I hope we can support your business for many years to come.

Yes, that the name may be misleading is a fair point. Even though it was (I think) called the Alaska Highway from the beginning, I changed the text to say "military roadway" -- hopefully this helps to clarify. Thanks for pointing this out!

That’s a good one!

Hm, thank you. I checked a few sources when adding this one but will go back and double-check the specifics/qualifiers.

Wikipedia, incidentally, seems to support the shorter timeline:

“The official start of construction took place on March 8, 1942, after hundreds of pieces of construction equipment were moved on priority trains by the Northern Alberta Railways to the northeastern part of British Columbia near Mile 0 at Dawson Creek. Construction accelerated through the spring as the winter weather faded away and crews were able to work from both the northern and southern ends; they were spurred on after reports of the Japanese invasion of Kiska Island and Attu Island in the Aleutians. During construction the road was nicknamed the "oil can highway" by the work crews due to the large number of discarded oil cans and fuel drums that marked the road's progress.[9] On September 24, 1942, crews from both directions met at Mile 588 at what became named Contact Creek,[10] at the British Columbia-Yukon border at the 60th parallel; the entire route was completed October 28, 1942, with the northern linkup at Mile 1202, Beaver Creek, and the highway was dedicated on November 20, 1942, at Soldier's Summit.”

> What I was most struck by in the conversation is that Zuck is actually doing some of the things Cowen advocates - policy experimentation, taking on long-term projects with uncertain payoffs, etc. at CZI.

I'm a big admirer of what Mark is doing with CZI (which is part of why Cowen/I agreed to the interview). Stripe is still a private company, but maybe I'll be able to intervene more directly over time. If I do, having CZI as precedent will be very helpful.