Stripe refunds: fees from the original charge are not returned
stripe.com
stripe.com
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.
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
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.
And yet in 2020, you still can't write an automated test suite that spins up a virgin test environment, simulates all relevant scenarios, and allows you to quickly verify that your integration is responding properly as part of your normal CI process.
Working with a single, persistent test environment that offers no facilities to manage events like simulated user actions, API requests and webhooks feels like programming in another, much less productive era. Sadly, this still seems to be the norm for online payment services.
It's particularly ironic that online payment services are among the worst offenders for making API changes that require significant changes to integrations or even a whole new integration, and that by their nature they are also at high risk of Very Bad Things happening if an integration breaks. This is exactly the sort of situation where you really want a tight feedback loop and ongoing automated integration testing! Stripe used to be a welcome exception, but even they have dropped the ball badly in recent times.
They are also somewhat unique in that they handle real money. You don't need a simulated API if you're sending an email or SMS message to a designated recipient or downloading the local weather forecast or traffic news, because there are no significant and irreversible consequences to these actions anyway.
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
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.
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...
We should all delete "I'm sorry you feel that way" from our mental phrasebooks. It is a phrase that always falls flat, comes across as potentially sarcastic, and is the textbook definition of a non-apology apology.
If you want to clarify something, go for it. If you don't want to apologize, don't feel obligated to do so. But please, for your own benefit, steer clear of this no-good phrase.
Most tech startups know the influence HN has, and to respond to a top post with a mostly defensive stance (vs. the OP points actually having an impact on the decisions being made) is a smart move on the part of the CEO (I would probably do the same thing).
Just saying I wouldn’t have used the words “beyond awesome”.
I recommended stripe to a friend because a hn (ad?) That mentioned the documentation was great. He struggled and I couldn't help him without a deep dive.
To be fair, my WordPress website has no problem with stripe.
That is the exact idea why they receive a notification when you mention Stripe ;).
Ps. I didn't have any problems with Stripe also, documentation was top notch
;)
And most importantly, without admitting fault.
And yet Authorize.net and many others manage it without drama. I know of one account you did not land because of this.
For someone who's not in the payment industry, could you elaborate on what this actually means?
Every processor optimizes this though.
When I reached out to support, they acknowledged that this was a type of attack, and I needed to manually go back and unapprove all of these purchases coming from a single IP address, that wasn't being stopped by Stripe.
Would I still need to pay to do all those fraudulent charge backs? If so, that single attack would have cost me hundreds of dollars out of pocket.
We’re here to support startups. If you ever have a unique circumstance, write us; we’ll try to be reasonable, in the same fashion that your hosting provider will try to be reasonable if an engineer e.g. fumble fingers a deploy and briefly turns on a larger fleet of servers than they intended.
(It's worth noting, for precision's sake, that a refund is not a chargeback. Chargebacks are when the person who actually owns the credit card calls the bank to complain; they're strictly worse for all parties than simple refunds.)
Attempting to find an answer as an outsider lead me to this PR release from last year: https://stripe.com/newsroom/news/chargeback-protection < It makes me assume that if the merchant wasn't paying that extra fee they are going to be slammed.
But there is an issue with this euphemism in the parent comment:
> a human who cares about your success
If Stripe "cares about your success", Stripe would return the processing fee on all refunded transactions (regardless of whether they are fraudulent) just like Square and Amazon Pay does.
You don't know that the poster is 100% honest also. Patio has always been transparent and honest, long before he joined Stripe ;)
> a human who cares about your success
Regarding honesty, if Stripe "cares about your success", Stripe would relinquish processing fees for all refunded transactions (regardless of whether they are fraudulent) just like Square and Amazon Pay do.
Considering how often you're going to be issuing refunds (I tend to do maybe 2 or 3 in a big month), I'd be surprised if we hadn't each spent more in billable hours typing into this text box than we will in Stripe refund fees over the next four years.
If I've already started selling tickets, and had to postpone the event because of something like COVID-19, I'd be looking at paying Stripe something like $3,500 in payment processing fees (it's 3.4%+$0.50 here; and assuming $100k in ticket revenue) for the privilege of refunding my attendees.
It's not an amount that would sink our non-profit, but the full fee is also not something that we should have to pay, just because we want to do right by our attendees.
Receiving a temporarily update on a situation that has to be checked, is better than no update.
Well, the truth sucks sometimes, doesn't it?
Traditionally there's been 2 customer service lines: regular and VIP.
Now there's 3: regular, VIP, and social media apology tour. And it'd sure be nice if these companies had decent policies to begin with... But that's the problem, isn't it?
All I know is the current situation, well, stinks.
So no, not like google at all. That somebody gets a response from a VP on hacker news is not evidence they will get no response outside hacker news.
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.
Visa test / approve / record account:
48 XXXX 01
Visa test / approve / donot record:
48 XXXX 02
Visa test / donot approve / record account
48 XXXX 03
Visa test / donot approve / donot record
48 XXXX 04
Hard to let it to client to decide how to test...
I mean really, you can get 99.9% of the way there with the test cards in the sandbox, and then give the thing a smoke test in production when you’re ready.
Please continue to do what you're doing in this space. Payments are such a complex beast and it's refreshing to work with a company that works so hard to abstract that complexity.
This is something that companies that are near public company size do since the amount of work required to meet payment regulations alone, not to mention all of the infrastructure to support things like subscriptions is staggering.
This is why there aren't many solutions to this problem. It's a very difficult problem.
Managing and developing your own billing system is a almost always a bad idea, no matter how big your company is. There is a high likelihood that you will end up running a business within a business if you go that route.
> you will end up running a business within a business if you go that route.
It provides a subscription management platform with all the features you would expect out of the box (recurring billing, plans management, dunning, notifications, etc.), but with also a plugin framework where you can implement your own billing logic.
You can continue to use processors like Stripe to handle the recurring charges (and compliance associated with storing cards), but they are only used to charge the payment methods. The mess that OP mentions stays in-house, where you have tighter control over it.
Uh, what?
Does this mean, lower processing fee/less need to increase processing fees?
Some percentage of these customers retry, perhaps with another card, and eventually succeed in buying the thing they want to buy. Some don't, and the business loses the revenue that a customer was already happy to give them.
Improving authorization rates (the industry jargon for that) recovers that revenue, for ~free (your product/advertising/etc spend to attract the customer is the same whether they successfully complete the purchase or not).
A phrase that comes to mind is: two wrongs don't make a right.
Escalating up the chain I got to the supervisor who told me that it was always their policy but they were just now enforcing it.
Oh okay. Sure. That makes it all okay. /s
https://www.theverge.com/2019/9/20/20876570/paypal-refund-fe...
Square still refunds processing fees to merchants for refunded transactions. They have the same fee (2.9% + $0.30) for online transactions, and a lower fee (2.6% + $0.10) for in-person transactions with their card reader.
https://squareup.com/help/us/en/article/5060-refund-overview
And the reason is that most people simply don't hate the status quo.
There's also always an option to take the first confirmation (~24sec in Ethereum) as a sufficient proof for small transactions.
Documentation has gone form terrible to bad. API has gone from always terrible to appearing OK but will periodically destroy your happiness and productivity for a week. I would never voluntarily work with PayPal tech.
Really, for your company's sake I hope what matters is not what you like, but that your company has a payment solution that does not stop working when Stripe freezes your account. Yeah, Stripe is not an iota better than PayPal when it comes to freezing accounts. The only sane thing to do is to have a backend system that at minimum can use both PayPal and Stripe. With such a system it should be easy to change between PayPal and Stripe and I suggest that we all shutdown the Stripe part to show our discontent.
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.
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?
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.
@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.
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).
"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"
I don't see enough of a problem that requires all the technical debt to support fake numbers in production.
Sadly the same experience here.
Getting them to fix the many many basic issues of their client libraries is hell, testing is no better and library updates often break your testing scenarios.
They are big and cool like stripe.
PS: not related to them, just met them at vivatech paris
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.
We just revamped our hosting on AWS and saved $6k/mo or so. Totally worth it.
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.
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 ;)
https://www.insideprivacy.com/financial-institutions/overlap...
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
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.
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.
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.
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.
So in this case it’s better for the user but worse for the person paying.
Just the opposite of enterprise software sells.
Kroger stopped supporting Visa cards for a minute and I realized that's literally all I carry.
but what with the fees from card a vs card b.
Suddenly all "reward cards" lost most of their rewards...
In the US, this was the subject of a recent class-action suit! https://www.paymentcardsettlement.com/en
So seems like $0.35 is allowable on any transaction of $8.75 or more.
[1] https://www.thebalance.com/credit-card-surcharges-315423
https://www.ncsl.org/research/financial-services-and-commerc...
Visa is one of Stripe's largest shareholders.
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.
Caveat here is that the card networks' rules are ridiculously byzantine and making blanket statements is usually a bad idea.
If that behavior is at all deterministic that sounds like it would be incredibly prone to abuse.
If so, I'd imagine it's more fair to refund them completely, and instead increase the base fee for payments.
The interchange fees aren't going up because of higher rates of returns. They're going up to pay for credit card rewards.
Stripe is keeping these fees when a purchase is returned simply to increase their overall profit.
Why punish businesses that have higher rates of returns if that is not the cause of the higher fees?
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’m seeing various things, but the consensus seems to be that the payment processor does get refunded the interchange fee.
https://www.quora.com/How-are-credit-card-processing-fees-ha...
So it would be fair if Stripe charged a small transaction fee for a refund but returned the bulk of the interchange fees.
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?
There is a different fee between PIN and signature debit, but not so much that signature debit matches credit cards.
https://www.valuepenguin.com/credit-card-processing/intercha...
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.
Adyen says they can route cards on different networks though i never used them personally.
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.
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.
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.
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.)
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 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.
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.
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.
> 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.
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?
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.
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.
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.
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.
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.
A quick search suggests that this incident isn't uncommon:
[1] Paypal Thinks I am a Charity Organisation: https://www.paypal-community.com/t5/Disputes-and-Limitations...
[2] Provide charity info - DD Business Inormation: https://www.paypal-community.com/t5/Disputes-and-Limitations...
[3] What's DD Business Information: https://www.paypal-community.com/t5/Disputes-and-Limitations...
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.
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)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.
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.