Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Payments Startup Stripe (YC S10) Joins the Billion Dollar Club

online.wsj.com

Post reply on HN
Print view View original

101–110 of 131 posts

Re: Payments Startup Stripe (YC S10) Joins the Billion Dollar Club

#101

Post by [deleted] »

rgbrenner wrote: post #96
steven2012 wrote: post #91

Earlier quoted context omitted.

My understanding by reading patcheudor's responses is that the issue isn't with Stripe's PCI compliance, but rather the fact that merchants that use Stripe's API need to be fully PCI compliant. According to him, using Stripe's API doesn't obviate the merchant's need to be fully PCI compliant, unless they do something like open up another window where the URL clearly shows that they are inputting a form from Stripe's…

This is my reading of his comment too.. more specifically, that since the page comes from the merchants server, the page could be modified by an attacker to alter the form to (for example) submit credit card details to another server instead of Stripe's. I think he has a point here. Certainly if the merchants web site is compromised, Stripe's PCI compliance won't prevent or detect the loss of credit card data (since…

[deleted]

Re: Payments Startup Stripe (YC S10) Joins the Billion Dollar Club

#102

Post by proksoup »

slexaxton wrote: post #88
patcheudor wrote: post #70

Earlier quoted context omitted.

That was maybe not quite the right language, but is easily salvageable. What the author was trying to convey is that the Stripe.js code is instantiated within the user browser by an HTTP response from the server infrastructure owned by the merchant. The actual credit-card form is delivered by the merchants server & therefore they own all the PCI DSS related controls surrounding ensuring that the payment form code del…

[Stripe Developer] [edited for clarification] I appreciate your interest in the security of Stripe, I think we definitely share the same goals here (making everything as secure as possible). However, I think there's some misunderstanding in some posts (and in the blog post): > [...] the Stripe.js code is instantiated within the user browser by an HTTP response from the server infrastructure owned by the merchant When…

This pretty clearly demonstrates to me the problem --- the stripe developers and management themselves don't actually understand the problem.

Patch is right, you need to be PCI compliant and Stripe (despite their recent funding) is apparently misunderstanding the problem with their approach.

And frankly, PCI compliance be damned, can ya'all not see how the "redirect to page" way is more secure.

Stripe hiding behind "our code is fine, only if you get hacked is it a problem" is, quite frankly, disgusting blame redirection.

Re: Payments Startup Stripe (YC S10) Joins the Billion Dollar Club

#103

Post by reinhardt »

lucidrains wrote: post #19

I am a developer interested in integrating a payment system into one of my sites where my target customers are mainly in the US. Could someone outline the major differences between Stripe and Balanced?

I'm also interested in this and would like to include in the comparison other companies which may (or may not, hard to tell as an outsider) be in the same space: Square, Dwolla, Braintree, WePay.

Re: Payments Startup Stripe (YC S10) Joins the Billion Dollar Club

#104

Post by naz »

diziet wrote: post #40
abuehrle wrote: post #33

Earlier quoted context omitted.

(I'm not associated with Stripe) Can you please give at least one example or suggestion?

Sure, glad to give feedback, though this would make sense if you're familiar with using stripe. Our team is of course not one of Stripe's larger users, though we do use them enough to fall under one of the volume discounts. Here's a few things that I can think of from the top of my head: When selecting a user to change the plan, the modal takes about 3-4 seconds to populate the new plan dropdown. The new plan dropdow…

> Event view is pretty cumbersome for managing things, as it shows only 20 events at a time.

Here's a secret URL for you: https://manage.stripe.com/events?count=100 :)

Re: Payments Startup Stripe (YC S10) Joins the Billion Dollar Club

#105

Post by billclerico »

jmtame wrote: post #72

Was just watching the old prototype day recordings from the s09 batch. Impressively focused on the same problem since day 1: "We're like Authorize.net, but we're easier and faster." Lots of progress - congrats!

where are these? i'd love to check them out

Re: Payments Startup Stripe (YC S10) Joins the Billion Dollar Club

#106

Post by pc »

diziet wrote: post #59
pc wrote: post #45

Earlier quoted context omitted.

This is great feedback -- thanks very much!

Happy to swing by your office sometime when you're hosting one of those hackathons (we're a few blocks away ourselves) :)

That would be great -- want to drop me an email (patrick@stripe.com) to coordinate?

Re: Payments Startup Stripe (YC S10) Joins the Billion Dollar Club

#107

Post by pc »

rgbrenner wrote: post #96
steven2012 wrote: post #91

Earlier quoted context omitted.

My understanding by reading patcheudor's responses is that the issue isn't with Stripe's PCI compliance, but rather the fact that merchants that use Stripe's API need to be fully PCI compliant. According to him, using Stripe's API doesn't obviate the merchant's need to be fully PCI compliant, unless they do something like open up another window where the URL clearly shows that they are inputting a form from Stripe's…

This is my reading of his comment too.. more specifically, that since the page comes from the merchants server, the page could be modified by an attacker to alter the form to (for example) submit credit card details to another server instead of Stripe's. I think he has a point here. Certainly if the merchants web site is compromised, Stripe's PCI compliance won't prevent or detect the loss of credit card data (since…

> I think he has a point here. Certainly if the merchants web site is compromised, Stripe's PCI compliance won't prevent or detect the loss of credit card data (since it never reached the point where Stripe could protect it).

Yes, this is certainly true. This is why we also use the dashboard to ask the relevant questions from the PCI self-assessment questionnaires. https://support.stripe.com/questions/do-i-need-to-be-pci-com... gives a brief overview, but this discussion is making me think that we need to write something longer and more definitive. There's a lot of confusion around PCI pretty much everywhere.

Re: Payments Startup Stripe (YC S10) Joins the Billion Dollar Club

#108

Post by icelancer »

diziet wrote: post #40
abuehrle wrote: post #33

Earlier quoted context omitted.

(I'm not associated with Stripe) Can you please give at least one example or suggestion?

Sure, glad to give feedback, though this would make sense if you're familiar with using stripe. Our team is of course not one of Stripe's larger users, though we do use them enough to fall under one of the volume discounts. Here's a few things that I can think of from the top of my head: When selecting a user to change the plan, the modal takes about 3-4 seconds to populate the new plan dropdown. The new plan dropdow…

>When selecting a user to change the plan, the modal takes about 3-4 seconds to populate the new plan dropdown. The new plan dropdown is like 200px wide, which makes managing multiple plans pretty cumbersome.

I agree with this. I was wondering "What Stripe UI improvements?" because I am largely happy with the UI (very much so, actually). But there are corner cases that could use some tweaking. This is definitely one.

The main dashboard could have some more information, or could be customizable, I agree. Not high priority for me but would be nice.

Post reply on HN