5 ms·

Stripe put my startup out of business before I launched

92 points by nodesocket 10y ago

Animats 10y ago
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.
- spott 10y ago
  I would think the idea is usually to get aquihired.
- nodesocket 10y ago
  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. [1] https://demo.baremetrics.com/ https://demo.baremetrics.com/
- the_watcher 10y ago
  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.
  - EpicEng 10y ago
    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.
brandonb 10y ago
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.
- danellis 10y ago
  Am I missing them? All I see is a landing page. The screenshot of the rules is actually from Radar.
sinatra 10y ago
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.
grecy 10y ago
That's a very clickbait title. What you mean to say is "Someone beat me to the punch".
- bbcbasic 10y ago
  Or I built a startup on shakey ground. 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.
diggan 10y ago
> Business model > 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)
- deleted 10y ago
  [deleted]
justinsb 10y ago
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!
- wiwillia 10y ago
  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).
  - mhluongo 10y ago
    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.
  - Artemis2 10y ago
    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.
  - justinsb 10y ago
    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!
dismantlethesun 10y ago
> 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.
- nodesocket 10y ago
  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.
  - grecy 10y ago
    > I never transmitted any credit card details. 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.
the_watcher 10y ago
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.
hoodoof 10y ago
Why is this on hacker news?
- striking 10y ago
  Because someone posted it. But it'll likely fall off the front page soon.
fuqted 10y ago
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. How did you plan on marketing this?
doublerebel 10y ago
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.
- fuqted 10y ago
  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.
  - doublerebel 10y ago
    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.
    - deleted 10y ago
      [deleted]
_Marak_ 10y ago
Justin - 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"
invokestatic 10y ago
What happens if an attacker simply blocks your JS?
rprime 10y ago
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 ;)
- nodesocket 10y ago
  Would you mind sending me an e-mail (in profile). Curious to hear about your experiences and factors.
aibottle 10y ago
I'm happy no CC details had to live inside your hipster bs stack.

92 points by nodesocket 10y ago

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.

spott 10y ago
I would think the idea is usually to get aquihired.
nodesocket 10y ago
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. [1] https://demo.baremetrics.com/ https://demo.baremetrics.com/
the_watcher 10y ago
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.
- EpicEng 10y ago
  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.

brandonb 10y ago

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.

danellis 10y ago
Am I missing them? All I see is a landing page. The screenshot of the rules is actually from Radar.

sinatra 10y ago

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.

grecy 10y ago

That's a very clickbait title. What you mean to say is "Someone beat me to the punch".

bbcbasic 10y ago
Or I built a startup on shakey ground. 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.

diggan 10y ago

> Business model > 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)

deleted 10y ago
[deleted]

justinsb 10y ago

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!

wiwillia 10y ago
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).
- mhluongo 10y ago
  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.
- Artemis2 10y ago
  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.
- justinsb 10y ago
  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!

dismantlethesun 10y ago

> 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.

nodesocket 10y ago
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.
- grecy 10y ago
  > I never transmitted any credit card details. 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.

the_watcher 10y ago

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.

hoodoof 10y ago

Why is this on hacker news?

striking 10y ago
Because someone posted it. But it'll likely fall off the front page soon.

fuqted 10y ago

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. How did you plan on marketing this?

doublerebel 10y ago

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.

fuqted 10y ago
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.
- doublerebel 10y ago
  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.
  - deleted 10y ago
    [deleted]

_Marak_ 10y ago

Justin - 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"

invokestatic 10y ago

What happens if an attacker simply blocks your JS?

rprime 10y ago

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 ;)

nodesocket 10y ago
Would you mind sending me an e-mail (in profile). Curious to hear about your experiences and factors.

aibottle 10y ago

I'm happy no CC details had to live inside your hipster bs stack.