Note: this is different than Braintree and Amazon payments, which either refund in full or simply charge only the $0.30 fee. Stripe is now at or near the most expensive here relative to the competition. The idea that they have been doing customers a favor is not accurate.
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.
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.
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
I used to run a company card for testing Stripe on prod, and then just processed a refund afterward. It was mildly inconvenient, and eventually I just stopped because there was never actually a difference between their staging and prod behaviour.
Payment providers have test gateways and cards for you to test your code against.
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.
I don't quite understand this comment. In my experience, payment processors (and related services) are somewhat unique in providing test gateways & APIs. Unlike other API services you can write integration tests against their test gateways. What are part of our industries is that normal? Most API-first services don't provide test endpoints at all.
In my experience, payment processors (and related services) are somewhat unique in providing test gateways & APIs.
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.
You can’t create an entirely new sandbox, no, but you can, quite easily test most scenarios. Including weird stuff like falling into delinquency - it takes a little bit more thought, but it’s fine.
Yes, testing in production can be dangerous and Stripe purposefully designed as many testing scenarios we could think of to avoid that (https://stripe.com/docs/testing).
Do you mean this in general or for Stripe? For the former, you have to run some tests on production after initial setup and major changes surely? API keys could be wrong for a start and a lot of web services don't give you a programmatic way to sync settings between environments.
If you want to do some sanity checking in prod to rule out any issue with the test environment setup... Why would you want to set up a special fake test card in prod?
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.
One feature I would like to see is the option to create multiple test environments. I have one dedicated for the CICD, and ideally each person testing locally would have their own API key they can use however they wish.
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.
Honestly, I don't find their support helpful with fixing any of my issues, and asking the same question multiple times gives completely different responses. I managed to completely break the Stripe Test API (nothing works, always "in the process of deleting"), and I've been in support limbo for at least a week now.
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
Nah, I don't want to be that guy. In the meantime I've just locally stubbed all Stripe API calls, since internal integration tests are all I need for non-production uses. I've also reached the point where regular production deployments make sense (or at least the payments logic is stable enough).
We use Adyen (we deal with international customers) and they've got the same rule - no test cards in production. I've never heard of a payment provider allowing test cards in prod.
I integrated with Adyen and found Stripe far easier to use. The international aspect forced me to use Adyen though. What was your experience like with them?
I've only done one integration with Stripe and it was such a nice experience that I recommended it to everyone. But nobody can beat Adyen's international support so it really depends on who your customers are.
That's what the dev/staging environments are for. Even if you run it 3x/day in production, it's less than $100/month. Use a company card and you get the money back too.
I don't see enough of a problem that requires all the technical debt to support fake numbers in production.
I've never had it happen and it shouldn't be a problem for occasional spot checks. Make sure everything in dev/staging environments is working first before doing a production run.
>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.
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.
I work on developer experience at Stripe. If you'd like to email me at my HN handle @stripe.com, I'd love to hear more about the trouble you've run into.
There's a vast payments ecosystem beyond Stripe that lets you avoid this.
With companies like Spreedly to provide almost-Stripe-quality APIs and PCI-compliant card vaulting at only a flat cost, and a massive amount of "merchant account providers" a quick Google away that can hook into Authorize.net and then into Spreedly, you can end up at 1.75% or less depending on your industry, and the flexibility to dynamically route transactions to merchant accounts (including Stripe itself) based on anything from geography to your own notion of fraud/return risk.
Stripe has far and away the best developer and administrator experience in the industry - it surprises and delights. But this doesn't make it the right solution for all businesses. Its genius was that it entered the zeitgeist as such.
Last I read, Authorize.net is never going to be updated to provide for PSD2/SCA authentication flows, which means it will not be suitable for charging customers in Europe in the future. Whether Spreedly will really be able to wrap those flows up in their API is an iffy question to me still.
Wow, Stripe is the best developer experience? When I integrated a few months ago their documentation was so confusing I ended up giving up and not using it at all, relying on using a library for laborious guess and check, and watching the JSON responses. I suspect my product can still be purchased for free if you use that EU security feature because nothing could help me figure out when I need to use it or how to do so, so it just looks like the payment succeeded. So much documentation recommends you use a totally different system I felt like I was caught in a loop.
Or just extend the same privacy protections to all your users globally and implement the same functionality once. Honestly, the PaymentIntent API is not difficult to wrap your mind around when you dive into the documentation, and it has you covered on 3D secure payments.
Nah there's some credit card security thing in the EU they talk about in the Stripe API. No comprehension of what it is, but I'm not talking about GDPR or anything, just weird credit cards.
I thought the Payment Intents and associated information about SCA had a learning curve, but was well documented. I think the aspect you're missing is that you don't need to decide, necessarily, when to use Payment Intents. You use only that API, and if there's an additional step required on the user's end, you'll get a different "state" in the response https://stripe.com/docs/payments/intents
Your experience isn’t invalid, but it’s by and far the best developer experience compared to everyone else.
Stripe was “bleeding edge” in their desicion to use JSON when I first integrated with them which was a hell of a lot easier than integrating with PayPal’s SOAP API
Idk, we’re at 5x that and the stripe fees are such a small part of our overall costs that it hasn’t been worth it to optimize there yet. We’ve found so many other places to optimize over time with bigger cost savings.
We just revamped our hosting on AWS and saved $6k/mo or so. Totally worth it.
It highly depends on the price of the product you’re selling.
If you’re selling 2.99 monthly subscriptions, then Stripe is eating ~13% of your revenue (30c + 2.9%). Or ~$6k per month in the grandparent commenter’s case ($30k in your case).
If you’re selling 99.99 monthly subscriptions, then it’s only ~3% of revenue.
Contrast this to PayPal who offer a “micro payments” solution for such cases - where it’s a flat 5% + 5c fee.
Some more context: this has been around for a couple years (for only new Stripe users). Payments are costing more to process. Card network fees have been gradually increasing over the years.
Stripe has kept this at bay for its longtime users for as long as we could, even as it's been getting more expensive. But with the water rising across the whole pond, we sadly have to start charging for some of these things.
Are processing fees really going up? As a longtime brick-and-mortar retailer, I am used to fees going up and then changing to a new processor to get competitive rates again. You just go back and forth between the different providers every few years. They give you a lower rate and then slowly raise the rates because they know it's a pita to switch.
As a SaaS founders, I use Stripe because it was easy to get reliable subscriptions up and running. I have no returns, so this particular policy doesn't impact me. However I know that I am still overpaying for convenience and it will likely be time to make a change this year or next.
Maybe when Stripe will drop rates once they start experiencing the same churn other processors deal with.
I work on this type of stuff thing at a major payments company and I can say this is _not_ true. For refunds, almost all of the interchange fee is returned. Sometimes even more than the original interchange fee is returned (don't ask why).
Caveat here is that the card networks' rules are ridiculously byzantine and making blanket statements is usually a bad idea.
What portion of the transaction cost goes to stripe and what portion goes to Visa/Mastercard or the card-holder's bank? Which part is the cost that is increasing?
Can this be further clarified? Are they keeping the 2.9 percent of the transaction and the transaction fee? If so, run away as fast as possible. If not, the transaction fee is still too high. Plenty of banks will will negotiate a much better fee with specific commitments, but it’s not too bad if you find value in the other features.
Just as an example, any business that deals with sex - porn sites, strip clubs, etc. have higher returns.
Why should your mom and pop diner with low fees pay more? When you are in certain types of business, you can take that as a cost of doing business.
But no matter what the reason is, if Stripe doesn’t get the money back why should they eat the cost? We should want companies that we use to pass the cost of doing business + profit to make enough to be sustainable.
I don't think you understood my point in the first post. The point is that we don't know if Stripe still has to pay interchange fees in case of refunds. It is assumed they don't, and they're just pocketing it.
Maybe now you can start charging us properly for debit card transactions, instead of pocketing the difference.
My company is now evaluating options to move off Stripe because of this fiasco and how it was communicated to customers, along with the complete lack of explanation of whether this impacted the % fee or just the flat $ fee.
> submit a transaction via an online API as a debit rather than credit
Yes, via ACH/SEPA Direct Debit but I don't believe it's common outside of Europe.
Processors, like First Data, will know at the point of transaction if it's a credit card, debit card, or even a prepaid card. Though it's been a few years, I remember the Adyen API returning all of this in the pre-auth response (had a business that didn't accept payments from prepaid cards, fraud was too high).
It's also possible this is encoded in the BIN/IIN (1st 6 digits), but my memory is fuzzy on the specifics.
BIN will tell you if its prepaid/card type. There's some weird rules around prepaid, like your can't set the recurring flag on prepaid on non-reloadable cards.
Adyen says they can route cards on different networks though i never used them personally.
It seems to be attached to the BIN. Our processor has a bin endpoint where I feed it the first 6 and it returns a bunch of info about the card, including credit/debit.
Why are payments costing more? Isn't technology lowering costs more and more for these companies? Is this just execs needing another summer home so they raise the prices to whatever they like?
Actually - it's mostly because of cost / benefit shifting.
A card can attract USERS by increasing the rewards it offers -> and charging MERCHANTS for the reward.
So visa infinite cards might charge a much higher swipe fee to a merchant, and then make available cash back + first party car insurance + lots of bennies to the holders of these "elite" cards.
They justify this to merchants by claiming that these "elite" users spend big bucks.
The reality - if users of cards were charged the actual swipe fee their card incurred -> they would push for SUPER low fees or switch to debit cards.
Many lucrative business depend on the person picking the service not being the one paying for it or the kickback going to someone other than one paying.
Pretty evil! I imagine the card companies have an explicit rule that, in order to accept their cards, a merchant can't charge their users any extra fee? I wonder if some regulation were created that bans rules like that from existence whether this would change tomorrow.
Kroger stopped supporting Visa cards for a minute and I realized that's literally all I carry.
Meanwhile it's become the new hot thing locally (Southern USA) to charge credit and debit card users a "convenience fee" sometimes as high as 35 cents a transaction. Everyone went from offering discounts to cash users to simply charging card users more.
Interestingly, in 2013 both credit card minimums (up to a maximum of $10) and surcharges (up to a maximum of 4%) became legally federally, although there are 10 states that still prohibit surcharges (including New York, California, and Texas).
So seems like $0.35 is allowable on any transaction of $8.75 or more.
What is the difference between a "discount for cash payers" and "convenience fee for card users", when the only two options are cash and card? In both scenarios, price for purchasing with cash is less than price for purchasing with card. Seems like semantics to me.
I've started seeing this trend in a lot of small shops here in NYC as well. There used to be a ton of "cash only" places, but now I'm seeing more places that I would expect to be cash only accepting credit cards with a "convenience fee."
I'm wondering if it has something to do with the increasing prevalence of rewards, which is driven by competition between issuers?
I mean, I get somewhere between 2% and 5% back on virtually everything I buy. On top of signup bonuses.
Whereas when I think back to 10 or 15 years ago, it seems like I usually got 1% back, and I still had cards that didn't offer any rewards back at all -- which is unthinkable to me today.
Just my anecdote, and I don't know if it's the main driver, but it certianly seems like rewards have become a much bigger thing.
" I get somewhere between 2% and 5% back on virtually everything I buy."
This is more a function of the extreme power that VISA etc. have over the transactions. They are locked into their fees and make it impossible to do things like 'pay this other way and save 2% etc.' i.e. trying to do anything to obfuscate to the consumer that they are in fact responsible for 3% of every purchase you make.
So various entities find ways around those controls by giving you money back in another direction.
Basically, there's immense 'market pressure' on those 3% fees, but the oligarchy has control over it, so those fees will nature be eaten away by any and all other angles.
If there was no oligarchy, those '2% back' programs would be less likely to happen and what we would see is material margin erosion for such fees.
AFAIK payments are only really costing more in the US. Europe, Australia, Canada have all regulated or negotiated lower interchange rates in the past years.
Hasn't this been the case for 4-5 months? I remember getting an email from Stripe about this back in September or October 2019, or was that PayPal?
The only thing that really bugs me a lot about Stripe (to the point where I've considered moving to Braintree for my next project) is how they handle fraud detection.
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.
But instead of providing Radar as a base service to all customers for the standard rates, they would rather you have fraudulent transactions against your account because they profit from "dispute fees", which is usually $17 or so per dispute that the merchant has to pay out of pocket, where Stripe takes some cut of that and the bank takes the rest of the cut.
It just feels super scammy of Stripe to not offer Radar as a thing you get by default, since it's so beneficial to have and business owners are powerless in preventing fraud on their own because they don't have hundreds of millions of transactions of data to lean against and a way to perform analysis on the transaction before it happens since merchants aren't directly in contact with credit card vendors (that's why we use Stripe).
I actually talked to support about this once in an email a few weeks ago, and the email began with them saying it's the merchant's responsibility to deal with fraud but by the end of the email discussion, support completely switched their position and said Stripe has the power to prevent it and they will pass my feedback to their product team. Which of course really means "ok, you win, Stripe is really responsible for fraud detection and we can totally do it, but we're never going to give it to customers out of the box because we profit from fraud regardless of you paying for Radar".
> 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.)
> (We only charge if you want to set custom rules etc.)
The rules are what really allows merchants to protect themselves against fraud but this information isn't possible to obtain without help from their payment gateway (ie. Stripe).
In other words, merchants have no reasonable options to set up rules like what Radar does while using our own custom logic because there's no API that Stripe provides for us to get things like the risk score before the transaction takes place.
If Stripe had an API endpoint where developers could get the risk level of a transaction before the payment intent was put into motion then we could in theory build our own risk management tool at our app level by saying "if $risk_score > X then deny transaction".
But AFAIK nothing like this is possible, so our only option is to pay the extra transaction cost for Radar or deal with a less than ideal fraud protection
even though Stripe can technically do this already. It just feels really dirty. It feels like instead of optimizing for the greater good and making the developer / business experience awesome, Stripe would rather pivot from being a payment gateway to an insurance company and then nickel and dime the businesses that helped build Stripe initially.
It's one of those things where it's like, we've been using you for years (quite happily in fact), but you collected all of this data from us and now instead of helping us by offering fraud detection across the board, you'd rather sell our data back to us in the form of insurance.
You're welcome to do your own risk scoring on any signals you want prior to directing us to charge a credit card for you. You're also welcome to do post-charge processing using our risk scores. Some companies will e.g. do post-transaction reviews prior to shipping; some write their own workflow SaaS into their admins to do this.
If you don't choose to write your own software using your own data, that's cool; you can buy that software from us, for two cents a transaction (or less).
We're a software company selling to software developers. We're cool with you writing your own software with your own data if you think your engineers are sufficiently efficient at this to make that the best possible use of their time. (The businessman in me suggests that it is extremely unlikely you can profitably employ engineers to write this software at most likely scales of your business and, contingent on being able to do that, it is quite likely there are a hundred better projects not upper bounded at 2 cents a transaction, but you are a project away from constructively disproving this if you strongly disagree.)
The issue is there's no hook between when the transaction is sent and the risk score is analyzed, and when the transaction is processed - after the risk score is returned, the transaction is already processed, and it's too late to deny!
> You're also welcome to do post-charge processing using our risk scores.
But if it's a post-charge operation, then the transaction already took place and it's too late.
If I need to refund a transaction after the fact because the transaction looks risky, then I lose out on the non-refundable processing fee that you now take, so I lose there.
Can you lay out a 100% exact work flow of how I can implement what Radar for teams does without losing money to extra transaction fees through either paying insurance on each transaction, or losing refund / dispute fees?
I understand that you are contemplating a build-or-buy decision and do not want to purchase the software which we sell. You can ask the engineering teams that you want to dedicate to this to scope out the build option; there are likely tradeoffs you can make which would make this a 3 engineer-year project or 30 engineer-year project. It is implausible that their design document for the build option will conveniently fit into an HN comment. I cannot write that design document for you as I do not have a good understanding of what data you believe you possess at the moment or e.g. the margin characteristics of your business, which would likely determine your tolerances with respect to some tradeoffs to make at design stage.
I wish your teams the best of luck and skill in this project. If in the alternative you would like to dedicate their time and attention to more pressing concerns in your business, our software is available for 2 cents a transaction.
> I wish your teams the best of luck and skill in this project. If in the alternative you would like to dedicate their time and attention to more pressing concerns in your business, our software is available for 2 cents a transaction.
Do you happen to work for Stripe support?
I'm just asking because your response reminds me of how they addressed my questions in email. It's very dismissive of my original questions, and then tries to guide the conversation away from my question into some type of "hey, good luck with whatever you do" response.
I'm not asking for an evaluation of whether or not it's a good use of engineering time for me to implement this feature. I'm just asking how I can do risk score assessment on my own without paying your extra transaction fees, or be forced into doing a post-transaction refund (and then lose the transaction fee on the refund).
You mentioned I'm free to do my own risk assessment, but I'm trying to say that's not possible to do in such a way that doesn't involve me paying extra money to Stripe since your API purposely goes out of its way to remove critical information unless you pay extra for Radar for teams (in which case using your API for this info wouldn't be necessary since your platform would provide that functionality in your dashboard).
He does work for Stripe. There are at least 4 Stripe employees in this discussion performing damage control: pc, patio11, nkohari, edwinwee, and anyone who has not yet self-disclosed.
" you collected all of this data from us and now instead of helping us by offering fraud detection across the board, you'd rather sell our data back to us in the form of insurance."
This kind of move is always galling. McGraw-Hill/Platts is terrible with this, where they take data from traders' transactions and then resell it back to them at extortionate rate. Whole market hates them.
EDIT: It appears that risk_score is indeed not available but risk_level is. You are still able to use your own logic to say for instance "don't capture if card country and tokenization IP country don't match and risk_level is elevated".
I honestly don't think it affects my answer much. They offer a less granular but still useful version for free.
AFAIK Radar also for free applies these learnings to the charges and blocks high risk ones for you.
> If Stripe had an API endpoint where developers could get the risk level of a transaction before the payment intent was put into motion then we could in theory build our own risk management tool at our app level by saying "if $risk_score > X then deny transaction".
But you can. The majority of what Radar custom rules allow you to do you can implement fairly easily on your own. You can take the risk scoring into account by separating auth (then looking at the risk score and make your own decisions) and capture (see link above). Granted it's a bit annoying you have to do a separation of auth and capture while with Radar custom rules you don't have to but it's not that big a deal.
There are possibly some pieces you cannot completely reproduce but for the most part you can build your own rules on your own. Even if one were to follow your reasoning of them using your transaction data to learn, Stripe doesn't owe you the part of Radar that allows you to write custom rules. That's an entirely tangential feature: Those are rather simple if statements that have little to do with the ML part of Radar.
I also encourage you to question your entire argument here. You'd have processed with Stripe if they used that data for anti-fraud ML or not. They didn't take that away from you or lured you into anything.
The actual work is in their engineers building the ML system, maintaining it (also: computing cost), tuning it, updating it, adding new data, cleaning up data (like extracting info from unstructured data on transactions).
I don't even think they owe their users the free version to be honest, but it's in their interest as well to make sure merchant exposure to fraud is reduced, and so you get it.
Blaming them for trying to make some money with an add-on system that simplifies writing custom rules like "if card country not IP country" or ones that combine the risk score, seems a bit rich.
And just to too this off I do have my qualms with some Stripe fees that seem outrageous, but Radar/Radar for teams, really?
I'm not sure what you are selling on Stripe but if it in anyway relates to software I'd expect some degree of understanding for the monetization approach.
> But you can. The majority of what Radar custom rules allow you to do you can implement fairly easily on your own. You can even take the risk scoring into account by separating auth (then looking at risk level and make your own decisions) and capture: https://stripe.com/docs/api/charges/object#charge_object-out...
Did you read the documentation you've linked to? :D
This field you linked is only available with Radar for Fraud Teams (it says this in the last sentence of the outcome.risk_score field). This is the extra Radar feature that you need to pay insurance / extra fees for. It's not available for everyone by default. Stripe purposely removes it from the API response because they know that score is the missing link to be able to do risk assessment on your own.
So as mentioned before, this feels really dirty because they are taking your private data and are profiting from it by selling it back to you and others in the form of insurance -- and there's nothing you can do about it.
True, but you can still use the less granular risk_level. So yeah, you don't get the full detail but you can still use the data they learned.
> So as mentioned before, this feels really dirty because they are taking your private data and are profiting from it by selling it back to you and others in the form of insurance -- and there's nothing you can do about it.
No, you and everybody else processing on Stripe has left that data there whether it's used for Radar's ML or not. I absolutely don't see anything dirty with them monetizing the software they built on that data.
Custom rules are the useful ones! The cost of Radar is a huge gripe of mine as well, we have lost thousands to a single fraudster that would have been easy to block with simple rules... The loss was less then the cost of Radar though. ;(
Otherwise, the API can be a bit confusing, but I've learned to just be very careful when I read the docs and to read them throughly.
I'm curious of whether they really required Radar custom rules specifically or whether Radar rules would just have been more convenient than writing your own rule evaluator?
With more competition coming into marketplace the costs of transactions inevitably goes down.
Charging more for transactions (in either direction) has nothing to do with "payments are costing more to process" lie.
This has everything to do with hook-and-charge business approach relying on majority of customers swallowing the arbitrary higher costs because it's more hassles to switch provider, especially for non-technical business owners.
> With more competition coming into marketplace the costs of transactions inevitably goes down.
There's intense competition for credit card customers that's driving transaction rates up in the US. Higher-end cards (Visa Infinite, Mastercard World Elite, Amex Platinum, etc.) offer a plethora of perks that are largely paid for by higher interchange rates on those cards.
I think you don’t understand the card ecosystem particularly well.
My impression (ex Stripe with no inside knowledge) is that Visa has been raising rates. Stripe are doing their best to avoid passing it on. This is one place where it surely became egregious not to.
I’ve never seen a company as averse to squeezing users as I had when I was there. The finance guy I worked with produced analysis for the team showing ways to reduce pricing more often than ways to increase it.
Your skepticism is warranted against most businesses. From my experience as a PM at Stripe, it is unwarranted in this case.
Disclosure: ex Stripe, own stock. No inside knowledge.
> Stripe are doing their best to avoid passing it on. This is one place where it surely became egregious not to.
According to the rest of the discussion on this page, Visa and other payment networks refund the interchange fee to payment processors (including Stripe) on refunded transactions.
There is no evidence that Stripe is any more charitable to their users than other payment processors. Stripe offers a commodity service, and increased the cost of using their service. Perhaps Stripe is "doing their best", but their competitors (e.g. Square and Amazon Pay) are doing even better by refunding the processing fee for refunded transactions.
> According to the rest of the discussion on this page, Visa and other payment networks refund the interchange fee to payment processors (including Stripe) on refunded transactions.
So far said that the refund fees on the brand side specifically increased or came into existence. I don't know if they did or not. I imagine though that transaction fees rising (which people do mention in the discussion) has an effect here. If you were able to make a given margin before while still allowing refund fees to be returned. Now transaction fees increase. As a PSP you can either choose to increase your processing fees or find other ways to make even. If you can achieve that by not returning fees on refunds (and make a bit more money along the way) that makes sense to me.
My main point is that rising fees in general can be a reason here even if the card brands didn't specifically add a new cost to refunds per se.
Recently got hit with this with QuickBooks. They actually charged me a fee to refund that was higher than the original fee charged. They think they deserve 3.5% on top of the initial 2.9% to send money back.
This is pretty standard for flat pricing nowadays, but hits certain types of merchants really hard.
It's a double whammy when you have a cancellation and have to refund and then lose 3% on top of that. Stripe should keep the fixed fee, sure, but keeping interchange doesn't seem right.
Why doesn't Stripe offer the option to do simple interchange+ pricing to all instead of restricting that option to 6 figure volume accounts with negotiated agreements?
That would cleanly solve the issue and be fair on both sides.
We are doing 200k+ in MRR and looking to move from Stripe because the cost is starting to hurt, and this change feels
unfair. Our use-case is pretty simple (capture card and manage subscriptions) and we don't need all the features they have built in the last 5 years or are planing to build.
We are looking into Spreedly. Does anyone have other suggestions of Stripe alternatives that are not so expensive?
I'm busy writing a Spreedly integration for my employer. It's not in production yet, but I can tell you that their iFrame API is a bit clumbsy and gives you less out of the box than Stripe Elements.
There are multiple little things that make me feel less trusting of stripe and that it’s shifting away to be more profit focused instead of customer oriented. One change that was unannounced (to my knowledge — maybe I missed something) was the payout schedule. It’s still two days technically, but at some point last year they started delaying the payout in their end if it was a weekend or holiday.
It used to be like this: income from Thursday, Friday and Saturday all arrived Monday, so Monday was a big payout day and this was good since it was often a higher expense day as well due to weekend charges being delayed to Monday.
Now, Thursday‘s sales arrive Monday (same), Friday’s Tuesday (a day later), and Saturday’s arrive on Wednesday (two days later), and any holidays further delay it.
This could be ok, but the unexpected change from what I had come to expect, and noting that it seems to be intentional design change on their end make it feel like they’re trying to delay the payout schedule while still claiming the same rolling 2-day, and in the end not really putting the customer first.
Not sure if that was the case in the past though or when it would have changed. I don't have any reason to doubt your story, so it's possible.
What you describe would be a calendar days setup I guess and I agree that changing that silently (on the same account) would piss me off. There might be good reasons for them to change it but not without reaching out to affected users. Or did you only see this new behavior on a different/newer account?
I'd say you should raise that with their support team! It should be fairly easy to find evidence of that change for Stripe, right? And you should also be able to find evidence of the old behavior (a bit of search work in the balance history but doable).
Still possible that your account is much older and you were grandfathered and then finally moved over to the new behavior long after this was standard for everyone. I'd really just check with them.
I'm a long-time Stripe user who processes ~$40k per month, and I think you're being too harsh. From a business owner's perspective, PayPal is the kind of company that would shut down your account and steal the balance for 6 months if their shitty algorithm detects anything "suspicious." Your attempts to contact them can be ignored or given generic responses that tell you nothing. PayPal just doesn't care, and it shows.
That's what "doing a PayPal" means to me.
But this fee increase? I'm actually grandfathered in so it doesn't apply to me, but if it did, it would amount to a 0.6% price increase in my typical monthly Stripe fees. So for example, if I paid $1000/mo in Stripe fees before this change, it would be $1006/mo now.
> From a business owner's perspective, PayPal is the kind of company that would shut down your account and steal the balance for 6 months if their shitty algorithm detects anything "suspicious." Your attempts to contact them can be ignored or given generic responses that tell you nothing.
Heh, PayPal just this month asked me to provide charity information for my personal account, and subsequently limited my receiving/sending privileges.
Phone calls to them trying to sort this out have always ended up at some call centre in the Philippines, where the agents can only tell their users that the account limitation is "for their safety".
They've also limited the personal account of a friend of mine (who's interestingly enough ex-PayPal) before, also asking for charity information.
That is absolutely incorrect. Eventually every account will have to pay, they just didnt get to you yet.
You mention $40k/month, that is irrelevant to what is being discussed here, more importantly is what is the amount of refunds that you process? That amount times 2.9% is your new reality.
My expectation has long been for Stripe to bring in more and higher fees. They offer a lot of top shelf free tooling that either brings their models into your code or moves the bookkeeping up to their system entirely, ex subscriptions.
Smart companies have their own bookkeeping system in house and thus can potentially negotiate better terms with Stripe, assuming they are big enough Stripe cares to retain them. Plenty of other places are looking at massive costs to move off Stripe and I am sure someone at Stripe is aware of that.
You're right about everything, but I disagree with your characterization of 'the first hit is always free'.
The lock-in features you describe are Stripe doing development work for your business.
With an addictive substance, the addiction gains control orthogonally to the 'benefit' it provides. When Stripe writes your recurring billing and bookkeeping system, they're straight up doing your work for you. Thats the desired effect– not a side-effect!
Put that way it's ridiculous enough if you are not refunding. Someone should do a points-free card with decent security (2fa on each purchase?) to minimise fraud that just gives say $50 cash of that to the consumer. They can then knock off 2.5% of whatever price they see in the store when thinking about what to buy. Such a card would be popular for expense accounts!
Accounts created before that were grandfathered in for fee refunds, but I don't have a grandfathered account, and therefore can't verify if that's still the case.
Here is our response to this ruthless and disrespectful decision by Stripe:
Hello,
We have just read your price changes to the grandfathered accounts and wanted to pass our discontent with Stripe's decision. Currently, we are weighing our options to move our business to other partners; however, as a small business that mainly operates in non-US currencies, the changes to your refund policies AND the non-US bank policies will effectively kill our partnership with Stripe.
We do not have tens of thousands of dollars per month worth of processing capabilities; however, we are a growing company as can be seen from our all time graphs on Stripe. We have used Stripe since the beginning and never considered alternatives. Your support team have always been helpful and your capabilities satisfied our needs. Until now.
The price hike to a grandfathered account is utterly unacceptable and looks/smells like a cheap attempt to make more money for the company. Stripe is also a rapidly growing company and grandfathered accounts could not have been hurting its business model. "Grandfathering" has an implied meaning that these people/companies/parties have been together since the beginning and a one-sided breach of this understanding is deeply damaging and distasteful.
In any way, unless Stripe can take steps to show sincerity towards our partnership from early on and rescind the changes to its fee policies, we will move our business out of Stripe before March 15th, 2020.
What is the least expensive payment gateway these days for a SaaS business? My stripe costs keep going up, happy to write the code to switch... what’s the lowest rate processor?
I haven't actively used stripe more than half a year, and I've really enjoyed it so far, except for some translation issues on stripe's checkout page. This change makes me somewhat uncomfortable using stripe.
Nordic countries has really good consumer protection laws and users can ask to cancel the purchase for any or no reason. Its also not allowed to charge the customer the fee, so this can become a issue.
It also sucks that the pricing for Norway is 1 % higher than our neighbours.
This is a disaster. Simply put, this change makes Stripe a nonviable option as an e-commerce payment
processor. The modern consumer expects easy, no questions asked refunds. How many people buy a few shirts/shoes of different sizes knowing that they will return the ones that do not fit? How can a retailer
provide that when there is now a 2.9% (in our case 3.5%) charge added on every item refunded?
This change directly hurts smaller retailers/e-commerce sites who are not big enough to negotiate smaller processing fees with Stripe.
I run a niche e-commerce site in Canada where the majority of my customers are located in the US.
This puts my processing rate at 3.5%. My products are priced anywhere from $1k to $6k.
So now with this change, I could pay up to $210 for when a customer simply changes their mind. I guess I could enact a strict NO REFUNDS policy but that will put me at a severe disadvantage vs the bigger retailers.
As things stand I would only recommend Stripe for recurring subscription billing.
A few companies do charge fees on the end user now. I did a refund on a plane ticket within the 24h grace period (basically refunded no question asked) but I had to pay the credit cards fee anyway. I don't do refund often, but it might become more common.
It’s not reasonable because the cost which the fee is covering is not the cost to process the transaction.
It’s three things, in order of their share of the total cost;
1) Rewards programs
2) Fraud risk
3) Interest expense
The rewards are negated, because a refunded transaction earns no points. The fraud risk is zero, because the merchant has returned the funds. This leaves only a portion of the interest expense, assuming the transaction balance was even paid into the merchant account at that point, but then the refund acts to reduce the card balance so that might even cancel out too.
Basically it’s justifiable to hold into the flat fee (e.g. $0.20) but to hold onto the 3% is an absolute scam.
I think it makes sense too, although from a slightly different perspective - that some work was done, and it’s additional work on Stripe (or Stripe’s systems) to refund or reverse a payment. Maybe a small fixed fee makes more sense than a percentage in this case, but either way, refunding a transaction still requires some effort.
It's standard from the consumer side that I see. If you return an item purchased with a foreign currency on a credit card with a forex fee, the forex fee isn't refunded.
the cost to network is often both in forward and reverse side, though most card providers zero out benefits to users so I'm convinced have higher than appropriate margins here (not stripe)
Makes me pine for FeeFighter's card processor comparator that GroupOn bought and killed.
But in reality, even with their high charges, Stripe makes it easy to get started, but startups can and should change vendors when the need arises. If other processors with lower fees for the particular volume a startup is doing and better APIs, it's worth considering them too.
I have one really annoying complaint with stripe connect. Its authentication work flow using oauth is conflicting with aws amplify authentication for social providers. Both of these are pretty much essential nowadays. I hope someone picks up on this comment and considers finding a solution
Stripe has the ability to negotiate with their upstream processors that we end users do not. Instead of trying to reduce their costs by pressuring their providers, they're passing along the fees to their customers.
Some of the other comments in this very post [1][2][3] suggest that Stripe isn't being charged the full fee by other parts of the network.
If they're intent on working with the customer to keep prices down, they should only charge a fixed fee for refunds (to pay for overheads), and not the interchange fee.
i dont really see the value in stripe compared to any other payment processor... they still do all the dirty tricks that everyone else does, like hold your money, cancel your account, hold your money.
The struggle is real. Small fees add up for smaller startups and that used to be their bread and butter--it was so much easier to get payments up and running. We eventually switched to paypal and never looked back.
I sell a lot on eBay and thought the fees were going to hurt - but really it's been a non issue. It sucks especially on a high ticket item but end of the day it ends up on my taxes and I recoup some of it. Cost of business.
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.