Collecting credit card info in HTTPS iframe within an HTTP site

What they are doing is certainly better than not doing https at all. However, their external http page is more susceptible to attacks like Man-In-The-Middle that could cause the 'secure' iFrame to be replaced or compromised in other ways. This method makes it hard for end users to make their own determinations, too - the lock icon is helpful and browsers are working hard to teach the users how to determine if a site is safe.

Given the minimal cost of https now and given how much additional security it offers in general, there's no reason for them to defend this - they should just fix it and go https everywhere.

Caveat, IANAQSA

Update: Slate isn't actually a SAQ A - they aren't using iframes, and they're submitting card info to, for example, https://profile.slate.com/widget/traditional_register.jsonp... most of what's below still applies in spirit though.

Could someone tell me if it is possible to securely get credit card information in the way they have described?

Yes, it is possible. However, there is some implied responsibility shifted to you to check that your connection is secure and that the payment site you go to is a legitimate payment processor.

That said, this configuration is both acceptable (as per PCI) and mildly inadvisable (per security best practices).

A reading of SAQ A - which applies to merchants who outsource all card handling to their processor via an iframe - suggests that this is a legal configuration. Note that it does not place any explicit requirements on the pages containing the payment page (iframe) enclosing the Service Provider's payment page(s); just the SP's page(s) come from the SP and the SP is PCI DSS compliant (which implies encryption):

Now, that being said, there are issues such as MITM that make the lack of outer encryption by Slate inadvisable. Many organizations have fought their way over this hump and eventually decided that encrypting everything on their site was preferable to dealing with the perception of insecurity. But it usually takes time and complaints before they organizations get there. So feel free to complain about this.

When you encrypt the whole site, you are protected against passive attackes, who only read the traffic without modifying it, as well as against active attackers, who will actively try to obtain information from you and to bypass security measures. By using an encrypted iframe, you are still protected against passive attackers, because the payment data is encrypted in transit. However, because the original page is unencrypted, an active attacker (aka a man in the middle) can just replace the secure iframe with one pointing to their own site, which they can make look identical to the one that is supposed to be there, or just force the iframe to load and submit over an unsecured connection (provided that it's not using HSTS to force you to load it over HTTPS). They are then able to capture everything that you enter, including your payment details. Moreover, there are no browser notices to inform you that what you enter is being intercepted, because iframes don't have protocol or origin indicators. That means that the only way for you to detect an attack like this would be to inspect element on the form, which almost nobody would do.

Using a HTTPS iframe is far better than nothing, but it would be wrong to say that is secure. Personally, I would never enter payment details on a page that doesn't have https in the URL bar, but when on a trusted connection (aka not public wifi), the risk is very small.