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.
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.
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.)
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.
You don't know that the poster is 100% honest also. Patio has always been transparent and honest, long before he joined Stripe ;)
> 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.
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.
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.
Receiving a temporarily update on a situation that has to be checked, is better than no update.
Well, the truth sucks sometimes, doesn't it?
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?
All I know is the current situation, well, stinks.
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.
But there is an issue with this euphemism in the parent comment:
> a human who cares about your success
If Stripe "cares about your success", Stripe would return the processing fee on all refunded transactions (regardless of whether they are fraudulent) just like Square and Amazon Pay does.
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.
https://www.theverge.com/2019/9/20/20876570/paypal-refund-fe...
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.
https://squareup.com/help/us/en/article/5060-refund-overview
And the reason is that most people simply don't hate the status quo.
There's also always an option to take the first confirmation (~24sec in Ethereum) as a sufficient proof for small transactions.
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.
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.
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.
> you will end up running a business within a business if you go that route.
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.
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.
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.
[1] https://www.braintreepayments.com/sg/braintree-pricing
[2] Looks like the US one has the same policy as Stripe: https://www.braintreepayments.com/braintree-pricing?locale=u...
For someone who's not in the payment industry, could you elaborate on what this actually means?
Every processor optimizes this though.
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?
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).
And yet Authorize.net and many others manage it without drama. I know of one account you did not land because of this.
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.
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.
Uh, what?
Does this mean, lower processing fee/less need to increase processing fees?
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).
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.
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"
A phrase that comes to mind is: two wrongs don't make a right.
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.
Oh okay. Sure. That makes it all okay. /s
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.
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.
That is the exact idea why they receive a notification when you mention Stripe ;).
Ps. I didn't have any problems with Stripe also, documentation was top notch
;)
And most importantly, without admitting fault.
@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.
Visa test / approve / record account:
48 XXXX 01
Visa test / approve / donot record:
48 XXXX 02
Visa test / donot approve / record account
48 XXXX 03
Visa test / donot approve / donot record
48 XXXX 04
Hard to let it to client to decide how to test...
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.
That's good advice.
Payment providers have test gateways and cards for you to test your code against. While it might be a minor convenience for you to have 'fake' cards in their production system, the only thing they have to gain is a potentially serious fraud loophole (at best), or an expensive footgun for you.
Don't "test" checkout flows in production unless you're using real credit cards :D
And yet in 2020, you still can't write an automated test suite that spins up a virgin test environment, simulates all relevant scenarios, and allows you to quickly verify that your integration is responding properly as part of your normal CI process.
Working with a single, persistent test environment that offers no facilities to manage events like simulated user actions, API requests and webhooks feels like programming in another, much less productive era. Sadly, this still seems to be the norm for online payment services.
It's particularly ironic that online payment services are among the worst offenders for making API changes that require significant changes to integrations or even a whole new integration, and that by their nature they are also at high risk of Very Bad Things happening if an integration breaks. This is exactly the sort of situation where you really want a tight feedback loop and ongoing automated integration testing! Stripe used to be a welcome exception, but even they have dropped the ball badly in recent times.
They are also somewhat unique in that they handle real money. You don't need a simulated API if you're sending an email or SMS message to a designated recipient or downloading the local weather forecast or traffic news, because there are no significant and irreversible consequences to these actions anyway.
Either don't do it, or have everything about it real. e.g. a canary purchase test & then a refund flow test. Yes there's a fee, but there's a fee when you do it for real. Hopefully you have many more real transactions.
Working with Stripe hasn't been error free. I've had one or two nasty bugs. But the product is fluid, works, and most importantly, they have great customer support. I wouldn't mind paying a little extra for it.
I'm a relatively small fish, but they replied within hours and fixed the issue. On a Saturday. As long this "Saturday test" remains true, I'm a happy user.
Haven't looked into the alternatives, but I hope I can move most commerce over to Bitcoin since I can run that fairly cheap internally to the company (and bypass PCI compliance, etc)
EDIT: Maybe I was being overly critical in the first half, but in general implementation has been a bumpy experience. Most transactions on this platform are microtransactions, so it isn't that Stripe is expensive as much as I'm using it in an unconventional way, and not having a $0.30 static fee drastically changes my profit margins
I don't see enough of a problem that requires all the technical debt to support fake numbers in production.
Sadly the same experience here.
Getting them to fix the many many basic issues of their client libraries is hell, testing is no better and library updates often break your testing scenarios.
They are big and cool like stripe.
PS: not related to them, just met them at vivatech paris
I have used stripe for years, but they are a company that has continued to make things worse with every update, versus AWS which has my trust they won't increase rates. If AWS ever offered a true competitor, we would switch.
They invest in publishing books, but they still miss basic features like a way to test credit cards in the production system for QA purposes. It's an easily solved problem (let you generate one time fake card numbers programmatically that stripe "pretends" to charge). I have been trying to test checkout flows with them for years and their official stance is "don't test production checkout flows", which is insane.
I hope stripe changes it's ways here, but they have been a large disappointment over the last 4 years or so after a solid start.