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.
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
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.
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.
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.
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.
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?
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.)
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.
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.
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.
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.
[+] [-] mchusma|6 years ago|reply
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.
[+] [-] pc|6 years ago|reply
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.
[+] [-] polemic|6 years ago|reply
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
[+] [-] btown|6 years ago|reply
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.
[+] [-] dangrossman|6 years ago|reply
[+] [-] hawkice|6 years ago|reply
[+] [-] longtermd|6 years ago|reply
[+] [-] pentae|6 years ago|reply
But Starting at 5 cents per API call? Hard pass.
[+] [-] edwinwee|6 years ago|reply
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.
[+] [-] jaxn|6 years ago|reply
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.
[+] [-] senordevnyc|6 years ago|reply
[+] [-] cosmotic|6 years ago|reply
[+] [-] bastardoperator|6 years ago|reply
[+] [-] Wowfunhappy|6 years ago|reply
[+] [-] Matheus28|6 years ago|reply
If so, I'd imagine it's more fair to refund them completely, and instead increase the base fee for payments.
[+] [-] ValentineC|6 years ago|reply
[+] [-] tomnipotent|6 years ago|reply
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.
[+] [-] sergiotapia|6 years ago|reply
[+] [-] simlevesque|6 years ago|reply
[+] [-] acvny|6 years ago|reply
[deleted]
[+] [-] nickjj|6 years ago|reply
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".
[+] [-] pc|6 years ago|reply
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.)
[+] [-] Trias11|6 years ago|reply
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.
[+] [-] ceejayoz|6 years ago|reply
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.
[+] [-] brunoTbear|6 years ago|reply
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.
[+] [-] ikeboy|6 years ago|reply
[+] [-] chrishynes|6 years ago|reply
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.
[+] [-] PerfectElement|6 years ago|reply
We are looking into Spreedly. Does anyone have other suggestions of Stripe alternatives that are not so expensive?
[+] [-] danpalmer|6 years ago|reply
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.
[+] [-] jherdman|6 years ago|reply
[+] [-] elijahparker|6 years ago|reply
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.
[+] [-] quelltext|6 years ago|reply
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.
[+] [-] pc|6 years ago|reply
[+] [-] vfclists|6 years ago|reply
Louis Rossmann won't be happy - https://www.youtube.com/watch?v=c1WPDVjXDj0
[+] [-] Meekro|6 years ago|reply
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.
[+] [-] frank086|6 years ago|reply
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.
[+] [-] jv22222|6 years ago|reply
[+] [-] danpalmer|6 years ago|reply
[+] [-] mc3|6 years ago|reply
[+] [-] teruakohatu|6 years ago|reply
[+] [-] ValentineC|6 years ago|reply
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.
[+] [-] adtac|6 years ago|reply
Alternatively, how do I check this myself?
[+] [-] Meekro|6 years ago|reply
[+] [-] whynotnowha|6 years ago|reply
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.
[+] [-] brianwawok|6 years ago|reply
[+] [-] NightlyDev|6 years ago|reply
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.
[+] [-] poxrud|6 years ago|reply
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.
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] icelancer|6 years ago|reply
[+] [-] kuon|6 years ago|reply