authorize api integration and encrypted credit card numbers

[jspanocsi]

Hi, I'm looking at integrating some form of authorize.net product into an existing winforms dot net application for the company i work for.  I've looked into several integrations and they all seem to just be an api for handling payments.  IE it's up to my app to get a credit card number and an amount and then send that to the api for validation etc.  The problem is i've been told we can't touch the credit card number since we don't want to have to worry about PCI compliance etc.  is there a way in authorize's offerings to get an encrypted credit card block of data directly from a credit card swiper and pass that to authorize?  There are other companies that offer this, hence our app never has to touch a live card number.  We'd much rather use authorize though if possible.  If this were on the web, i'd just use their web shopping card and shell out to it etc.  Easy mode, but this is in a windows application.  

Thanks!

[TJPride]

The only way to totally avoid PCI compliance would to have a merchant-specific swiper that connects directly to the merchant over an encrypted channel and doesn't have the capability for passing credit card data to any other devices. If you're using a regular swiper that just translates the track data into text and passes that to your application, then you're on the hook for PCI - no amount of advanced software is going to avoid this. The good news is that if the computer you're running your software on is ONLY used for swiping credit cards (no browsing, running other software, etc.), isn't networked to any other computers locally, and has sufficient firewalls and so on, you qualify for SAQ-C, which is hugely easier to pass than SAQ-D.

Short version - Authorize.net is an API layer on top of the merchant, it isn't the merchant itself (though its parent company Cybersource does supply merchant services as well for people who don't already have a merchant). You'll have to talk to your merchant if you want a swiper that does what you're describing, and you'd be connecting directly to the merchant and not through Authorize.net.

[jspanocsi]

Thanks TJ.  That's kind of what i thought.  We actualy resell our software to users and want to make an entire packaged system so it probably won't be possible to have specific merchant swipers.  THere are other companies that do this.  While they sell specific swipers that only work with them, they are just like authorize and just process the transactions against any merchant account.  I had hoped authorize offered something similar.  You buy their swipers, you get an encrypted block of text every time someone swipes a card, you pass the block to them, they return good/bad etc and your done.

our lawyers don't want to get into the compliance game at this point in time.

[swainjk]

TJ,

I have been talking with Pioneer POS regarding an encrypted PIN Pad with an encrypted magnetic card reader for the system that I am developing. The reader sends encrypted track data to the gateway. When ordering the device, we tell them who our processor is and they pre-load it with that processor's encryption key.

Do I undertand from your post that Authorize.net does not support receiving and processing encrypted track data?

I am in the same camp as the previous poster - developing a Windows application that runs an unattended donation terminal. Since I will be selling hardware and software to clients, I don't to have to be concerned about installation PCI compliance. If I can use an encrypted reader and submit my software for a PCI compliance certification, I won't have to.  Of course all that is predicated upon Authorize.Net being able to process encrypted track data. If Authorize.Net doesn'tt, I may have to cancel my project or move to a different gateway/processor.

[Trevor]

At this time, Authorize.Net does not support encryption from the swipe device.  It is likely something that we will add support for in the future, but I cannot commit to supporting any specific device at this time as there is not single standard used by encrypted swipe device manufacturers.