42

I'm overhauling our absolute time-bomb of an order processing system that would put us out of business tomorrow were we audited for PCI compliance. It's so amateur it's scary.

I'm planning on making a case to the higher-ups that the liabilities of storing CC information outweigh the conveniences of not having to re-ask the customer for numbers, but I know I'm going to get asked how vendors like Amazon and such get away with storing information for repeat purchases, and I have no answer to this.

So, how do vendors like Amazon and everybody else who bills monthly authorize future charges without storing things like CVV info, which is expressly forbidden by PCI DSS v3?

I read elsewhere that tokens can be created and stored in lieu of stripe info, but isn't possession of a token representing the contents of the stripe just as valuable as the stripe info itself? Anybody with possession of the token could make fraudulent charges, so who cares whether they have that or the actual CC/CVV info?

Or is token conversion just a way of saying "we're not storing the actual PAN/CVV" and passing along regulatory compliance issues to whoever issued it?

Improve this question
8
  • Have you read through the PCI DSS guidelines? From my understanding (and it's been a while since I've had to read the guidelines) you cannot store the PAN in it's entirety in cleartext. Assuming this is the case, a salted hash should fit the bill.
    – DKNUCKLES
    Jun 6, 2014 at 19:29
  • 8
    A coworker of mine used to work with Amazon. He described their system to me once, and trust me, your company does not want to use Amazon as a model of how you should do credit card processing, at least not unless you have the resources of a company like Amazon! The server that holds the CC information is literally locked in a vault, and that's just the beginning of their security.
    – Mason Wheeler
    Jun 6, 2014 at 21:10
  • 2
    DKNUCKLES - My interpretation is that it is acceptable to store a hash of a PAN, but my understanding of hashing is that it's a one-way operation. If we can't un-hash the card number in order to use it again, I don't see the point in storing it in the first place (as opposed to a reference number)... Mason - Very interesting, thanks. And yes, part of my reasoning for not wanting to house CC data is that we don't have the resources of such entities. I'm just one guy!
    – Ivan
    Jun 6, 2014 at 21:28
  • 1
    you are correct @ivan - I eat crow. I'm blaming that one on a lack of caffeine...
    – DKNUCKLES
    Jun 6, 2014 at 22:18
  • 1
    Go with tokens. 1) If CC info never hits the server, you don't need to bother with PCI 2) A token can be invalidated without much collateral damage. Compare with sending a replacement CC to all users. 3) It's usually bound to a certain merchant's account, so a leak of your DB doesn't allow the attacker to send the money to their account. In contrast a CC number can be used with any destination account.
    – CodesInChaos
    Jun 7, 2014 at 11:28

4 Answers 4

Reset to default
34

Ivan, this is an absolutely huge topic. And you have a bunch of questions here. I'll try to help but this will likely be closed as too broad.

I'm planning on making a case to the higher-ups that the liabilities of storing CC information outweigh the conveniences of not having to re-ask the customer for numbers, but I know I'm going to get asked how vendors like Amazon and such get away with storing information for repeat purchases, and I have no answer to this.

It's perfectly acceptable to store credit card data, but there are a ton of rules surrounding how you do it - where, how, auditing, etc. There are a lot of books on this subject.

So, how do vendors like Amazon and everybody else who bills monthly authorize future charges without storing things like CVV info, which is expressly forbidden by PCI DSS v3?

You don't need to have the CVV info at all, it just helps with fraud. After checking it the first time (which can be done without writing it to disk) you can assume the card is not fraudulent. It has done the job it needed to do.

I read elsewhere that tokens can be created and stored in lieu of stripe info, but isn't possession of a token representing the contents of the stripe just as valuable as the stripe info itself? Anybody with possession of the token could make fraudulent charges, so who cares whether they have that or the actual CC/CVV info?

Tokenization is good if you manage to get the cardholder information out of your environment and into someone else's care. The 'token' is a unique identifier that allows your system to still act in the traditional sense. You provide a list of tokens to your provider and they translate them into the real numbers.

This is good because it is their responsibility to store / process / etc the real numbers. Your liability disappears in this regard.

Or is token conversion just a way of saying "we're not storing the actual PAN/CVV" and passing along regulatory compliance issues to whoever issued it?

Exactly, except it's to whomever processes it, not who generates the tokens. :)

Edit: a lot of businesses don't take interest without understanding the cost of non compliance.

See http://www.pcistandard.com/card-association-fines/

