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.
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.
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
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.
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?
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?
"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.
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.
@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...
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.
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
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
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.
So,
if(IsInEurope(Customer.Country) || IpAnalyzer.IsInEurope(visitor.Ip))
{
//Enable something
}
Should do it. But fallback method should be implemented, took me 3 minutes of reading documentation + googling.
Between all those tax regulation differences, I think this one is mostly straightforward for handling global payments.
Ps. Don't forget to encrypt your actual data, I think you will be amazed at what needs to happen for selling in EU ;)
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
We just revamped our hosting on AWS and saved $6k/mo or so. Totally worth it.
But Starting at 5 cents per API call? Hard pass.
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.
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.
Caveat here is that the card networks' rules are ridiculously byzantine and making blanket statements is usually a bad idea.
As far as Visa/MC and the banks? The banks get something like 9/10 of that portion off the top; Visa/MC get about 1/10th.
If so, I'd imagine it's more fair to refund them completely, and instead increase the base fee for payments.
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.
Is there a provider who provides debit card online processing?
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.
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.
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".
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.)
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.
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.
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.
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.
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.
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.
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 looking into Spreedly. Does anyone have other suggestions of Stripe alternatives that are not so expensive?
Particularly if most of your customers are in the EU where interchange fees are capped at something like 0.3%, so their cost base is much lower.
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.
https://stripe.com/docs/payouts#2-day
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).
EDIT: I tried to go back on the wayback machine and it said business days for quite some time before last year (https://web.archive.org/web/20170905023631/https://stripe.co...).
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.
Louis Rossmann won't be happy - https://www.youtube.com/watch?v=c1WPDVjXDj0
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.
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.
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.
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.
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!
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.
Alternatively, how do I check this myself?
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.
Thanks for the ride and have a great day.
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 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.
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.
Who says it has to be? Businesses have all kinds of costs not directly related to the day to day transactions with customers.
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)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.
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.
[1] https://news.ycombinator.com/item?id=22371571
DeFi (Decentralized Finance) is coming for you guys.
It might take some time, but we’ll get there.