Toughey Talks
PCI-PA-DSS: 31 Flavors of Cashiering
March 18, 2010
As I mentioned in my last e-mail, there seems to be a lot of confusion about "cashiering-like" systems. There appear to be as many different views of what Cashiering is as there are ice-cream flavors at Baskin-Robbins®.
There is the "robust flavor" of traditional business office cashiering, where you hear a "ding" when the cash-drawer opens. It is rich in functionality, including receipting, session management, and workflow tools. Every station has its readers and printers. In a robust system, local software manages the swipe devices, meaning the software must be PA-DSS certified.
On the other hand, there is a "light flavor" for a credit card authorization station. The only sound you hear is the click of a keyboard. There are no swipe devices, no cash drawers to manage, and no integration with other systems. In this virtual terminal solution, you might not have payment software running on the PC at all. It may be a hosted solution running somewhere on the Web. Nonetheless, that doesn't eliminate the responsibility to comply with PCI DSS.
The point is, if you are the merchant of record when you TYPE or SWIPE card data for a customer, you are responsible for meeting the broad scope of PCI DSS requirements for all of your cashiering "flavors." You might hear others tell you differently or see claims that argue against this view. But if it sounds too good to be true, it just may be. At the end of the day, you are the merchant and you are "on the hook" for PCI compliance.
Thanks for reading.
Dan Toughey
dan2e@touchnet.com
PS: Send me an email if you have questions about p.Commerce (in person payments).
Toughey Talks
PCI-PA-DSS: 31 Flavors of Cashiering
March 18, 2010
As I mentioned in my last e-mail, there seems to be a lot of confusion about "cashiering-like" systems. There appear to be as many different views of what Cashiering is as there are ice-cream flavors at Baskin-Robbins®.
There is the "robust flavor" of traditional business office cashiering, where you hear a "ding" when the cash-drawer opens. It is rich in functionality, including receipting, session management, and workflow tools. Every station has its readers and printers. In a robust system, local software manages the swipe devices, meaning the software must be PA-DSS certified.
On the other hand, there is a "light flavor" for a credit card authorization station. The only sound you hear is the click of a keyboard. There are no swipe devices, no cash drawers to manage, and no integration with other systems. In this virtual terminal solution, you might not have payment software running on the PC at all. It may be a hosted solution running somewhere on the Web. Nonetheless, that doesn't eliminate the responsibility to comply with PCI DSS.
The point is, if you are the merchant of record when you TYPE or SWIPE card data for a customer, you are responsible for meeting the broad scope of PCI DSS requirements for all of your cashiering "flavors." You might hear others tell you differently or see claims that argue against this view. But if it sounds too good to be true, it just may be. At the end of the day, you are the merchant and you are "on the hook" for PCI compliance.
Thanks for reading.
Dan Toughey
dan2e@touchnet.com
PS: Send me an email if you have questions about p.Commerce (in person payments).