So I'm facing a challenging issue today. I'm currently working on the payment interface of an app I'm developing. I have to give the apps future users the option to store and edit their payment card details for easy checkout. Every business in my industry does the same. So giving my users the ability to add and edit card details is a must.
I was thinking about storing the users card details to an AWS RDS database we rent using PCI standards. I plan on using PHP and mcrypt along with salt and pepper to encrypt and decrypt card data when it is needed.
Do you guys think storing the payment data to our db would be an appropriate option in this case? or is their any third party providers that will store the user payment details for us?
It is important to note that we will be using our own merchant accounts for some transactions and for others we will be using various suppliers merchants accounts to processes our transactions VIA their API.
Thanks
I would recommend the following blueprint:
Cloudfront -> API Gateway -> Lambda -> RDS
The Lambda function is the only place that has access to the RSA private key to decrypt the field value that was encrypted by Cloudfront. Then turn around and re-encrypt the card holder information with the AWS Encryption SDK and finally store it in RDS. That lambda is only allowed to use the KMS key for encryption. Create a separate lambda function that is responsible for reading the data out of RDS, decrypting it with KMS and transmitting it to the third party.
There are is a lot more devil in the details to the solution, but at least you aren't going to get your PHP application compromised and expose a massive number of credit cards if you follow this blueprint. At the end of the day you want to limit the number of places card holder information is handled to reduce your PCI audit exposure. I'd even say go so far as having a separate VPC and RDS for the card holder data. Return "tokens" to your application for reference.