next »

[iiyoyoguy]

I am interested in you developing a card swiper for the android phone for use with your product.

It should not be hard, you have two paths, either the usb port that could be flakey, or translate 1200 baud data from the audio in port.

-GReg

[tim]

Hi Greg,

We are evaluating our swipe options again, but it's more complex than you might think.  If you don't mind the ramble, here's what we are dealing with.   

First, there are really two reasons swipe is an attractive option...

1)  Lower processing rates due to "CP" or "Card Present" transactions.
2)  Easy of use, speed of card entry.

Should we provide support for "Card Present" the gateway has to be configured for "Card Present."  This means that the Merchant Account also has to be set for "Card Present."  Most Authorize.Net gateways are setup for Ecommerce and MOTO (Mail Order / Telephone Order) and by nature, they are configured for "CNP", or "Card Not Present."  Basically, whether you accept payments over the internet, or take orders over the phone, "CNP" applies.  This means, even "if" you swipe you won't get the lower rates.

It's my understanding that Authorize.Net accounts are setup with "CP" or "CNP" and cannot be changed.  So, if you have a website that uses Authorize.Net for a gateway, you'd need another Authorize.Net and Merchant Account to take advantage of the lower rates via swiped transactions.  It's also my understanding the PayPals Web Payments Pro has no rate structure to discount swiped transactions.

Second, is in regard to the Bluetooth options...

Bluetooth swipe devices have to be PCI DSS compliant.  In short, the bluetooth "swipe" needs to be encrypted for security purposes so that nobody could "sniff" the wireless card data being passed from the swipe unit to the phone.  It's my understanding that this encryption actually happens between the gateway and the swipe device.  Neither Authorize.Net, nor PayPal Web Payments Pro have such a feature.

While this is something that we are still investigating, we don't yet see a way to use Bluetooth for a swipe reader until such time as we have a PCI DSS compliant encryption option.  This may explain why you don't see other mobile products with Bluetooth Swipe options that support Authorize.Net or PayPal Web Payments Pro.

Third, the USB Option...

Okay, so there are really two USB Options here:

One operates just like the Bluetooth version in that one could process "Card Present" transactions.  Again, the user would likely need a different Merchant Account and Authorize.Net account because in all probability, theirs is currently set for "Card Not Present."

The other USB Option is really a keyboard emulator.  Basically, it scans the card and "pastes" the card number into whatever field the cursor is in.  That's all it does.  This may help with the speeding up the processing, but it wouldn't lower the rates.  This should be pretty easy to do, and it may actually work now, although we haven't tested.

So that's it.  It's something we'd like to do, but there's really a good deal more at play than there appears to be.  If someone reading this can clarify, or expand on any of these points, please do.  Meanwhile we'll keep plugging along and should anything change, we'll post it here.

Best,

Tim

[spiread]

Tim,

I just posted a new topic with a similar question. 
http://www.mobilemerchantpro.com/mmp-forums/index.php/topic,133.0.html

Then I noticed your helpful response here.

For my client, their primary interest is not the lower fees with a "card present" scenario.  They just want the convenience to swipe and the numbers appear in your app.  This will speed things along if they have 10 people lined up at a trade show wanting to buy their product.

So if you could offer something in that regard -- or maybe you do by now -- that would be EXACTLY what we're looking for. 

Thanks! 
Jeremy