Hacker News new | past | comments | ask | show | jobs | submit login

I like how the author doesn't immediately reject orders if they have just one sign (IP address country different from shipping country, shipping to a reshipping center, etc.) but looks at all the indicators as a whole to make a decision.

Edit: isn't this how Stripe Radar[1] works?

[1]: https://stripe.com/us/radar




From my experience, nothing drives users away faster than a false positive on a fraud check. You immediately lose all trust in the eyes of the users.


Yeah, but that's something you have to accept for the positive benefits. In a lot of online businesses, credit card fraud is just insanely rampant. You lose a lot more money by not doing checks with the occasional false positive than you do by not having it.

The cost of fraud is chargeback fee (usually ~15 bucks) + merchandise. It gets expensive fast. Every modern e-commerce business has to be fighting it now to stay alive. For certain SaaS / Software products the cost of failing to fight it is a tad lower, but for physical products it's killer.


>The cost of fraud is chargeback fee (usually ~15 bucks) + merchandise.

that's the least of the cost. the real cost of chargebacks is in the processing rate increases.


Sure, you can't ignore fraud.

We have a lot of those each months.

What is more important is to have a smart way to detect the frauds. Most clients that had received false positives never came back even with discount codes and apologies. Nobody likes getting stuck on a checkout page with an error message telling them they are in the wrong.


One way to optimize is to maximize expected revenue - expected cost of false positives or fraud.

A savvy business will know (or can estimate): customer lifetime value, false/true positive/negative rates of their fraud detection system, rate of charge-backs, expected rate of fraudulent purchases, revenue from given suspected transaction.

If average discounted customer lifetime value is $10k, charge-back rate is 2%, your fraud detection false positive rate is 0.1% and true negative rate is 99.9%, fraud detection true positive rate is 95% and false negative is 5%, customer is purchasing a $20 item. Then

* expected revenue if purchase is fraudulent: $0 * (true positive rate) - $20 * (false negative rate) = -$1

* expected revenue if purchase is non-fraudulent: $20 * (true negative rate) - $10k * (false positive rate) = $9.98

* total expected revenue value (with fraud detection enabled): (expected revenue if purchase is fraudulent) * (rate of fraudulent purchases) + (expected revenue if purchase is non-fraudulent) * (1 - rate of fraudulent purchases) = $9.7604

Without fraud detection, your expected revenue is: $20 * 0.98 = $19.6

Simplifying assumptions: false positive results in complete loss of customer value (realistically, replace this with big drop in customer lifetime value). Fraud rate is constant (realistically, should be modeled). Fraud rate is charge-back rate.

In this case, it's easy to see that seemingly low 0.1% false positive rate is still too high for this small of a purchase and these customer lifetime values. The 'smart' decision would be to ignore fraudulent purchases of this size in this case. (for this scenario, you need FPR below 0.004% with all else same)

Better model still would be a fraud detector that outputs a confidence score rather than "yes/no", and use the formula above to determine if the predicted false-positive-rate at this confidence level is sufficiently high to expect a revenue uplift from enabling the detector.


Or even better, one retailer I dealt with that did all their fraud checking manually after charging you.

So they took my money, decided they wouldn't sell to me, then I had to wait a week to get my money back.

At no point did they so much as call or email me to try and see if we could correct any issues with the information before initiating the refund.

I've spent more on identical products from other retailers just to avoid them.


I see it differently. A merchant who takes fraud seriously is someone I would trust more.


I had NewEgg flag a transaction of mine as fraudulent in 2009, they just silently cancelled it then gave me strange errors on the order status page. When contacted they said the transaction was flagged and there was nothing they could do.

I didn't use NewEgg again until 2017 as a direct result. That one bounced transaction (and frankly how they handled it) cost them six years worth of business that Amazon got (talking easily $3K+).

I think you're the edge case. Most customers will be somewhere between put out and outright angry.


The problem I see is NewEgg handled it poorly, it doesn't sound right that there wasn't anything they could do. That's NewEgg's problem and nothing wrong with actually flagging a transaction that requires a manual investigation.


Not even angry or slighted. People will just assume that Merchant X doesn’t ship to their area and they never go back because they never receive any information to the contrary.

I’ve only been flagged once, and that was when I was a new B&H customer. A quick phone call fixed the problem and in spite of changing addresses at least ten times since then, haven’t had a problem since.

However, it is occasionally a problem that B&H won’t ship to hotels.


NewEgg’s operating margin is probably between 3 and 10%, so that bounced transaction cost them ~$250 in profit. Would they have lost more than that by fulfilling your order size in 2009 if it had been fraud?


On the other hand I've shopped with NewEgg since 2005. I've had orders flagged as fraud once in a while both from NewEgg and also (more often, actually) from the bank when they receive the charge from NewEgg. While quite annoying, it is one of the many reasons I continue to order from them.


The more false positives they have, the more false negatives they're going to have and that's where it becomes an issue.


Fully agree. It multiplies the anxienty for a novice online shopper.


Yes, Stripe Radar will automate most of these checks. They also have the benefit of being able to see other merchants' transactions within their network, which helps when someone tries test transactions across a bunch of different merchants all at the same time from the same IP.


It seems to me like the author doesn't actually do anything programmatically, and instead has few enough orders that they eyeball it and do additional human steps. A good start but not scalable.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: