7 ms·

Stripe cofounder here. As this news breaks, I want to say thanks to the HN community. Stripe is in large part the result of the feedback and advice we've receiv

by pc 13y ago

Stripe cofounder here. As this news breaks, I want to say thanks to the HN community. Stripe is in large part the result of the feedback and advice we've received here since we launched on HN back in Sept 2011 -- https://news.ycombinator.com/item?id=3053883 https://news.ycombinator.com/item?id=3053883.

Implicated 13y ago
And thank you, as a developer stripe has made a ridiculously difficult process ridiculously easy.
- patcheudor 13y ago
  Not ridiculously easy, rather slightly easier as the merchant still must maintain aspects of their environment covered by the PCI DSS as they are still delivering Stripe.js from their server environment. Here's a bit more information on that: http://pciguru.wordpress.com/2013/06/30/developers-beware-stripe/ http://pciguru.wordpress.com/2013/06/30/developers-beware-st...
  - pc 13y ago
    This post is inaccurate. (Check out Darragh's response in the comments.) It's also worth noting that 1) Stripe and its processes are audited every year (we're a PCI-certified service provider), and 2) that MasterCard has actually followed a very similar strategy with their Stripe competitor.
    - patcheudor 13y ago
      Stripe's level one service provider which is independent of the merchants PCI compliance. The merchant is presenting the form for which the user enters their credit card information from within the context (same origin) of their domain: e.g., https://merchant.com/payment.. https://merchant.com/payment... As a result, under the PCI DSS they are obligated to protect that component of the transaction because if they don't a criminal could change it so that the card data doesn't POST to Stripe.com but instead goes to the criminal. Implementing a bit of Javascript and enabling SSL/TLS is far from all that is needed to be PCI compliant as a merchant so long as the payment form itself, whether delivered via an iFrame or a bit of Javascript is hosted within the merchant domain.
  - slexaxton 13y ago
    (Stripe Developer) - tl;dr -- This claims that Stripe.js runs on the merchant's server environment, causing the server to be subject to PCI DSS. In reality, Stripe.js is served from Stripe's servers, and runs only in the browser, and this has always been the case.
    - patcheudor 13y ago
      In order to get Stripe.js to execute within the same origin of the merchant environment the merchant must include code like this: <script src='//stripe.com/Stripe.js> within their HTTP response. This can be modified by a criminal on the merchant server to go to <script src='//badguy.com/mystripe.js> if the merchant has not implemented proper controls as outlined in the PCI DSS. The same can happen if they implement weak crypto. At the end of the day the merchant is responsible for this PCI related component because it's executing within the context of their merchant domain. Adding a bit more to be crystal clear here. The merchants customer will only see the address in the address bar for the merchant and will be able to validate the merchants public cert. No customer I know of would view the source to make sure that the reference to Stripe.js is in the source. Additional edit to address Silhouette's point. Yes, an attacker can modify the <a href to go to their site as well, but unlike an embedded script the customer does have a chance to call BS and back out of the transaction after growing concerned by the domain transfer & doing a Google search to see if it's legit. They don't have any chance in the case of an embedded script. Now if we go back to my original concern, it's that merchants are being told that they simply need to implement Stripe.js & enable HTTPS. Modifying that statement to something like this would be far better: "Stripe minimizes the scope of PCI DSS by removing the need to implement and audit security controls surrounding the transmission, processing, and storage of card-holder data. This does not; however, absolve Merchants from compliance with the PCI DSS & in order to assist with that we offer the following..."
      - Silhouette 13y ago
        This can be modified by a criminal on the merchant server to go to <script src='//badguy.com/mystripe.js> And then the merchant won't be following one of Stripe's two basic rules for staying PCI DSS compliant any more, will they? That aside, of course you want to keep your server secure. But if you can't, as a matter of practical security and protecting cardholders in the real world, how would it be any better to have your site intended to transfer entirely to a payment service on their own domain rather than just loading JS from that domain? An attacker who has compromised the security of the files on a merchant's server can change an <a href='...'> that should transfer to the payment service so it goes to a hostile site just as easily as they can change a <script src='...'> that should load JS from a payment service so it loads JS from a hostile site.
patcheudor 13y ago
Now if Stripe could practice truth in advertising that would be great. SpecificallY: "Anyone accepting credit card payments must be PCI compliant. Stripe makes it easy to do so: Serve your payment page over SSL, i.e., the page's web address should begin with “https”, not “http”. Use Stripe.js or Checkout to accept payment information and transmit it directly to Stripe's servers. And you'll be PCI compliant!" https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do https://support.stripe.com/questions/do-i-need-to-be-pci-com... If it were only so easy. I guess there's no need for the merchant to have a PCI program, properly implement SSL/TLS, have anti-virus, change default passwords, protect agains SQLi, XSS, command injection or any number of other flaws which would give an attacker access to modify the Stripe.js code or the DOM for the page used for the collection of card information within the merchant's same origin. Nope, none of this is necessary because Stripe says that a merchant only needs to use HTTPS & implement their Stripe.js to be PCI compliant. It's interesting that this isn't how the PCI council sees things: https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf https://www.pcisecuritystandards.org/documents/Tokenization_...
- pc 13y ago
  Hm, it looks like that support forum answer needs to be updated -- we actually support filling out PCI SAQs right from our dashboard (and automatically ask users to do so). We'll go update it. Also, if you'd like to drop me an email at patrick@stripe.com, would be happy to chat about PCI more.
  - pc 13y ago
    (Updated.)
    - patcheudor 13y ago
      Confirmed.
- JunkDNA 13y ago
  Instead of just down voting this post, it would be helpful to know what specific parts of it are incorrect. This is the first I've heard of these objections.
cfontes 13y ago
I know it's not a priority but. Will you guys bring your magic to Brazil at some point? I would be really interested in it. On a side note I see Australia is in Beta :D which is great. Thanks
- pc 13y ago
  We definitely will. (Sorry we don't have a timeline, though.)
  - cfontes 13y ago
    No Worries! Congrats and keep up the good work!
diziet 13y ago
Hope to see you guys update the web interface a bit for a performance/little more flexibility. The API is great, but the web interface could use a bit more love :)
- pc 13y ago
  Agreed. On the way!
  - diziet 13y ago
    Awesome :) One big issue (with actual effect on revenue of your users) you guys could solve better would be handling delinquent/expiring cards better. We had to built some things in house to deal with this on our end, as once you have a non trivial amount of paying customers it can become at least a small pain. I know there are webhooks for failed payments etc but this stuff is really difficult to surface in the web interface.
    - guayosr 13y ago
      Eduardo from Stripe here - sending you an email now; I think we can help!
    - aculver 13y ago
      Hey Alex, Churn Buster (http://churnbuster.io/ http://churnbuster.io/) is available via Stripe Connect to solve exactly this problem. We're in private beta right now, so please email me at andrew@churnbuster.io if you'd like to take it for a spin. We've got a number of paying customers already (including some folks who previously had their own basic webhooks integration) and they're all saving much more in rescued transactions than they're investing in the product. Also, it's a 30-day free trial, so you literally can't lose! :-)
- abuehrle 13y ago
  (I'm not associated with Stripe) Can you please give at least one example or suggestion?
Negitivefrags 13y ago
Seeing this comment makes me realise how much of a crazy technical risk I made choosing to use Stripe when I did. My company started charging for things in April 2012, but I made the decision to use Stripe months before that, something like January 2012. Only 4 months after you launched! We only did 1500 transactions on our launch day, yet at the time it was enough to break your service for a little while due to load. Your customer service at the time was really great and you refunded all the transaction fees for our launch day and gave us a list of all the customers who had tried and failed to make transactions so we could contact them. I don't think I realised at the time how small you guys were. We are lucky that you guys didn't fail, and I doubt that the me of today would have relied on such a young company. Certainly we could have moved to a different payment processor, but losing all the saved card data would have sucked a lot. So great work on that!
- pc 13y ago
  Thanks for taking the risk :-).
- deleted 13y ago
  [deleted]
- nwenzel 13y ago
  Large companies tend to have arbitrary size requirements for potential vendors before allowing them to become an approved vendor. But I think companies should consciously choose startups as vendors for precisely that reason. Startups care more about figuring out what it takes to make customers happy.
- yesimahuman 13y ago
  Yep, same here. Had our first customers in February 2012 on Stripe. Glad it worked out, but we always knew it would :)
