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

131–140 of 275 posts

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

#131

Post by [deleted] »

jader201 wrote: post #119
echelon wrote: post #78

Earlier quoted context omitted.

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

While it’s nice to hear more context in response to the OP’s criticisms, I’m not sure I would consider a response mostly defending the criticisms “beyond awesome”. 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).…

[deleted]

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

#132

Post by derrick_jensen »

edwinwee wrote: post #68
derrick_jensen wrote: post #65

Earlier quoted context omitted.

Honestly, I don't find their support helpful with fixing any of my issues, and asking the same question multiple times gives completely different responses. I managed to completely break the Stripe Test API (nothing works, always "in the process of deleting"), and I've been in support limbo for at least a week now. Haven't looked into the alternatives, but I hope I can move most commerce over to Bitcoin since I can r…

Hrm, not good. Could you add me to that email chain and I can help? (edwin@stripe.com)

Nah, I don't want to be that guy. In the meantime I've just locally stubbed all Stripe API calls, since internal integration tests are all I need for non-production uses. I've also reached the point where regular production deployments make sense (or at least the payments logic is stable enough).

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

#133

Post by BrandonMarc »

pc wrote: post #101
tomc1985 wrote: post #100

Earlier quoted context omitted.

> we built an ML engine to automatically optimize the bitfields of card network requests. Uh, what?

Card network requests are comprised of fairly complex ISO 8583 messages. ( https://en.wikipedia.org/wiki/ISO_8583. ) We now have enough data across Stripe to implement an ML engine to optimize these requests on a per-issuing bank basis. As mentioned in original comment, this helps collect a lot more "free" revenue for our users.

What is meant by "free" revenue? I'm wondering how the one leads to the other.

Does this mean, lower processing fee/less need to increase processing fees?

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

#134

Post by slivanes »

pc wrote: post #66
mchusma wrote: 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…

Does this keeping of fee also apply to voided non-captured payments?

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.

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

#135

Post by foo_llc »

pc wrote: post #77
totalZero wrote: post #74

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…

You're right! (Though I am.) I edited the comment.

I guess your comment was not... pc enough.

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

#136

Post by hellotomyrars »

inferiorhuman wrote: post #112
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…

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.) A phrase that comes to mind is: two wrongs don't make a right.

Reminds me when my Charter/Spectrum told me that even though I cancelled my service 2 days into the billing period, that I paid for a fixed term of service per billing period and they would not give me a prorated refund.

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

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

#137

Post by floatingatoll »

pc wrote: post #66
mchusma wrote: 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…

Is there a Stripe permalink (blog, tweet, etc.) from back in 2017 that describes this change back when it was announced? And/or for this year’s change, that drops the exclusion?

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

#138

Post by hawkice »

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…

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.

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

#139

Post by polemic »

Silhouette wrote: post #128
polemic wrote: post #47

Earlier quoted context omitted.

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

I don't quite understand this comment. In my experience, payment processors (and related services) are somewhat unique in providing test gateways & APIs. Unlike other API services you can write integration tests against their test gateways. What are part of our industries is that normal? Most API-first services don't provide test endpoints at all.

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

#140

Post by elijahparker »

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.

Post reply on HN