Any type of account that works for both Card-Present and Card-Not-Present transactions..??

[angelleye]

I'm the developer of USBSwiper, a point of sale solution that uses a standard USB credit card reader in combination with software I developed that allows you to create an invoice, swipe the card, and it'll process using various gateways. 

I've always used AIM to integrate Authorize.Net into websites for people, and I never really dealt with the card-present aspect of things until I built USBSwiper.  Now what I've learned, though, is that apparently I need an entirely separate merchant account to use for CP transactions in order to get the lower rates on fees.

Many of my customers, though, are using Authorize.Net on their website already, and they just want to add some sort of a simple swipe solution to that.  Our solution provides that, but they don't ever get the lower swipe rates.  If they switch to a CP account, though, all of the transactions that come through on their website would get charged at a higher rate.

So far when people call me in this situation the only t hing I've been able to tell them is they  have to either stick with a CNP account and pay the higher rates for swiped cards (but at least have the ability to swipe), or they could create a separate CP merchant account to use for swipes and stick with the CNP account for their website.  Of course, this isn't ideal because now they're paying and managing two separate accounts.

Is there any way at all to use a single account with Authorize.Net and get good web rates when transactions come from there, but get good CP rates when transactions are swiped through our software? 

Any information on this would be greatly appreciated.  Thanks!

[TJPride]

Not to my knowledge, no. People would undoubtedly misuse the accounts and cause all sorts of problems if you could do both from the same account. Since the difference in fees is only like 1%, this isn't likely to impact anyone to an extent that matters, aside from businesses with a sales volume high enough to afford two accounts. It's a pain for you, I know, but it is what it is, and it's probably decided on the merchant end of things and not Authorize.net, which is just the layer that sits on top.

[angelleye]

I don't see how anybody would take advantage of this..??  The rate you get on any given card is based on lots of variables like whether it was swiped or keyed, if it's a rewards card, company card, etc.  The official interchange rate tables have more than 200 variables on them.

Having a single account used to process all cards from any source would work just fine if they just markup the interchange rate (interchange plus) or gamble with some sort of a bucket or flat rate pricing like many are doing these days.

The PayFlow Gateway, PayLeap, and Group ISO all allow me to do this without the need for separate merchant accounts.  Seems odd that Authorize.Net is still lagging behind.