Pci Tokenized Card Storage?

[xison]

Alright, so I figure I'd bring this up here instead of elsewhere because you all seem very intelligent and may have experience in this department.

 

I've been working on some stuff for a client of mine's in-house web-based app (remotely hosted).

 

We have people registering through their website, which dumps data into a database and then it gets picked up and is accessible through the web app (think of it kind of like a CRM).

 

The issue I am running into is my client has zero knowledge of PCI compliance laws and he wants me to take credit card details and store them in the database (type, name on card, card number, exp date, cvc). While I am wrapping it in json_encode and encrypting the string using asymmetric encryption I still don't feel safe doing this, and it's a real worry of mine. The server it is hosted on is their own. I manage it for them and maintain security updates and it's locked down fairly tight.

 

I personally use Stripe, and love their tokenization storage. I'm curious if anyone has ever come across a service that ONLY does tokenized PCI compliant storage that is not a merchant/processor. He has all of his merchant stuff set up and I've spoken with the company they deal with and they do not offer any tokenized solutions.

 

I'm thinking like a simple API that I can push/pull data from via curl using the token and never store the information on the server that processes this clients information.

 

I've done some googling and I've come up with Auric System's PaymentVault: http://auricsystems.com/products/paymentvault/

 

They don't list any pricing but I'm just curious if anyone has come across what I'm looking for.

[Michael]

Can't you use Blesta for this?

[xison]

Can't you use Blesta for this?

I'm looking for offsite/remote, PCI-DSS compliant tokenized storage with an API. I can encrypt the data as much as I'd like on the local server but it still bothers me, as it really is not PCI-compliant.

[Gareth-Host Red Dragon]

Alright, so I figure I'd bring this up here instead of elsewhere because you all seem very intelligent and may have experience in this department.

 

I've been working on some stuff for a client of mine's in-house web-based app (remotely hosted).

 

We have people registering through their website, which dumps data into a database and then it gets picked up and is accessible through the web app (think of it kind of like a CRM).

 

The issue I am running into is my client has zero knowledge of PCI compliance laws and he wants me to take credit card details and store them in the database (type, name on card, card number, exp date, cvc). While I am wrapping it in json_encode and encrypting the string using asymmetric encryption I still don't feel safe doing this, and it's a real worry of mine. The server it is hosted on is their own. I manage it for them and maintain security updates and it's locked down fairly tight.

 

I personally use Stripe, and love their tokenization storage. I'm curious if anyone has ever come across a service that ONLY does tokenized PCI compliant storage that is not a merchant/processor. He has all of his merchant stuff set up and I've spoken with the company they deal with and they do not offer any tokenized solutions.

 

I'm thinking like a simple API that I can push/pull data from via curl using the token and never store the information on the server that processes this clients information.

 

I've done some googling and I've come up with Auric System's PaymentVault: http://auricsystems.com/products/paymentvault/

 

They don't list any pricing but I'm just curious if anyone has come across what I'm looking for.

 

Has the card aready been charged? How long is the data retained?.

 

Storing cvc numbers is explicitly against MasterCard and Visa terms. If your client is caught storing them (regardless of whether they are encrypted or not), MasterCard or Visa could ban your clients merchant account. 

 

Technically, once the card has been charged, the cvc code should be destroyed, and if it is stored in a database, then it needs to be securely erased.

 

A quick search on google, did show some saying that you can store it if you do batch processing, but once you have run the batch, it has to be securely destroyed, others saying you can not.

 

Personally, I would avoid storing it at all.

[xison]

Has the card aready been charged? How long is the data retained?.

 

Storing cvc numbers is explicitly against MasterCard and Visa terms. If your client is caught storing them (regardless of whether they are encrypted or not), MasterCard or Visa could ban your clients merchant account. 

 

Technically, once the card has been charged, the cvc code should be destroyed, and if it is stored in a database, then it needs to be securely erased.

 

