> charge-control.js was the front-end JavaScript that users add into their existing checkout page. It essentially just monkey patches
You can't do that. Essentially you advocated using a man-in-the-middle library. Running that running javascript client-side would completely break PCI compliance. Stripe literally couldn't stop you from operating, but they could break integration with you (i.e. not allow you to collect money via their own API). They could also refuse services to anyone who used your middle-man application.
What you should have done instead is have a backend application that operates after the token is created. Once you have a token, do fraud scrubbing and throw away the token if it fails.
You can't break PCI compliance, if you do, then you open yourself, your clients, and everyone else on the chain who knew you existed and did nothing to litigation----or worse, simply being banned by VISA, thus dying completely as a company. I've known a few payment processing companies who inadvertently went against a regulation, and VISA banned them for life. It's a monetary death sentence, and VISA tends to track everyone associated with building the company and refusing to work with them in the future too because it is seen as risky.
I don't really blame Stripe for seeing "client side javascript" then immediately burning any bridges.
Back up. I never transmitted any credit card details. All the inputs were heuristics about the end-user (ip address, GeoIP location, user-agent, referer, language, etc) or transaction meta-data (price, etc). Card number, expiration, CVV were NOT part of the inputs in Charge Control.
PCI compliance is only partially concerned with transmitting CC details, and is very much concerned with "YOU SHALL FOLLOW THE RULES".
The rules say you are not allowed to do what you were doing. It's completely irrelevant if what you were doing is not a security or data transmission issue, it's simply against the rules.
PCI compliance is an absolute nightmare, and is not something to be reasoned with, trust me. Logical thought and analysis has no place in PCI compliance. Follow the rules or else.
I'd be curious if you can point to a specific section of PCI that states that a 3rd party cannot collect user meta-data. If that is true Google Analytics and Intercom could not track on checkout pages.
I don't think it's a question of collecting user metadata or not. Here it really depends on "are the credit card details touching any non-PCI-compliant code?"
Section 6.3.2 requires you to verify any "custom" code released to a customer that handles credit card information.[1] The way I see it, since your code touches that information, you must be PCI DSS compliant or you're breaking the chain of trust.
There is no such thing, but the standard dictates that all payment pages have to be served from a PCI DSS compliant environment. Stripe is in a very grey area, because they don't even have their merchants use iframes. Tampering with the script that (according to Stripe) makes the merchant compliant, and not being certified doing so, is a big no-no.
A lot -- maybe most -- QSAs would absolutely flag an analytics script on a checkout page as a security issue, though they probably wouldn't consider it a pass/fail issue. PCI-DSS is a viral system, infecting every system that comes into contact with a covered environment. I've seen email servers and phone dialers get scoped in because they were used by employees handling payment card data.
> Logical thought and analysis has no place in PCI compliance.
Only at a local level.
If you're writing standards that are going to be rolled out to the whole world and are difficult to change, and where the potential downside is people losing a lot of money, then a 'better safe than sorry' heuristic is the correct choice.
Monkey-patching into your payments library at runtime certainly doesn't seem like a 'safe' practice that PCI ought to endorse at all.
It's essentially impossible to write a standard that perfectly anticipates every edge case. And if it were possible, the list of rules would be even longer and more difficult to follow.
I wonder if in part PCI compliance is designed this way as to avoid details or holes in the overall system from creeping up to the surface after years and years of usage and technologies evolving.
I mean, sure, today he's just getting IP addresses, user-agents, and languages, but tomorrow we may be able to harvest something more, and in combination with what was given before, _just_the_credit_card_info on it's own isn't as valuable to an attacker as everything combined. Perhaps in it's own sick way, the rules as absolute is a design that prevents "feature"-creep from pushing its way into the PCI-compliance standards system. Maybe in limited circumstances we could adopt this sort of attitude to prevent feature-creep in other technologies from undermining the original intent of the work.
I say this with full respect for the fact that in reality, if somebody tells me to "follow the rules" because "that's how it's done", I'm usually quite upset at their attitude about the whole thing.
> PCI compliance is an absolute nightmare, and is not something to be reasoned with, trust me. Logical thought and analysis has no place in PCI compliance. Follow the rules or else.
It's amazing how much of a pain it can be to deal with PCI, at least if you try to strictly follow the rules as written.
For example, users will send email to support@yourcompany that says something like "I have a new credit card. Please update my subscription to bill using my VISA card 4111111111111434 with security code 123, expires 2020-03 instead of my current card, MasterCard 5111111111111506, security code 876, expires 2016-11. My account number is 123456. Thanks!".
Of course that automatically generates a ticket in your ticket tracking system, and so now you've got a couple plain text credit card numbers (with CSCs!) in the ticket tracking database...which you never intended to store credit cards and have outside the PCI network's firewall.
Is this a problem? It's a credit card number and it is stored on one of your servers, so one could certainly make a strong case that you need to get rid of it at the very least, and maybe you even need to have the ticket tracker inside the PCI network firewall and subject to all of the annoying PCI access restrictions. Ugh!
And what if you are using a ticket tracker product that you don't host yourself? It's hosted on the vendor's servers. If a user sends in a credit card number in a support request, who is responsible for dealing with it? You, or the ticket tracker server provider?
And it gets even worse. Suppose you've got anti-spam software running on your mail system. When that user mailed a credit card number to support@yourcompany, the anti-spam software saw the credit card number. It might now be stored in a token database for the anti-spam software's bayesian filters.
How the heck are you supposed to deal with that?
If you have any forums, they can also have this problem. Or if you have a company blog that allows users to comment. And what if you are outsourcing the comments to some place like Disqus?
Then there is the problem of telephones. Customer calls your support line after hours, and leaves a message letting you know of their new credit card number, and giving the details. Oops...now you've got a stored credit card number in the saved recording of that customer's message. Does this mean your whole damned phone system has to be on the secure network and is in scope for PCI? (And what if you've outsourced your phone system?)
My point is that credit card numbers can end up on almost any system that has data entered (directly or indirectly) by end users, even if it is not a system that is part of your actual credit card processing path.
Heck, I've seen people somehow end up putting a credit card number in the address field when giving their shipping address, on a form that was nowhere near anything that actually asked for a credit card number.
I've posted this idea before on HN, but: if you believe you have a better way to detect fraud, put your money where you mouth is, and price and sell insurance on a per-charge basis. If a chargeback is made for for fraud, you would cover the loss.
What stripe has done is great, but is really a rules engine, and the challenge will be keeping those rules up to date and making the business decisions to feed into the rules. If you price and take-on the risk, it becomes a very simple business decision for your customers: "am I still making a profit?"
This is of course a much harder business ... but don't give up just yet!
Unfortunately this wouldn't really work. If you're selling insurance, you're going to have a strong incentive to play it safe. If you run a business, you're going to be furious if legitimate customers are rejected (which is unavoidable at some level, but no matter what level that is you're going to make the business furious when they discover a legitimate charge being rejected).
I wasn't thinking about outright rejecting any charge, but rather that you would price some charges more expensively than others. As a seller of insurance, you're going to price above your estimated percentage, to give you some profit and compensation for the risk, but if you price too high you have no revenue.
It also becomes a much more interesting market if there are multiple competing providers of insurance that bid against each other (just as ad networks work, for example).
As a buyer of insurance, I would always have the choice to not buy the contract and take on the risk myself.
If the market works (which is a big if), it should become an efficient transfer of risk to companies that are experts in evaluating it.
Very interested to hear more of your thoughts though, as you're obviously part of the target audience at your dayjob!
There is a new, quite stealthy startup that does this (not sure if I can give away their name when their website doesn't say what they actually do). They guarantee every payment they accept against fraud.
The tradeoffs are pretty obvious to merchants when they compare their authorization rates between processors and look at the revenue the lose, either through fraud or through false positives.
I think a different model could align incentive while still providing the same service. Maybe "We get X% in payment processing that's not charged back" or similar.
It may not be a bad idea to position your product as "Stripe Radar for the rest of us." Basically, companies that can't use Stripe for whatever reason can still get Radar-like protection through your product. This will be a lot more integration work for you, though.
From the article: "The entire premise was to piggyback on Stripe and allow Stripe users to specifically create rules to prevent and reduce fraud and chargebacks."
That's usually a bad business concept, unless you have patent protection. If you get successful, the big guy takes your idea.
Have you seen Baremetrics (Subscription Analytics & Insights for Stripe, Braintree and Recurly). They started off only supporting Stripe for a long time. Their current MRR[1] is hovering around $59,000, so I'd say that works.
Not really. If that were the case, using the API of a company to build a business on would always be a bad idea. If it's a good idea, and you can execute quickly (something big players generally struggle with, for reasons good and bad), getting traction with users is the key.
Not always a bad idea, but always a huge risk. You're farming out your core competency and are 100% subject to the whims of whomever controls that API.
> Pricing was to be charged per successful request (accept) > and similar to Sift Science in terms of a handful of cents > per request. Reject requests were to be free.
That strikes me as a weird way of doing the pricing. If a request was successful but should really have been rejected, the user is paying. If the request was denied but should really have been successful, the user of the service (of the fraud detection service) is loosing.
Also, this part sounds really scary when you're dealing with payments:
> . It essentially just monkey patches Stripe.card.createToken() to call our api first
Would probably brake the payment as well if Stripe is updating the script (and since the script HAS to be loaded from their domain, nothing you can "guard" against)
I was forced to create something similar to Radar (minus the fancy machine learning) as we've been seeing huge amounts of fraud, it's been running nicely and the fraud/disputes rate went down around 98%, what I found to be a great factor in determining if a user is a scammer is the user's behavior before purchase, so in the end what I wan to say is that there's plenty of improvement to be done in the space ;)
Your mocks look really nice! If you're interested in the fraud problem, you might try some of the other fraud detection startups, like Sift Science (which you mention), Forter, Riskified, or Signifyd. I'll bet you'd bring a unique perspective, having built parts of Charge Control.
It's hard to imagine that you didn't once consider this outcome? At Control (the Android/iOS/Web app for Stripe) we knew Stripe was making an iOS app and we continued to make ours anyway, because we knew we were able to offer a different featureset. If Stripe is integrating such a system, then that helps validate your business model.
Since we built on top of Stripe, we kept an open dialogue with them so we wouldn't be caught by surprise like this. I think it's really important to have an ongoing conversation with all of your most important vendors to be aware of their roadmap, especially startups because things change so quickly.
There are multiple companies who have written an API similar to Stripe's, have you considered applying your API to Braintree, Alipay, or any of the other many worldwide processors? If you really have a working anti-fraud product, the worst you could do is sell it. Don't just throw it in the trash.
He says in his post that his product would've revolved around allowing merchants to set rules on who could buy. Radar is a product centered around Stripe using deep learning with their own data to detect fraud; allowing merchants to set rules is just the cherry on top.
OP mentions Braintree but is rightfully hesitant. The release of Radar might send them playing catch up and OP is a solopreneur that could just as easily be working on something with less competition.
Sorry, I'm not sure what you're getting at, I read the post and I'm more than familiar with what Stripe is up to.
There are countless startups building on Stripe's API, if Stripe hadn't done this there would have been plenty of other competition. I would expect OP's service to have planned to differentiate themselves by target market, effectiveness, price, or payment processor.
Stripe just has a really easy API, but the competition has almost caught up to them. Anti-fraud is a hard problem, so if OP's solution is really novel, it should be applicable to other platforms.
Beyond the PCI compliance issue, this would've been a solid idea.
I don't think there's anything wrong with piggybacking - it's shrewd if anything - though this time you definitely got bested by the venture funding. One idea closer to a winner.
Have you reached out to Stripe? While they obviously won't be replacing Rader with your product, they might have some ideas about what to do with the work you've done.
You can't do that. Essentially you advocated using a man-in-the-middle library. Running that running javascript client-side would completely break PCI compliance. Stripe literally couldn't stop you from operating, but they could break integration with you (i.e. not allow you to collect money via their own API). They could also refuse services to anyone who used your middle-man application.
What you should have done instead is have a backend application that operates after the token is created. Once you have a token, do fraud scrubbing and throw away the token if it fails.
You can't break PCI compliance, if you do, then you open yourself, your clients, and everyone else on the chain who knew you existed and did nothing to litigation----or worse, simply being banned by VISA, thus dying completely as a company. I've known a few payment processing companies who inadvertently went against a regulation, and VISA banned them for life. It's a monetary death sentence, and VISA tends to track everyone associated with building the company and refusing to work with them in the future too because it is seen as risky.
I don't really blame Stripe for seeing "client side javascript" then immediately burning any bridges.