I can't test this due to the product being out of stock, but I wonder what their approach to PCI compliance is.
Processing credit card data has a high compliance burden if you're unwilling to use a secure widget made by an already-authorized provider like Stripe. That's for a good reason, most web and mobile apps are designed such that their backend servers never see your full credit card number and CVV. You can't do this over SSH.
I also wonder whether you could even do this if you had to handle PSD2 2-factor authentication (AKA 3d Secure), which is a requirement for all EU-based companies. This is usually implemented by displaying an embed from your bank inside an iframe. The embed usually asks you to authenticate in your banking app or enter a code that you get via SMS.
You can take the easy way out of course and make the payment form a web page and direct the user to it with an URL and/or a Unicode-art rendition of a QR code.
They mention in the faq that they use Stripe - https://www.terminal.shop/faq. Stripe does offer integrations that are not natively using their widgets. Ultimately, the PII data is stored at Stripe.
PS: I work at Stripe but I don't really work on the PCI compliant part of the company.
The fact that the card number data is stored at Stripe doesn't matter that much. As parent commenter says, the card numbers are still visible on terminal.shop's network because it all goes over their SSH connection.
For most websites that use the Stripe widget, the website owner can never see the full card number, because the credit card number entry fields are iframed in on the page. That means website owners in this scenario are PCI compliant just by filling out PCI SAQ A (self assessment questionnaire A), which is for "Card-not-present Merchants, All Cardholder Data Functions Fully Outsourced": https://listings.pcisecuritystandards.org/documents/SAQ_A_v3...
But that questionnaire is only for merchants where "Your company does not electronically store, process, or transmit any cardholder data on your
systems or premises, but relies entirely on a third party(s) to handle all these functions;" For e-commerce merchants who CAN see the card number, they need to use SAQ D, https://listings.pcisecuritystandards.org/documents/SAQ_D_v3.... This includes additional requirements and I believe stuff like a pen test to be PCI compliant.
it's been a while since I did the full pci compliance rigamarole, but I don't recall it being that difficult. you basically just answer a bunch of questions correctly about how you are transmitting and storing the data using sufficient encryption and then they run some automated pen tests on your site and then you are done.
>run some automated pen tests on your site and then you are done
Haha you are obviously choosing to hide some pain away from your memories.
I agree that you run automated pen tests, but then securing up all networks servers with the results of those pentests can be incredibly time consuming and awkward.
I suppose on a very complex system, that could be a big deal. But I think the last site I did it on was running on AWS so all ports were closed unless I specifically opened them for a specific purpose and it was just a few tweaks I had to make to pass. I normally only have 80 and 443 open to the outside world.
To be clear, that is exactly what the PCI SAQ A-EP questionnaire covers. It basically says "You don't access any cardholder data, but you own the page that hosts/redirects to the third party processor (like Stripe)." So the questions in the SAQ A-EP are about ensuring that your page has enough basic security (at least as can be asked in a questionnaire) to prevent hijacking, whereby a nefarious script (through an XSS vulnerability for example) sends them to a site to phish their cc details. Note that a decent content security policy on your website can prevent most of these types of problems.
That wouldn't help, at least with my bank in the UK, the iframe just shows a message to open the mobile app to approve the payment. The payment details are then shown in the app, you don't interact with the page in the iframe at all.
But that would still require an eagle-eyed consumer, which (coming from experience working in the fintech space) is quite rare.. I.e., you may know the iframe is supposed to just ask you to open your mobile app, but I think the vast, vast majority of users wouldn't think twice if that iframe had been hijacked and instead asked them to enter their credit card information directly.
Interestingly Stripe started life as /dev/payments and I seem to remember the first iteration was an agent on your server that literally processed card payments when you wrote the details to /dev/payments
Not just EU companies. Also EU customers. I cannot use my cards in a Card-Not-Present transaction that does not support 3D Secure. This obviously isn't a concern for them yet since they only ship to the US, but it might become one.
In the past one of my banks required me to put in a One-Time Password on the frame I'm shown. While it's different right now, you do need to show that page in the general case. That would really break the immersion of their process :/
I remember seeing a 3D Secure screen in some app that didn't use a webview but rendered the form as native controls. It worked with Estonian LHV at least (I think?). If that can be done with Stripe, they could render the form as a TUI.
And if everything fails, they can just render the 3DS page in the terminal! (e. g. using Browsh [1]) Although I'm not sure if that would be compliant with the regulations.
I think that a better way (which is protocol-independent, and does not require a web browser, or even necessarily an internet connection), would be a kind of payment specification which is placed inside of a order file. This payment specification is encrypted and digitally signed and can be processed by the bank or credit card company or whatever is appropriate; it includes the sender and recipient, as well as the amount of money to be transferred (so that they cannot steal additional money), and possibly a hash of the order form. A payment may also be made by payphones or by prepaid phone cards (even if you do not have a bank account nor a credit card), in which case you may be given a temporary single-use key which can be used with this payment specification data; if you do not do this, then you can use the credit card instead.
I was asking myself the same thing while watching the live stream where they somehat explained how it works.
It's still not clear to me if they are compliant.
To make it work like in the browser it would require some sort of SSH multiplexing where your client is connected to both the shop and Stripe's SSH server and you enter your card data into a terminal region that is being rendered by stripe's ssh server. And then the triangle is completed by Stripe notifying the shop that the payment is ok.
I don't know if this is sarcasm or not, but in Poland we have BLIK and it is amazing. Paying online is as simple as entering a 6 digit code from the app and confirming transaction in the app. Afaik every major bank supports it too
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.
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.
The burden of PCI compliance is a lot lighter than you might think. You basically just have to fill out a bunch of forms, there's no inspection or anything.
No I'm not a manager, I'm a programmer. I haven't personally had to fill out the forms, we have a guy for that. Actually that's not his main job, but he used to work as a paralegal so he got volunteered for it.
Processing credit card data has a high compliance burden if you're unwilling to use a secure widget made by an already-authorized provider like Stripe. That's for a good reason, most web and mobile apps are designed such that their backend servers never see your full credit card number and CVV. You can't do this over SSH.
I also wonder whether you could even do this if you had to handle PSD2 2-factor authentication (AKA 3d Secure), which is a requirement for all EU-based companies. This is usually implemented by displaying an embed from your bank inside an iframe. The embed usually asks you to authenticate in your banking app or enter a code that you get via SMS.
You can take the easy way out of course and make the payment form a web page and direct the user to it with an URL and/or a Unicode-art rendition of a QR code.