Stripe put my startup out of business before I launched
justink.svbtle.com
justink.svbtle.com
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.
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.
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 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.
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.
1: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2....
(This is my opinion, which should be taken with a grain of salt.)
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?)
Namely, that you shouldn't have credit card numbers inside an insecure system, whether a ticket tracker or an answering machine.
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.
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!
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.
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!
What you mean to say is "Someone beat me to the punch".
It's the equivalent of using hubpages instead of your own domain name for a marketing site. Or relying solely on SEO etc.
Your fate is on the hands of another company that can pull the rug.
That's usually a bad business concept, unless you have patent protection. If you get successful, the big guy takes your idea.
> 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)
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.
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.
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.
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.
How did you plan on marketing this?
Sorry this didn't work out well.
Been watching your other projects over the past few years and have been impressed.
Not sure if you have started a new project yet, but I think I have something you might be potentially interested in.
Send me a DM on Twitter, handle is "marak"