5 ms·

PCI itself is Payment Card Industry. PCI DSS as noted is the Data Security Standard. https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standar

by shagie 11mo ago

PCI itself is Payment Card Industry. PCI DSS as noted is the Data Security Standard. https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec... The time it was in the transition between 2.0 and 3.0 (its been refined many times since). https://listings.pcisecuritystandards.org/documents/PCI-DSS-v3_2_1-ROC-Reporting-Template.pdf https://listings.pcisecuritystandards.org/documents/PCI-DSS-... is the 3.2.1 audit report template. One of the most important things in there is you don't mix dev and production. The idea of putting a development box next to a production box that runs the same transactions... that just doesn't happen. Failing a PCI DSS audit means hefty fines and increases of transaction fees (paying 1% more on each transaction done with a credit card can make a $10k/month - $100k/month fine a rounding error) to a "no, you can't process credit cards" which would mean... well... shutting down the company (that wouldn't be a first offense - its still not something you want to have a chat about with accounting about why everything costs 1% more now). Those are things that you don't want to deal with as a developer. So, no. There is no development configuration in production, or mirroring of a point of sales terminal to another system that's running development code. Development code doesn't touch other people's money. We had enough side eyes looking at the raw data for our manager's payment card on development systems because only people that banked at that local bank occasionally experienced a problem with their visa check card... https://en.wikipedia.org/wiki/Digital_card#Financial_cards https://en.wikipedia.org/wiki/Digital_card#Financial_cards - when it says "generally '^'" it means it can be some other character... and it was... and this wasn't a problem for most people, but it turned out that the non-standard separator (that we only found after reading the card's raw data) and a space in the surname would result in misparsing of the track and giving an error - but none of our other cards used a separator that didn't match the "generally"). So, being able to generate real production load (in the cafeteria) without using Visa, Mastercard, etc... was important. As was being able to fall back to using the nearly antique credit card imprinter ( https://en.wikipedia.org/wiki/Credit_card_imprinter https://en.wikipedia.org/wiki/Credit_card_imprinter ) for the store that was lucky to get a dozen transactions a day.

ChrisGreenHeur 11mo ago
surely you have logs from the production systems? just gather the logs and run them through the dev box. verify the end result matches between the two. You dont actually need the dev box to sit next to the production system.
- brendoelfrendo 11mo ago
  You cannot, under any circumstances, keep a real card # and use it as test data. I think that's where this conversation is getting hung up, because the idea of running a transaction through prod and them doing the same in test to see if it matches isn't something you can do. I mean, of course you can throw the prices and UPCs at the new system and verify that the new system's math matches the old system, but that's only the most basic function of a POS system. Testing a transaction from end-to-end would have to be done with synthetic data in an isolated environment, and I'll assume that's what OP is trying to articulate.
  - ChrisGreenHeur 11mo ago
    the reproduction is always fake to some extent, that does not matter, the point is to do as good a job as you can. for example you can have a fake transaction server with the credit card numbers made up and mapped to fake accounts that always have enough money, unless the records show they did not.
    - Ghoelian 11mo ago
      I've also worked with payment processors a lot. The ones I've used have test environments where you can fake payments, and some of them (Adyen does this) even give you actual test debit and credit cards, with real IBAN's and stuff like that.
      - brazzy 11mo ago
        It's even public: https://docs.adyen.com/development-resources/test-cards-and-credentials/test-card-numbers https://docs.adyen.com/development-resources/test-cards-and-...

by shagie 11mo ago

ChrisGreenHeur 11mo ago

surely you have logs from the production systems? just gather the logs and run them through the dev box. verify the end result matches between the two. You dont actually need the dev box to sit next to the production system.

brendoelfrendo 11mo ago
You cannot, under any circumstances, keep a real card # and use it as test data. I think that's where this conversation is getting hung up, because the idea of running a transaction through prod and them doing the same in test to see if it matches isn't something you can do. I mean, of course you can throw the prices and UPCs at the new system and verify that the new system's math matches the old system, but that's only the most basic function of a POS system. Testing a transaction from end-to-end would have to be done with synthetic data in an isolated environment, and I'll assume that's what OP is trying to articulate.
- ChrisGreenHeur 11mo ago
  the reproduction is always fake to some extent, that does not matter, the point is to do as good a job as you can. for example you can have a fake transaction server with the credit card numbers made up and mapped to fake accounts that always have enough money, unless the records show they did not.
  - Ghoelian 11mo ago
    I've also worked with payment processors a lot. The ones I've used have test environments where you can fake payments, and some of them (Adyen does this) even give you actual test debit and credit cards, with real IBAN's and stuff like that.
    - brazzy 11mo ago
      It's even public: https://docs.adyen.com/development-resources/test-cards-and-credentials/test-card-numbers https://docs.adyen.com/development-resources/test-cards-and-...