MICROS 3700 ID 1

[hsumer]

Hi,

I am fight with RES3000 ver2.6.I have a couple question
1.Is it working with only NT4.0 sp4 or Can i use win2000
2.What is sample database or standart database admin id

I installed on wireless system and they are working fine but credit card has problem.I am trying find out different solution for it.For example PC-Charge.Does anyone try it with micros 3700 v2.6

 

[TobeThor]

Res3000 will work with NT or Win2K.

Admin ID varies from site to site, the installing dealer sets that up.

I don't beleive you can use PC Charge, with Micros 3700 I think you must go thru Merchant Link as the Gateway. You have to call your local Micros dealer to get that set up.
I am not 100% positive thou, maybe some other folks can answer that one more accurately.

 

[Shift4SMS]

You don't have to use MerchantLink. Do a web search for "Secure Micros Credit Card Driver" - you should find other options.

Steve Sommers

http://www.shift4.com

-- Creators of $$$ ON THE NET(tm) payment processing services

Blog:

http://shift4sms.blogspot.com

 

[pmegan]

There's a little confusion here on 3700 versions.

Version 3 was named Res3000. Version 2.6 is just 3700 v2.6.
Anything below 3.1 uses NT. 3.0 can run on w2k with a registry hack, but micros support won't touch it.
Versions 3.1 and 3.2 will run on w2k.
Versions 4.0 and above run on XP pro and win2003.

About the credit cards. This is definately not an area you want to cheap out on. There's a lot of scary things going on with identity theft and the new laws aimed at preventing it.

If you're going to run credit cards through your POS, you cannot use 3700 v2.6. It's 8 years and 5 versions old. The new PCI laws that the credit card companies pushed through require O/S and POS software versions less than 3 versions old. They also require that credit card numbers, expiration dates and cardholder names be masked on the printed voucher. Also any CC data stored on the server or transmitted through the network or an internet connection must be encrypted. These are things that 3700 v2.6 never has and never will do. Micros isn't doing any more development on it so there will be no service packs to bring it up to speed.

I don't know about going around MerchantLink. We use them in all our restaurants and haven't had a reason to go elsewhere. Whichever way you go, do not let anybody convince you that you're ok running cards through that system unless you get a contract stating that the system is PCI compliant with their drivers and they'll be financially responsible for non-compliancy fines if you're compromised before hitting the internet or phone lines, because these fines are staggering. If you're a single store doing average sales they can easily put you out of business. If you're compromised, the forensic audit alone costs thousands of dollars. If your system is found to be below standards you get hit with an initial fine of a few thousand dollars and then accrue additional fines daily until you either stop processing credit cards or bring your system up to speed.
I know of at least 2 restaurant chains here in Manhattan that were compromised and had fines over $300,000 each.

While you're googling for an alternate credit card processors, look up "PCI compliancy" and "CISP compliancy" as well. You should also take a look at the links below before deciding on who's going to handle your credit cards.

http://www.americanexpress.com/datasecurity

http://www.pcisecuritystandards.org

Pat

 

[TobeThor]

PMegan Great post, well said, restaurants have to be very careful processing CC thru POS!

If sites upgrade to Micros Res3000 Ver 4.1 will they be able to use existing WS4 terminals? I heard Micros has a newer L7 terminal which a micros rep at the food show described as a beefed up WS4. Could you define beefed up.
Thanks

 

[Shift4SMS]

Pat,

I think you might be correct about PCI & 3700 v2.6, currently it cannot be made PCI compliant. Let me rephrase though (just to confuse people), technically it can be made PCI compliant, but the cost to validate and certify it as compliant is too great for, as you said, an 8 year old technology. (who knows, market demand may change this?)

One area where your advise may be a little too aggressive: "Whichever way you go, do not let anybody convince you that you're ok running cards through that system unless you get a contract stating that the system is PCI compliant with their drivers and they'll be financially responsible for non-compliancy fines if you're compromised..." Certified compliant drivers are listed on the Visa website and there are non-MerchantLink drivers on the list. Also, no one, even MerchantLink, will accept full liability for a breach. There are too many factors out of control of Micros or the payment vendor to accept the full risk. What if a rogue employee installs a keyboard logger - should MerchantLink, Micros or any other vendor be liable? If you require this in writing from a Micros non-preferred vendor, then you should require it from their preferred vendor. Good luck on that one. I do fully agree with you on all the ramifications of using a non-compliant system.

Tobe, as for the WS4 question, I fairly certain they will be compatible BUT you should really ask a dealer. Micros has a history of not supporting all hardware platforms with newer versions.


Steve Sommers

http://www.shift4.com

-- Creators of $$$ ON THE NET(tm) payment processing services

Blog:

http://shift4sms.blogspot.com

 

[pmegan]

Thanks TT. I just installed my first LX terminals last week so don't really know what they're capable of. They do have more memory than the old WS4's, and run on CE6 instead of CE4. Micros hasn't been able to tell me much more than that so I'm kind of figuring things out for myself.

