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 <a href="https://dashboard.stripe.com/search/rules?rule_token=block_if_high_risk" rel="nofollow">https://dashboard.stripe.com/search/rules?rule_token=block_i...</a> 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."<p>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).
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.
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.<p>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.<p>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.<p>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.<p>I'm still looking for a job in fraud prevention friends at Stripe :D
This looks good, and is sorely needed.<p>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).<p>I wonder how Stripe will react to this major change in the market?<p>For example: <a href="https://developer.americanexpress.com/products/accept-amex" rel="nofollow">https://developer.americanexpress.com/products/accept-amex</a>
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.
It's a bit unclear to me; these rules appear to be automated but then they show a rule builder interface?<p>How would I ever know if the rule I've built is too constraining, or too loose in accepting payments?<p>Payment is not exactly an area of my business that I want to do a lot of trial and error..
> 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.<p>To do this more precisely, a scoring rule (<a href="https://wiki.lesswrong.com/wiki/Scoring_rule" rel="nofollow">https://wiki.lesswrong.com/wiki/Scoring_rule</a>) gives a system credit for both (1) making accurate predictions and (2) being confident at the right times.
Is there support for whitelisting transactions?<p>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.
The webpage automatically loads a 206MB video <a href="http://imgur.com/a/Xyie6" rel="nofollow">http://imgur.com/a/Xyie6</a><p>That's insane.
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.<p>If Stripe is sure that their models work, they should offload the chargebacks from the merchants.<p>A friend of mine worked for a startup that did exactly that. They were sold to an online payments behemoth in about 2009.
The video (from Teespring) is 206M, easily explains why it's so slow to load.<p>(Congrats, we were using a separate fraud detection company that was quite intrusive and this seems much better)
I love having this built in, but if you're NOT using Stripe and you want similar protections I'd strongly urge you to check out MaxMind's minFraud.<p><a href="https://www.maxmind.com/en/minfraud-services" rel="nofollow">https://www.maxmind.com/en/minfraud-services</a>
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.<p>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?
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?
Doesn't seem to be a way to use this <i>without</i> 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.<p>Thanks to uladzislau - wasn't aware of SiftScience - will have to check them out...
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.)
Yeah, I still wouldn't trust it.<p>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.<p>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.<p>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.<p>Sincerely,<p>Someone who was once your enemy<p>PS my favorite part of this? Telling the carder how to defeat their algos:<p>* "This card has been used from an unusually large number of IP addresses across the Stripe network over the last 24 hours."<p>* "This email has been linked to an unusually large number of cards across the Stripe network over the last hour."<p>Thanks for not saying the card was declined. If you wouldn't mind, please hold while I switch socks and make a new email.<p>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.