In version 7.0.7435 we have added support for Address Verification Service (AVS) and Card Verification Value (CVV).

If your customers enter the AVS or CVV information incorrectly online, or if the cashier doing a MANUAL transaction at the theatre enters the CVV information incorrectly, the transaction will fail. However, due to the way CC processing works, there will be a hold placed on the card for the amount of the transaction. If the customer (or cashier) continues to try the transaction with the wrong information there will be multiple holds.

These pre-authorized transactions will not batch out at the end of the night and will drop off the customers statement within a few days when the hold is released.

This hold is not caused by RTS, it is just how CCs work.

If you have further questions, contact Technical Support.

Gareth, I do not completely understand this. When one of my cashiers enters a card manually and it is declined, we have no feedback as to why the card was declined. To be sure we didn't make a mistake with the abnormally small on-screen buttons on the computer screen while keying a card (and the inability to clear just a few characters, you must clear the whole field), we always re-key one more time. Why can't the terminal give us more information about a declined/failed transaction? All I have ever seen is "EM" and I have no idea what this means. Even with a declined card that was swiped we have nothing to tell the customer. Why can't the terminal say "Invalid security code" or similar if we key a number wrong? Why on earth would the credit processor pre-authorize a card and put a hold on a customers money if WE keyed inaccurate information. Between this, the inability to process cards offline (even at our own risk), and the inability to split-tender transactions, RTS is failing to properly meet our needs.

I forgot one other thing...I have had at least three phone calls to the cinema in the past few weeks asking what "Cvv" on our ticket purchase webpage is. Having a customer call the cinema to ask what this field is for negates the convenience of online ticket purchases. Some explanation should be placed on the ReadyTicket page.

Wesley,

If you are getting an error code back from the credit card processor that has no message, I need to get a screenshot of the error window and the steps to recreate the problem.

There are a wide variety of error codes that the CC company can kick back depending on what the issue is. The RTS error screen just displays the message that the CC processor passed to us, so it would be interesting to see if they are passing back an error code with no error message in it.

The holding of the funds has nothing to do with RTS, that's done by the CC companies.

I'm not sure what you mean by "process cards offline".

Split tenders is being worked on.

We will put a graphic online showing the CVV locations for Visa/MC and AMEX.

Thanks

So, let me see if I understand; Myself or one of my customers manually keys a credit card. They key the CC number correctly, and expiration date correctly, but key the CVV number WRONG. Then an attempt to process the transaction occurs. The transaction fails because of the incorrect CVV, but the funds are held out anyway? This doesn't make logical sense to me, but I will contact Mercury Pay and attempt to get an explanation. What will happen is that I will talk to several people before I even get someone that remotely understands what I am talking about, then they will pass the buck back to RTS and RTS will pass the buck back to MPS. What am I supposed to tell a customer that might have this problem? "That's just the way CC's work" is not an acceptable answer.

Regarding processing offline; Most other mainstream POS systems that I have worked with in the retail and restaurant industry had some provision for accepting CC's when there was no connection to the payment processor. Right now, if we lose our internet connection, we are completely out of luck. Some provision should be made for the rare times without internet connectivity so that cards can still be taken without an authorization.

If you are using Mercury Pay, they do offer a router which does have fall-back processing capabilities should your internet connection fail. (Contact Mercury Pay for details).

Your negotiated processing rates encompass all types of processing and associated risks.

Informing your employees of proper credit card handling proceedures is vital to providing a good level of customer service to your client. Garth is correct, when you attempt to charge a card (get authorization) the first thing which happens is verification of the dollar amount. Once this completes successfully THEN address verfication and CVV verifcation are performed secondary.

Most banks release held funds within about 5 business days although this can vary greatly by the individual card issuer and the risk group of their customers (secured cards sometimes withold funds for 20 to 30 days).

Before just repeatedly trying transactions, be accurate. Use a mag stripe reader and you will not have keying errors to worry about.

As far as the reason for decline, no merchant is authorized to know this information. This is between the bank and their customer. Release of this information would be a breach in confidentiality of consumer banking records.

If it is declined, it is up to the customer to contact their issuing bank to find out the reason. The only error codes which can be returned to the merchant are related to Authorized, Declined, Pickup Card, and address various address verification denial codes.

quote:

Originally posted by Wesley:
So, let me see if I understand; Myself or one of my customers manually keys a credit card. They key the CC number correctly, and expiration date correctly, but key the CVV number WRONG. Then an attempt to process the transaction occurs. The transaction fails because of the incorrect CVV, but the funds are held out anyway? This doesn't make logical sense to me, but I will contact Mercury Pay and attempt to get an explanation. What will happen is that I will talk to several people before I even get someone that remotely understands what I am talking about, then they will pass the buck back to RTS and RTS will pass the buck back to MPS. What am I supposed to tell a customer that might have this problem? "That's just the way CC's work" is not an acceptable answer.

Regarding processing offline; Most other mainstream POS systems that I have worked with in the retail and restaurant industry had some provision for accepting CC's when there was no connection to the payment processor. Right now, if we lose our internet connection, we are completely out of luck. Some provision should be made for the rare times without internet connectivity so that cards can still be taken without an authorization.

The one thing that bugs me is that we get charged if a customers card is declined when we have no way of knowing if a card will be good or not before we swipe it. It seems the customer should accrue that cost. Remember to tell your employees that if a card is DECLINED once, there is not need to swipe it again (more fees).