Good point.

Our POS/Video rental program can process cards outside of the scope of PCI
(and we use it for our business for our own sales)... so we're safe.. we use
Xcharge so we don't need to store the credit card info.

When we are selling someone software, we want it to be easy for them to give
us their money... and customers feel safer giving us the data over the
phone.. and we can ring them up while we're talking to them... so it's easy
for us.

Our big problem is training our customers to not store credit card
information.. because they do that so they can go back and charge late
charges or charge for a non returned movie. If they are using Xcharge.. it's
not an issue because of the token.... but for those that have a separate
machine.. they're storing the card data in our program.. we can't stop them
from doing it... if we take the cc field away, they'll store it in the memo
(which is worse). So, to protect those that insist upon entering credit card
info... we changed the name of the credit card field to blank... that keeps
us out of the scope of PCI/PA... and went ahead and encrypted the field
anyway.

If they use Xcharge and scan in the card to get a token, it stores the
allowable credit card #'s, and the expiration date, and the token.

So far so good... as long as Xcharge approves our software, we're good. We
comply with their rules because they are the ones that are PA compliant...
let them spend the money

Ray
VMT