TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Watsi.org: Dealing with donation fraud

14 点作者 prymitive超过 7 年前

3 条评论

SyneRyder超过 7 年前
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&#x27;t considered that charities would be a target for card testers, but it makes sense.<p>For related reading, there&#x27;s the blog post of when Candy Japan was targeted by card testing fraudsters:<p><a href="https:&#x2F;&#x2F;www.candyjapan.com&#x2F;behind-the-scenes&#x2F;how-i-got-credit-card-fraud-somewhat-under-control" rel="nofollow">https:&#x2F;&#x2F;www.candyjapan.com&#x2F;behind-the-scenes&#x2F;how-i-got-credi...</a>
joshmn超过 7 年前
This is a mostly terrible read on how to prevent fraud. As someone who has worked with Target and Michael&#x27;s with their breaches, as well as someone who was that guy carding your sites...<p>&gt; 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.<p>How is validating a CVV (everyone but Amazon does it) combating fraud? It&#x27;s not. When you buy a card from a shop, you&#x27;re given the option to sort by cards with the CVV or not. This isn&#x27;t 1999. Don&#x27;t get me started about Stripe&#x27;s anti-fraud, either, because it&#x27;s shit.<p>&gt; Since adding reCAPTCHAs to our checkout flow in May 2016, disputed charges have decreased by 85%.<p>Okay, great, that&#x27;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.<p>&gt; Requiring donors to enter zip codes had no effect on the amount of fraud,<p>I would have guessed this would have had an effect. A valid billing address on cards these days is rarely required, though it&#x27;s common to see a zip code validated.<p>&gt; Our manual review starts by reviewing the email associated with the donation.<p>This is good. Hell, check for their social media accounts and see if they reside where the request IP is from.<p>&gt; 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!).<p>This is bad. Anyone could enter pam.beasley@theoffice.com ... it&#x27;s not like you&#x27;re going to require someone to confirm their email address to take their money.<p>&gt; 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.<p>This is okay, but do you really think that someone who _really_ wants to validate a credit card isn&#x27;t going to use a SOCKS5 that&#x27;s not on a blacklist? It&#x27;s trivial and inexpensive, and you might as well with card prices approaching $10 for a good BIN.<p>&gt; 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.<p>This is good, but some carders have a hoard of emails waiting to be used.<p>... if anyone wants to talk shop or has problems with fraud, my email is in my profile.
评论 #15878436 未加载
评论 #15877804 未加载
growt超过 7 年前
Here is my experience handling fraud in a very similar situation:<p>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<p>2) You can code rules like &quot;asdf@&quot; 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).<p>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.)<p>4) The most important thing I learned: The type of fraudster who checks 100 cards with $5 transactions doesn&#x27;t care (or maybe even notice) if 85% of those transactions&#x2F;checks fail. He&#x27;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&#x27;t let him try again (unless he changes so many variables that it becomes to much work to outplay your system).<p>I found a way to do 4. and we haven&#x27;t seen much fraud since then.