simonebrunozzi 13y ago
Patrick, big fan here - we also met in person once, in the Mission. Congrats on the milestone, and keep up the good work.
- pc 13y ago
  At Blue Bottle, right? (Thanks!)
treenyc 13y ago
I started building a SaaS for the legal industry around 2004. It was very small targeted at specific industry. Back then it was very hard to get everyone on board to use Credit Card. I ended up automating everything (including the monthly billing sent directly the user's inbox), but because of difficulty of payment gateway processing (getting a merchant account, parsing the authorize gateway code) And since I was a one man shop, I just had my users to send me checks at end of the month. I was not the best organized person back then. So let's just say there were quite few uncashed checks. Really wish Stripe was around them.
dmix 13y ago
One of the best parts of that 2011 thread is the number of people asking for Canadian support, then how quickly Stripe actually ended up supporting Canada (within 1 year roughly). We desperately needed Stripe and you guys delivered so quickly. Much appreciated.
TomGullen 13y ago
Stripe is great, we're really enjoying using it! I have three comments though if you're willing to listen! - I think your customer service department (although they do a good job) the quality has gone down, I often have to now wait several days for a reply. I guess this is the inevitability of growth though. In an ideal world it'd be nice to go back to when I got same day replies :) - We're a UK business. We take payments in EUR/GBP/USD. Like EUR, it would be nice to be able to withdraw our USD to our USD account in the UK! At the moment we're forced to withdraw it to our GBP account which is expensive. - It would be nice to be able to hold up withdrawls. At the moment our account is flooded with lots of payments, it would be nice to schedule all payments to be weekly/fornightly or a specific day of the month. Make our accounting process a lot easier and cheaper. Thanks for all the great work, I've been excited ever since I've started reading about you and am a big fan! (I got a tshirt on the way as well for reporting a small glitch which I'm excited to receive!)
- peacemaker 13y ago
  I'm pretty sure you can hold up withdrawals. You just cancel the automatic transfers from your dashboard then when you want to do a transfer just schedule it manually (or through the API).
