Yep, all webhooks still sent as normal.
17,202 karma · joined February 19, 2007
I'm one of Stripe's cofounders.
While there are lots of antecedents (this is, after all, just a checkout page with a URL), and even though this was substantially inspired by the growth of the no-code ecosystem[0], the thing that's interesting to me about the payment link "space" is that it's a use case that really took off in other markets first -- Nigeria, India, Philippines, etc. I suspect that staying abreast of important new patterns emerging outside US/Europe will become more important for many businesses in the years ahead... there are a lot of legacy assumptions being questioned.
And feedback very welcome on our Payment Links product itself!
[0] We were excited to have Ben Tossell, one of the original no-coders, as one of our beta users: https://twitter.com/bentossell/status/1397246339898093568
- In large part based on prior feedback from HN users, we're giving all existing users free usage until January 2024.
- Our starter tier will yield free usage indefinitely for >95% of users.
They stopped publishing WM1NS, the weekly, non-seasonally adjusted version.
They still publish https://fred.stlouisfed.org/series/M1SL, the monthly, seasonally adjusted version.
One could perhaps hold a theory about how the seasonal adjustment (or monthly smoothing?) occlude some important dynamics. But the headline as-written ("Fed has stopped publishing the M1 money stock data") is not true.
I bring this up just to make clear that we do care a lot about every single problem like this.
I'm actually not sure. I'll check with the team. (The timing of the survey was coincidental, though -- we've been working on making our Billing pricing consistent since the start of the year.)
> To be honest, none of the new Billing features are relevant to us. We'd much rather have new features gated, like customer portal is, than paying 0.5% for features we never intend to use.
We seriously considered that. It gets pretty complicated (and error prone), though, with the number of different code paths that have to be maintained. The fact that such a large fraction of customers we reached out to directly were willing to pay for a more full-featured Billing (mostly on the basis of competitors being significantly more expensive) made us eventually conclude that it wasn't worth the complexity of having two adjacent versions of the product.
There's obviously heterogeneity, though, and we'll be as reasonable as possible. If this would be really disruptive for your business, or if you need more time to plan a migration (if you don't think Billing makes sense for you), or something like that, I'd be happy to connect you with the team -- we could extend your current pricing through the end of 2021.
While this is true on some level, the challenge is that we'd have to set pricing at an inefficient point (i.e. we'd end up charging more than some businesses can afford to pay and less than others are willing to pay). If we charged $1/sub/mo (say), $5/mo subscriptions would be prohibitively expensive. At the other extreme, if we charged $0.02/sub/mo per month, it just wouldn't make sense to invest as much in improving the product, which would indirectly hurt businesses by depriving them of a counterfactual product that they'd like to be able to buy. Pricing is obviously always an exercise in trying to find a reasonable trade-off between simplicity / optimality and this is our best effort.
(Our actual thinking was that we'd iterate on the product for a few years until we were confident it was good and worth paying for -- with both large and small companies using and paying for it -- and then revisit.)
Hi folks -- as Edwin points out elsewhere in the thread, the article title isn't accurate. (I'll update or delete my comment if it's fixed.)
[Update: it was changed. It used to read "Stripe is now charging 0.5% more for recurring charges."]
You can happily make recurring charges yourself and no additional fees are incurred. Lots of Stripe customers do this and we don't charge anything extra for it.
If you decide to use Stripe Billing, which is a separate product, we charge for that. Stripe Billing's pricing hasn't changed in a few years. What's changing is that we're ending the several-year grace period where we didn't charge anything for Stripe Billing for businesses who started to use this functionality before 2018.
Charging for Billing helps us fund a lot more investment in it -- we've gone from very basic cron-like functionality to a pretty full-featured subscriptions management tool. (You can read more at https://stripe.com/billing.) Billing is now sophisticated enough that companies like Slack and Atlassian are using and paying for it. We've built things like "Smart Dunning" (which improves revenue recovery for failed charges by about 14%), better analytics, international payment method and invoicing support, and a whole host of other features. There are now more than 30 people working on improving Billing.
Importantly, Stripe Billing is (and will remain) significantly cheaper than most of the other competitors in the space.
Absolutely. That is category 2!
(1) The practical reality that a lot of people will have a suboptimal experience until we (both "we Stripe" and "we the industry") figure out more scalable ways to assess people. We'll do the best we can to identify promising people but a lot of people will get something somewhat functionally equivalent to a form rejection. You could argue that this is merely a prioritization decision -- we could keep hiring recruiters until everyone could be individually assessed -- but doing so would require a recruiting team of comparable magnitude to the rest of the Stripe organization and so the current state is an unfortunate compromise given the current constraints and given the decision to have an open application form (which is, I think, on net better for everyone).
(2) Cases where people at Stripe mishandled the process. I know for a fact that some of the anecdotes shared in the thread are from many years ago, and I know that our process has improved since then (we have empirical data to this effect), but we're also acutely aware that we continue to make mistakes -- recruiting is a high-stakes and complex process with a lot of fallible moving parts. For whatever it's worth, we issue CSAT surveys to every candidate who interviews (about 6,000 onsite interviews in 2019), and track the results both at the aggregate Stripe level and at the individual recruiter level. And I get why some people here sound so annoyed -- what might be "another entry in a database" to a recruiter or hiring manager is "the future of my career" to someone on the other side. While it's always hard to know what to make of a set of anecdotes, and while our referral rate among Stripe employees is very high today, I'm nonetheless bothered by the number of cases shared here, and we're going to be digging in. (Specific anecdotes with more concrete dates or data are welcome at patrick@stripe.com.)
More broadly, Stripe now works with a long list of businesses that are processing more than $1B/year or more, and that list is growing quite quickly. Indeed, there are more enterprises using Stripe than Adyen, which is often cited as an ostensibly enterprise-focused competitor. Larger companies using Stripe include Amazon, Shopify, Instacart, and Peloton. (There's a longer list at https://stripe.com/customers). That's all to say: we're very invested in this enterprise thing.
If any enterprises you work with have had a bad experience, would welcome any details. patrick@stripe.com