> they are changing Stripe.js to now serve up the data in an iFrame so you can keep using their product more or less like before but without heightened requirements
I imagine they're changing things to be like Google Wallet, where you use a pop-out window to type your credit card number into (just the first time, it's save on their side after). That way you know you're giving your CC just to google.com by looking at the URL of the new window.
Stripe's current JS-based version has better UX, but it's a little scary if the merchant whose site you're entering your card into has no legal security requirements. On the other hand, it's a purely theoretical problem afaik - I haven't heard of any breaches resulting from merchants which use JS third party payment solutions having their websites hacked to serve up bad JS.
I've seen non-https sites serve up HTTPS iframes. The whole iframe thing just seems like a bad idea for processing credit information. Ignoring HTTP interception, it's difficult for customers to verify that the iframe is indeed coming from an HTTPS site.
With the old Stripe.js, you serve up the form but the Stripe javascript takes over the form and posts directly to Stripe, so your servers never see the data.
The new Stripe.js will render an iFrame, (Edit:) through which Stripe will send the data, which again posts to directly to stripe.
They basically behave the same way and will look the same way, the only difference is that the iFrame is in it's own Javascript "domain" so that if your site is infected with malicious javascript it can't take over the POST to stripe as easily (although that is debatable).
The former requires really high security requirements now and the latter requires almost none.
The new Stripe.js does not render an iframe, the credit card information is still entered on your site so $("#credit-card-number").val() would return the card number. The transmission of the card data happens through the iframe. So the card number gets copied to the iframe, and the iframe makes the post to Stripe.
> the iFrame is in it's own Javascript "domain" so that if your site is infected with malicious javascript it can't take over the POST to stripe as easily (although that is debatable).
A malicious attacker could simply replace the entire iframe with something else that looks identical, but sends a copy of the CC details to some other server.
I imagine they're changing things to be like Google Wallet, where you use a pop-out window to type your credit card number into (just the first time, it's save on their side after). That way you know you're giving your CC just to google.com by looking at the URL of the new window.
Stripe's current JS-based version has better UX, but it's a little scary if the merchant whose site you're entering your card into has no legal security requirements. On the other hand, it's a purely theoretical problem afaik - I haven't heard of any breaches resulting from merchants which use JS third party payment solutions having their websites hacked to serve up bad JS.