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

241–250 of 275 posts

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

#241

Post by patio11 »

nickjj wrote: post #123
pc wrote: post #120

Earlier quoted context omitted.

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

You're welcome to do your own risk scoring on any signals you want prior to directing us to charge a credit card for you. You're also welcome to do post-charge processing using our risk scores. Some companies will e.g. do post-transaction reviews prior to shipping; some write their own workflow SaaS into their admins to do this.

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

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

#243

Post by freeone3000 »

patio11 wrote: post #241
nickjj wrote: post #123

Earlier quoted context omitted.

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

You're welcome to do your own risk scoring on any signals you want prior to directing us to charge a credit card for you. You're also welcome to do post-charge processing using our risk scores. Some companies will e.g. do post-transaction reviews prior to shipping; some write their own workflow SaaS into their admins to do this. If you don't choose to write your own software using your own data, that's cool; you can…

The issue is there's no hook between when the transaction is sent and the risk score is analyzed, and when the transaction is processed - after the risk score is returned, the transaction is already processed, and it's too late to deny!

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

#244

Post by sovande »

thowfaraway wrote: post #194
sovande wrote: post #184

Earlier quoted context omitted.

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

PayPal does not look so bad. Their API and documentation has also become pretty good. 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.

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

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

#245

Post by quelltext »

nickjj wrote: post #123
pc wrote: post #120

Earlier quoted context omitted.

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

My understanding is that what Radar does that you cannot is the ML to calculate the risk scoring and they give that to you for free: https://stripe.com/docs/api/charges/object#charge_object-out...

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.

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

#246

Post by nickjj »

patio11 wrote: post #241
nickjj wrote: post #123

Earlier quoted context omitted.

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

You're welcome to do your own risk scoring on any signals you want prior to directing us to charge a credit card for you. You're also welcome to do post-charge processing using our risk scores. Some companies will e.g. do post-transaction reviews prior to shipping; some write their own workflow SaaS into their admins to do this. If you don't choose to write your own software using your own data, that's cool; you can…

> You're also welcome to do post-charge processing using our risk scores.

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?

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

#247

Post by nickjj »

quelltext wrote: post #245
nickjj wrote: post #123

Earlier quoted context omitted.

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

My understanding is that what Radar does that you cannot is the ML to calculate the risk scoring and they give that to you for free: https://stripe.com/docs/api/charges/object#charge_object-out... 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…

> But you can. The majority of what Radar custom rules allow you to do you can implement fairly easily on your own. You can even take the risk scoring into account by separating auth (then looking at risk level and make your own decisions) and capture: https://stripe.com/docs/api/charges/object#charge_object-out...

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.

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

#248

Post by jasonkester »

commoner wrote: post #234
jasonkester wrote: post #224

Earlier quoted context omitted.

For what it's worth, the success of my business doesn't hinge on whether Stripe gives me a dollar. I hope yours doesn't either.

The fee is only $1 when the transaction amount is $24.14. The fee is $29.30 for a $1,000 transaction. For industries with lower margins or higher refund rates, Stripe's refusal to return the fee on refunded transactions is a problem. Regardless, Stripe's nickel-and-diming is not something to be grateful for in any industry when there are competitors that don't do the same.

Feel free to substitue $29.30, or even $1,000 as values that should not sink one's software business.

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.

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

#249

Post by martin_a »

rfrey wrote: post #233
martin_a wrote: post #230

Earlier quoted context omitted.

Sounds like Google. Either you know somebody deep in there or you are lost with your request. Your problem.

In the case of Google we have a supertanker full of anecdotes of them ignoring customers with problems. In the case of Stripe we have no evidence their customer service is non existent outside social media flareups. To the contrary,they seem to have a pretty good reputation. 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 n…

You're right. Maybe I was too harsh.

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

#250

Post by patio11 »

nickjj wrote: post #246
patio11 wrote: post #241

Earlier quoted context omitted.

You're welcome to do your own risk scoring on any signals you want prior to directing us to charge a credit card for you. You're also welcome to do post-charge processing using our risk scores. Some companies will e.g. do post-transaction reviews prior to shipping; some write their own workflow SaaS into their admins to do this. If you don't choose to write your own software using your own data, that's cool; you can…

> You're also welcome to do post-charge processing using our risk scores. 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 fo…

I understand that you are contemplating a build-or-buy decision and do not want to purchase the software which we sell. You can ask the engineering teams that you want to dedicate to this to scope out the build option; there are likely tradeoffs you can make which would make this a 3 engineer-year project or 30 engineer-year project. It is implausible that their design document for the build option will conveniently fit into an HN comment. I cannot write that design document for you as I do not have a good understanding of what data you believe you possess at the moment or e.g. the margin characteristics of your business, which would likely determine your tolerances with respect to some tradeoffs to make at design stage.

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.

Post reply on HN