6 ms·

Colin, With the iframe implementation, is the burden of PCI compliance back on you(or someone who implements a similar function on their own hardware)? I tota

• cperciva 14y ago
  The PCI rules only apply to systems which touch credit card data -- not to a system which serves up a credit card form.
  • DASD 14y ago
    Sorry if I misunderstand. Aren't you(paymentiframe) processing the form which is touching the data and then passing the data onto Stripe via their API?
    • cperciva 14y ago
      The iframe uses Stripe's javascript to send the card details directly to Stripe's servers -- the only thing which hits the tarsnap server is a token which Stripe returns (and nothing at all goes back to the server hosting the iframe).
      • flatline3 14y ago
        This approach of Stripe's has always seemed like a bit of a shell game to me, but I can only assume it's been deemed PCI compliant.
        • cperciva 14y ago
          As I point out in my blog post, what the networks care the most about is ensuring that there aren't months or years worth of cards stored anywhere which might leak out. Having a site get compromised and a few days of cards stolen is orders of magnitude less important.
          • harshreality 14y ago
            I think the point was frustration over the disconnect between PCI rules and reality, that there's no difference in security between self-hosting the form action (over ssl, sending the cc info to the payment processor, and getting a confirm that way), compared to hosting an iframe and "not touching" credit card data. A compromised webserver means the iframe can be compromised so that the card details do hit your server.
            • Ralith 14y ago
              There is a difference: If the data never touches your server at all, it is impossible for you to inadvertently record it.
              • deleted 14y ago
                [deleted]
              • sp332 14y ago
                If the iframe that you host is compromised, you have no idea where that info is being recorded. The fact that it doesn't touch your server doesn't ensure that your site isn't leaking numbers.
                • Ralith 14y ago
                  Certainly. But it does ensure that access to your server does not entail access to historical numbers.
                  • flatline3 14y ago
                    Unless the compromise is a long-term one. Part of what PCI attempts to address is limiting legitimate access to servers, as well as preventative measures against compromise. I personally think that Stripe may be within the letter of the law, but not necessarily the spirit.
          • atesti 14y ago
  • dan_manges 14y ago
    That's not universally true. Unfortunately, the PCI DSS is somewhat subjective and enforced inconsistently, so it's difficult to definitively answer what's required for PCI compliance for a certain type of payments integration. Even for merchants that use third-party hosted payment forms, it's still common to need to complete SAQ A (a short self-assessment questionnaire) and have quarterly network scans. For example, with PayPal[1]: "Our hosted solution takes a lot of the work out of meeting these standards. The only remaining requirements are a Security Self-Assessment Questionnaire (SAQ) and Quarterly Security Scans." According to MasterCard[2]: "All merchants that store, process, or transmit cardholder data must be PCI compliant." It's subjective whether using Stripe.js could be considered transmitting cardholder data. Visa[3] holds Acquirers responsible for ensuring their merchants are PCI compliant. Requirements vary depending on processing volume: "In addition to adhering to the PCI DSS, compliance validation is required for Level 1, Level 2, and Level 3 merchants, and may be required for Level 4 merchants." Notice that for Level 4 merchants, validation only may be required, although those merchants should still be adhering to the PCI DSS. Stripe has several PCI requirements in their terms of service[4], and their FAQ does seem to indicate[5] that merchants have some responsibility for PCI compliance. According to the TOS "It is your responsibility to comply with these standards." and according to the FAQ: "Most Qualified Security Assesors (QSAs) will want to talk through many of the implementation details before giving an opinion" Disclosure: I work for Braintree. Disclaimer: This response is my opinion; I'm not speaking for Braintree. [1] https://merchant.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=merchant/pci_compliant_solution https://merchant.paypal.com/us/cgi-bin/?cmd=_render-content&... [2] http://www.mastercard.com/us/company/en/whatwedo/determine_merchant.html http://www.mastercard.com/us/company/en/whatwedo/determine_m... [3] http://usa.visa.com/merchants/risk_management/cisp_merchants.html http://usa.visa.com/merchants/risk_management/cisp_merchants... [4] https://stripe.com/terms/US https://stripe.com/terms/US [5] https://answers.stripe.com/questions/what-exactly-do-i-need-to-do-on-my-end-for-pci-compliance https://answers.stripe.com/questions/what-exactly-do-i-need-...