Live data from Hacker News

Payment iframe - the easiest way to insert Stripe into your website

paymentiframe.com

41–50 of 84 posts

Re: Payment iframe - the easiest way to insert Stripe into your website

#41
post #40
post #36

Earlier quoted context omitted.

That doesn't make any sense, because the whole point of PAYMENTIFRAME.COM is that you don't trust Stripe. Colin implemented this because besides credit card numbers , he was unwilling to give Stripe control over his website. Colin's users trust him with things that are much more sensitive than credit card numbers.

People trust Stripe. I think the issue here is Javascript and origin-policy and relinquishing control. When Stripe releases their version of STRIPEPAYMENTIFRAME.COM as an iframe solution then this can go away. I believe Colin mentioned a need for this now rather than waiting for Stripe. Interesting side note: Yes I know it's only meant to be a demonstration site but PAYMENTIFRAME.COM is using Google Analytics. Oh HAI…

Colin trusts Stripe to collect credit cards. He does not trust them for anything else. Embedding the form on a page on TARSNAP.COM trusts them for everything that can happen on any web application on the same domain.

Re: Payment iframe - the easiest way to insert Stripe into your website

#42
post #35

Please don't use this. There is nothing stopping paymentiframe.com from taking your customer's credit card numbers.

Do you use Typekit? Google Analytics? Mixpanel? Olark? Do those services get used anywhere in the path your users might take from your front page to the page in your app where you take credit cards? Then all those services can take your customer's credit cards too. I frankly trust Colin Percival a lot more than I trust Olark. And I like Olark. Your point is something Colin should address in his FAQ, and so it was goo…

> Your point is something Colin should address in his FAQ, and so it was good of you to make it, but it's also trivially knocked down.

So, you're saying that because Google Analytics could conceivably touch credit card information (using Stripe's JS), it's perfectly fine for some random guy with a suspect domain-name to?

I disagree.

Re: Payment iframe - the easiest way to insert Stripe into your website

#43
post #35

Earlier quoted context omitted.

Do you use Typekit? Google Analytics? Mixpanel? Olark? Do those services get used anywhere in the path your users might take from your front page to the page in your app where you take credit cards? Then all those services can take your customer's credit cards too. I frankly trust Colin Percival a lot more than I trust Olark. And I like Olark. Your point is something Colin should address in his FAQ, and so it was goo…

> Your point is something Colin should address in his FAQ, and so it was good of you to make it, but it's also trivially knocked down. So, you're saying that because Google Analytics could conceivably touch credit card information (using Stripe's JS), it's perfectly fine for some random guy with a suspect domain-name to? I disagree.

I think Thomas is saying that I'm not "some random guy".

Re: Payment iframe - the easiest way to insert Stripe into your website

#44
post #36

Earlier quoted context omitted.

The book describes techniques that Stripe could use in developing their own iframed credit card form. I'd only trust a solution from them directly.

That doesn't make any sense, because the whole point of PAYMENTIFRAME.COM is that you don't trust Stripe. Colin implemented this because besides credit card numbers , he was unwilling to give Stripe control over his website. Colin's users trust him with things that are much more sensitive than credit card numbers.

That's great for Colin. But he should describe the steps he took to host his own iframed Stripe form. Not encourage others to blindly copy/paste an tag pointing to his domain onto their website.

Re: Payment iframe - the easiest way to insert Stripe into your website

#45

Earlier quoted context omitted.

Maybe the FAQ should include a "Q: Why should I trust your domain to host this for me? A: You shouldn't. This is a sample, you should implement it yourself for security."

Good point, added. I thought it was obvious, but given some of the comments here, I guess it wasn't obvious enough.

Thanks!

I think it's obvious to most people here, but Stripe's targeted at essentially everyone. It's quite possible that someone'd stumble across your site who just learned PHP and goes "sounds good, I'll drop it in".

Re: Payment iframe - the easiest way to insert Stripe into your website

#46
post #41
post #40

Earlier quoted context omitted.

People trust Stripe. I think the issue here is Javascript and origin-policy and relinquishing control. When Stripe releases their version of STRIPEPAYMENTIFRAME.COM as an iframe solution then this can go away. I believe Colin mentioned a need for this now rather than waiting for Stripe. Interesting side note: Yes I know it's only meant to be a demonstration site but PAYMENTIFRAME.COM is using Google Analytics. Oh HAI…

Colin trusts Stripe to collect credit cards. He does not trust them for anything else. Embedding the form on a page on TARSNAP.COM trusts them for everything that can happen on any web application on the same domain.

Did my comment not cover something?

Re: Payment iframe - the easiest way to insert Stripe into your website

#47
post #35

Earlier quoted context omitted.

Do you use Typekit? Google Analytics? Mixpanel? Olark? Do those services get used anywhere in the path your users might take from your front page to the page in your app where you take credit cards? Then all those services can take your customer's credit cards too. I frankly trust Colin Percival a lot more than I trust Olark. And I like Olark. Your point is something Colin should address in his FAQ, and so it was goo…

> Your point is something Colin should address in his FAQ, and so it was good of you to make it, but it's also trivially knocked down. So, you're saying that because Google Analytics could conceivably touch credit card information (using Stripe's JS), it's perfectly fine for some random guy with a suspect domain-name to? I disagree.

Sourcing dynamically-generated Javascript from some opaque randomized URL that plugs into an entire giant Rails application that nobody has ever assessed and that sees an "agile" deployment once every three hours, solely in order to get "dynamic A/B testing metrics" or "live chat": JUST FINE.

Sourcing static content from a static web server run by a security expert in order to segregate your application's secrets from those of Stripe: TOTALLY IRRESPONSIBLE.

Re: Payment iframe - the easiest way to insert Stripe into your website

#48

Earlier quoted context omitted.

Good point, added. I thought it was obvious, but given some of the comments here, I guess it wasn't obvious enough.

Thanks! I think it's obvious to most people here, but Stripe's targeted at essentially everyone. It's quite possible that someone'd stumble across your site who just learned PHP and goes "sounds good, I'll drop it in".

It's quite possible that someone'd stumble across your site who just learned PHP and goes "sounds good, I'll drop it in".

I'm not sure that someone would be automatically wrong to do that. People should be aware that using paymentiframe.com means trusting me to not steal their customers' credit cards and trusting me to keep the site secure, but if someone makes an informed decision to place that trust in me, I can't say that they're necessarily wrong to do so.

As I said: Tools, not policy.

Re: Payment iframe - the easiest way to insert Stripe into your website

#49

Earlier quoted context omitted.

> Your point is something Colin should address in his FAQ, and so it was good of you to make it, but it's also trivially knocked down. So, you're saying that because Google Analytics could conceivably touch credit card information (using Stripe's JS), it's perfectly fine for some random guy with a suspect domain-name to? I disagree.

I think Thomas is saying that I'm not "some random guy".

Your name is familiar...You're the fellow that does security consulting for bingo card sites right? :)

Re: Payment iframe - the easiest way to insert Stripe into your website

#50
post #38

Earlier quoted context omitted.

And you can accomplish the same thing by using an iframe that you have full control over. Instead, if you use this service, you're trusting another 3rd party site to be available and to not be compromised.

That is true, but the point is that the only thing that is going to be compromised is the data that would be going to Stripe. I know it is shocking to many of you to hear this, but the data Stripe collects is not really the most sensitive information on the Internet. The point of the iframe is to contain the damage from any possible compromise. If PAYMENTIFRAME.COM is insecure (heh), you still aren't going to lose us…

No, just potentially their credit card information.
Post reply on HN