How Candy Japan got credit card fraud somewhat under control

<i>If you suspect an order is fraud, don&#x27;t go out and say to the criminal &quot;hey, I declined your super suspicious order!&quot;. Instead, play dead. Pretend they got you. Tell them &quot;thank you for your order&quot;, behaving exactly the same way as if it really was a successful order.</i><p>The name of the game is to make things cost more for your enemies than they cost for you. Removing instant feedback is key. Instant feedback is great. Delayed feedback is costly.<p>This is in large part why most DRM and anti-cheat failures happened. Companies and developers need to think about the economics of what&#x27;s going on. It&#x27;s not the side with the trickiest mechanism that wins. It&#x27;s the team with economics on their side.<p>(Amateurs: tactics, pros: logistics)

PM from a fraud detection company here. One thing I didn&#x27;t see mentioned on this thread is Device ID, which is very common on fraud detection platforms. When a user comes to your website or mobile app, you have access to hundreds of signals from their device. Some like IP address are easy to spoof. Others like whether the user has changed their phone alarm from the default settings are often ignored by fraudsters but surprisingly telling signals (fraudsters don&#x27;t bother to change from default settings). We wrote an article on some interesting findings recently here: <a href="https:&#x2F;&#x2F;simility.com&#x2F;device-recon-results&#x2F;" rel="nofollow">https:&#x2F;&#x2F;simility.com&#x2F;device-recon-results&#x2F;</a>. A good device ID product can not only tell if the same fraudster is accessing your app repeatedly while pretending to be different users, it can detect risky user profiles when they land on your app. Before they even make a payment.

