Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Stripe refunds: fees from the original charge are not returned

stripe.com

Post reply on HN
Print view View original

181–190 of 275 posts

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

#181

Post by leesalminen »

longtermd wrote: post #86
btown wrote: post #40

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 r…

I agree. I would love Stripe 10X more if they'd offer much lower prices. Their fees become really huge as your business grows beyond 50k MRR

Idk, we’re at 5x that and the stripe fees are such a small part of our overall costs that it hasn’t been worth it to optimize there yet. We’ve found so many other places to optimize over time with bigger cost savings.

We just revamped our hosting on AWS and saved $6k/mo or so. Totally worth it.

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

#182

Post by jaxn »

jaxn wrote: post #52
cosmotic wrote: post #9

Earlier quoted context omitted.

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?

Stripe is Visa. Visa is one of Stripe's largest shareholders.

https://fortune.com/2015/07/28/stripe-visa/

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

#183

Post by leesalminen »

tomnipotent wrote: post #153
koolba wrote: post #102

Earlier quoted context omitted.

I know the fees are lower. I’m asking if it’s possible to submit a transaction via an online API as a debit rather than credit.

> submit a transaction via an online API as a debit rather than credit Yes, via ACH/SEPA Direct Debit but I don't believe it's common outside of Europe. Processors, like First Data, will know at the point of transaction if it's a credit card, debit card, or even a prepaid card. Though it's been a few years, I remember the Adyen API returning all of this in the pre-auth response (had a business that didn't accept paym…

It seems to be attached to the BIN. Our processor has a bin endpoint where I feed it the first 6 and it returns a bunch of info about the card, including credit/debit.

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

#184

Post by sovande »

tomcam wrote: post #127
pc wrote: post #66

Earlier quoted context omitted.

(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?

No, this is infuriating, but we must not forget that they “built an ML engine to automatically optimize bla bla bla.” But really, pretense should be off. Stripe is nothing more than a PayPal clone. Even the refund policy is now perfectly cloned. Someone here said that the only way our discontent can be heard is for us to switch between platforms regularly. Right now, PayPal does not look so bad. Their API and documentation has also become pretty good. Of course, the better thing would be to just get a merchant account and drop all these middleman leeches. Apropos, don’t get me started on the AppStore were we only pay 30% for the privilege

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

#185

Post by patio11 »

burningion wrote: post #88
pc wrote: post #66

Earlier quoted context omitted.

(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…

A few months back, I was hit with an attack from a spammer, who managed to place a few hundred orders through my Stripe checkout. It seems they were attempting to place thousands of orders, and looking for functional credit card information. When I reached out to support, they acknowledged that this was a type of attack, and I needed to manually go back and unapprove all of these purchases coming from a single IP add…

I'm sorry that happened to you. Could you email me at this handle at stripe.com? I want to look into why we didn’t auto-detect that surge in suspicious transactions.

We’re here to support startups. If you ever have a unique circumstance, write us; we’ll try to be reasonable, in the same fashion that your hosting provider will try to be reasonable if an engineer e.g. fumble fingers a deploy and briefly turns on a larger fleet of servers than they intended.

(It's worth noting, for precision's sake, that a refund is not a chargeback. Chargebacks are when the person who actually owns the credit card calls the bank to complain; they're strictly worse for all parties than simple refunds.)

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

#186

Post by shaneprrlt »

NicoJuicy wrote: post #151
hawkice wrote: post #138

Earlier quoted context omitted.

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…

Euh, you are talking about EU security features? 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 dat…

Or just extend the same privacy protections to all your users globally and implement the same functionality once. Honestly, the PaymentIntent API is not difficult to wrap your mind around when you dive into the documentation, and it has you covered on 3D secure payments.

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

#187

Post by futhey »

tarr11 wrote: post #80
Meekro wrote: post #15

Earlier quoted context omitted.

I have a grandfathered account from 2016, and I'm still getting the fee refunds.

I have an account that is from 2013, and they are ending March 1 for us.

Also from 2016, didn't get a notification. Just confirmed I am still getting refunded. I guess it could be decided by volume or another factor?

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

#188

Post by longcommonname »

Mtinie wrote: post #122
lyall wrote: post #97

Earlier quoted context omitted.

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.

Think about things that have increase in values during during a clearing period. Stock dividends is one.

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

#189

Post by adrr »

tomnipotent wrote: post #153
koolba wrote: post #102

Earlier quoted context omitted.

I know the fees are lower. I’m asking if it’s possible to submit a transaction via an online API as a debit rather than credit.

> submit a transaction via an online API as a debit rather than credit Yes, via ACH/SEPA Direct Debit but I don't believe it's common outside of Europe. Processors, like First Data, will know at the point of transaction if it's a credit card, debit card, or even a prepaid card. Though it's been a few years, I remember the Adyen API returning all of this in the pre-auth response (had a business that didn't accept paym…

BIN will tell you if its prepaid/card type. There's some weird rules around prepaid, like your can't set the recurring flag on prepaid on non-reloadable cards.

Adyen says they can route cards on different networks though i never used them personally.

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

#190

Post by abduhl »

patio11 wrote: post #185
burningion wrote: post #88

Earlier quoted context omitted.

A few months back, I was hit with an attack from a spammer, who managed to place a few hundred orders through my Stripe checkout. It seems they were attempting to place thousands of orders, and looking for functional credit card information. When I reached out to support, they acknowledged that this was a type of attack, and I needed to manually go back and unapprove all of these purchases coming from a single IP add…

I'm sorry that happened to you. Could you email me at this handle at stripe.com? I want to look into why we didn’t auto-detect that surge in suspicious transactions. We’re here to support startups. If you ever have a unique circumstance, write us; we’ll try to be reasonable, in the same fashion that your hosting provider will try to be reasonable if an engineer e.g. fumble fingers a deploy and briefly turns on a larg…

While this is an interesting response, it strictly does not the answer the poster’s question. Would they be liable for the fees for an attack like this?
Post reply on HN