PCI DSS: Is there a way to pass encrypted billing data through a server without compliance?

Question

Hope all is well.

I am developing a primarily cloud-based tool that allows the end-user to enter in billing data and task data via a desktop application, and the billing data is stored locally (their account data and the task data is stored on a sever, but there are no issues with that).

They can create, edit, delete, and run these "tasks" that purchase items from E-Commerce stores right when they release to secure copies, and it is generally intended to be used for obtaining limited sneakers right when they release. So, their billing data, which is stored locally, is in JSON format and encrypted using our own keys. It will get sent to a server, running an instance of a task execution system we've setup on several of its ports. When a task is ran, it will search for one of these ports that isn't in use, and send the package of data so the script can run and purchase the product(s). This package of data contains the billing info JSON, which is decrypted upon arrival at the server, and some plaintext data (such as what size of shoe or what shoe color).

The server has an SSL and other basic security practices in place, but I do fear the complicated PCI standards inhibiting this project. So, that leaves me with two questions:

1) It looks like the amount of money you need to pay for compliance varies on your number of servers. If I have several ports on one server transmitting the billing data, do I need to get all of those ports assessed and pay for all of that, or just the one server that is hosting all of them?

2) Can I do this without complying to any of these standards? And if not, is there any good way to estimate would the price range would be per server?

Thanks so much for your time.

Answer 1

Disclaimer: I'm not a PCI expert, but I felt morally obligated to chime in with some perspective. There are a number of similar PCI related questions you can find in the "related" tab - PCI is not just a matter of paying for compliance.

PCI compliance is applicable to anyone who processes credit card information. That would be anyone who can take that card and turn it into cash, so to speak - or who has a service agreement with a different company that can do things with that card.

If you had a relationship with a credit card processor (there are many services available), you would almost certainly be contractually obligated not to store this information - but you would also almost certainly use the credit card processing company for storage, so you wouldn't need to deal with compliance.

If you were processing card information directly, you would need to be PCI compliant, but it's not just about number of servers, but your entire set of processing behavior, and it would be very difficult to comply because your fundamental application model is broken.

The example use case you describe, PCI Compliance is the least of your worries, because your application workflow model is basically tantamount to a guy on the street hanging out outside a Costco or other members-only store and saying "give us your credit card and tell us what you want us to buy for you, and we'll go into the store and buy it... until they ban us because someone keeps giving us stolen credit cards."

You can't hold on to a customer's card information so you can submit it on other web sites. Period. It's a logistical and security nightmare for a number of reasons.

1. There's big business in validating if a stolen credit card works - scammers are constantly trolling the internet for sites that don't have rate limits or captchca checks so they can test card numbers against them. This is great for them because it sounds like they're even telling you what to buy and what card to use, and even support different sites! It's like an API for spammers.
2. Stores are just going to ban you sooner or later, probably for using stolen cards or placing many orders with different addresses and payment information, which will trigger all sorts of fraud checks.
3. There's no benefit to your server handling this data instead of it all happening directly on a user's machine - a script or client side application could purchase directly from a user's computer, without trying to awkwardly make the workflow go through your own servers. I expect this would impact your business model, though.
4. If your idea of submitting data for asynchronous task execution to a server is "see if one of the ports is free", you don't want to be dealing with credit card information and the liabilities associated with it. It betrays a general lack of experience with software architecture and development... which is fine for an passion project, but is a really bad idea when you want to be touching credit card numbers. You're talking about a system that if misused could get you sued, or lose people all the money in their debit accounts or leave them with hefty credit card bills if something goes wrong with the architecture or security.
5. It's possible that if your system was compromised in any fashion, or even if it wasn't, users wouldn't be able to claim their credit cards were stolen, because it's not uncommon for credit card user agreements to essentially say that if you give someone your card number or card so they can use it, you won't get reimbursed for fraudulent transactions.
6. Why not just have an application that notifies users when things they've flagged go on stock? There are existing plugins and applications that can make it simple for them to fill in card information, without needing to deal with storing it.