More detail for Market type and Device type

[nhwilly]

Is there somewhere I can get more detail on these settings?

I found a little  here: http://developer.authorize.net/api/reference/features/payment_transactions.html

But I would like to know more so I can get the setting right.

TIA

[Lilith]

@nhwilly If you go to the API Reference and look at the createTransaction API call, it should have more details about marketType and deviceType:

https://developer.authorize.net/api/reference/#payment-transactions-charge-a-credit-card

marketType	0 for ecommerce 1 for moto 2 for retail  This element is required if you submit the retail element.	Default value is 2.
deviceType	1, 2, 3, 4, 5, 6, 7, 8, 9, 10  1 = Unknown  2 = Unattended Terminal  3 = Self Service Terminal  4 = Electronic Cash Register  5 = Personal Computer- Based Terminal  6 = AirPay  7 = Wireless POS  8 = Website  9 = Dial Terminal  10 = Virtual Terminal  This element is required if you submit the retail element.

Did you have specific questions about these settings?

[nhwilly]

Thanks for the quick reply.

Yes, I saw that list, but I really don't know what the difference, technically, is between moto and ecommerce, for example.

More importantly, if I have a mobile app, which device type do I use?  Self Service, Unattended, or are those only devices controlled by the merchant?  Do I use website, even though there really isn't a webpage involved?  I have no idea what AirPay is.

Do any of these effect the rates applied by the merchant processors?  I don't want to pick the wrong one and find out my customers are getting over charged.

Stuff like that.

[Lilith · Accepted solution]

@nhwilly Authorize.Net accounts are set up with a Market Type, and so it really depends on the merchant base you're after. You'd want to match Market Types to prevent integration errors, and to make sure your merchants' rates aren't impacted.

"Retail" means that a card is physically swiped.

"eCommerce" means the card information is submitted over the Internet, from a shopping cart or other web-based solution.

"MOTO" is "Mail Order and Telephone Order" -- that is, they do not receive orders over the Internet, but they don't swipe cards either.

So if your solution needs a card swipe, and you plan on sending the track data to us, you'd want to use "Retail" -- and, you will need to let your potential users know they need an Authorize.Net account set specifically for Retail purposes.

As for the Device Type, for a mobile solution I would suggest using 7, "Wireless POS."

"AirPay" is a legacy product, and I can see about having that flagged as such.

I wouldn't use 2 ("Unattended Terminal") or 3 ("Self Service Terminal") unless you're building out a kiosk.

Regarding merchant rates, that tends to be impacted more by what data you send above and beyond Market Type and Device Type.

For example, if you submit retail transactions, your merchants will get better rates if you submit Track 1 or Track 2 data, than they would if you parsed out the card number and expiration date, and sent that separately.

If you're not submitting track data, your best bet against downgrades is to include the billing address and CVV code, for AVS/CVV checks.

If you're also handing Level 2 (business-to-business) processing, you'll need to include the Purchase Order Number, Tax Status, Tax (if collected), Duty, and Freight.

I hope this helps -- but let me know if you need further details.

[nhwilly]

Perfect!  Just what I was looking for.