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.
This is in large part why most DRM and anti-cheat failures happened. Companies and developers need to think about the economics of what's going on. It's not the side with the trickiest mechanism that wins. It's the team with economics on their side.
(Amateurs: tactics, pros: logistics)
http://gameological.com/2013/05/inventory-9-games-with-creat... (it is the first one)
Better to reliably catch the humans behind this and impose stringent legal penalties than allow them to keep guessing without a cost for being wrong.
You can get disposable physical addresses as well.
It is part of why some companies flag a mailing address I use as a fraudulent order. I primarily use it to avoid handing out my RL address on domains that don't allow whois protection.
At my last company I build systems specifically designed around wasting the time of people that we "caught". We used to keep a dashboard with the top abusers on a wall in the office once they'd be caught to show how much of their time we were wasting. It was therapeutic.
It's incredibly easy to dupe and manipulate. If someone is determined enough, they can just edit the packet before it hits your server, or install another app/font/package/etc to change the fingerprint. "Well what about IMEI?" see reference to intercepting packets.
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's minFraud [1] or any other, in an attempt to avoid having to review each charge?
We tried MaxMind, for our use case it was pretty useless. The feature that sort of worked which we considered using was the geo-location stuff. Our idea was to see how close a customer was to where the goods where to be sent. Sadly the countries we operate in are to small, and IP location is to inaccurate.
As a test we ran a couple of months worth of fraudulent order data through MaxMind, with a success rate of 100%.
The best solutions we found is: - Block cards not issued in the country where you operate. This shield us from poor credit card security in countries like the US. - Enabled 3D Secure. This blocks all the amateurs - Manually call customers ordering for large amounts.
Generally speaking it's very difficult to tell the difference between a fraudulent order and a first time customer.
Please, don't do this. It's so annoying.
> Enabled 3D Secure
Yes, this is a really good idea.
I have evaluated a number of different options and I am about to start using Sift Science[1]. In addition to using standard ip address/email based information they also use social data and machine learning to identify fraud.
Their API/data model is the most well thought out and comprehensive one that I have come across and they allow you to back-fill up to 12 months of historical data for free to help improve your detection rates. They also have a console to assist with optional manual review workflows and store integration apis to allow full automation.
On top of all that they offer scalable pricing that works for both large and small business at 6c per transaction.
Obviously I can't vouch for their results yet, but what I have seen so far looks pretty good. If you have a fraud issue you should at least check them out.
However, you still need to use the same basic process:
Step #1 - No instant feedback
Step #2 - Your antifraud SaaS provider / process / whatever
Step #3 - Reject anyone who fails step #2 after ~24 hours.
Am I being naive here?
The best option is to get a PSP that will let you do selective fraud detection. Then you funnel large order and first time orders through the fraud detection, and skip it on repeat customers. Otherwise it can become an expensive service.
At $DayJob we have a similar process [e.g. Accept any card that passes the checksum, hand out rejections on a 24 hour delay after we've handled our fraud signals and processed the charge with the gateway]
The credit card processors aren't particularly interested in handling this for you and you [the merchant] pay the price if you gave the processor stolen card numbers.
Services like these:
https://www.signifyd.com/pricing/ [1% per transaction]
https://www.maxmind.com/en/minfraud-services [ $0.005 ]
would have no customers if you could get a reliable partner to handle this all for you for free-ish.
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 >= 20, request a VOID on the authorization request 4b) If the riskScore is low, submit a REQUEST SETTLEMENT on the AUTHORIZATION
This has worked extremely well, but a few still slip through the minFraud check.
Even though Braintree offers it'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.
I NEVER have this issue with PayPal transactions. Even if it's fraud, they just reverse the transaction and there's no chargeback fee.
The amount of grief that your solution causes me is significant. I'm a legitimate customer who does nothing fraudulent. However, whole swaths of the internet treat me as if I have leprosy just because my IP address is in Russia.
If combating CC fraud is leading to negative profits in those countries then cut them. If not, continue the war.
We essentially stamped it out overnight by giving false positives. If we detected and order as fraudulent (and you can do it in a number of ways, that you seem to be doing) - we'd show a 'Successful Order' page and send them a success email.
The guys that were pre-testing cards had bad data, and the guys trying to fraud would have to wait .. weeks to find out nothing came in the mail, and then try again, unsure what got them caught in the first place.
Personally, I'd avoid trying to interract with their card. Authing / voiding is going to cost you money, and if it slips through, you'll get a chargeback.
We only ever had one 'false positive' (or false-negative..?) - the guy emailed us inquiring about his order, we took some extra steps to check his card, and the problem was solved.
If I never again have to deal with a situation where some kid 'borrowed' mommy or daddy's credit card, I'll die happy. No amount of fraud detection can prevent that situation.
I'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.
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).
Not sure if it's relevant for "subscription" 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't checked but this could also solve the "instant feedback" problem for providers that give it as "authorsied" is less conclusive than "charged" for the scammer.
Imagine that you place a legitimate order and they don't tell you it failed; how do you find out? Days later when the order never arrives? That would result in very angry customers.
In this case, the idea is these are people who tripped red flags for you, and upon investigation didn't give you any reason to believe they were legitimate orders.
If you're really worried, you can contact them and ask.
A rules-based approach has helped, but we've also been playing around with SiftScience[1] and I've seen it do wonders for some sites, so we'll likely be implementing it. The key problem is keeping the false positive rate down, as we don't want to inadvertently block our legitimate users.
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'm entering my information to is actually PayPal, and I have two factor authentication. Before I didn'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.
I can understand why PayPal is not a good choice for sellers (I'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/unpopular choice as a customer.
I've set up stripe before, so I have a casual understanding of how it works, but I'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' 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)
I would think it does not make sense for every ecommerce merchant out there to build their own solution.
Bemmu, you say you use PayPal - isn't PayPal also accepting Credit Cards? Don'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.
---
Peter Thiel on PayPal: "In mid-2000, we had survived the dot-com crash and we were growing fast, but we faced one huge problem: we were losing upwards of $10 million to credit card fraud every month. Since we were processing hundreds or even thousands of transactions per minute, we couldn't possibly review each one - no human quality control team could work that fast.
So we did what any group of engineers would do: we tried to automate a solution. First, Max Levchin assembled an elite team of mathematicians to study the fraudulent transfers in detail. Then we took what we learned and wrote software to automatically identify and cancel bogus transactions in real time. But it quickly became clear that this approach wouldn't work either: after an hour or two, the thieves would catch on and change their tactics. We were dealing with an adaptive enemy, and our software couldn't adapt in response."
They ended up going with a hybrid approach where their algorithm would flag suspicious transactions, which would then be manually reviewed.
PayPal is an option, unless you have low margins, it's a very expensive way of accepting a credit card. It's also a terrible user experience for people in countries that aren't to familiar with PayPal.
The 'trial' period is advertising.
attached session data, "remora data", tracked IP's, (in fact trace routed all IP's looking for suspicious proxy flags like going through Ghana), browser meta data- etc etc. I'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.
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. :)
In which case we just encouraged a phone call and solid proof of information for an account override.
It was war! Good article!
See https://en.wikipedia.org/wiki/Luhn_algorithm for details
But, ok, what about an innocent CCV typo.
You need to give real users errors when they make mistakes.
Not sure what the rules are, but I thought it might help.
