CP Integration; but some transactions appear CNP

[danw]

Hi there,

We've got a CP implementation, but some of our customers are reporting that their bank is treating some of their transactions as CNP (i.e., it appears that the CC number has been keyed, rather than swiped), and hence charging higher fees.
Why would this be?

Cheers,

Dan.

[Joy]

Hi,

There are two components to obtaining swiped/retail transaction rates. First is that you must be using a card present account, second is that you must be sending us the full track data and not just the card number and expiration date. Sending the card number and expiration date to a retail Authorize.Net account will result in the transaction as the type "Customer Present - Key Entry". This transaction type is usually used in retail scenarios where the cards magstripe is damaged and cannot be swiped.

My best guess is that your software is submitting data to us in the incorrect way. You'll want to make sure that it is sending the track data to us unmodified.

Thanks,

Joy

[danw]

Hi Joy,

Thanks - we're always posting Track data.

Could it ever be the case that track data obtained by swipe would be received by Authorize.Net as a CNP and/or 'Customer Present - Key Entry', or would this only occur if someone had actually manually keyed the card info?

Cheers,

Dan.

[danw]

Bump!

[RichardH · Accepted solution]

Hello danw,

I believe your answer is on page 29 of the Card Present documentation:

If neither Track 1 nor Track 2 data is submitted, but x_card_num and x_exp_date are submitted, the Card Present transaction rate mightbe downgraded.

 Richard

[danw]

Great - thank you!

I must have overlooked that.

Cheers,

Dan.