5 ms·

He did a great job with the interview. I think Stripe will be the next big YC company, on the list with Heroku, Dropbox, and Airbnb. I always find it a bit odd

by staunch 15y ago

He did a great job with the interview. I think Stripe will be the next big YC company, on the list with Heroku, Dropbox, and Airbnb. I always find it a bit odd though, the claim that before Stripe you had to have a merchant account. I've signed up (on behalf of various projects) for PayPal's "Web Site Payments Pro" a half dozen times. It doesn't require a merchant account, the setup is quite quick, and it has a very simple API ("NVP"). It's pretty much everything Stripe is except less polished, with a slightly slower setup, and a $30/mo fee (insignificant for all my projects). I'll definitely choose Stripe next time though just because they're at least 20% more polished on all fronts and I like them a lot more than PayPal. I can't help wondering whether they just didn't know about PayPal's product or they're ignoring it for marketing purposes.

pbreit 15y ago
Stripe has one fairly major advantage over PayPal in its Javascript library which insulates the merchant from handling the credit card information thus making PCI compliance more realistic.
- eurleif 15y ago
  I've only encountered Stripe as a customer, and only once, so it may just be that the merchant (Browserling) was implementing it wrong. But the merchant asked me for my credit card number on its own domain, without SSL. I trusted the site enough to believe it really used Stripe (the only verification was text saying so), and that it was secure, but there was nothing there to prove it to me. So maybe Stripe is secure, but they might want to work on appearing more trustworthy. When I've used PayPal as a customer, it asked for my credit card on its own domain, not the merchant's. Doesn't that insulate the merchant from handling credit card details at least as well as Stripe's API does?
  - storborg 15y ago
    I don't believe it's possible for a site accepting credit cards on a non-SSL page to be PCI compliant, period, no exceptions. It's trivial to MITM to steal your card info.
    - eurleif 15y ago
      The merchant's page is loaded over an insecure connection, but the credit card details are sent to Stripe's servers over a secure connection using an iframe. So it's secure; the customer just can't verify that it is without looking at the source.
      - ZiadHilal 15y ago
        Not exactly. Iframes aren't involved (yuck how ugly!). Javascript is used to catch the form's submit, all the data on the form (credit card info) is sent straight to Stripe's server over https (via AJAX) and then their server sends back a response. Their implementation is both elegant and smart. Even easier than Braintree.
        eurleif 15y ago
        There seems to be an iframe involved: http://i.imgur.com/R4efp.png http://i.imgur.com/R4efp.png
      - delroth 15y ago
        If the merchant's page include any Javascript over an insecure connection (for example, jQuery from a CDN) then an attacker can intercept this connection and replace the Javascript by a malicious script that will remove Stripe's iframe and replace it by any other iframe. So yes, passive network sniffing won't work with Stripe's iframe being loaded over HTTPS, but this does not protect against any type of "active" man in the middle attack.
      - storborg 15y ago
        How does the customer know it's even Stripe's javascript running at all? There's nothing preventing the injection of malicious JS to capture the card number.
  - pc 15y ago
    We actually require that our users use SSL on their payment pages. We describe the requirements (and motivations) in more detail at https://stripe.com/help/ssl https://stripe.com/help/ssl.
sunsu 15y ago
One issue with Web Site Payments Pro that might affect some HNers is that Paypal will deny Third Party Payment Aggregation business models almost 100% of the time. Stripe has no issues with TPPA as long as you don't start getting tons of chargebacks. Stripe FTW.
- staunch 15y ago
  That would be very cool. A company I contracted for had to abandon a product because of just that problem. I could be misintrepreting it but the Stripe ToS seems to contradict you: From https://stripe.com/terms https://stripe.com/terms 12. Restricted Use In addition to any other requirements or restrictions set forth in this Agreement, you shall not: ...(iii) act as a payment intermediary or aggregator or otherwise resell our services on behalf of any third party...
  - LogicX 15y ago
    Interesting - I wonder if that makes my weekend hack project http://hipay.me http://hipay.me in violation of their terms...