- michaelschade 13y ago
  Thanks for the feedback, Tom! I understand how the USD -> UK transfers would help; we're looking into making that an option. For accounting, we've found that better reporting tools usually solve the need for less frequent transfers. Would one of the options at https://support.stripe.com/questions/reconciling-transfers-with-bank-account https://support.stripe.com/questions/reconciling-transfers-w... make this easier on you? Feel free to email me if not so I can understand more about your setup. Every part of Stripe should be incredibly simple, including accounting, and I want to make sure we get this right. Re support: you're right that the replies have been slower than they should be, though that's getting better. Basically, our userbase grew massively in 2013 and our support hiring didn't keep up with it. I spend all of my time on scaling the team, and we've more than doubled the size of the team in the past couple of months. More hires are on their way. I realize our internal machinations aren't very relevant—you just care that the result is excellent—and I'd like to be clear that we're working on this. You should expect to see significantly faster replies and more ways to get in touch with us over the coming months. While you should already be seeing improvement in this area, feel free to get in touch with me directly at michael@stripe.com anytime. I'd love to hear any other feedback, and am more than happy to help with whatever questions you have.
stevenwagner 13y ago
any Bitcoin integration plans?
drbillnye 13y ago
awesome man, joined the club 2 years ago and now my company relies on you and EasyPost, both YC companies to get our work done every day. It's great to work with your group, you guys have done a great job, props!
ChrisNorstrom 13y ago
Dear Stripe. I love you. Please add Micro-Transactions support like PayPal at the 5% + 0.05 cents transaction fee for payments under $12 dollars. Patiently waiting, Chris Norstrom.
coreymgilmore 13y ago
great job guys. i've used stripe and it definitely works well. love the "checkout" and the customization i can do with integration into my own page. pretty seamless compared to other vendors. only quip: price! would love to see a different pricing scheme for cheaper products. $0.30 fixed fee is a lot for carts that are only a few dollars!

