Just checked our Stripe dashboard and it looks like this has quietly been doing good work for us for many months now blocking suspicious charges. It took me a few clicks to find https://dashboard.stripe.com/search/rules?rule_token=block_i... and after going through a few of them, the per-charge risk factor descriptions are really helpful too. The high-risk reasons are messages like: "This card has been used from an unusually large number of IP addresses across the Stripe network over the last 24 hours." and "This email has been linked to an unusually large number of cards across the Stripe network over the last hour."
Thanks to Stripe for making it not-a-black-box! I hope others who build machine learning systems also find a way to make its decisions understandable by humans (when possible).
One thing to note is that the risk factor surfaced in the dashboard is the primary risk factor, but the final risk level is a combination of many different factors--it's not accurate to say that the charge was blocked only because the card country did not match the IP country. That said, if you are certain that there are areas where there are high numbers of false positives, Radar does provide tools for making corrections (by writing rules to allow or send charges to review, for example). I'm happy to talk more about the specifics in your case if you send me a note (and definitely let me know if there's a way we can make this clearer in docs/product) -- I'm tara@stripe.com.
Usually fraud systems are black boxes to prevent abuse, not because they can't be human readable.
I agree however that to my eye it does usually seem excessively black-box, as it's not like most fraudsters are idiots, they already know what tools are arrayed against them.
Prime example is MaxMind's minFraud. How long do you think it took for someone to pay $500 and test their card details + billing information + shipping information + sock5/rdp before submitting payment on a MaxMind "protected" webstore?
MaxMind isn't a black box either. You can pay 0.03 USD to get the full break down of scores on an inquiry. You can register and get an ID number to token your fraudulent VM/RDP with the card before submitting a real payment. That partially helps defeat their device tracking [1].
Purchasing minFraud or creating device ID numbers? If you're on a RDP or VM who cares? The trail will lead back to nowhere.
You want to create a history, a trail, so to speak with browser/device, IP, and card usage. MaxMind's device ID tracking is similar to what Radar is offering. You've used your card before on a MaxMind protected website with device ID creating LSOs. Now they have you fingerprinted and they can tell if you suddenly start making purchases from an unusual PC/IP. It helps you as a legitimate cardholder at the expense of your privacy.
Stripe uses IESnare when you sign up to determine if you have any sketchy internet history or are a previously banned user. It's a similar strategy, pose as a legitimate user for a week by browsing the internet normally and search for payment processors to "compare" online. Then sign up after you've created history on the device and IP.
If a system requires that it be a black box to prevent abuse, you should use another system. A black box with flaws that allow abuse is difficult to fix. With an open, auditable system, methods of abuse are more easily exposed and fixed.
The problem is not "flaws" being protected in a security-by-obscurity sense.
Rather, it's that these predictive models mostly consist of linear combinations of metrics. (By necessity: "linear combinations of metrics" is usually what most accurately reflects the real world.)
If you know exactly which factors, at what weightings, a given predictive model has, you can build a simple function to spread out your fraudulent activity that will ensure that you never exceed their fraud threshold in your aggregate score.
Say someone's anti-fraud model uses two factors: P(using a prepaid card) and P(using a Nigerian postal address). If you know the weights on those two factors are (0.3, 0.7), and you know that the system says "fraud" when you score above 1.0, then you can still do both of those things, just so long as you never do them both at the same time.
Basically the only thing that makes these systems useful at all is that their input-factors and weights are hidden information. There is no anti-fraud system that would survive being public; they'd all, as a class, be rendered instantly useless.
But you can't really harshly limit their methods. So long as a scammer uses the exact same method as a real customer would use he can get away with it. The effectiveness of fraud detection is finding where the scammer slipped up.
I like the rotating 3D model in the landing page very much. Are they using some sort of pre-baked library which lets you create such an visualization with 30 lines of Javascript, or is it 100% custom? Maybe someone can point me to a good resource for such elegant WebGL renderings.
Glad you like it! We used Three.js (https://threejs.org) to handle rendering the icosahedron itself. Three.js actually includes an icosahedron as one of its built-in primitives, however we also wanted to add some subtle details to the model such as rounded edges. So, we created a rounded version in Cinema 4D, and then rendered both that model as well as an invisible copy of the object using the Three.js primitive. The primitive gives us easy access to things like the vertex coordinates, that are then used to position the labels, which are plain DIVs and not rendered with WebGL.
Great work, result is awesome. Love how it pops in and fits with the page background nicely. I find your web pages and documentation to be pretty much the nicest on the internet.
They're using Three.js, but it looks like the spinning icosahedron is custom-made with about 300 lines of code. That includes calculating the vertices of the icosahedron, loading the model from a 3D model file, setting up the surface material characteristics, setting up the lights, animation, moving HTML nodes with the labels along with the vertices, and mouse dragging.
Stripe's product pages and FE technical excellence are second to none. Maybe Apple, but they tend to over do it sometimes whereas Stripe does a great job of making the perfect amount of 'subtle flashy'.
I think the "golden age" of online fraud is coming to an end quickly. I've posted quite heavily on Stripe and fraud threads on HN previously if you want to read my comment history.
This is a big step for Stripe. I've often asked why they didn't have an integration with MaxMind or SiftScience already set up. They've been building their own behind-the-scenes the entire time! This feature is fantastic if you are a merchant and want to avoid fraud.
To me, the more interesting side of online credit card fraud is the merchant/payment processor side. Stripe has a cult-like following in the fraud world because it's known as the the easiest target. They make it so easy to sign up and process transactions compared to other services like Authorize.net/BrainTree/etc. They've shed this label recently, in part because the biggest forum thread discussing it was closed. The other reason was because it became so much more difficult. With this release, I think it's simply because they could identify accounts with high numbers of suspected fraudulent transactions. All the fraudsters were used to just signing up, running charges on their webstore with sock5, and waiting 2 days for bank transfers. Now Stripe can identify those transactions well in advance and assign each account a risk score. Previously, Stripe had to identify the account risk by sales volume, chargebacks, bank account provider, sign up IP, and every one's favourite privacy invader IESnare.
Fraudster's have one last shining hope against Stripe. Passing their card data to Stripe via API, instead of Stripe.JS/Checkout. Radar only works with Stripe.JS/Checkout. Setting up your own web server to pass card information prevents them from ever seeing any IP address except the web server. All you have to do to get them to be okay with this is to turn over a PCI self-compliance form. Rumour on the internet has it that there's a pre-built web application specifically for charging Stripe accounts via API.
I'm still looking for a job in fraud prevention friends at Stripe :D
Using Spreedy to act as a 'white' proxy to their API would make it an even harder job for Stripe to detect the fraudsters. What would be your solution to the problem?
It seems Spreedy is the solution I'm talking about. I can't say with absolute certainty. Their website says it uses api.stripe.com, which is great. Basically, any code that passes directly to Stripe's API instead of to Stripe.JS/Checkout.
If you strip away the "buyer's" IP then a lot of their ability to detect fraudulent transactions goes away. They still have account based limits and other methods, but my personal opinion is the anecdotal increase in difficulty of creating fraudulent Stripe accounts is due to Radar based detection.
AlphaBay. It had a 200+ page thread on Stripe and methods for creating Stripe accounts to process fraudulent payments. I feel confident saying this time 1 year ago they were easily pushing 500k-1m USD in transactions a month. There were several users who posted screen shots of single accounts reaching 50k-180k.
Threads deleted, but only to stop newbies and methods from leaking out to public readers like myself.
It seems one of Stripe's biggest risks is the impending PSD2/XS2A changes within the EU/UK. This means banks/merchants/retailers will ditch traditional card networks (and their fees) to instruct P2P payments directly. This probably opens up a host of very effective anti-fraud measures too (eg. 2FA with mobile devices).
I wonder how Stripe will react to this major change in the market?
This is why Stripe is my favorite startup out of the so-called unicorns. They are really good at finding ways to make more money, while at the same time improving customer experience.
Agreed, their design gets high marks on executing current trends well, having a distinct brand, and being functional to interact with. And that's on top of serious talent and execution on the tech and business angles as well.
I can't wait to see how they expand as a company going forward and would absolutely love to work with them if I wasn't preoccupied with more personal pursuits.
I have some holiday reading to plan and would love a book recommendation from their UX/UI people. The state-of-the-art in HCI has moved on from what I learned as a novice developer in the '90s. (I already have Tufte's VDQI of course)
(I work at Stripe) Stripe's already actioning charges based on the feedback from the machine learning models. We hope that they'll take care of most fraud for you.
If you do want to write custom rules on top of what the models are doing, we've actually built in a testing interface to the rule creation process. When you test a rule, we'll actually simulate what the rule would have done had it been active for the past 6 months. Using that information, you'd be able to tell the # of legitimate, fraudulent, or already blocked payments that would have matched the rule & make a decision on what's best for your business.
That said, we're looking to make our opinion on a given rule more clear (rules are still in beta) and would love more feedback on how we can make this better. Feel free to drop me a line (tara@stripe.com) if you have feedback!
> we've actually built in a testing interface to the rule creation process. When you test a rule, we'll actually simulate what the rule would have done had it been active for the past 6 months.
> On its own, a bimodal distribution does not tell you that a model is good. (A vacuous model that randomly assigns probabilities of just 0.0 and 1.0 would also have a bimodal score distribution.) However, in the presence of evidence that transactions with a low score are not fraudulent and transactions with a high score are fraudulent, an increasingly bimodal distribution is a sign of improved efficacy for a model.
To do this more precisely, a scoring rule (https://wiki.lesswrong.com/wiki/Scoring_rule) gives a system credit for both (1) making accurate predictions and (2) being confident at the right times.
E.g. if we are executing a charge for a known-good customer, but using acompletely new card - we'd like to suppress all automated fraud checks and, ideally, indicate to the client's bank that this is a legit charge.
We try to be smart about things. For example, if you use Subscriptions, we assume that subsequent charges of a happily paying customer are also very likely to be good and so we do not block them.
Most users won't need to tweak the default behavior, but it is flexible in both directions. You can use the same rule builder interface to whitelist a transaction vis-a-vis Stripe, using boolean logic on a variety of things Stripe knows about the charge. Whether this will work for what you want to do depends a bit on the specifics of it -- we'd be happy to advise.
A subtlety: Due to the way credit card payments work, customers' banks already assume that every business running a charge is representing to them "It is our good faith belief that this payment is legitimate" and so they don't expose a way to say "No, really, we're EXTRA SPECIAL sure about this one. Please give us their money." If they come to the conclusion that a payment is likely to not be authorized, they will take action to protect their customer.
You can write your own rules. According to the docs you can only really inspect the current charge, you can't inspect anything about the customer[1]. The ability to look through to the attached customer object at metadata would make a great feature request.
Most merchants don't want a rule engine, or rules. Most merchants want either a declined transaction (possibly with explanation -- possibly), or an accepted one with a guarantee against chargebacks.
If Stripe is sure that their models work, they should offload the chargebacks from the merchants.
A friend of mine worked for a startup that did exactly that. They were sold to an online payments behemoth in about 2009.
-- Most merchants want either a declined transaction (possibly with explanation -- possibly), or an accepted one with a guarantee against chargebacks.
Well in fact their is an issue of misaligned incentives here. Your chargeback insurance has a strong incentive not to receive any chargeback (of course), so they will be overly cautious and decline a lot of valid charges. Stripe on the other hand as perfectly aligned incentives with the merchant, as they don't make money on a blocked transaction.
This does not contradict what I said. Declines should be free. Accepts should be guaranteed (but not free). Stripe currently offers free declines, but not guaranteed accepts.
Unsure as to why you're being downvoted... as chargeback insurance is the predominant model used by anti-fraud companies. That said, it's not necessary for Stripe to take their cut that way as they already are the payment service provider and so already have taken a cut and their model allows them to just offload risk to the client.
This looks very promising. Stripe seems to have sometimes let surprising payments through up to now, even with all the card details security checks they provided activated, and they've never supported 3-D Secure. They've also suffered from surprisingly high rates of unexpected declined charges in our experience. Hopefully if they're now rolling out more comprehensive fraud protection, that will go some way to addressing all of those concerns, so best of luck to them with this new development.
Edit: It appears there's a small per-transaction charge for their enterprise customers on custom plans but it's now included for free with the standard pricing. Can anyone confirm this?
We had the same experience, unfortunately most of stripes "declined" charges are actually declined by the bank and stripe cannot, nor is willing to help you out. They are just a gateway. Once it happened on my own site with my own card, I called my bank's security team and asked what is the exact reason on their side and all they could tell me over the phone that they declined the transaction only because it was too "high risk"
My theory (just a theory) is:
A. banks fraud detection systems just don't like the way stripe is avoiding the whole merchant account game, so stipe just has a bad rep at banks
B. stripe is so easy to set up and use, therefore various stripe websites
has fraudulent transactions going on, so from the bank point of view just
being a new merchant coming through stripe is automatically high risk
The whole machine learning for fraud detection imho is very annoying from a merchant point of view, because there is no real way to fix it. We have had cards that got declined only the second-third month in a rent-to-own business and the only thing we can do is to ask the customer to call their bank.
Hopefully once fraud detection happens at the stripe level instead of the bank level,
banks will see less fraud coming from stripe and the overall decline rate will ... decline.
Agreed on pretty much all of that. We too have wondered whether the ease of use that makes Stripe so attractive to a small business might also induce some sort of penalty in terms of fraud checks by other organisations. If that really is the case, presumably it leaves Stripe in a tough situation, but this seems like a responsible and hopefully effective step on their part.
We see quite a lot of failures on the second month of a subscription, particularly for customers abroad (we're in the UK). We also tend to see these sort of failed charges happen in waves, with few problems for a while but then a sudden spike in declined transactions. That suggests at least one plausible explanation: the lack of CV2 after that first charge may be enough to tip something over the edge into "too suspicious" territory following some sort of update in the overall scoring scheme used by whoever is blocking the charge.
We're looking into various potential ways to improve the situation, such as allowing more automated retries of failed charges over a longer period before we give up, and possibly advertising prices in our customers' local currencies. However, each of those has some potential downsides and obviously there is only so much you can do as the merchant anyway.
If Radar can start to make Stripe, and by extension its merchants, a harder target for for fraudsters, maybe that will also move the needle a bit. A few times I think we've lost more subscribers in a month to failed card charges than everything else put together, including customers actively choosing to cancel and including failures via all other payment methods we accept, so it's definitely an issue worth exploring.
(just saw your edit) Radar is included for the vast majority of our users who are on the standard rate. If you're an enterprise customer on a very custom plan, there's a small per transaction fee.
In addition to what everyone else said there are big regional effects: in North America cardholders have often never seen 3D Secure before, they don't know their passwords, and issuers don't care enough to make their authentication pages usable.
But in France and the UK it's pretty standard; cardholders are used to it, and issuers make an effort to decide whether it's worth requiring authentication.
I've experienced 3D secure and verified by visa effectively insulating a merchant from chargeback risk (I'm talking 99% success rates winning chargebacks). You're right, it is incredibly user-hostile and truly painful to integrate (as compared to Stripe) but if you're in a business that sees a lot of people trying to rip you off it works wonders.
Perhaps, but it's important to actually run that calculation. After all, shutting down web payments entirely would totally eliminate fraud—but also cripple your business in the process.
Personally, I will never use a 3D Secure system these days. If you require it, I'll simply skip purchasing.
It's not great in many respects, but it has the compelling advantage of shifting fraud liability from the merchant to someone else. Depending on your market, it may be worth the loss in conversions from activating it.
Even if you're in a normally low-fraud market, as every business I work with that takes card payments is, almost anyone taking small value card payments on-line is vulnerable to being used as a card testing engine if their system can be automated. If nothing else, being able to toggle the extra check on temporarily if you become aware that your system is being abused that way is an extra level of security you can apply in a hurry.
Which bank are you with? Every bank in the UK seems to have a different implementation of it. My own bank just does some automated fraud detection (I assume picking up my IP address, browser details, etc), while a friend's bank requires the user to enter three random letters from a passcode.
(I work on Radar at Stripe) thank you, and do let me know if there's anything we can do to help you get set up on Radar. Additionally, we actually do support 3Dsecure in private beta -- mind emailing me (tara@stripe.com) for access?
Ironically, we probably have much less interest in 3-D Secure if Radar will now let us deal with the same "sudden spike in dubious sign-ups" problem anyway.
One interesting possibility might be if the kind of rules you allow for Radar could be used to determine whether to apply 3-D Secure if it's available, so we could enable it selectively for countries where people don't already have a zip/postal code to verify for example.
However, for my own small businesses, I suspect we'll be more interested in what Radar can do, particularly to add immediate extra security checks if we are suspicious of a pattern of requests from a certain part of the world.
I work at a company with a fairly large number of transactions and we don't really have a problem with fraud. I don't know anyone else who's really battled it either. Is it much more prevalent for certain industries and products?
The most common scenario where we experience credit card fraud is high value items ($500+) and a freight forwarder.
The scammer orders the item, using the billing address of the legitimate owner of the card, but a shipping address that corresponds with a freight forwarding operation. These places offer a US address, but forward the shipments on to various places, including South America, islands in the Caribbean, etc.
Typically, the legit card owner notices the transaction way after it's shipped, and files a chargeback. As with all "card not present" transactions, the shop owner then foots the bill, including a chargeback fee.
It took about 3 times getting burned before we took the time to put some countermeasures in place. The most helpful were geo-ip location for the purchase itself, and a "flag this for review" filter for anything going to the Miami area and/or anything with a longish suite number, keywords (freight, global), etc.
Edit: Worth noting that most credit card fraud solutions I've seen don't have a way to take the shipping address (as opposed to billing address) as part of the data to check. For the type of fraud noted above, it's vital. Geo-ip doesn't work well when the buyer is using a US proxy, or US based accomplice.
I understand your concerns as seller, but as a buyer located outside the US, blacklisting freight forwarders is really annoying, as it blocks access to legitimate buyers as well.
The government-owned postal service in New Zealand, NZPost, run a service known as YouShop https://www.nzpost.co.nz/tools/youshop specifically to allow Kiwis to get access to products that are either only sold overseas, or would cost ridiculous amounts of money to ship via those sellers. They operate by providing a personal address in US, the EU, or China, backed by third-party freight forwarders.
Unfortunately, the fraud rate is just too high for us to do otherwise.
Additionally, it creates issues even with legitimate customers. If the product arrives with shipping damage, there's no way to know if it was caused by our shipper, or the freight forwarder. The customer, though, is quite sure it's our issue to resolve...
MaxMind allows you to take into account shipping address and billing address. Their 'insights' service will also show you the estimate distance between IP & shipping/billing.
Yeah, before your last line I was wondering, "does this story end with it being impossible to get anything delivered to those addresses deemed sketchy?" Guess not yet.
There are many kinds of fraud with different patterns. Some have a lot to do with what you sell, but others can affect anyone that takes credit cards.
For instance, fraudsters that have received a bunch of stolen credit card numbers will want to test which cards are still good. They'll do that by making a small purchase at an online retailer, and if the charge clears, then use the card to get something illegitimately. While you might not be a good target for that second step, anyone that takes credit cards and has weak fraud protection steps will be a target.
What one day looks like an unexpected spike in sales becomes a huge spike in chargebacks later, as all of those sales were fraudulent. I am pretty sure there's been stories in Hacker News about this.
I remember I had to pay $10 cash to get an account on the Computer Science lab back in college. For some reason their credit card option became very popular as a way to test that cards still worked and they couldn't do anything about it.
Yes unfortunately. We run a property rental advertising service and are always battling fraud. We have had to implement tons of security features to try and catch things before they come through.
Fraud is not an issue at all for our business SaaS products.
I have my stolen identity in the past, and had over 15 transactions in next few days.
most are buying credit for online services, like online data storage, care.com, etc. and to throw a curve ball, they created yahoo account with my first name plus extra characters and created a subscription to USA today, verified with my fake yahoo account, and sent it to my home.
it happened after I went out with friends to a bar and they had my Amex and ID on a tap.
Most likely the card was compromised from an online store weeks or months before hand. Cards that are stolen at brick and mortar stores have the CVV value from the magnetic strip and are more valuable than those stolen from online databases. Those are re-encoded and typically used at gas station pumps or other stores that haven't switched to chips.
Cards stolen online typically come with the CVV2 and billing data that makes online fraud easier. At one time the Secret Service would analyze patterns in purchases to identify which merchants had been compromised. They wouod identify large databases of cards that had been compromised and would turn that information over to the card issuing bank. Given the cost of reusing the cards most banks would chose to mark the cards for additional surveillance instead of re-issuing the cards. At a conference one bank executive said that 20% of cards in the portfolio were marked this way.
The net is that if you carry five cards it's probably that one is in the hands of a fraudster already.
I once worked at a startup that took payments on behalf of charities. Due to the pick-your-price nature of donations there'd be a lot of users who've bought or stolen credit card information testing to see which ones are still active by making charges small enough to go unnoticed.
What sucked is that the charity would then be charged a fee when the card holder reversed the transaction.
Charities are a huge fraud target too. Often, stolen credit cards get run against donation portals for charities like the Red Cross to see if the still work and are valid (as the charges can be quite small).
This costs the charities a lot of money in chargebacks and man power in dealing with it. Stripe's offerings here could prove invaluable in this scenario.
You can prevent a lot of fraud by simply requiring both a postal code and the CVV on the card. It's unlikely that a card thief has both pieces of data. (If you steal the physical card, you won't have the postal code, if you buy a database of cards, unlikely that they will have CVV's)
I wish this were true. We have both AVS and CVV checks on payments and things still made it through a property rental advertising service we run. It was an uphill battle until we implemented https://www.maxmind.com/en/minfraud-services
But not all countries use postal codes, and checking of card registered address details is always a bit fuzzy simply because there may be several correct but different ways a legitimate cardholder might enter them.
Doesn't seem to be a way to use this without using stripe. Would be handier to send them info, have them give a pass/fail or score, and return that info. And charge for the service, vs having to migrate to them.
Thanks to uladzislau - wasn't aware of SiftScience - will have to check them out...
I would think that cuts both ways. SiftScience only needs to have a few big retail clients and they'll be doing a huge volume. More to the point I would think Stripe's strength here is their weakness....they're only as good as the users they have on Stripe vs Sift which might have a broader mix of datasets. Of course, as Stripe continues to grow that weakness will diminish.
Cool feature. Stripe are pretty awesome at creating marketing pages for these things too. Although it's a shame they messed up the green HTTPS padlock on that page by serving mixed content. (The Teespring video on AWS S3 simply needs the protocol changing from http to https to rectify this.)
Chrome says the page is 600kb. That might be large compared to say, HN, but compared to tons of other landing pages (or just regular pages) it's fairly light!
Nothing beats manual verification. People aren't sharing credit card numbers on public forums and mashing them against Stripe. People are paying for fulls, and grabbing a socks5 that's piped within a few miles of the address of the cardholder.
Never trust your processor to protect you against your (potential) customers. Stripe has very little incentive to do so. They'd rather you pay that fat $15 fee when you get hit with a chargeback. They really would.
I'm coming out with a book about Stripe (and a few other processors) and fraud. Trust me it will be good, and this is already a part of it.
Sincerely,
Someone who was once your enemy
PS my favorite part of this? Telling the carder how to defeat their algos:
* "This card has been used from an unusually large number of IP addresses across the Stripe network over the last 24 hours."
* "This email has been linked to an unusually large number of cards across the Stripe network over the last hour."
Thanks for not saying the card was declined. If you wouldn't mind, please hold while I switch socks and make a new email.
Sorry if this is crass, but whoever decided on telling the end-user why a card was declined... complete fucking idiot and should never work in fraud protection or payment processing again.
Thanks to Stripe for making it not-a-black-box! I hope others who build machine learning systems also find a way to make its decisions understandable by humans (when possible).