We will be implementing a fraud detection service. cs-cart will be the first official cart supported. But others will be supported at a later date after we develop the reference model.
We wanted to give you an idea of the types of things we are doing (though some are not discussed in detail due to them being proprietary).
In general, this is a “pre payment” type of detection (I.e. customer/order validation). We feel that the various payment providers and/or processors can afford to do a much more detailed job on dealing with cart/payment fraud than we would ever hope to.
So we are focusing on customer, order, device and location validation, validation.
You will be able to select and “score” rules related to what our server (and the addon) determines about the customer and/or the billing/shipping relationship to the ip address and/or domain. We will also try to detect whether an order is being placed by a robot or not.
A “score” is based on a ranking between 0 and 100 for an order. Our server is called with the IP address and address info of the bill/ship (if the same, or a call for each if selected and they are different). No IP or customer addresses are stored on our server. This is for geo-location only. IP/address info is evaluated on our server and distance and “top level scoring” is returned to the client which establishes the “base ranking” of the order. It can be anywhere from 50 to 100 (you specify weight to each rule).
Each rule selected is evaluated and the “score” is ranked. For example, if you had a rule established that the billing location must be within 25miles of the location of the IP address and the score was set for “10” and you had another rule for that mileage being 50 miles (same score) and the distance from the IP to the billing address was 30 miles, the score would be -10 for those rules (one passed the other failed).
You would set a trigger point of where an order is to NOT be processed. I.e. 30. So if you have rules that fail and the resulting score is less than 30 then the user would see a message (adjustable via lang var) of something like “There is a problem with your order, please contact customer service.” The admin would be able to override the rejection and let the order continue after contact. Or you can allow it to be processed by the payment provider for a score down to say 50 but orders between a score of 30 and 50 would be flagged and placed into a special order status (I.e. Potential Fraud). Orders above 50 would proceed normally and the order (and customer if registered) would inherit the score of the order.
If the customer is a registered customer then this fraud ranking will follow them and if a ranking exists and is below the “submit to processor” threshold, then any future order by them would never even be created.
There are a ton of details to work through but wanted to start the feedback loop on your thoughts based on what you see in your businesses.
Examples of some rules might be:[list]
[]Ship address different than bill address
[]IP distance (bill and/or ship)
[]IP location (banned countries)
[]Customer order history (prior fraud ranking)
[]Valid device used (browser versus robot)
[]Bad email domains (domain doesn’t exist or can’t be resolved)
[]Email domain in blacklisted country
[]Uses public email (gmail, yahoo, hotmail, etc.)
[]Order details such as
[list]
[]Max of N items in order
[]Max of N quantity for single item
[]Max of N quantity for all items
[/list]
[/list]
Be interested in any feedback you might have.
Nice one tbirnseth.
Thats a realy complex Addon,and its going to need a large beta tester base.
I now for a fact that online travel agencies that have the most problems with fraud, use a kind of ready made software that work with analytics, behavioral tools and holistic approaches, rather than rule-based approaches.
Most frauds are with fake credit cards, so do you have in mind to intergrade a solution on that ?
Is your solution going to be able to support a wide variety of devices? It should also differentiate between consumer and business behavior as B2B is also a great deal of business these days.
Software as a Service (SaaS) offerings continue to gain market share. Are you planing for that kind of solution?
Fotis
Hey Fotis,
Yes, it will end up a big project and the goal is to grow it over time. But I like to larger (and complete) implementations that focus on interacting with the merchant versus the customer.
There are current services available that can do the full gambit of purchase, payment and risk management assessments. Kount.com is an example and I've done an integration with them for a client. However, they are very expensive (like $0.50/transaction) and there can be multiple transactions per order…
Doing things based on heuristics can get you locked into a particular industry. My goal in this project is to detect fraudulent customers before the order is actually placed and either notify the admin of such an order or deny it moving beyond the placement (I.e. before payment processing). I'm sure the rule generator will also evolve over time to be more “constraint based” than absolute, but the initial release will be more pass/fail.
It would be partially a SaaS offering (for location and other generic rules/heuristics) but the bulk would be done on the merchant site since one has much more of the specific order data available on site versus sending all of that across the network to be evaluated. The other goal is to keep the off-site interaction to a minimum and have it be as fast as possible. Keeping the majority of the business rules on the client side enables one to set different rules based on B2B or B2C. It puts the logic in the hands of the merchant.
Cs-cart will be the reference model. In the end, my goal is to sell transactions that are a solid value proposition (insurance) for the merchant. I hope to work with other developers who work with other shopping carts to make the service available to other providers.
As far as device type goes, I'm assuming you mean differentiating between mobile and desktop. I.e. a purchase from a mobile device would probably want to be a lot more flexible in the distance determinations than a desktop (I.e. fixed location) device.
This is NOT intended to detect fraudulent card activity. This is intended to help the merchant identify potential fraud to avoid charge backs and other payment fraud. As it stands today, if I sell someone a DVR for $100 and they pay me with a stolen credit card where the processor is not yet aware of the theft, I ship the product and then at the end of the month the customer files a complaint via their cc company, the cc company does a charge back and I end up loosing the revenue and have lost the goods too since they've already shipped. As a merchant, I get hit double for the fraudulent order.