POS - Card Present. vs. Non-Card Present transactions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

POS - Card Present. vs. Non-Card Present transactions

Vince Clark
Currently POS handles CC transactions exactly like eCommerce. From a payment processor perspective they are both "non card present" transactions, which carry higher fees.

Has anyone implemented POS to support "card present" transactions?

Vince Clark
Global Era
The Freedom of Open Source
[hidden email]
(303) 493-6723
Reply | Threaded
Open this post in threaded view
|

Re: POS - Card Present. vs. Non-Card Present transactions

BJ Freeman
would need a card swipe and pin entering device.
depends on the gateway also.
using the authorize.net connectionmethodsguide.pdf
should not be to hard.
not sure about other gateways ofbiz supports.

Vince M. Clark sent the following on 12/11/2007 12:00 PM:

> Currently POS handles CC transactions exactly like eCommerce. From a payment processor perspective they are both "non card present" transactions, which carry higher fees.
>
> Has anyone implemented POS to support "card present" transactions?
>
> Vince Clark
> Global Era
> The Freedom of Open Source
> [hidden email]
> (303) 493-6723
>

Reply | Threaded
Open this post in threaded view
|

RE: POS - Card Present. vs. Non-Card Present transactions

Christopher L
I has been some years since I have been in the credit card processing industry, but would a pin entering device be specifically required, as opposed to a keyboard?  I would think you could get by with a card swipe and a keyboard (numeric only or alpha numeric) that could be used to punch the CVV codes.  A pin pad for customers to use would only be required by straight, non-visa, non-mc debit cards, and does anyone have those anymore?  Last I heard, you had to pay to get a debit card without the Visa or MC functionality.

My knowledge is mostly US, this could be different elsewhere.

To my knowledge, there are just a few additional fields that need to be sent to qualify for "card present" rates.  I just checked the Authorize.net site and the integration manual is absolutely glorious.  Well written, easy to read, all the information is right there, including examples.

http://www.authorize.net/support/CP_guide.pdf

I also checked out the ofbiz integration, and it currently uses the Advanced Integration Method (AIM) that Authorize.net requires for swiped transactions.  This could be pretty easy.

I also ordered a card present test account from them.  I don't have a card swiper though.  Anyone have any suggestions on a stable yet inexpensive model?

Chris

> Date: Tue, 11 Dec 2007 12:33:16 -0800
> From: [hidden email]
> To: [hidden email]
> Subject: Re: POS - Card Present. vs. Non-Card Present transactions
>
> would need a card swipe and pin entering device.
> depends on the gateway also.
> using the authorize.net connectionmethodsguide.pdf
> should not be to hard.
> not sure about other gateways ofbiz supports.
>
> Vince M. Clark sent the following on 12/11/2007 12:00 PM:
> > Currently POS handles CC transactions exactly like eCommerce. From a payment processor perspective they are both "non card present" transactions, which carry higher fees.
> >
> > Has anyone implemented POS to support "card present" transactions?
> >
> > Vince Clark
> > Global Era
> > The Freedom of Open Source
> > [hidden email]
> > (303) 493-6723
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: POS - Card Present. vs. Non-Card Present transactions

Vince Clark
I'm reading the same guide. I agree, it is very well documented and the fact that we are already using AIM suggests we just need to add a few fields to the transaction submitted to Authorize.net. I'll post more as I test.

We have a couple of dedicated POS terminals that have built in swipes. But we have also tested with a standalone version from MagTek that plugs into a USB port. Functionality seems to be about the same as the built in devices so you should be able to simulate the process on a regular PC. I think the MagTek's go for around $20 USD.

----- Original Message -----
From: "Christopher L" <[hidden email]>
To: [hidden email]
Sent: Tuesday, December 11, 2007 5:01:37 PM (GMT-0700) America/Denver
Subject: RE: POS - Card Present. vs. Non-Card Present transactions

I has been some years since I have been in the credit card processing industry, but would a pin entering device be specifically required, as opposed to a keyboard? I would think you could get by with a card swipe and a keyboard (numeric only or alpha numeric) that could be used to punch the CVV codes. A pin pad for customers to use would only be required by straight, non-visa, non-mc debit cards, and does anyone have those anymore? Last I heard, you had to pay to get a debit card without the Visa or MC functionality.

My knowledge is mostly US, this could be different elsewhere.

