So long as stripe.js is linked from your site, there is nothing preventing someone who can breach your server from seeing all CC numbers going through that page (namely by modifying the served stripe.js). It is just as insecure as processing the CC numbers on the server yourself, but deleting them after confirming the transaction.
I know for a fact that Stripe is staffed by some really brilliant people, so maybe I am missing something, but as far as I understood, their business model has always been: "ease the legal requirements on merchants by making use of the technicality of not sending CC info to their servers, while still not significantly adding security to CC processing".
But this is kinda a fundamental issue with the whole CC# system, one that redirecting to "trusted processors" just marginally improves. It stretches belief sometimes that in 2015 we have full-disk encryption and TLS-everywhere, but not a sane financial transaction system based on public-key signatures (hopefully we are moving in that direction now? and getting chips in US cards?).
So long as stripe.js is linked from your site, there is nothing preventing someone who can breach your server from seeing all CC numbers going through that page (namely by modifying the served stripe.js). It is just as insecure as processing the CC numbers on the server yourself, but deleting them after confirming the transaction.
This has always been a weak argument though, because if someone can breach your server, they can impersonate whatever they like from a typical visitor's point of view and see whatever data anyone enters. They can do this even if you're not a legitimate merchant at all and don't even use a credit card payment service.
Redirecting to a external processor still works to some degree, assuming people check for say "[PayPal, Inc [US]]" in their address bar. I am not arguing that the iframe thing is really better (specially not an invisible iframe). I am arguing that there are good reasons for requirements to be more demanding than "you must send your POST requests to a trusted server".
I suppose ideally we should have platform support for this sort of thing, though. Perhaps something like a payments browser API, hopefully supporting multiple processors (like most browser's search bars). After set-up it should be as simple as getting a browser-level pop-up asking you to confirm the amount or cancel it (plus any sort of auth required by the processor, which hopefully should be as simple as nothing for small transactions and tapping your card to the NFC reader for large ones).
> 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.
The heightened requirements are actually for when you are using services that _don't_ let the merchant see the CC number. Like the "old" Stripe.js.