[isaachall]

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.

[trungonnews]

You're missing the point.

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. :)

[tptacek]

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.

[robfig]

PCI Compliance is about protecting consumers from third parties, not from the merchant.

As part of Compliance, the merchant attests that he never handles the cardholder information, and that closes off huge portions of it.

[drivebyacct2]

... which thus precludes the security (and thus simplicity) aspect of Recurly.js.

[pbreit]

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.

[trungonnews]

socialgold had a similar product before google acquired it.