Dec 8, 2017

Improving Watsi's fraud prevention

Watsi.org — a great company — recently published a blog post titled Stopping Sharon. It describes how they deal with and attempt to prevent “online donation fraud.”

Quotes because “online donation fraud” makes it seem worse than it is: fraudulent transactions, most of the time from someone with a stolen credit card, are made to check the validity of a credit card.

If there was one thing I am an expert in, it’s fraud.

Going through their post, I’ll go into detail about how each measure taken builds into the bigger picture of a transaction and its validity.

Our first line of defense is our payment processing provider, Stripe.

You should never trust your payment processor to do anything but run your transactions. Their anti-fraud is mostly a joke, and they’d rather have the $15 chargeback fee, anyway.

They help by blocking cases where there is an expired credit card, wrong security code, or some other egregious mistake.

Any payment processors don’t process transactions with an invalid/expired card, and you have the choice to validate the CVV, so why not? After all, the only large-scale website that doesn’t validate CVV is Amazon, and nobody is Amazon but Amazon.

We’ve implemented reCAPTCHA to validate that donations are being made by actual humans, not automated software designed to test credit cards.

It’s always important to block scripts. However, someone who is dedicated to using your site to check the validity of cards will use one of the recaptcha-solving-services that cost less than a cent per completed captcha. If I’m a card-checking service charging $0.50-$2 per checked card, I love you.

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

So you had a lot of transactions that were scripted and probably failed to see if browsers were actually completing the transaction. Note: most carders don’t use Selenium when automating checkers.

Requiring donors to enter zip codes had no effect on the amount of fraud, and we also wanted to be careful about rejecting legitimate charges.

Requiring donors to enter zip codes does not mean you’re validating those zip codes against the billing address of the card. I’m assuming this box was left unchecked within Stripe. Valid billing addresses are and always will be a hot commodity.

Our manual review starts by reviewing the email associated with the donation. 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!).

So they should use pam.beasley@theoffice.com. Got it. Except, a lot of carders who actually care about validating a credit card know this. They don’t use throwaway emails. They use generic things at the big 3 providers, with addresses like hoopdreams12@gmail.com.

Stripe displays the IP address for each donation, so we can see if a credit card from South Africa is being used in France.

Any carder who cares about validating a credit card knows to get a fresh SOCKS5, not on a blacklist, that will geolocate to and around known addresses associated with the card such as a billing address or zip code. This is carding 101.

Stripe also tells us how long somebody spent on the site and if any previous charges were disputed as fraud.

They do this by email and by card number. Most of the time it’s a hit-and-run with a transaction: ensure the card is valid, use it on whatever site the carder wants, and then dump it.

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.

The idea is good, but again, most people who care about validating a card will use an actual email address (see hoopdreams12@gmail.com). Ensuring that a transaction receipt is opened seems strange to me — I don’t open many receipts — but maybe they know something that I don’t.