You're exposing credit card number on the input field of the original publisher's HTML page. This means that the publisher can pick up the credit card number himself, or an included third party javascript library(like google analytics).
I think this is absolutely true, but my understanding is that the PCI powers-that-be are OK with it. If the credit card numbers are by design not hitting your server, you don't need an audit. Yet another reason why we've avoided doing PCI stuff.
The Recurly.js library dramatically reduces PCI compliance scope because the sensitive cardholder data does not pass thru your servers. There's a lot of additional PCI compliance issues when the credit card numbers pass thru your server, even if it only resides in memory during the request. Instead, the data is sent directly from the web browser to Recurly, who is PCI Level 1 Compliant.
Obviously, you still have to maintain a secure web server regardless of how you collect payments. That means protecting your users from cross site scripting.
Madness. Are users expected to check the DOM tree before they type their credit card details in to make sure they're sending their info to the iframe they expect to?
The rule should be: if your app has a credit card form under its own banner, the whole thing is implicated for PCI assessments. But that's not the rule.
Recurly still supports hosted payment pages in which case the merchant doesn't need SSL.
As far as I know, Recurly and Stripe are the only two processors providing JavaScript libraries to tokenize credit card information such that merchants do not handle the credit card information that suscepts them to PCI compliance.
You're exposing credit card number on the input field of the original publisher's HTML page. This means that the publisher can pick up the credit card number himself, or an included third party javascript library(like google analytics).