Live data from Hacker News

Stripe refunds: fees from the original charge are not returned

stripe.com

161–170 of 275 posts

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

#161
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.)

Custom rules are the useful ones! The cost of Radar is a huge gripe of mine as well, we have lost thousands to a single fraudster that would have been easy to block with simple rules... The loss was less then the cost of Radar though. ;(

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.

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

#162
post #160

Earlier quoted context omitted.

Why not use a small charge against a real card? A few $1 charges work fine and are cheap enough to ignore.

I've always had a concern about getting a real card flagged for fraud / card-status-probing and thus locked.

I've never had it happen and it shouldn't be a problem for occasional spot checks. Make sure everything in dev/staging environments is working first before doing a production run.

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

#163

Earlier quoted context omitted.

Actually - it's mostly because of cost / benefit shifting. 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" us…

Meanwhile it's become the new hot thing locally (Southern USA) to charge credit and debit card users a "convenience fee" sometimes as high as 35 cents a transaction. Everyone went from offering discounts to cash users to simply charging card users more.

I've started seeing this trend in a lot of small shops here in NYC as well. There used to be a ton of "cash only" places, but now I'm seeing more places that I would expect to be cash only accepting credit cards with a "convenience fee."

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

#164

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…

Nah there's some credit card security thing in the EU they talk about in the Stripe API. No comprehension of what it is, but I'm not talking about GDPR or anything, just weird credit cards.

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

#165
post #142

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

We're actually working on speeding up payouts, for free. They're currently faster than they've ever been and will continue to get faster.

That sounds great! But they’re currently faster than they’ve ever been? I don’t see how that reconciles with my experience I just described...

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

#166
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?

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

#167

Earlier quoted context omitted.

We use Adyen (we deal with international customers) and they've got the same rule - no test cards in production. I've never heard of a payment provider allowing test cards in prod.

I integrated with Adyen and found Stripe far easier to use. The international aspect forced me to use Adyen though. What was your experience like with them?

I've only done one integration with Stripe and it was such a nice experience that I recommended it to everyone. But nobody can beat Adyen's international support so it really depends on who your customers are.

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

#169
post #87
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…

> we built an ML engine to automatically optimize the bitfields of card network requests For someone who's not in the payment industry, could you elaborate on what this actually means?

There’s a few fields you can set meta data around the transaction. Eg: it’s a recurring charge

Every processor optimizes this though.

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

#170
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…

Thanks for replying on this thread, PC. I'm curious to get your take on how this plays out for customers with large average transaction values ($500+)?

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?

Post reply on HN