Since the page is loaded over plaintext, there's no easy way for a normal user to know that the credit card isn't being intercepted by a malicious script. It's not safe to serve a payment page over plaintext HTTP, even if it POSTs to a HTTPS endpoint as it could be modified in transit.
If you read a bit further, the Stripe documentation explains that it is recommended, but not required.
You can make live transactions just fine from a regular HTTP page - whether that's a good idea or not is another issue, but making Stripe payments from an HTTPS payment page is not required from an API point of view.
Required in the 'it's a good idea because it will make the web more secure and make your customers trust you' sense, not required in the sense that it's something the API enforces.
Yes, but how do you know you're looking at the correct payment page?
The page that sends the POST request should also be verifiable as owned by the domain, otherwise I could inject a different "payment system" library, that looked like stripe to the user (unless they analyzed the traffic), but actually sends me the CC details.
> - It's more secure. In particular, it significantly reduces your risk of being exposed to a man-in-the-middle attack.
> - Users correctly feel more comfortable sharing their payment information on pages visibly served over SSL. Your conversion rate is likely to be higher if your pages are served over SSL/TLS, too.
I had to look around for a minute to find the "powered by stripe" message in the bottom left corner of the overlay. Simply seeing that message shouldn't be synonymous with security. I'm trained to look for the secure lock in the address bar of the browser.