Improve this answer
7
  • 1
    Good comments. Of course, you can process the data yourself and still get some of these benefits by offloading the actual card processing to a sub-system that has the best security available. This is what some (maybe all?) large banks do.
    – Julian Knight
    Jun 6, 2014 at 19:31
  • @JulianKnight - true. We use a method very similar in house. I didn't want to confuse the matter with the 'they' possibly being a dedicated team in the office.. That's a whole ball of wax on its own.
    – Tim Brigham
    Jun 6, 2014 at 19:57
  • 1
    Very interesting; thanks, Tim. As it stands we just don't have the resources (or the business need, frankly) to safely store consumer data in-house, and PCI compliance is only going to be a topic of concern as long as I'm employed here and making noise about it. At least if the higher-ups tell me to carry this feature forward I can try to work out something better than storing names and PAN numbers in plaintext tables! I'll see what our processor can do. Thanks again!
    – Ivan
    Jun 6, 2014 at 21:53
  • 1
    @Ivan - a lot of businesses aren't interested until they see how stiff the peanalties are. See edit.
    – Tim Brigham
    Jun 6, 2014 at 22:00
  • Hi @TimBrigham could you elaborate on the sentence "except it's to whomever processes it, not who generates the tokens" ? What do you mean precisely by "process" ? Do you mean that we could for instance send data along with a token of our own (generated around a uuid) so whoever "generates" (issue) the token value (the string) is not a matter ?
    – niahoo
    Jul 3, 2020 at 16:22
7

It's been a few years, but when I was doing ecommerce (including one job for a large company that had previously been storing thousands of credit card numbers in plaintext), my preferred method was using Authorize.net's CIM service (other providers have similar services, that's just the one that I'm most familiar with; shop around for the one that works best for you).

The way that it worked was that you sent the info to the processor and they returned a token. The token is safer than the actual card data because it is only good to charge that card to your account using that one processor. Someone couldn't take the token and use it elsewhere, and if they did get it, all they could do with it would be to make bogus charges from you, which would put money in your account and make you look bad, but you could refund the money and cancel the tokens and no real harm done except temporary inconvenience - no money lost to the bad guys and no need to replace the card.

If the recurring charges are consistent and scheduled, some other card processing services let you set up subscription plans, where you initially send the card info along with a plan description of how often to bill how much. Thereafter, you can cancel the plan, but you don't have either the card info nor a token, so you can't accidentally charge them (as you could with a token) or lose their card info in a breach.

Never ever store CVV in any way, that is strictly forbidden. You don't need it at all, and having it is a huge liability. You should not need to store anything except at most a token or subscription id. The last 4 digits and card type (visa/mastercard/etc) may help customer service, but not really necessary.

Improve this answer
2
  • Stripe also does this. They create a token that can be used to do recurring charges to a credit card and you don't have to worry about storing credit card numbers yourself.
    – SameOldNick
    Jun 7, 2014 at 6:22
  • tokens are only useful for smaller transactions... gateways go down, and your secondary gateway can't access the persons details using the token from provider 1, so it comes down to that also. Tokens are the best 'quick and dirty' way to to this.
    – Dawesi
    Jan 26, 2017 at 11:21
2

RSTaylor is pointing you in the right direction. There are companies who will provide credit card processing for you (for a fee, of course). You can build a site so that the customer's number never goes to your servers, not even in RAM, so it can't be compromised there.

Disclaimer 1: You'll have to rely on the integrity and compliance of that company. I don't know enough to suggest a specific company.

Disclaimer 2: It is also somewhat tricky to get the credit card function seamlessly into your site, but it can be done.

Improve this answer
5
  • Disclaimer 3: Your web server is still in-scope for PCI compliance.
    – Timee
    Jun 9, 2014 at 15:48
  • @Timee's disclaimer is just plain wrong. If the cardholder information isn't in RAM at some point it wasn't transmitted to the server in question. If a server doesn't transmit, store or process cardholder data it isn't in scope.
    – Tim Brigham
    Jun 12, 2014 at 15:07
  • Read the new scoping guidelines for PCI DSS 3.0. if a system can influence the integrity of card data then it is considered in scope for PCI compliance and must meet the requirements. Here is a direct quote from PCI DSS 3.0: "To be considered out of scope for PCI DSS, a system component must be properly isolated (segmented) from the CDE, such that even if the out-of-scope system component was compromised it could not impact the security of the CDE." With the type of payment configuration described a compromise to the webserver could impact the CDE and card data.
    – Timee
    Jun 12, 2014 at 17:35
  • 1
    The web server can absolutely be in scope, it is entirely dependent on the implementation. See the official guidance: pcissc.secure.force.com/faq/articles/Frequently_Asked_Question/…
    – freb
    Jun 12, 2014 at 18:01
  • This this this this this. Freb also has the right of it (or stated alternately, Tim Brigham and Timee are both right).
    – Smithers
    Dec 26, 2014 at 19:06
0

For your question

So, how do vendors like Amazon and everybody else who bills monthly authorize future charges without storing things like CVV info, which is expressly forbidden by PCI DSS v3?

I want to give an exact scenario about it.

  1. I buy a book from Amazon via my Kindle with one click payment process but the payment fails. I am sure I have enough credit on my credit card and I always shop with the same card at Amazon.
  2. When I check the order details it says there is problem in the payment process, and asks me to please use another card.
  3. When I check the card and bank information I realize my bank has a fraud check because it stolen some card data and CVV is required for all online payments.

So it means it is about a fraud rule between the merchant and the bank.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .