4 ms·

They mention in the faq that they use Stripe - https://www.terminal.shop/faq https://www.terminal.shop/faq. Stripe does offer integrations that are not natively

They mention in the faq that they use Stripe - https://www.terminal.shop/faq 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.

samwillis 2y ago
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
- niutech 2y ago
  You can still find the source code here: https://github.com/benweissmann/dev-payments https://github.com/benweissmann/dev-payments
- ppbjj 2y ago
  That's awesome
- cperciva 2y ago
  I thought /dev/payments was their second name. Weren't they /dev/creditcard or something like that first?
- tazu 2y ago
  I'm guessing they ditched that idea because it wouldn't absolve the "writer" of PCI compliance, since the information has to pass through RAM.
hn_throwaway_99 2y ago
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.pdf 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_Merchant.pdf https://listings.pcisecuritystandards.org/documents/SAQ_D_v3.... This includes additional requirements and I believe stuff like a pen test to be PCI compliant.
- jjeaff 2y ago
  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.
  - ansc 2y ago
    It's expensive.
  - alt227 2y ago
    >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.
    - jjeaff 2y ago
      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.
- throwaway5371 2y ago
  you can say the same about the widget, as the website embedding the widget has access to the document's keydown
  - makingstuffs 2y ago
    If the widget is in an iframe with a different host the parent documents JS engine has no way of interacting with the child.

samwillis 2y ago

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

niutech 2y ago
You can still find the source code here: https://github.com/benweissmann/dev-payments https://github.com/benweissmann/dev-payments
ppbjj 2y ago
That's awesome
cperciva 2y ago
I thought /dev/payments was their second name. Weren't they /dev/creditcard or something like that first?
tazu 2y ago
I'm guessing they ditched that idea because it wouldn't absolve the "writer" of PCI compliance, since the information has to pass through RAM.

hn_throwaway_99 2y ago

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.pdf 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_Merchant.pdf https://listings.pcisecuritystandards.org/documents/SAQ_D_v3.... This includes additional requirements and I believe stuff like a pen test to be PCI compliant.

jjeaff 2y ago
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.
- ansc 2y ago
  It's expensive.
- alt227 2y ago
  >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.
  - jjeaff 2y ago
    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.
throwaway5371 2y ago
you can say the same about the widget, as the website embedding the widget has access to the document's keydown
- makingstuffs 2y ago
  If the widget is in an iframe with a different host the parent documents JS engine has no way of interacting with the child.