A quick search on google, did show some saying that you can store it if you do batch processing, but once you have run the batch, it has to be securely destroyed, others saying you can not.

 

Personally, I would avoid storing it at all.

I'm _very_ familiar with the rules.

 

While the client keeps insisting on storing it, I ensure it is removed after the card is processed. All card accesses are logged, and restricted to the user(s) that need access by way of asymmetric encryption.

 

This is besides the point of what this discussion is about. I'd like to offload a lot of these headaches, as described in my original post.

[Scott Horsley]

We actually use a bank to store tokenisation information. They then return a token for us. We can then ask the bank to perform a transaction on that card. 

 

From memory, we pass the "customer id" (our own ID) and a token number to the bank itself. This makes it a key/pass scenario. The CC details are NEVER exposed to our system, our database, our clients or our staff members (except for the first 2 and last 4 digits, plus expiry (for expiry reminders)).

 

Using Blesta, we will be using the clientID and encrypting the token number.

 

This works quite well. I think it comes down to the fact that you really need to push the fact that what they are asking you to do is going to get them (and you) into trouble.

[Cody]

I'm not sure there are many services out there that handle secure storage of card data. Besides the trust issues that arise from such a solution, I don't believe it alleviates PCI compliance since one of the PCI compliance questions is whether or not you share card data (which obviously you would be).

 

I've encountered customers like the one you've described many times. I make it clear that it is simply not an option to store card security codes, and I'll often recommend merchant gateways with offsite storage (just about every merchant gateway these days). In my experience they've chosen either not to process auto debits, or have chosen a gateway that supports offsite storage. If the customer is adamant about storing card security codes then we fire the customer because that sets off a red flag for future issues with the client.

[Scott Horsley]

we fire the customer

I love it!!

[xison]

Thanks for your input thus far. Typically I just recommend Paypal or Stripe and be on my way.

This is a client of approx 4 years. We keep bumping our heads on this issue. They are not willing to use another gateway provider, nor are they willing to budge on this whole storing the cards (and other info) issue. Basically his justification is "Kijiji does it" and after hours of trying to explain how and why Kijiji does it, it comes down to a frank "I write the cheques, do as I say".

Unfortunately this project isn't a simple e-commerce site, which I've done many of in the past and where Paypal or Stripe work very well.

I'd be happier not storing /any/ card info with a fully tokenized system. :-)

[Paul]

Why must you store, even temporarily the CVV data? If you have to store locally, at least it can be PCI compliant. Does this gateway require the CVV for every transaction?

 

Cody's right.. this would probably be a deal breaker for us if the client was unwilling to listen. There are lots of negotiables with development, but this isn't really one of them and you could be drawn into it if there is a breach. If it's a customer you really need to keep, at a minimum, I would want a signed liability waiver and acknowledgement that it goes against your recommendation. If there is a breach later on, he can't point the finger at you (or sue you).

[Cipher]

Updated link for Auric System's PaymentVault for PCI tokenized card storage: http://www.auricsystems.com/products/paymentvault-tokenization/

Prices are very reasonable and are currently listed on the website.

[xison]

I totally forgot about this thread. Thanks for bumping it Cipher.

In response to Paul, they manually run the card numbers through their terminals.

The company they deal with now has a properly documented payment gateway I can run them through, never storing the information. For their type of business, where repeat customers are high, but several months to a year apart, they can type their card number in each time.

I have since removed the CVV requirement off the payment page against the owners request, and he honestly hasn't even said anything. I don't think he's noticed. Hopefully I can get this all migrated to the merchant payment gateway system and he'll never be the wiser.

[flangefrog]

This is one of the best articles about PCI compliance I have read: http://kencochrane.net/blog/2012/01/developers-guide-to-pci-compliant-web-applications/

You can tell your customer they can be liable for up to a $500,000 fine if they breach these requirements. The article also has a section about Tokenization services. Note that if any card is still passing through your servers, you will still need to complete at least SAQ-C.