Live data from Hacker News

Stripe refunds: fees from the original charge are not returned

stripe.com

121–130 of 275 posts

Re: Stripe refunds: fees from the original charge are not returned

#122
post #97

Earlier quoted context omitted.

Hmm, so when refunds are processed, Stripe still always has to pay the interchange fees?

I work on this type of stuff thing at a major payments company and I can say this is _not_ true. For refunds, almost all of the interchange fee is returned. Sometimes even more than the original interchange fee is returned (don't ask why). Caveat here is that the card networks' rules are ridiculously byzantine and making blanket statements is usually a bad idea.

> Sometimes even more than the original interchange fee is returned (don't ask why).

If that behavior is at all deterministic that sounds like it would be incredibly prone to abuse.

Re: Stripe refunds: fees from the original charge are not returned

#123
post #120
post #117

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…

> Stripe has all the power to prevent many forms of fraud and provides this as a service as long as you pay a premium for it in the form of Radar. You have to pay extra on top of the 2.9% + 30c per transaction to get this protection. Radar's ML-based shield is free for all accounts on standard pricing. See https://stripe.com/pricing#radar-pricing . (We only charge if you want to set custom rules etc.)

> (We only charge if you want to set custom rules etc.)

The rules are what really allows merchants to protect themselves against fraud but this information isn't possible to obtain without help from their payment gateway (ie. Stripe).

In other words, merchants have no reasonable options to set up rules like what Radar does while using our own custom logic because there's no API that Stripe provides for us to get things like the risk score before the transaction takes place.

If Stripe had an API endpoint where developers could get the risk level of a transaction before the payment intent was put into motion then we could in theory build our own risk management tool at our app level by saying "if $risk_score > X then deny transaction".

But AFAIK nothing like this is possible, so our only option is to pay the extra transaction cost for Radar or deal with a less than ideal fraud protection even though Stripe can technically do this already. It just feels really dirty. It feels like instead of optimizing for the greater good and making the developer / business experience awesome, Stripe would rather pivot from being a payment gateway to an insurance company and then nickel and dime the businesses that helped build Stripe initially.

It's one of those things where it's like, we've been using you for years (quite happily in fact), but you collected all of this data from us and now instead of helping us by offering fraud detection across the board, you'd rather sell our data back to us in the form of insurance.

Re: Stripe refunds: fees from the original charge are not returned

#125
post #78

Earlier quoted context omitted.

If I may make a sincere criticism, as a person who knows nothing about either side of this conversation.... We should all delete "I'm sorry you feel that way" from our mental phrasebooks. It is a phrase that always falls flat, comes across as potentially sarcastic, and is the textbook definition of a non-apology apology. If you want to clarify something, go for it. If you don't want to apologize, don't feel obligated…

To be fair, this is the CEO personally reaching out. I think that's beyond awesome.

Are you starstruck? Is that what you're trying to say?

Re: Stripe refunds: fees from the original charge are not returned

#126

The struggle is real. Small fees add up for smaller startups and that used to be their bread and butter--it was so much easier to get payments up and running. We eventually switched to paypal and never looked back.

I sell a lot on eBay and thought the fees were going to hurt - but really it's been a non issue. It sucks especially on a high ticket item but end of the day it ends up on my taxes and I recoup some of it. Cost of business.

Re: Stripe refunds: fees from the original charge are not returned

#127
post #66
post #33

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…

(I'm one of Stripe's cofounders.) 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…

If you were a customer of Stripe, would you feel you were being treated well by this policy after you'd already been dealt a refund?

Re: Stripe refunds: fees from the original charge are not returned

#128
post #47
post #33

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…

> ..don't test production checkout flows.. 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 r…

Payment providers have test gateways and cards for you to test your code against.

And yet in 2020, you still can't write an automated test suite that spins up a virgin test environment, simulates all relevant scenarios, and allows you to quickly verify that your integration is responding properly as part of your normal CI process.

Working with a single, persistent test environment that offers no facilities to manage events like simulated user actions, API requests and webhooks feels like programming in another, much less productive era. Sadly, this still seems to be the norm for online payment services.

It's particularly ironic that online payment services are among the worst offenders for making API changes that require significant changes to integrations or even a whole new integration, and that by their nature they are also at high risk of Very Bad Things happening if an integration breaks. This is exactly the sort of situation where you really want a tight feedback loop and ongoing automated integration testing! Stripe used to be a welcome exception, but even they have dropped the ball badly in recent times.

Re: Stripe refunds: fees from the original charge are not returned

#129
post #66
post #33

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…

(I'm one of Stripe's cofounders.) 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…

The question you can answer about this change: Does stripe get interchangeable refunded from the card networks/banks on a refunded transaction?

Also any of the big processors you can negotiate the refund of interchange just like you can negotiate interchange plus pricing instead of blended which I assume stripe even offers to big merchants like Shopify. I do wonder if Shopify drops stripe since the change has pissed off all their $100mm+ merchants and they may lose a few. There isn’t a long term contract in place just a 6 month notice to quit.

Re: Stripe refunds: fees from the original charge are not returned

#130
post #78

Earlier quoted context omitted.

If I may make a sincere criticism, as a person who knows nothing about either side of this conversation.... We should all delete "I'm sorry you feel that way" from our mental phrasebooks. It is a phrase that always falls flat, comes across as potentially sarcastic, and is the textbook definition of a non-apology apology. If you want to clarify something, go for it. If you don't want to apologize, don't feel obligated…

To be fair, this is the CEO personally reaching out. I think that's beyond awesome.

Yeah this is damage control.

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.

Post reply on HN