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.
A few months back, I was hit with an attack from a spammer, who managed to place a few hundred orders through my Stripe checkout. It seems they were attempting to place thousands of orders, and looking for functional credit card information.
When I reached out to support, they acknowledged that this was a type of attack, and I needed to manually go back and unapprove all of these purchases coming from a single IP address, that wasn't being stopped by Stripe.
Would I still need to pay to do all those fraudulent charge backs? If so, that single attack would have cost me hundreds of dollars out of pocket.
I'm sorry that happened to you. Could you email me at this handle at stripe.com? I want to look into why we didn’t auto-detect that surge in suspicious transactions.
We’re here to support startups. If you ever have a unique circumstance, write us; we’ll try to be reasonable, in the same fashion that your hosting provider will try to be reasonable if an engineer e.g. fumble fingers a deploy and briefly turns on a larger fleet of servers than they intended.
(It's worth noting, for precision's sake, that a refund is not a chargeback. Chargebacks are when the person who actually owns the credit card calls the bank to complain; they're strictly worse for all parties than simple refunds.)
While this is an interesting response, it strictly does not the answer the poster’s question. Would they be liable for the fees for an attack like this?
It's difficult for me to predict our response in every possible hypothetical circumstance, so I'm promising what I feel we can actually promise: a human who cares about your success will review the circumstances and make a judgment call.
Translation: Come to HN with your problems and you'll get the VIP treatment while there's a spotlight on the company.
Attempting to find an answer as an outsider lead me to this PR release from last year: https://stripe.com/newsroom/news/chargeback-protection < It makes me assume that if the merchant wasn't paying that extra fee they are going to be slammed.
patio11 gave a nonanswer, which is hardly transparent.
> a human who cares about your success
Regarding honesty, if Stripe "cares about your success", Stripe would relinquish processing fees for all refunded transactions (regardless of whether they are fraudulent) just like Square and Amazon Pay do.
The fee is only $1 when the transaction amount is $24.14. The fee is $29.30 for a $1,000 transaction. For industries with lower margins or higher refund rates, Stripe's refusal to return the fee on refunded transactions is a problem. Regardless, Stripe's nickel-and-diming is not something to be grateful for in any industry when there are competitors that don't do the same.
Feel free to substitue $29.30, or even $1,000 as values that should not sink one's software business.
Considering how often you're going to be issuing refunds (I tend to do maybe 2 or 3 in a big month), I'd be surprised if we hadn't each spent more in billable hours typing into this text box than we will in Stripe refund fees over the next four years.
I organise tech conferences as part of a non-profit.
If I've already started selling tickets, and had to postpone the event because of something like COVID-19, I'd be looking at paying Stripe something like $3,500 in payment processing fees (it's 3.4%+$0.50 here; and assuming $100k in ticket revenue) for the privilege of refunding my attendees.
It's not an amount that would sink our non-profit, but the full fee is also not something that we should have to pay, just because we want to do right by our attendees.
That's the un-charitable interpretation. When dealing with complex problems with no clear cut analytical solution putting a real human in the loop who can make a judgement call instead of playing back a prewritten script is often the optimal solution.
Traditionally there's been 2 customer service lines: regular and VIP.
Now there's 3: regular, VIP, and social media apology tour. And it'd sure be nice if these companies had decent policies to begin with... But that's the problem, isn't it?
I do get that. But many of these stories we hear have to do with consistent customers with a stable payment history and a good relationship. Something goes terribly wrong, helpdesk bombs it, and then what? Well, twitter, HN, reddit.
All I know is the current situation, well, stinks.
In the case of Google we have a supertanker full of anecdotes of them ignoring customers with problems. In the case of Stripe we have no evidence their customer service is non existent outside social media flareups. To the contrary,they seem to have a pretty good reputation.
So no, not like google at all. That somebody gets a response from a VP on hacker news is not evidence they will get no response outside hacker news.
We were attacked by someone using different IP addresses testing out credit cards. Stripe caught a lot of these but surprisingly it seemed several went through that we had to refund & pay the transaction fee for. A lot of these didn't even require the CVC check it seemed.
We were able to get fairly good support, 100 times better than most places I deal with.
Unfortunately we had to switch to Radar for Teams to put in fairly basic checks such as making sure CVC verification happens before accepting the card. This costs a bit extra per transaction.
At the end of the day we were able to get it solved. Stripe puts plenty of human resources on helping & they have fairly good documentation. It does really stink that we need to purchase Radar for Teams just to add a few basic rules in place to prevent scammers like this. We lost around $100 that could have went to helping families whose kids have cancer which always sucks. We also had to implement an "invisible" Google Captcha which I wasn't a fan of. This could have been a lot worse though which is what troubled me the most.
Just to be clear in this example a chargeback wouldn't have happened. A chargeback can only happen if there was a valid credit card that made a purchase that requested a reversal of the money transfer.
This trend is awful for businesses. In October 2019, PayPal (which owns Braintree) also started to retain their 2.9% + $0.30 processing fee from refunded transactions. Stripe is now in the same class as PayPal.
Square still refunds processing fees to merchants for refunded transactions. They have the same fee (2.9% + $0.30) for online transactions, and a lower fee (2.6% + $0.10) for in-person transactions with their card reader.
We recently made the decision as a SaaS company to switch from a subscription management platform I won't name to Stripe. The process has not been without a couple bumps along the way, but frankly working with Stripe is similar to that scene from Lord of the Rings: The Two Towers when Gandalf tells Theoden to "Breathe the free air again, my friend."
Please continue to do what you're doing in this space. Payments are such a complex beast and it's refreshing to work with a company that works so hard to abstract that complexity.
My personal experience is that all subscription management platforms fall over when you're doing enterprise SaaS. At a certain level (because literally your most valuable customers insist), you have to deal with credit cards, ACH, wire transfers, and checks. On top of that: custom plans, all sorts of weird line items and discounts, prepays, etc. And then you usually want reporting in multiple different formats (e.g. for the accountants/IRS, for company leadership)... it gets messy really quickly and I haven't seen platform that can handle the mess. Probably a startup in there, but not one I'd like to build.
In house solutions. Once a company becomes large enough where paying a company like Stripe's fees becomes larger than hiring enough people to create and maintain an internal billing system, then you do it yourself.
This is something that companies that are near public company size do since the amount of work required to meet payment regulations alone, not to mention all of the infrastructure to support things like subscriptions is staggering.
This is why there aren't many solutions to this problem. It's a very difficult problem.
I have migrated 2 companies away from internal billing systems (one went to Stripe and the other went to Chargify). The amount of hacks that went into maintaining these internal systems was shocking. One company literally devised its own currency to deal with the complexity.
Managing and developing your own billing system is a almost always a bad idea, no matter how big your company is.
There is a high likelihood that you will end up running a business within a business if you go that route.
Yea it depends on the technological competencies of the company. I have a friend who works at a company who implemented their own, and they seem to be doing fine, but you hit the nail on the head saying
> you will end up running a business within a business if you go that route.
Take a look at open-source solutions, specifically Kill Bill [1] (disclaimer, I'm a core contributor)
It provides a subscription management platform with all the features you would expect out of the box (recurring billing, plans management, dunning, notifications, etc.), but with also a plugin framework where you can implement your own billing logic.
You can continue to use processors like Stripe to handle the recurring charges (and compliance associated with storing cards), but they are only used to charge the payment methods. The mess that OP mentions stays in-house, where you have tighter control over it.
I was hit by this charge too, when doing some test purchases.
Support said "use test mode for that", but test mode is NOT adequate to fully test a live production system. The keys are different, the card numbers are different... it should work the same but may not.
With this policy change, there's no way to test a live production system without paying Stripe all the money it would have gotten if the charge were real.
And that's just a minor case. What happens if a huge fraudulent charge is made and we undo it before shipping product? We potentially get hit with huge fees, for no particular reason: Stripe doesn't have to pay those fees to the processor if there's a refund (Stripe cofounder, please correct me if I'm wrong).
That being the case, this is pure gouging and nothing else.
And gouging because others gouge is not a good reason or excuse. Be better, don't stoop to their level.
> Our policy on refunds is pretty much the same as Braintree's.
I'm seeing something different on (my local) Braintree site [1][2]:
> All processing fees, except the per transaction fee, are returned for full refunds. For partial refunds, all processing fees are returned at a prorated amount, but the transaction fee is not returned.
Thanks for replying on this thread, PC. I'm curious to get your take on how this plays out for customers with large average transaction values ($500+)?
Stripe's cost to process and refund a payment, while not zero, is generally flat (card networks refund interchange fees, Stripe only has to cover the minimal cost of running the software to process the transaction, which is the same for all transaction sizes). Shouldn't the retained fees be flat and not a percentage?
Slightly amusing story about “testing” payment flows in production: In Germany we have payment providers like Sofortüberweisung that ask you for your online banking credentials and then access your online banking via browser orchestration to initiate a transfer (I know it’s an utterly horrible idea from a privacy and security point of view).
What they didn’t know initially was that some banks provide test accounts to customers where you can simulate transfers without transferring any money, and where you can simply enter your desired bank account balance (now that would be a killer feature for real online banking). Some people figured this out and used those fake accounts to make fraudulent orders.
So if you offer such testing card numbers you should make sure your customers need a specific workflow to handle them (e.g. by returning a special error response code that can be distinguished from a normal error).
The question you can answer about this change: Does stripe get interchangeable refunded from the card networks/banks on a refunded transaction?
Also any of the big processors you can negotiate the refund of interchange just like you can negotiate interchange plus pricing instead of blended which I assume stripe even offers to big merchants like Shopify. I do wonder if Shopify drops stripe since the change has pissed off all their $100mm+ merchants and they may lose a few. There isn’t a long term contract in place just a 6 month notice to quit.
Does this keeping of fee also apply to voided non-captured payments?
When PayPal pulled this change (yes, imo this is a scummy thing to do to merchants), I changed my PayPal flow only to authorize prior to doing the charge so that this refund fee could be avoided.
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.
Businesses invest in product development and marketing to bring a customer to them. The customer is convinced of the value of the thing they want to buy and puts in their credit card number. Sometimes it doesn't work, for example because a poorly understood interaction of systems at their bank decides the charge is likely fraudulent. (Ask me about how a particular US bank has caught 17 of the last 0 times a fraudster in Japan used my credit card to purchase software.)
Some percentage of these customers retry, perhaps with another card, and eventually succeed in buying the thing they want to buy. Some don't, and the business loses the revenue that a customer was already happy to give them.
Improving authorization rates (the industry jargon for that) recovers that revenue, for ~free (your product/advertising/etc spend to attract the customer is the same whether they successfully complete the purchase or not).
Appreciate the explanation. We actually noticed a huge improvement since last summer with charges made with Stripe.
Still, we lost a few thousands €€ in these years because of customers' banks rejecting our transactions. I hope that one day this problem will be gone.
We share that desire, and are iterating on this a thousandth of a basis point at a time, because at the scale of the internet it really matters. (Anyone want to work on this? Super fun stuff. https://stripe.com/jobs/listing/backend-api-engineer-acquiri... You get to e.g. build systems which blackbox reverse engineer the behavior of financial institutions worldwide, in some cases getting to explain the behavior of their systems to them directly because the people who built them retired years ago.)
No, this is infuriating, but we must not forget that they “built an ML engine to automatically optimize bla bla bla.” But really, pretense should be off. Stripe is nothing more than a PayPal clone. Even the refund policy is now perfectly cloned. Someone here said that the only way our discontent can be heard is for us to switch between platforms regularly. Right now, PayPal does not look so bad. Their API and documentation has also become pretty good. Of course, the better thing would be to just get a merchant account and drop all these middleman leeches. Apropos, don’t get me started on the AppStore were we only pay 30% for the privilege
PayPal does not look so bad. Their API and documentation has also become pretty good.
Documentation has gone form terrible to bad. API has gone from always terrible to appearing OK but will periodically destroy your happiness and productivity for a week. I would never voluntarily work with PayPal tech.
> I would never voluntarily work with PayPal tech.
Really, for your company's sake I hope what matters is not what you like, but that your company has a payment solution that does not stop working when Stripe freezes your account. Yeah, Stripe is not an iota better than PayPal when it comes to freezing accounts. The only sane thing to do is to have a backend system that at minimum can use both PayPal and Stripe. With such a system it should be easy to change between PayPal and Stripe and I suggest that we all shutdown the Stripe part to show our discontent.
"You should have noticed in 2017 when we started this process to begin with" (would that have helped, complaining at the time?)
"We're confident we're not at a competitive disadvantage by doing this"
"We developed our product " (to remain competitive) " and had to add a bunch of stuff that people expect card processing services to do " (more than one currency) " and some stuff many customers won't care about being delivered by a card processing service " (things other than cards) " and rather than charge the appropriate fees to the appropriate customers at point of use we are instead funding this progress by penalising customers who are already in the loss-making situation of having to make a refund"
Is there a Stripe permalink (blog, tweet, etc.) from back in 2017 that describes this change back when it was announced? And/or for this year’s change, that drops the exclusion?
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.)
A phrase that comes to mind is: two wrongs don't make a right.
Reminds me when my Charter/Spectrum told me that even though I cancelled my service 2 days into the billing period, that I paid for a fixed term of service per billing period and they would not give me a prorated refund.
Escalating up the chain I got to the supervisor who told me that it was always their policy but they were just now enforcing it.
If I may make a sincere criticism, as a person who knows nothing about either side of this conversation....
We should all delete "I'm sorry you feel that way" from our mental phrasebooks. It is a phrase that always falls flat, comes across as potentially sarcastic, and is the textbook definition of a non-apology apology.
If you want to clarify something, go for it. If you don't want to apologize, don't feel obligated to do so. But please, for your own benefit, steer clear of this no-good phrase.
While it’s nice to hear more context in response to the OP’s criticisms, I’m not sure I would consider a response mostly defending the criticisms “beyond awesome”.
Most tech startups know the influence HN has, and to respond to a top post with a mostly defensive stance (vs. the OP points actually having an impact on the decisions being made) is a smart move on the part of the CEO (I would probably do the same thing).
Just saying I wouldn’t have used the words “beyond awesome”.
I recommended stripe to a friend because a hn (ad?) That mentioned the documentation was great. He struggled and I couldn't help him without a deep dive.
To be fair, my WordPress website has no problem with stripe.
Agreed, that phrase strikes me as without intrinsic meaning (though I can't say I ever grasped the meaning of "sorry" in the non-apology sense). It always seems to me like the person wants to say something that appears comforting without actually meaning anything, and seems disingenuous.
What would you recommend for a Stripe-backed SMB who has to turn away dozens of users per month because they only have some kind of "bank card" (which is normal in many European countries now). This business doesn't currently have the budget to implement support for all of these card types (Stripe UK does have support for most of them, it seems).
> I can assure you that the ratio of people working on improving our payments stack to publishing is about 1000:1.
@pc, I just checked that Stripe has about 1800 employees. Could I ask why so many? :) I wouldn't expect such a big number for the company providing one (?) product/service.
But then does the developer now need to track this list of production test cards and make sure the application doesn’t enact some other logic based on the test purchase?
I mean really, you can get 99.9% of the way there with the test cards in the sandbox, and then give the thing a smoke test in production when you’re ready.
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.