pc 15y ago
Patrick from Stripe here. This is a really good point, and one that's worth clarifying. I'm just back from a run, and can't reply in depth right now, but wanted to add this comment as a placeholder before the thread falls off your radar. Will update here within a few hours. (And, PS, thanks for the kind words.) [Update follows] I don't think we've ever claimed that before Stripe you had to have a merchant account. We're of course aware that there were a a bunch of services that didn't require a merchant account before Stripe (not just PayPal, but also Google Checkout and Amazon Payments). The point we always do try to make is that the vast majority of sites (and, especially, the best sites) end up using their own merchant account. Whatever about the feature sets of PayPal and similar systems, people still ended up preferring merchant accounts, and the traditional merchant account infrastructure powers most of the e-commerce on the web. It turns out that there are actually pretty good reasons for this: the merchant-account based solutions gave you the most control over the end-user experience, the most control over the relationship with your customers, and so on. Merchant accounts were the best solution and still are the most widely deployed option. To the extent that Stripe is competing with anything, we're competing with that. And so, to get back to your point: it is, overall, a pretty subtle situation, and how best to make the landscape clear in a few sentences to someone watching TV -- or someone who doesn't know much about the industry -- isn't easy. We want to be as accurate as possible without compromising clarity or brevity. If you've any suggestions as to how we could do it better, they'd be much appreciated: I'm patrick@stripe.com.
- donald_draper 15y ago
  Now can you bring it to Europe, too ? :-) We will build you a golden shrine and worship you every morning for doing so.
  - deleted 15y ago
    [deleted]
  - pc 15y ago
    Working on it, I promise :-).
workhorse 15y ago
With all due respect to all other YC companies, I think in the end, none of them will even come close to Stripe.
sown 15y ago
> I think Stripe will be the next big YC company, on the list with Heroku, Dropbox, and Airbnb. I think so, too, and that makes rejection burn all the more.
ZiadHilal 15y ago
PayPal is a lot better than the older solutions (think Authorize.net). However, Stripe makes PayPal look just as bad and complicated as Authorize.net. With Stripe, you can seriously setup a site to start taking subscriptions under an hour. It's ridiculous just how easy it is. Their documentation is great too. The first time I used Stripe, my jaw dropped when I figured out their implementation. It's just so obvious and makes so much sense (Javascript FTW).

by staunch 15y ago

pbreit 15y ago

Stripe has one fairly major advantage over PayPal in its Javascript library which insulates the merchant from handling the credit card information thus making PCI compliance more realistic.

eurleif 15y ago
I've only encountered Stripe as a customer, and only once, so it may just be that the merchant (Browserling) was implementing it wrong. But the merchant asked me for my credit card number on its own domain, without SSL. I trusted the site enough to believe it really used Stripe (the only verification was text saying so), and that it was secure, but there was nothing there to prove it to me. So maybe Stripe is secure, but they might want to work on appearing more trustworthy. When I've used PayPal as a customer, it asked for my credit card on its own domain, not the merchant's. Doesn't that insulate the merchant from handling credit card details at least as well as Stripe's API does?
- storborg 15y ago
  I don't believe it's possible for a site accepting credit cards on a non-SSL page to be PCI compliant, period, no exceptions. It's trivial to MITM to steal your card info.
  - eurleif 15y ago
    The merchant's page is loaded over an insecure connection, but the credit card details are sent to Stripe's servers over a secure connection using an iframe. So it's secure; the customer just can't verify that it is without looking at the source.
    - ZiadHilal 15y ago
      Not exactly. Iframes aren't involved (yuck how ugly!). Javascript is used to catch the form's submit, all the data on the form (credit card info) is sent straight to Stripe's server over https (via AJAX) and then their server sends back a response. Their implementation is both elegant and smart. Even easier than Braintree.
      - eurleif 15y ago
        There seems to be an iframe involved: http://i.imgur.com/R4efp.png http://i.imgur.com/R4efp.png
    - delroth 15y ago
      If the merchant's page include any Javascript over an insecure connection (for example, jQuery from a CDN) then an attacker can intercept this connection and replace the Javascript by a malicious script that will remove Stripe's iframe and replace it by any other iframe. So yes, passive network sniffing won't work with Stripe's iframe being loaded over HTTPS, but this does not protect against any type of "active" man in the middle attack.
    - storborg 15y ago
      How does the customer know it's even Stripe's javascript running at all? There's nothing preventing the injection of malicious JS to capture the card number.
