4 ms·

If there is anyone from Stripe here, this is certainly not a good payment experience: http://c.kristian.io/image/0g331z470L2g http://c.kristian.io/image/0g331z4

If there is anyone from Stripe here, this is certainly not a good payment experience: http://c.kristian.io/image/0g331z470L2g http://c.kristian.io/image/0g331z470L2g There is no way for the user to verify that the payment details are indeed sent over HTTPS. I wouldn't want to enter my payment details in a form like that.

bgross 13y ago
Hey yeah so that's the default out-of-the-box Stripe payment solution. Wish I had more time to setup something more familiar like paypal. But got rejected from app store a few days ago and wanted to release this weekend.
- bgross 13y ago
  also, not sure how I feel about charging for this in general. Figured I'd try as that was the original app store plan. Here's a free link for HN types though: prismviz.com/download/hackernews
  - oellegaard 13y ago
    I think it's more than fine to charge for your app - the price is also very affordable ;)
chrischen 13y ago
I think the website owner is supposed to put the page the payment form is on on a HTTPS site.
pc 13y ago
(I work at Stripe.) Yeah, we require that people use SSL on the payment pages they serve. ... And yet, despite that, it's not quite a clear-cut situation. When you enter payment details on a site, checking for HTTPS in the address bar is just a heuristic -- you're (mostly reasonably) assuming that "the payment form is served over HTTPS" implies "payment details will be submitted over HTTPS". Browsers try to help here (with warnings for HTTPS -> HTTP form submission), but a poorly implemented site could easily leak information, and you couldn't tell in advance unless you audited all the HTML and JavaScript. The Stripe Checkout -- which prismviz is using -- always submits details over SSL (of course), but we additionally require websites to serve the enclosing page over SSL because it's both more secure and what users expect. We rolled out some code recently to more effectively prod users that aren't using SSL in production to implement it. This helps a bit, but it'll always be possible for a weekend project to go live without having crossed every t. Either way, people tend to do the right thing here pretty quickly, since -- as this thread shows -- users complain if they don't.
- mbesto 13y ago
  > but we additionally require websites to serve the enclosing page over SSL because it's both more secure and what users expect. Curious - what makes it more secure if it does and less secure if doesn't?
  - pc 13y ago
    In theory, someone could have MITM'd the page and replaced the site's publishable key with their own.
    - btown 13y ago
      Or they could have replaced the entire Stripe JS with custom JS that presents a similar-looking dialog that submits the CC data to a third party (possibly also submitting it to Stripe to avoid detection).

bgross 13y ago

Hey yeah so that's the default out-of-the-box Stripe payment solution. Wish I had more time to setup something more familiar like paypal. But got rejected from app store a few days ago and wanted to release this weekend.

bgross 13y ago
also, not sure how I feel about charging for this in general. Figured I'd try as that was the original app store plan. Here's a free link for HN types though: prismviz.com/download/hackernews
- oellegaard 13y ago
  I think it's more than fine to charge for your app - the price is also very affordable ;)

chrischen 13y ago

I think the website owner is supposed to put the page the payment form is on on a HTTPS site.

pc 13y ago

(I work at Stripe.) Yeah, we require that people use SSL on the payment pages they serve. ... And yet, despite that, it's not quite a clear-cut situation. When you enter payment details on a site, checking for HTTPS in the address bar is just a heuristic -- you're (mostly reasonably) assuming that "the payment form is served over HTTPS" implies "payment details will be submitted over HTTPS". Browsers try to help here (with warnings for HTTPS -> HTTP form submission), but a poorly implemented site could easily leak information, and you couldn't tell in advance unless you audited all the HTML and JavaScript. The Stripe Checkout -- which prismviz is using -- always submits details over SSL (of course), but we additionally require websites to serve the enclosing page over SSL because it's both more secure and what users expect. We rolled out some code recently to more effectively prod users that aren't using SSL in production to implement it. This helps a bit, but it'll always be possible for a weekend project to go live without having crossed every t. Either way, people tend to do the right thing here pretty quickly, since -- as this thread shows -- users complain if they don't.

mbesto 13y ago
> but we additionally require websites to serve the enclosing page over SSL because it's both more secure and what users expect. Curious - what makes it more secure if it does and less secure if doesn't?
- pc 13y ago
  In theory, someone could have MITM'd the page and replaced the site's publishable key with their own.
  - btown 13y ago
    Or they could have replaced the entire Stripe JS with custom JS that presents a similar-looking dialog that submits the CC data to a third party (possibly also submitting it to Stripe to avoid detection).