There’s a lot of misinformation about collecting and storing credit card data, especially in business to business (B2B) environments for card not present transactions. Best card not present practices and how Payment Card Industry Data Security Standards (PCI DSS) requirement 3, protect stored cardholder data, applies are reviewed in this article.<\/p>\n
Getting paid for one time it’s not OK to store cardholder data after authorization. The only cardholder data that may be stored after authorization is the primary account number or PAN (rendered unreadable), expiration date, cardholder name, and service code.<\/p>\n
Merchants are not permitted to store full track data, which includes the cardholder number (primary account number or PAN) and expiration date or other sensitive authentication data after authorization.<\/p>\n
Per Payment Card Industry Data Security Standards (PCI DSS) Requirement 3, protect stored cardholder data, The only cardholder data that may be stored after authorization is the primary account number or PAN (rendered unreadable), expiration date, cardholder name, and service code.<\/p>\n
This applies even if the data is protected by:<\/p>\n
Encryption
\nPassword protection
\nData scrambling\/obfuscation
\nMasking
\nProprietary data formats
\nOther mechanisms<\/p>\n
What’s the exception?
\nBusinesses may have a need to store track data (temporarily) for troubleshooting purposes. Why? Track misreads, network errors, encryption issues, etc. This is not a daily business practice, but a temporary solution. PCI requires documentation Ensure documented procedures include:<\/p>\n
Collecting sensitive authentication data only when needed to solve a specific problem
\nCollecting the minimum amount of data needed to solve the specific problem
\nStoring any such data in a specific, secure location with limited access
\nDo not retain more data than needed
\nEncrypt data when stored\/transmitted
\nSecurely delete data immediately when troubleshooting is complete
\nInclude a destruction practice
\nVerify data cannot be retrieved once troubleshooting is complete<\/p>\n
Typical location of card verification value or codes include:<\/p>\n
Paper
\nDatabases
\nFlat files
\nLog files
\nDebug files<\/p>\n
Systems that commonly store card verification value or code data:<\/p>\n
Authorization servers
\nWeb servers
\nKiosk<\/p>\n
Card verification value or codes are NOT required for recurring card-not-present transactions.? If your system requires you to key enter the CVV each time, this is a red flag. Ensure your systems is sending transactions with the proper flag for unscheduled credential on file. Reasons why you would have to enter every time:
\nUsing a desktop terminal and key entering each time. The transactions are not being sent with correct indicator.
\nIt\u2019s also a PCI DSS requirement that unprotected PANs must not be sent or received via any end-user messaging technologies (such as e-mail, instant messaging, and chat). However, users may not be aware of this, and may be e-mailing PANs internally or even externally without the organization\u2019s knowledge<\/p>\n","protected":false},"excerpt":{"rendered":"
There’s a lot of misinformation about collecting and storing credit card data, especially in business to business (B2B) environments for card not present transactions. Best card not present practices and how Payment Card Industry Data Security Standards (PCI DSS) requirement … Continue reading