[AndroTux]

We solved this by introducing a silent block. If the system notices unusual behavior (too many payment attempts per user, for example), it no longer sends the payment attempt to the provider. Instead, it idles for a second or two and then just fails with a generic “payment declined.” Most attackers don’t notice they’re being blocked and just assume all credit cards are bad.

[quietbritishjim]

Sounds like any per-user detection wouldn't have worked in this case.

[williamdclt]

the "notice unusual behavior" is the hard part

[dylan604]

thousands of $1 charges and refunds in a 7 hour period seems unusual to me. then again, i've never run a site that received thousands of charges ever, so seeing it in a few hours would be obvious.

[datsci_est_2015]

Genuinely asking, are you a product manager? You’re giving me flashbacks to all of the PMs who suggested a 2-3 branch decision tree for a complex classification problem, because that’s what struck them as intuitive. We are just a few baby steps away from reinventing the entire field of fraud detection within this thread.

[dylan604]

Sir, I resent the implication! I do not lie with such swine!

It's easy to say that every site must add protections against every single type of attack, except it's impossible for site owners to be experts in fraud. While credit card processing vendors are expected to be experts in fraud. I ask you where in this situation would be the better place to implement fraud detection? Of the two places, whose more financially at risk?

[datsci_est_2015]

:)

I think we’re 100% in agreement: let the payment processors handle the fraud. Except payment processors unfortunately hold all the cards and will shut your site down if you don’t comply with their standards :(

[Terr_]

> reinventing

https://xkcd.com/793/