by pc 13y ago

Implicated 13y ago

And thank you, as a developer stripe has made a ridiculously difficult process ridiculously easy.

patcheudor 13y ago
Not ridiculously easy, rather slightly easier as the merchant still must maintain aspects of their environment covered by the PCI DSS as they are still delivering Stripe.js from their server environment. Here's a bit more information on that: http://pciguru.wordpress.com/2013/06/30/developers-beware-stripe/ http://pciguru.wordpress.com/2013/06/30/developers-beware-st...
- pc 13y ago
  This post is inaccurate. (Check out Darragh's response in the comments.) It's also worth noting that 1) Stripe and its processes are audited every year (we're a PCI-certified service provider), and 2) that MasterCard has actually followed a very similar strategy with their Stripe competitor.
  - patcheudor 13y ago
    Stripe's level one service provider which is independent of the merchants PCI compliance. The merchant is presenting the form for which the user enters their credit card information from within the context (same origin) of their domain: e.g., https://merchant.com/payment.. https://merchant.com/payment... As a result, under the PCI DSS they are obligated to protect that component of the transaction because if they don't a criminal could change it so that the card data doesn't POST to Stripe.com but instead goes to the criminal. Implementing a bit of Javascript and enabling SSL/TLS is far from all that is needed to be PCI compliant as a merchant so long as the payment form itself, whether delivered via an iFrame or a bit of Javascript is hosted within the merchant domain.
- slexaxton 13y ago
  (Stripe Developer) - tl;dr -- This claims that Stripe.js runs on the merchant's server environment, causing the server to be subject to PCI DSS. In reality, Stripe.js is served from Stripe's servers, and runs only in the browser, and this has always been the case.
  - patcheudor 13y ago
    In order to get Stripe.js to execute within the same origin of the merchant environment the merchant must include code like this: <script src='//stripe.com/Stripe.js> within their HTTP response. This can be modified by a criminal on the merchant server to go to <script src='//badguy.com/mystripe.js> if the merchant has not implemented proper controls as outlined in the PCI DSS. The same can happen if they implement weak crypto. At the end of the day the merchant is responsible for this PCI related component because it's executing within the context of their merchant domain. Adding a bit more to be crystal clear here. The merchants customer will only see the address in the address bar for the merchant and will be able to validate the merchants public cert. No customer I know of would view the source to make sure that the reference to Stripe.js is in the source. Additional edit to address Silhouette's point. Yes, an attacker can modify the <a href to go to their site as well, but unlike an embedded script the customer does have a chance to call BS and back out of the transaction after growing concerned by the domain transfer & doing a Google search to see if it's legit. They don't have any chance in the case of an embedded script. Now if we go back to my original concern, it's that merchants are being told that they simply need to implement Stripe.js & enable HTTPS. Modifying that statement to something like this would be far better: "Stripe minimizes the scope of PCI DSS by removing the need to implement and audit security controls surrounding the transmission, processing, and storage of card-holder data. This does not; however, absolve Merchants from compliance with the PCI DSS & in order to assist with that we offer the following..."
    - Silhouette 13y ago
      This can be modified by a criminal on the merchant server to go to <script src='//badguy.com/mystripe.js> And then the merchant won't be following one of Stripe's two basic rules for staying PCI DSS compliant any more, will they? That aside, of course you want to keep your server secure. But if you can't, as a matter of practical security and protecting cardholders in the real world, how would it be any better to have your site intended to transfer entirely to a payment service on their own domain rather than just loading JS from that domain? An attacker who has compromised the security of the files on a merchant's server can change an <a href='...'> that should transfer to the payment service so it goes to a hostile site just as easily as they can change a <script src='...'> that should load JS from a payment service so it loads JS from a hostile site.

patcheudor 13y ago

Now if Stripe could practice truth in advertising that would be great. SpecificallY: "Anyone accepting credit card payments must be PCI compliant. Stripe makes it easy to do so: Serve your payment page over SSL, i.e., the page's web address should begin with “https”, not “http”. Use Stripe.js or Checkout to accept payment information and transmit it directly to Stripe's servers. And you'll be PCI compliant!" https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do https://support.stripe.com/questions/do-i-need-to-be-pci-com... If it were only so easy. I guess there's no need for the merchant to have a PCI program, properly implement SSL/TLS, have anti-virus, change default passwords, protect agains SQLi, XSS, command injection or any number of other flaws which would give an attacker access to modify the Stripe.js code or the DOM for the page used for the collection of card information within the merchant's same origin. Nope, none of this is necessary because Stripe says that a merchant only needs to use HTTPS & implement their Stripe.js to be PCI compliant. It's interesting that this isn't how the PCI council sees things: https://www.pcisecuritystandards.org/documents/Tokenization_Guidelines_Info_Supplement.pdf https://www.pcisecuritystandards.org/documents/Tokenization_...

pc 13y ago
Hm, it looks like that support forum answer needs to be updated -- we actually support filling out PCI SAQs right from our dashboard (and automatically ask users to do so). We'll go update it. Also, if you'd like to drop me an email at patrick@stripe.com, would be happy to chat about PCI more.
- pc 13y ago
  (Updated.)
  - patcheudor 13y ago
    Confirmed.
JunkDNA 13y ago
Instead of just down voting this post, it would be helpful to know what specific parts of it are incorrect. This is the first I've heard of these objections.

cfontes 13y ago

I know it's not a priority but. Will you guys bring your magic to Brazil at some point? I would be really interested in it. On a side note I see Australia is in Beta :D which is great. Thanks

pc 13y ago
We definitely will. (Sorry we don't have a timeline, though.)
- cfontes 13y ago
  No Worries! Congrats and keep up the good work!

diziet 13y ago

Hope to see you guys update the web interface a bit for a performance/little more flexibility. The API is great, but the web interface could use a bit more love :)

pc 13y ago
Agreed. On the way!
- diziet 13y ago
  Awesome :) One big issue (with actual effect on revenue of your users) you guys could solve better would be handling delinquent/expiring cards better. We had to built some things in house to deal with this on our end, as once you have a non trivial amount of paying customers it can become at least a small pain. I know there are webhooks for failed payments etc but this stuff is really difficult to surface in the web interface.
  - guayosr 13y ago
    Eduardo from Stripe here - sending you an email now; I think we can help!
  - aculver 13y ago
    Hey Alex, Churn Buster (http://churnbuster.io/ http://churnbuster.io/) is available via Stripe Connect to solve exactly this problem. We're in private beta right now, so please email me at andrew@churnbuster.io if you'd like to take it for a spin. We've got a number of paying customers already (including some folks who previously had their own basic webhooks integration) and they're all saving much more in rescued transactions than they're investing in the product. Also, it's a 30-day free trial, so you literally can't lose! :-)
abuehrle 13y ago
(I'm not associated with Stripe) Can you please give at least one example or suggestion?

Negitivefrags 13y ago

Seeing this comment makes me realise how much of a crazy technical risk I made choosing to use Stripe when I did. My company started charging for things in April 2012, but I made the decision to use Stripe months before that, something like January 2012. Only 4 months after you launched! We only did 1500 transactions on our launch day, yet at the time it was enough to break your service for a little while due to load. Your customer service at the time was really great and you refunded all the transaction fees for our launch day and gave us a list of all the customers who had tried and failed to make transactions so we could contact them. I don't think I realised at the time how small you guys were. We are lucky that you guys didn't fail, and I doubt that the me of today would have relied on such a young company. Certainly we could have moved to a different payment processor, but losing all the saved card data would have sucked a lot. So great work on that!

pc 13y ago
Thanks for taking the risk :-).
deleted 13y ago
[deleted]
nwenzel 13y ago
Large companies tend to have arbitrary size requirements for potential vendors before allowing them to become an approved vendor. But I think companies should consciously choose startups as vendors for precisely that reason. Startups care more about figuring out what it takes to make customers happy.
yesimahuman 13y ago
Yep, same here. Had our first customers in February 2012 on Stripe. Glad it worked out, but we always knew it would :)