Steve, maybe I should have rephrased that with an "as installed" clause or something like that. A rogue employee putting a keystroke logger on the system is an extenuating circumstance. All I'm saying is that anybody claiming their product will keep you out of trouble, as installed, should put their money where their mouths are. There are restaurants who have been compromised and have received partial reimbursment of the fines from their vendor.
I've seen a lot of pretty shady companies working the "we cost less than micros" angle and it scares me how many small businesses will end up ruined because somebody told them they could save a buck by using a 3rd party processor instead of merchantlink. There's even at least one company claiming that there's no reason to trade in your 2700, they have a system that will make it legal. There's no way you can make a DOS product PCI compliant.

 

[Shift4SMS]

Even with the "as-installed" angle, you'll have a hard time convincing any vendor to accept all liability. The problem is that any contractual wording accepting liability can spark a legal firestorm if anything goes awry - no matter the cause. Your best bet is to make sure that your solution is on the official PABP certified list and I fully agree with you, don't just take the vendors word.

Also, if your into the techie stuff, I would also recommend that you get some details on how the system is made secure. I would argue that our technique is more secure that the Micros preferred vendor approach. While the card associations focus on "compliance" for achieving security, we focus on secureity for achieving compliance -- it may sound like symantics, but there is a difference. For example, compliance says that stored card data must be encrypted; best security practices say don't store what you don't need. The preferred solution stores credit card information throughout the day. The other solution NEVER stores the sensative cardholder data. And one better, the other solution runs on top of the native code that stores cardholder information encrypted, this way, after an unsuspecting hacker wastes his time decrypting the data files, all he/she gets are useless tokens (at least useless for the hacker!).

A little off subject, I have never heard of anyone making the 2700 compliant but there is an 8700 solution on the official list. Just because Micros says it cannot be made secure does not mean it cannot, after all, they have no interest in making it secure, but they do have an interest in convincing (forcing) people to upgrade.

Anyway, hope this helps. The bottom line is that information (Googling) is your friend. Once you find a potential solution, verify it on the Visa site for compliance and if you have time, do a little more research and compare technologies.

 

[pmegan]

When all this came about I researched a number of solutions and truthfully all but the Micros/Merchantlink package fell short.

I agree that the best bet is to not even store the card information, this is why I'm switching to the transaction vault driver. Once the processor gets the card data it's removed from the micros server and replaced with a reference number. However, there are situations where it becomes necessary to store the information locally.

Here are a few things I couldn't get answers about and remained leary of. Some companies had workarounds for some of these, but nobody except Micros addressed them all. They're focused on the 3700 because I haven't dealt with any other system in almost 10 years.

1) How do they work with offline transactions? If the internet connection in one of our stores goes down we call our processor and enter manual auth codes. In this case the cc info has to be stored locally until a connection is re-established. Upgrading to v4.1 ensures that this data is triple DES encrypted with a random encryption seed and stored as a binary data type.

2) One of the requirements is that the card #, exp. date and cardholder name cannot be shown on the vouchers. Res 3.0 and below aren't capable of this. If the 3rd party drivers enable this on the older systems, how is it done, with a SIM script? In most cases this would require purchasing a PMS/SIM license code.

3) Password rotation for anyone with end-user database access is also a PCI requirement. The compliant versions of 3700 have this available as a security settings along with password length and repeat frequency settings. Older versions do not, and if compromised you'd have to convince the PCI goon squad that you are indeed changing passwords periodically.

4) The system running credit cards cannot be more than 2 software versions or operating systems back from current. Res 3.0 and below do not meet these software requirements. 2.6 and below will only work on WinNT making them double failures, and although 3.0 will run on w2k with a registry hack, Micros won't support it.

5) Database user accounts and passwords now have to be customizable by individual site. older systems don't have the passwords hard-coded into the applications. how is this addressed?

6) With the compliant 3700 versions all data passed between the server and workstations is encrypted. If that pesky rogue employee runs a package monitoring program on a Res3000 network the CC info will come across as plain text regardless of the CC drivers.

These are some of the reasons I always tell people to check out the PCI Security Standards website before making a decision on a vendor.
So yes, the credit card drivers from these companies may be compliant, and may even work better than those provided by Micros, but there's more to compliancy than dropping in a driver that meets the standards. To me that's like replacing the u-bend under a sink and advertising the house as having new plumbing. There are a lot of requirements a POS system has to live up to outside of the credit card transactions and I haven't seen these addressed by any of the 3rd party companies.

 

[Shift4SMS]

Pat,

I would love to talk offline with you just to get your take on the Micros options you researched. You may want to do a little more research on the Micros Transaction Vault solution as it does not eliminate entirely the card information on the Micros side - it is still stored throughout the day and cleared at end-of-day.

With the exception of #2 (SIM is required), all can be covered either directly or indirectly with compensating controls. By compensating control, I do not mean more work for the merchant, just another technology covering that base. A lot of the requirements are taken out-of-scope if the Micros application NEVER sees real credit card information.

Anyway, this thread is long enough. Feel free to PM me your contact info if you want to talk offline. Again, I would love to get your take on Micros (no sales pitch, I'm in product development side of the house).