Watsi.org: Dealing with donation fraud | Hacker News Reader

Watsi.org: Dealing with donation fraud

blog.watsi.org

14 pointsprymitive6 comments

This was actually a pretty good read on dealing with card fraud, though most of it will be familiar to anyone dealing with e-commerce. I hadn't considered that charities would be a target for card testers, but it makes sense.

For related reading, there's the blog post of when Candy Japan was targeted by card testing fraudsters:

https://www.candyjapan.com/behind-the-scenes/how-i-got-credi...

This is a mostly terrible read on how to prevent fraud. As someone who has worked with Target and Michael's with their breaches, as well as someone who was that guy carding your sites...

> Our first line of defense is our payment processing provider, Stripe. They help by blocking cases where there is an expired credit card, wrong security code, or some other egregious mistake.

How is validating a CVV (everyone but Amazon does it) combating fraud? It's not. When you buy a card from a shop, you're given the option to sort by cards with the CVV or not. This isn't 1999. Don't get me started about Stripe's anti-fraud, either, because it's shit.

> Since adding reCAPTCHAs to our checkout flow in May 2016, disputed charges have decreased by 85%.

Okay, great, that'll stop the bots. Most of the time, though, carders will check against a site for a one-off transaction manually so they can go ahead and use the card.

> Requiring donors to enter zip codes had no effect on the amount of fraud,

I would have guessed this would have had an effect. A valid billing address on cards these days is rarely required, though it's common to see a zip code validated.

> Our manual review starts by reviewing the email associated with the donation.

This is good. Hell, check for their social media accounts and see if they reside where the request IP is from.

> An address that looks like something a cat made up by stepping on a keyboard is a good clue that something may be off (hello, asdfgh@aol.com!).

This is bad. Anyone could enter pam.beasley@theoffice.com ... it's not like you're going to require someone to confirm their email address to take their money.

> Stripe displays the IP address for each donation, so we can see if a credit card from South Africa is being used in France. Stripe also tells us how long somebody spent on the site and if any previous charges were disputed as fraud.

This is okay, but do you really think that someone who _really_ wants to validate a credit card isn't going to use a SOCKS5 that's not on a blacklist? It's trivial and inexpensive, and you might as well with card prices approaching $10 for a good BIN.

> As a final line of defense, we use Mailgun to verify whether our transaction emails are being sent to a real account and if they are being opened.

This is good, but some carders have a hoard of emails waiting to be used.

... if anyone wants to talk shop or has problems with fraud, my email is in my profile.

> Hell, check for their social media accounts and see if they reside where the request IP is from.

Not to sidetrack from your whole thoughtful response, but be careful not to assume that everyone has social media.

There is life outside Facebook.

Of course there is; my folks don't have Facebook. But it's one of those points of data that, if you can confirm, should increase the confidence of a valid transaction.

Good case by case review of the measures. What I would love to see Stripe do more is look at the billing history for a particular card since they are a platform that extends across so many companies using them, so if they catch fraud in one place it immediately gets triggered elsewhere. This is already the case, but would like to see this get more attention.

But as for the original comment, certainly there are pros and cons to each measure and fraud prevention is a large mesh of filters, rules, etc, but what would be an addition that you recommend, that most providers aren't doing that would really help decrease fraud?

Here is my experience handling fraud in a very similar situation:

1) Checking the transactions manually only works if you have a very low transaction volume and you have to somehow delay the booking which is not always possible or desired

2) You can code rules like "asdf@" is likely fraud, or every email that doesnt contain a firstname (from a list of common firstnames) increases the fraud-score. But this rules list gets really long really fast and is almost always reactive (latest fraudster used a throw-away email, lets add a check for those).

3) You can use machine learning to convert inputs (name, email, amount, etc) to output (fraud score). That does work reasonably well and limits the amount of coding you have to so (see 2.)

4) The most important thing I learned: The type of fraudster who checks 100 cards with $5 transactions doesn't care (or maybe even notice) if 85% of those transactions/checks fail. He'll try again with the next batch and check the rest elsewhere. So you need to implement a system that bans the fraudster on the first try (or as soon as possible) and doesn't let him try again (unless he changes so many variables that it becomes to much work to outplay your system).

I found a way to do 4. and we haven't seen much fraud since then.

Reply on news.ycombinator.com