



WheresTheDog wrote:Thanks for the explanation. It's only something I have run across once. I'd have to ask my wife (who's at the store most of the time) if she's experienced it more.
When it was presented to me I wasn't sure how to even do it (we're currently using QBPOS at the store). In QBPOS, there is only 1 credit card field. When you enter an amount there and hit Enter to accept you're prompted to swipe the card. It reads if it's Visa, MC, AMEX, etc and processes the card (taking some human error out of the equation).
If you didn't enter the full amount of the sale, it dynamically popped in an additional credit card field. It was a surprise to me, but made it easy to use.
It did handle each credit card transaction separately, printing out a total of 4 receipts (2 for the customer to sign and 2 for the customer to keep).
In reality it did nothing more than the work around you suggest for RetailEdge here or in the other post I read about version 7.5 and processing the sale as a layaway. It only took a step or two out of the process.
Off Topic:
I hope you're not getting sick of me spouting off QBPOS this, QBPOS that, but it's what we currently use and we know it pretty well, so I keep referring to it for comparison. However, we are not happy with it entirely (mostly I don't trust it with our data) and I'm currently looking for something else.

[/quote]Bill wrote:RetailEdge can handle split media. So if someone has a sale for $3.00 and they want to pay with $1.50 cash and $1.50 VISA, then this is not a problem. However, the problem is when someone pays for the $3.00 sale with $1.50 from Visa 1 and $1.50 from Visa 2 or AMEX AND you are trying to process the credit cards through the program.
Most of our customers have experienced Scenario 1 (Cash and Credit) or process credit cards outside of the program with a separate terminal. We have had one customer ask for this function in the past. It is in the list of suggestions but with a pretty low priority for the following reasons:
1. Not that many people have asked for it.
2. It is complicated to implement. From a programming perspective the entire transaction needs be broken into separate pieces with different payments. Not being a programmer, I am not sure that the tools and payment gateways we use would even support this. Also there is a whole new UI that would be required.
3. It is more difficult for users to setup. We try and keep the program as simple as possible and only add complexity where we think it is necessary. Complexity can add to support costs (A lot of "What does this do?" guestions) and user frustration ("I thought I was doing correctly but did not and now I have to unwind it")
4. There is a pretty simple and guickly done workaround. The workaround is to take first payment, and save the sale as an open order. Then recall the open order and take the payment on the second credit card.
So not a lot of benefit but a lot of downside.
quote="WheresTheDog"]I was just reading through some different forum posts and ran across one for 7.5 stating that RetailEdge 7.5 could not process a sale using multiple credit cards. Then listed a work around. Is this still the case with the current version of 8.0?



Users browsing this forum: No registered users and 18 guests
Copyright © 2016 - 2018 ForumUS. All Rights Reserved. Powered by phpBB® Forum Software © phpBB Limited.