So it appears that a combination of (1) removing instant feedback (not alerting fraudsters as to the success&#x2F;failure of their charge) and (2) giving a grace period to review and cancel charges has given Candy Japan some breathing room.<p>Though it does seem that this requires a manual step (2) before sending charges through, does anyone have experience using a fraud detection API, like Maxmind&#x27;s minFraud [1] or any other, in an attempt to avoid having to review each charge?<p>[1] <a href="https:&#x2F;&#x2F;www.maxmind.com&#x2F;en&#x2F;minfraud-services" rel="nofollow">https:&#x2F;&#x2F;www.maxmind.com&#x2F;en&#x2F;minfraud-services</a>

I&#x27;m guessing this has been asked before, but why not just use a credit card processor that handles all of that stuff for you. Seems like they are in the business of selling Japanese candy, not preventing CC fraud.<p>Am I being naive here?

I have a website that processes a fairly small number of monthly credit card transactions, 1-4 per day. However, it didn&#x27;t take long for the website to be used as a place for requests, mostly from Vietnam, to check the validity of CC numbers. It cost me a lot of money in chargeback fees.<p>I ended up implementing a system using Braintree to do 1) Request an AUTHORIZATION for the amount 2) If the AUTHORIZATION fails, return the error (sounds like I need to change this part, but how to do it without hurting legitimate users?) 3) Send information, including IP and email address, to minFraud 4) If the minFraud riskScore is &gt;= 20, request a VOID on the authorization request 4b) If the riskScore is low, submit a REQUEST SETTLEMENT on the AUTHORIZATION<p>This has worked extremely well, but a few still slip through the minFraud check.<p>Even though Braintree offers it&#x27;s own fraud checking, I still feel more comfortable with minFraud. I really wish that processors like Braintree would put more effort into fraud detection.<p>I NEVER have this issue with PayPal transactions. Even if it&#x27;s fraud, they just reverse the transaction and there&#x27;s no chargeback fee.

I remember building a subscription system back around 2009-10. Very few of the tools available now existed back then, and things were much less efficient. Or at least that what it seems like looking back. The service targeted competitive gamers (teenagers, early 20s) and I&#x27;ve always suspected that we had to deal with a higher incident of attempted fraud than would be the case with other audiences.<p>If I never again have to deal with a situation where some kid &#x27;borrowed&#x27; mommy or daddy&#x27;s credit card, I&#x27;ll die happy. No amount of fraud detection can prevent that situation.

Thanks for the insights.<p>I&#x27;ve been fighting this fight for over 17 years now. The landscape has changed a lot - mostly for the better IMHO. In particular, issuers are taking more responsibility for checking the validity of the cards but some of them are hopeless and there is still a way to go.<p>Criticise me all you like but I still have a blacklist of countries where I will never send physical goods to (unless they direct deposit the money, for one of my sites).<p>Not sure if it&#x27;s relevant for &quot;subscription&quot; model businesses but Stripe and a couple of other providers have an option to charge the card immediately or just get authorisation for the amount. The authorisation is only held for seven days, but I have found that this has often been enough for the owner of the card to notice and cancel the authorisation before the charge happens. I haven&#x27;t checked but this could also solve the &quot;instant feedback&quot; problem for providers that give it as &quot;authorsied&quot; is less conclusive than &quot;charged&quot; for the scammer.

When I worked on an e-commerce website shipping physical goods we would only ship to the customer&#x27;s billing address for credit card payments. Anyone shipping to a different address needed to call their credit card company to add the address (every credit card company I&#x27;ve dealt with would allow customers to have multiple valid addresses on file), or use a different payment method. We never had big issues with fraud and I don&#x27;t recall a customer ever complaining about it. I think in 3 years we had 2 chargebacks due to fraud.

Eliminating immediate feedback about failed transactions makes things harder for everyone the fraud detection system identifies, both fraudsters and the many false-positives. And the false-positive rates seem very high, IME; it seems like I and everyone I know has encountered that problem multiple times.<p>Imagine that you place a legitimate order and they don&#x27;t tell you it failed; how do you find out? Days later when the order never arrives? That would result in very angry customers.

I really love how open Candy Japan has been with the business on HN, since the beginning. Thanks!

We exclusively use PayPal as they kindly cover all of our transaction fees. However, we still experience fraud which creates work for accounting and Customer Service.<p>A rules-based approach has helped, but we&#x27;ve also been playing around with SiftScience[1] and I&#x27;ve seen it do wonders for some sites, so we&#x27;ll likely be implementing it. The key problem is keeping the false positive rate down, as we don&#x27;t want to inadvertently block our legitimate users.<p>[1] <a href="https:&#x2F;&#x2F;siftscience.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;siftscience.com&#x2F;</a>

In the article, PayPal it&#x27;s often mentioned that PayPal is generally disliked.<p>As an international customer, I prefer PayPal over giving them my credit card details. When entering my CC, there is a big risk that my data gets stolen (is the data truly securely transmitted, stored, and processed?). I know I can request a refund that any time with my bank but that is a big hassle. I have to write them a physical letter, and wait for a couple of days. During that period, my CC is blocked and I they will likely issue me a new credit card (which costs 10€). When paying with PayPal, I can report a fraud online or call them and they have been really quickly in responding (I have once not gotten a product and they were very quick in issuing a refund). Also, I feel way more comfortable using PayPal because I can see that the site I&#x27;m entering my information to is actually PayPal, and I have two factor authentication. Before I didn&#x27;t have a CC, PayPal was the best solution because they would just withdraw the money from my bank account and they merchant would get their money immediately.<p>I can understand why PayPal is not a good choice for sellers (I&#x27;ve heard stories where PayPal blocked merchant accounts for a few months without giving them their money they had on PayPal, and refusing any new transactions). So, can you explain to me why PayPal is a bad&#x2F;unpopular choice as a customer.

My understanding is that Stripe is pretty much the de facto solution to get started with credit card payments on your site, and if you&#x27;re relatively low volume you can review for fraud and manually reject it yourself.<p>I&#x27;ve set up stripe before, so I have a casual understanding of how it works, but I&#x27;m curious what an attacker would be able to do (worst case) if a server I have Stripe payments on gets rooted. Are they only able to charge legitimate customers&#x27; cards for the period of time that a payment token is active? Or I suppose they could re-direct the payment page to their own payment page. If they steal the Stripe secret key is there a way they can steal money using it? (other than just bulk testing if they can charge cards)

Is there no service that does CC processing and fraud detection already?<p>I would think it does not make sense for every ecommerce merchant out there to build their own solution.<p>Bemmu, you say you use PayPal - isn&#x27;t PayPal also accepting Credit Cards? Don&#x27;t they do the fraud detection in this case? I would expect them to have a huge advantage. You only see the IPs and other metadata from a few customers. They see millions and should be able to do way better fraud protection.

What&#x27;s the best way to do &quot;no immediate feedback&quot; when you&#x27;re selling something that is instantly delivered? (Site paywalls, for instance.)

I wrote a similar system for an ecommerce site-<p>attached session data, &quot;remora data&quot;, tracked IP&#x27;s, (in fact trace routed all IP&#x27;s looking for suspicious proxy flags like going through Ghana), browser meta data- etc etc. I&#x27;m proud of how robust it ended up being. Constantly recursively crunching shipping addresses, CC numbers, IPs, all that jazz and accounts- so if someone tried several different cards their account would be flag, which would flag their IP which would then trickle down the system.<p>Of course never letting an attempted scammer know the system was on to them- in fact encourage them to keep using more cards and try different combinations so the flagging system would grow over time. Sure we got some false positives, but drastically cut down on repeat scammers. :)<p>In which case we just encouraged a phone call and solid proof of information for an account override.<p>It was war! Good article!

Not sure if the author tried this, but there are many experts on carding around the internet (the most famous being Brian Krebs) who might give advice for free on credit card fraud countermeasures. The simplest way to find them is to google for presentations at hacker conferences about carding, cyber criminals, credit card theft, etc.

What if a real users mistypes their credit card number... your order was successful.

Hey bemmu, your presentation last year at Hacker News Kansai was really interesting, and I learned a lot. Thanks for putting the time into following up!

This article does not solve anything. Only thing I have found working is 3D security request for VISA cards.

I use chargebee so much better and cheaper than recurly

the problem is credit cards. the should be depricated

<a href="http:&#x2F;&#x2F;d.pr&#x2F;i&#x2F;x0JD+" rel="nofollow">http:&#x2F;&#x2F;d.pr&#x2F;i&#x2F;x0JD+</a> vs <a href="http:&#x2F;&#x2F;d.pr&#x2F;i&#x2F;16wJh+" rel="nofollow">http:&#x2F;&#x2F;d.pr&#x2F;i&#x2F;16wJh+</a><p>Not sure what the rules are, but I thought it might help.