
Watsi.org: Dealing with donation fraud - prymitive
http://blog.watsi.org/donation-fraud/
======
SyneRyder
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...](https://www.candyjapan.com/behind-the-scenes/how-i-got-credit-card-
fraud-somewhat-under-control)

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

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

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

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