simonebrunozzi 13y ago

Patrick, big fan here - we also met in person once, in the Mission. Congrats on the milestone, and keep up the good work.

pc 13y ago
At Blue Bottle, right? (Thanks!)

treenyc 13y ago

I started building a SaaS for the legal industry around 2004. It was very small targeted at specific industry. Back then it was very hard to get everyone on board to use Credit Card. I ended up automating everything (including the monthly billing sent directly the user's inbox), but because of difficulty of payment gateway processing (getting a merchant account, parsing the authorize gateway code) And since I was a one man shop, I just had my users to send me checks at end of the month. I was not the best organized person back then. So let's just say there were quite few uncashed checks. Really wish Stripe was around them.

dmix 13y ago

One of the best parts of that 2011 thread is the number of people asking for Canadian support, then how quickly Stripe actually ended up supporting Canada (within 1 year roughly). We desperately needed Stripe and you guys delivered so quickly. Much appreciated.

TomGullen 13y ago

Stripe is great, we're really enjoying using it! I have three comments though if you're willing to listen! - I think your customer service department (although they do a good job) the quality has gone down, I often have to now wait several days for a reply. I guess this is the inevitability of growth though. In an ideal world it'd be nice to go back to when I got same day replies :) - We're a UK business. We take payments in EUR/GBP/USD. Like EUR, it would be nice to be able to withdraw our USD to our USD account in the UK! At the moment we're forced to withdraw it to our GBP account which is expensive. - It would be nice to be able to hold up withdrawls. At the moment our account is flooded with lots of payments, it would be nice to schedule all payments to be weekly/fornightly or a specific day of the month. Make our accounting process a lot easier and cheaper. Thanks for all the great work, I've been excited ever since I've started reading about you and am a big fan! (I got a tshirt on the way as well for reporting a small glitch which I'm excited to receive!)

