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).
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).
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.
While the user is entering the credit card number, there's a chance that someone can intercept and steal the CC.
You can easily solve this problem by putting the credit card form inside your own iframe. :)
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.
As part of Compliance, the merchant attests that he never handles the cardholder information, and that closes off huge portions of it.
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.
These forms sure are pretty though.