Comment by fuzzy_biscuit
2 years ago
The FAQ says they use Stripe for orders and don't even have their own DB in which to store purchase data, so PCI compliance should be a non-issue
2 years ago
The FAQ says they use Stripe for orders and don't even have their own DB in which to store purchase data, so PCI compliance should be a non-issue
PCI compliance is never a non-issue.
Even if you're using a third party provider that handles both credit card entry and processing, you need to comply with some subset of the PCI/DSS requirements.
In the case of terminal.shop it's not even true, since they can see the credit card number on their side, even if all they do is to forward that number to Stripe and forget about it.
For small and medium-sized merchants, PCI/DSS classifies different types of handling through the concept of which SAQ (Self-Assessment Questionnaire) you have to fill in. Different SAQ have different subset of requirements that you need to fulfill. For e-commerce use cases, there are generally 3 relevant SAQs, in order of strictness:
- SAQ A: Applicable when the merchant redirects payment requests to the payment processor's page or shows an iframe that is hosted by the processor. This is the level required for Stripe Checkout or Stripe Elements.
- SAQ A-EP: Applicable when the merchant handles input on the browser, but sends the data directly to the processor without letting it pass through the merchant's server. This is equivalent to the classic Stripe.js.
- SAQ D: Applicable when the card data is transmitted, stored or processed on the merchant's own server, even if the merchant just receives the card number and passes that on to the payment provider. Stripe calls this type of usage "Direct API Integration" [1].
The level of compliance required for terminal.shop should be SAQ-D for Merchants, which is quite onerous. It covers almost all of the full set of PCI/DSS requirements.
But even if a merchant just uses Stripe.js, the PCI SSC still cares about the possibility of an attacker siphoning card data from the merchant's site through an XSS vulnerability.
And even if the merchant is using an iframe or a redirect (with something like Stripe Checkout or Stripe Elements) there is still the possibility of hard-to-detect phishing, where an attacker could replace the iframe or redirect target with their own site, made to look exactly like Stripe.
---
[1] https://docs.stripe.com/security/guide
I think the important element is that terminal.shop's use case (likely SAQ D, likely level 4 or level 3 volumes) allows them to comply with relatively minimal expense and complexity.
Sure, there would be a non-zero time investment required to implement and ensure actual compliance with what is being attested, but it's quite doable for a person or small group of folks with a mix of SDE skills, SRE-like skills, and PCI-DSS experience.