peacemaker 13y ago
I'm pretty sure you can hold up withdrawals. You just cancel the automatic transfers from your dashboard then when you want to do a transfer just schedule it manually (or through the API).
michaelschade 13y ago
Thanks for the feedback, Tom! I understand how the USD -> UK transfers would help; we're looking into making that an option. For accounting, we've found that better reporting tools usually solve the need for less frequent transfers. Would one of the options at https://support.stripe.com/questions/reconciling-transfers-with-bank-account https://support.stripe.com/questions/reconciling-transfers-w... make this easier on you? Feel free to email me if not so I can understand more about your setup. Every part of Stripe should be incredibly simple, including accounting, and I want to make sure we get this right. Re support: you're right that the replies have been slower than they should be, though that's getting better. Basically, our userbase grew massively in 2013 and our support hiring didn't keep up with it. I spend all of my time on scaling the team, and we've more than doubled the size of the team in the past couple of months. More hires are on their way. I realize our internal machinations aren't very relevant—you just care that the result is excellent—and I'd like to be clear that we're working on this. You should expect to see significantly faster replies and more ways to get in touch with us over the coming months. While you should already be seeing improvement in this area, feel free to get in touch with me directly at michael@stripe.com anytime. I'd love to hear any other feedback, and am more than happy to help with whatever questions you have.

stevenwagner 13y ago

any Bitcoin integration plans?

drbillnye 13y ago

awesome man, joined the club 2 years ago and now my company relies on you and EasyPost, both YC companies to get our work done every day. It's great to work with your group, you guys have done a great job, props!

ChrisNorstrom 13y ago

Dear Stripe. I love you. Please add Micro-Transactions support like PayPal at the 5% + 0.05 cents transaction fee for payments under $12 dollars. Patiently waiting, Chris Norstrom.

coreymgilmore 13y ago

great job guys. i've used stripe and it definitely works well. love the "checkout" and the customization i can do with integration into my own page. pretty seamless compared to other vendors. only quip: price! would love to see a different pricing scheme for cheaper products. $0.30 fixed fee is a lot for carts that are only a few dollars!