- pc 15y ago
  We actually require that our users use SSL on their payment pages. We describe the requirements (and motivations) in more detail at https://stripe.com/help/ssl https://stripe.com/help/ssl.

sunsu 15y ago

One issue with Web Site Payments Pro that might affect some HNers is that Paypal will deny Third Party Payment Aggregation business models almost 100% of the time. Stripe has no issues with TPPA as long as you don't start getting tons of chargebacks. Stripe FTW.

staunch 15y ago
That would be very cool. A company I contracted for had to abandon a product because of just that problem. I could be misintrepreting it but the Stripe ToS seems to contradict you: From https://stripe.com/terms https://stripe.com/terms 12. Restricted Use In addition to any other requirements or restrictions set forth in this Agreement, you shall not: ...(iii) act as a payment intermediary or aggregator or otherwise resell our services on behalf of any third party...
- LogicX 15y ago
  Interesting - I wonder if that makes my weekend hack project http://hipay.me http://hipay.me in violation of their terms...

pc 15y ago

Patrick from Stripe here. This is a really good point, and one that's worth clarifying. I'm just back from a run, and can't reply in depth right now, but wanted to add this comment as a placeholder before the thread falls off your radar. Will update here within a few hours. (And, PS, thanks for the kind words.) [Update follows] I don't think we've ever claimed that before Stripe you had to have a merchant account. We're of course aware that there were a a bunch of services that didn't require a merchant account before Stripe (not just PayPal, but also Google Checkout and Amazon Payments). The point we always do try to make is that the vast majority of sites (and, especially, the best sites) end up using their own merchant account. Whatever about the feature sets of PayPal and similar systems, people still ended up preferring merchant accounts, and the traditional merchant account infrastructure powers most of the e-commerce on the web. It turns out that there are actually pretty good reasons for this: the merchant-account based solutions gave you the most control over the end-user experience, the most control over the relationship with your customers, and so on. Merchant accounts were the best solution and still are the most widely deployed option. To the extent that Stripe is competing with anything, we're competing with that. And so, to get back to your point: it is, overall, a pretty subtle situation, and how best to make the landscape clear in a few sentences to someone watching TV -- or someone who doesn't know much about the industry -- isn't easy. We want to be as accurate as possible without compromising clarity or brevity. If you've any suggestions as to how we could do it better, they'd be much appreciated: I'm patrick@stripe.com.

donald_draper 15y ago
Now can you bring it to Europe, too ? :-) We will build you a golden shrine and worship you every morning for doing so.
- deleted 15y ago
  [deleted]
- pc 15y ago
  Working on it, I promise :-).

workhorse 15y ago

With all due respect to all other YC companies, I think in the end, none of them will even come close to Stripe.

sown 15y ago

> I think Stripe will be the next big YC company, on the list with Heroku, Dropbox, and Airbnb. I think so, too, and that makes rejection burn all the more.

ZiadHilal 15y ago

PayPal is a lot better than the older solutions (think Authorize.net). However, Stripe makes PayPal look just as bad and complicated as Authorize.net. With Stripe, you can seriously setup a site to start taking subscriptions under an hour. It's ridiculous just how easy it is. Their documentation is great too. The first time I used Stripe, my jaw dropped when I figured out their implementation. It's just so obvious and makes so much sense (Javascript FTW).