[LeBlanc]

I'm the lead API engineer at WePay, so I'm definitely biased toward the WePay API, but I do think Stripe is a great service.

The WePay API does allow you to embed the entire checkout experience on your own site with our iframe checkout. The iframe contents are customizable (header color, button color, etc), but as Greg mentions in the comments, it's not quite as customizable as Stripe or another merchant account based system.

Unfortunately, even with Stripe, you are still liable for most of the PCI spec (our iframe checkout gets around this). We made a bet that there are a lot of developers out there that who are willing to give up a little on the customization side to not have to deal with the headache of PCI compliance (we've gone through that process ourselves and it is complicated and expensive).

[mrkurt]

Out of curiosity, how does an embedded iframe let you avoid PCI completely and an external javascript lib not?

[LeBlanc]

The external javascript library is still being loaded on a page served from your domain, so it's totally possible for you to grab the credit card data and ajax it to your server (or for an XSS vulnerability to allow a 3rd party to send it somewhere). Since the CC info is accessible to both the client and Stripe, both are liable for PCI compliance. [edit: just to be clear, with stripe, you aren't liable for all of the PCI spec (just part), which is one of the awesome things about the service]

With the iframe, the checkout form is served from WePay's domain, so javascript on your page can't directly access elements on the checkout form. There are still potential vulnerabilities such as clickjacking (we do some things to protect against this), but since the CC form is served from our domain, only we are liable for PCI compliance.

[boucher]

We at Stripe (and more importantly, our PCI auditors) don't agree with this assessment of how the chain of responsibility works.

When you use Stripe.js, you need only serve your page over SSL and verify that you aren't collecting credit cards through other means to be PCI compliant.

[tptacek]

We don't do PCI assessments (I have a generally low opinion of the process), but we do the "real" appsec work for lots of companies that do, and the impression I have is that --- counter to what you'd expect --- 'boucher is right, and you can self-assess using their interface, despite the fact that anyone doing so is in fact an XSS flaw away from giving up cards.

In particular, while I have no idea whether Stripe's implementation is letter-of-the-law PCI compliant, I do know that 'LeBlanc's reasoning is not PCI reasoning (particularly: you can't draw a line from architectural susceptibility to "liable to audit") --- even though it's the reasoning I myself would use.

[lsh123]

Interestingly, PayPal actually offers (or offered?) an iFrame checkout for some customers and it was confirmed to be PCI-compliant. But again, another PCI auditor might have another opinion on it :)

[shivang]

Paypal actually offer a Embedded payment experience which in no sense gives the feeling of embedded payments on the website. https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&c...

On this link you can find the experience of Embedded payments, i implemented it on our site but the docs on the api are not complete on paypal, rather complete they are not present at one place.

[saurik]

(PayPal Digital Goods for Express Checkout in fact uses an iframe.)

[lsh123]

Disclaimer: I work for WePay and I am directly responsible for WePay's PCI audit process

I am sure everyone would agree that PCI spec is complex and not easy to understand :) Said that, its intention is pretty clear: protect credit card information from leaking to "bad" guys.

A great deal of PCI spec is about protecting the stored credit card data. You are absolutely correct that Stripe's JS solution allows one to avoid dealing with these issues. However, many other sections of PCI spec discuss other potential vectors of attacks. For example, if you don't follow security coding guidelines then an attacker can embed a malicious JS on your website (through XSS or other attacks) and steal credit cards information. Obviously, the suggestion to serve your pages from SSL don't help you to avoid these problems.

I think Stripe's model is great. But I don't believe that it allows one to completely avoid PCI compliance. I believe that you correctly phrased it on the stripe's home page: "Stripe.js lets you build your own payment forms while still avoiding most PCI requirements."

[gtaylor]

I guess you could say Stripe gives you the shotgun, but you have to decide whether you want to use it properly, or blow your foot off.

So basically: Be smart about what goes on your sensitive, mission-critical payment-receiving pages, as you should be. It's not extremely difficult. A little bit more responsibility in turn for more flexibility.

[lsh123]

Someone already said in this discussion that PCI compliance is a legal term :) To some degree, it is a deal between you and your QSA (or you again if you are doing self-assessment). I heard about a few businesses that accept credit card numbers w/o bothering to do anything about security at all. You will need to decide for yourself the acceptable risk for your business in various "things gone bad" scenarios and how much you want to invest in protecting against scenarios that are bad for your business.

We've designed WePay solution to make it "out-of-the-box" as secure as possible for both our partners and WePay. We plan to offer more customization options in the future to improve usability while keeping it simple and secure to use. Doing security right is hard. We believe that WePay can help with it and make our partners life easier.

[nupark2]

This seems like a risky compliance hack to be relying on. While it might conform to the letter of the law[1], it absolutely does not comply with the spirit of PCI compliance in regards to securing cardholder data.

There's literally no security difference between processing the card transaction through your own servers, and processing it client-side via HTML/JS that your servers are providing (and can modify).

[1] I wouldn't have thought this would meet compliance requirements, but I'm not a PCI expert -- I've only had to work on compliance on the user side, and deal with the auditing requirements.

[LeBlanc]

Sorry, I should have made it more clear that with stripe you aren't liable for all of the PCI spec (I edited my comment to reflect that).

Either way, I think Stripe is doing awesome work and I hope you keep kicking ass!

[saurik]

With this same argument, could I not use the JavaScript I inject into the site (via XSS or whatever) to replace your entire iframe with a different iframe (hosted off my corrupt and evil server) that looked identical to yours? I don't need to access elements of the checkout form: the key problem with an iframe is that the user cannot tell what the URL of the iframe is to do basic verification of where the page is being served from.

[ericd]

What about a script injection to rewrite the DOM and create a mock WePay iframe that's actually loaded from a third party server?

[tptacek]

There is no good reason for any of these backdoors around PCI, except for the fact that everyone knows it's not going to be feasible to "test"† every website anywhere that does any commerce.

It's probably best not to ask too many questions. It'll only hurt your brain.

† (If that's what you want to call PCI assessments)

[dminor]

Another thing to keep in mind is that PCI scope and PCI requirements expand with every iteration, so today's backdoor may be gone tomorrow.

PCI compliance is ridiculous enough that it's still worth avoiding though, even if only for the short term.