4 ms·

No, not the "we store decryption keys on our user facing app servers" part. The decryption should happen on back-office payment processing server, with the key

• jermaustin1 8y ago
  In my early days, I had to write a payment processor and it pass a PCI "inspection." TL;DR - PCI compliance was a joke in my experience. The payment page didn't log requests (made figuring some things out hard), it submitted the encrypted card data (public key) to another server through the firewall with only a single non-standard port open, to the data store with write only access. There was then a trigger on insert that would launch a small console app that passed the decrypted (private key stored locally) card and charge information to Authorize.Net, if successful it would then write a success to the charges database, and send that charge identifier to the application's data store. Only access to the payment server was from behind the firewall over RDP and MSSQL over non standard ports. Just the description of this satisfied the PCI guy, and no physical inspection of the hardware was ever done. I'm not sure if what I did was best practice, and I was always so scared it would get hacked. Thankfully after so many fraud charges that my boss couldn't handle the $15 chargebacks we switched to paypal and I no longer had sleepless nights.