With the changes in the PCI requirements, we need to discontinue AIM. 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. The clerks need to manually enter the amount, invoice number and items.
This makes VPOS too slow for use in real-world POS situations.
What is recommended for PCI compliant transactions?
02-13-2012 03:37 PM
02-14-2012 02:49 AM
The situation is not quite the same. The application at http://community.developer.authorize.net/t5/Integration-and-Testing/Card-Present-for-Web-POS-System/... is web based. My application is desktop based. My app currently works just as you describe (collect the card data, encrypt it and pass it to Authorize.net).
The challenge is with the rule, "A payment application is anything that stores, processes, or transmits card data electronically." and "any piece of software that has been designed to touch credit card data is considered a payment application." Source: http://www.pcicomplianceguide.org/pcifaqs.php In other words, I need to process payments without touching the card numbers.
The SIM interface will do what I need. I can start a transaction by sending data in a post. I enter the card number on the Authorize.net website from within my app. The only data I save is what Authorize.net gives back to me. It works well. But, SIM does not support swiped data. Card swipes are necessary for efficient POS transactions.
VPOS does support card swipes. However, VPOS has limitations:
Overcoming these limitations means manual entry. This slows the sales process to do the work accurately. In a POS environment, this is not possible.
Unless I can find a solution to this problem, my customers will be forced to use a non-compliant application.
Any other ideas?
Bruce
02-14-2012 01:26 PM - edited 02-14-2012 01:29 PM
How many times do I need to say this. If you are in ANY way transmitting credit card data through your computer, you may as well be using AIM (assuming you're using it via your application, rather than from a web-based application...) The ONLY way to avoid credit card exposure is to have your swiper transmit the data directly to the merchant and have the computer only receive a status code, which from the sound of it is not something your swiper is designed to do. The swiper would have to be merchant specific, and therefore probably far more expensive.
However, you can still qualify for SAQ-C as long as your computer passes the security rules. It's next to impossible to pass with a remotely hosted web site, but a computer is a fairly controlled environment if you want it to be.
02-14-2012 07:18 PM