cancel
Showing results for 
Search instead for 
Did you mean: 

Card Present for Web POS System

I have a web-based POS system that I would like to integrate with a card-swipe device.  It is currently working with AIM for taking card not present transactions.  Does anyone know if there is a secure way to introduce an attached card-swipe machine and accept a swipe without having to putting me in the highest level of PCI compliance (SAQ D).  From the research I have done it seems that if you have a card-swipe device attached to a web app and are either parsing the magnetic strip or sending the entire contents of the strip it greatly increases your PCI exposure. 

 

Though it is easy to implement a javascript solution to parse the data from the mag strip and place values in the respective inputs (i.e., name, CC number, expiration) this seems like a risky solution.  Any ideas?

crocrabrad
Member
3 REPLIES 3

As I understand it, you're good for SAQ C as long as the computer your swiper is connected to is (a) only connected to the Internet, not networked to any other computers, (b) has appropriate firewalls (Norton?) and is only used for processing credit cards (browsing the Internet with it would violate SAQ C), and (c) does not store the credit card data, just transfer it to a certified merchant system (Authorize.net qualifies). In other words, to qualify for SAQ C, you need to install PHP or whatever language you use on a local computer and use that to call Authorize.net directly, rather than using your web site as an intermediary. And the computer you use has to be reserved just for processing credit card transactions. Short of that, you'll have to ditch the swiper and just use the virtual terminal inside your Authorize.net account to type things in manually, which would qualify you for SAQ C-VT.

 

Your web site is probably SAQ D, incidently. So if you're going to use it regardless, you don't really lose anything using a swiper.

TJPride
Expert

I'm dealing with a similar situation here. We used AIM for years. However, with the changes in the PCI requirements, we need to discontinue AIM (unless we are certified). The SIM interface works for the desktop app. I can send sales information with a POST and it becomes part of the transaction. Unfortunately, the old fashioned card swipes can no longer be used.

 

VPOS is the only method that supports a card swipe. Card swipes are what my customers want to use. They are willing to purchase the newer cardswipes. The problem is that there is no way my app can additional information to VPOS. They expect the clerks to manually enter the amount, invoice number and items.

 

This makes VPOS unsuitable for use in real-world POS situation. Authorize.net support is not much help either.

I'm not sure what to do. Good luck with your problem.

brucerowe
Member

As I said, you can probably qualify for SAQ-C if the computer the swiper is connected to is not networked to any other computers, has sufficient firewalls, is used only for this purpose (no additional software, period, no browsing the Internet using that computer), and connects directly to Authorize.net. The problems with qualifying for SAQ-C normally have to do with computers that are being used for multiple tasks and/or are networked and/or shared (virtual dedicated / shared hosting). There's no way to 100% guarantee security on those.

 

EDIT: And I'm talking about using a CP account with AIM, in combination with any swiper (and there are many) that just gives you a simulation of keyboard typing. Put focus on a "track" field in your software, swipe to fill it in, press go and have the swiper pass the data internally. I woudn't think it would be that difficult. The key is to have your software run on the computer connected to the swiper, and connect directly to Authorize.net.