EMV ?'s

[TobeThor]

Can anyone offer clarification re: SA EMV devices

If the new EMV devices are stand-alone (SA) devices why would the POS hardware (models) matter at all?
Is deployment of SA EMV devices with older POS Stations that have a Windows XP OS OK now (reCI DSS rules) since credit card data no longer resides in the POS in any fashion; IOW, does an expired OS no longer matter?
Will the new SA EMV devices also read gift cards, Mgr cards etc. or will end-users need to have and maintain two card swipe/dip devices?
How do these new SA EMV devices effect other payment types such as Apple Pay, Pay Pal?
How will end-users issue credit card refunds after they deploy SA EMV devices?
Are the EMV devices bank specific, IOW's after deploying SA EMV devices an end-user wants to switch their credit card processor, does it require new SA EMV devices?

 

[hosehead78]

The main difference with the newer EMV devices are that theres a chip reader on the device, Credit Card's with the Chip are no longer "Swiped", they are inserted into the terminal. (example:

https://youtu.be/hz9HKNj1-m8?t=33).

The older model workstation may not be able to handle communication between the processor and machine, This is why new models may be needed. As for Windows base systems, I do not know off hand. I only know that Micros Workstation 5 and above (not sure about 4LX's) work with the new devices.

 

[pmegan]

Standalone readers don't interface with the POS at all. You Use them to auth and close credit card transactions. The check still has to be closed manually on the POS side, with the credit card tenders essentially set up the same as you would any other tender that can accept a gratuity. Manager cards, gift cards, payment apps, etc... would still be swiped/read on the POS terminal, not the SA EMV reader.

Going this route is a pain operationally; you have to close transactions on both the reader and the POS, introduce a new layer of user error possibilities, and will have to reconcile the EMV batch to the POS CC tenders. On the other hand, there's no CC traffic going through your POS at all, so the only items in your PCI scope are the readers. You can use whatever POS/OS you want, as long as they're not on the same network as the EMV readers.

 

[TobeThor]

Thanks everyone.

Sorry, I should have mentioned that I am hearing the term semi-integrated re: SA EMV devices. POS providers are telling my clients that the SA EMV devices are connected to the POS network via IP address and although the SA EMV devices connect to the internet separate from the POS these new SA EMV devices use the POS guest check printers to print the authorization slips for guests to sign. So I say connected but that may not be 100% accurate. I understand what pmegan is describing as that is common approach (two separate systems, POS and SA terminals for credit cards) for the few clients that have older POS systems that do not process the credit cards and yes I agree with pmegan re: the potential for errors and spending 1 hour trying to correct a $3 mistake.

So all my questions are re: the semi-integrated SA EMV devices. Maybe I shouldn't be using the term stand-alone. I am under the impression that the new semi-integrated EMV terminals do not require their own batching process rather clients will continue to batch as they have in the past (from the back office) albeit a separate batch for each EMV device in some situations. Because these new EMV terminals do remove the POS from storing (or having) any credit card data on-board I'd like to see all our clients move in that direction BUT it seems very confusing and difficult to get specifics when asking questions.

 

[PosGuyUS]

Although the devices look like stand alone, that doesn't mean they are. In our case, each device is connected either through USB or Network to the system. Either way, there is software on each terminal to talk to the reader assigned to it. Basically, the software says to the system, there is a card in the reader and which reader if IP. The reader is sending data around the system which is good because it makes the POS software more out of scope of PCI since it isn't ready the CC. A token is sent to the server so there is one central program that has the batch to balance to the POS.
The only delays we've had have been tips and certifications for lesser used processors, some aren't even closed to certified.