To my knowledge, there are just a few additional fields that need to be sent to qualify for "card present" rates. I just checked the Authorize.net site and the integration manual is absolutely glorious. Well written, easy to read, all the information is right there, including examples.

http://www.authorize.net/support/CP_guide.pdf 

I also checked out the ofbiz integration, and it currently uses the Advanced Integration Method (AIM) that Authorize.net requires for swiped transactions. This could be pretty easy.

I also ordered a card present test account from them. I don't have a card swiper though. Anyone have any suggestions on a stable yet inexpensive model?

Chris

> Date: Tue, 11 Dec 2007 12:33:16 -0800
> From: [hidden email]
> To: [hidden email]
> Subject: Re: POS - Card Present. vs. Non-Card Present transactions
>
> would need a card swipe and pin entering device.
> depends on the gateway also.
> using the authorize.net connectionmethodsguide.pdf
> should not be to hard.
> not sure about other gateways ofbiz supports.
>
> Vince M. Clark sent the following on 12/11/2007 12:00 PM:
> > Currently POS handles CC transactions exactly like eCommerce. From a payment processor perspective they are both "non card present" transactions, which carry higher fees.
> >
> > Has anyone implemented POS to support "card present" transactions?
> >
> > Vince Clark
> > Global Era
> > The Freedom of Open Source
> > [hidden email]
> > (303) 493-6723
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: POS - Card Present. vs. Non-Card Present transactions

Vince Clark
One more thing on the swipes. We had to adjust a setting on the time allowed for keyboard events to get the swipe working reliably. Read this thread:
http://www.nabble.com/POS-MSR-problems-on-WinXP-to14129710.html#a14140144 

----- Original Message -----
From: "Vince M. Clark" <[hidden email]>
To: [hidden email]
Sent: Tuesday, December 11, 2007 4:57:10 PM (GMT-0700) America/Denver
Subject: Re: POS - Card Present. vs. Non-Card Present transactions

I'm reading the same guide. I agree, it is very well documented and the fact that we are already using AIM suggests we just need to add a few fields to the transaction submitted to Authorize.net. I'll post more as I test.

We have a couple of dedicated POS terminals that have built in swipes. But we have also tested with a standalone version from MagTek that plugs into a USB port. Functionality seems to be about the same as the built in devices so you should be able to simulate the process on a regular PC. I think the MagTek's go for around $20 USD.

----- Original Message -----
From: "Christopher L" <[hidden email]>
To: [hidden email]
Sent: Tuesday, December 11, 2007 5:01:37 PM (GMT-0700) America/Denver
Subject: RE: POS - Card Present. vs. Non-Card Present transactions

I has been some years since I have been in the credit card processing industry, but would a pin entering device be specifically required, as opposed to a keyboard? I would think you could get by with a card swipe and a keyboard (numeric only or alpha numeric) that could be used to punch the CVV codes. A pin pad for customers to use would only be required by straight, non-visa, non-mc debit cards, and does anyone have those anymore? Last I heard, you had to pay to get a debit card without the Visa or MC functionality.

My knowledge is mostly US, this could be different elsewhere.

To my knowledge, there are just a few additional fields that need to be sent to qualify for "card present" rates. I just checked the Authorize.net site and the integration manual is absolutely glorious. Well written, easy to read, all the information is right there, including examples.

http://www.authorize.net/support/CP_guide.pdf 

I also checked out the ofbiz integration, and it currently uses the Advanced Integration Method (AIM) that Authorize.net requires for swiped transactions. This could be pretty easy.

I also ordered a card present test account from them. I don't have a card swiper though. Anyone have any suggestions on a stable yet inexpensive model?

Chris

> Date: Tue, 11 Dec 2007 12:33:16 -0800
> From: [hidden email]
> To: [hidden email]
> Subject: Re: POS - Card Present. vs. Non-Card Present transactions
>
> would need a card swipe and pin entering device.
> depends on the gateway also.
> using the authorize.net connectionmethodsguide.pdf
> should not be to hard.
> not sure about other gateways ofbiz supports.
>
> Vince M. Clark sent the following on 12/11/2007 12:00 PM:
> > Currently POS handles CC transactions exactly like eCommerce. From a payment processor perspective they are both "non card present" transactions, which carry higher fees.
> >
> > Has anyone implemented POS to support "card present" transactions?
> >
> > Vince Clark
> > Global Era
> > The Freedom of Open Source
> > [hidden email]
> > (303) 493-6723
> >
>