14 ms·

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 em

by LeBlanc 15y ago

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 15y ago
Out of curiosity, how does an embedded iframe let you avoid PCI completely and an external javascript lib not?
- LeBlanc 15y ago
  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 15y ago
    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 15y ago
      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 15y ago
        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 :)
        saurik 15y ago
        (PayPal Digital Goods for Express Checkout in fact uses an iframe.)
        shivang 15y ago
        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&content_ID=developer/e_howto_api_APIntro 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.
    - LeBlanc 15y ago
      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 15y ago
    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 15y ago
    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 15y ago
  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 15y ago
    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.

by LeBlanc 15y ago

mrkurt 15y ago

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

LeBlanc 15y ago
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 15y ago
  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 15y ago
    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 15y ago
      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 :)
      - saurik 15y ago
        (PayPal Digital Goods for Express Checkout in fact uses an iframe.)
      - shivang 15y ago
        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&content_ID=developer/e_howto_api_APIntro 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.
  - LeBlanc 15y ago
    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 15y ago
  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 15y ago
  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 15y ago
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 15y ago
  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.