Credit Cards 'Technical Error'

RMS V 1.3 - Since we have made our switch to RMS V 1.3, we have been receiving 'Technical Errors' on transactions. The Technical Error received on

1 transaction will cause a blockade in processing the remaining transactions while additionally assigning the 'Valid' transactions with a Technical Error. When the issue was brought to Microsoft, they kicked us some scripts to address the error after the fact. New West developed their new Card Vault program because of our situation. Microsoft does not know what causes the error, their suggestion was to look to New West for an add on of the Card Vault. I am not looking for an add-on, but rather a resolution. Here is what is known about a card that results in a Technical Error. The card is swiped> it moves to our Gateway host (we are not on Vital)> they transfer and send the data to our Processor> our processor sends a request to Issuer for Approval> Issuer sends answer to Approval to our Gateway> Gateway transfers Approval Decision back to RMS (and only Approval Status back, they do not transmit the credit card numbers back)> the transaction moves to Settlement Batch. In the process between moving from the approval code to settlement, we find that the card either loses or gains digits. Example, I had a Visa with an error that was 10 digits long. I can see based on separate reporting with our Processor that they did indeed receive and log the credit card in a valid form (correct digits), additionally, if they had not, what Issuer would assign an approval on an invalid card number? What happens to this credit card number that the data becomes corrupted when transferring to the settlement batch? This problem has been ongoing and unresolved for 6 months (since our switch to V 1.3). We are losing on average $10,000 per month. We have had an open ticket with Microsoft for about 4 months, and still do with no end foreseeable. If anyone has made it all the way to the bottom of this post, thank you. If you have anything, anything at all that may provide as helpful, please let us know. Thank you again. snipped-for-privacy@kuhlmancompany.com
Reply to
Jocelyn
Loading thread data ...

Jocelyn,

I thought the Card Vault was updated with the card number before the transmission to the processor? I guess that's a better question for New West.

What, if any, validation mask are you using for your credit card tenders?

What add-on are you using to transmit to the Gateway from RMS?

If your processor has the correct card number, how can you be losing any money?

Reply to
Jeff

Jeff, thank you! First of all, while the Card Vault was created for us, we do not yet use on all locations. And to be totally honest, I do not think a proper solution is to purchase an add-on.

Validation mask, I have no idea. I am not sure where I would find that data. I know that they are masked, save but the last 4 digits.

We are not using an add-on to transmit from the Gateway to RMS, they only send back the approval code, not the credit card numbers.

While the processor has the valid credit card number, we face multiple charge backs when a transaction is not processed within 3 days. We lose the chargebacks if a transaction is manual, which they often come back as, because we have to re-key the data.

Actually that number is an average of the past 5 months. When we first began seeing the Technical Errors, we had zero idea they were out there for a couple of reasons: employees were not making anyone aware that they had received an error in settlement, because when they looked back on the batch in settlement, nothing was there. Additionally, our cash manager totally missed the first $30,000 that was missing. The EDC Reports only reside at the store location. Upon learning of the situation, New West also created a custom HQ Report to report on settlement batches and to specifically point to Technical Errors.

When the batch was processed against our locations that we did not know about the errors on, it was almost 3 months after the fact. We lost all of the charges, even the originally valid ones - no surprise.

"Jeff" wrote:

Reply to
Jocelyn

Jocelyn,

But what I'm getting at is that there may be something with your situation.

When I read your first message, I was online to a store that had rung up 473 credit cards before 11 AM and hasn't had a peep of problems in almost 2 years of using the built-in RMS program.

Validation mask - Manager | Tender types | one of your credit card tenders | Verification mask tab | Validation mask If you have a separate tender type for each type of card you take, you can have a mask for each. For example, a Visa card would look like this 4################, that's a 4 followed by

15 #'s. What this does is that when you swipe the card, it must start with a 4 and have 16 digits in the card number. MasterCard's start with a 5, Discover with a 6. AMEX is different in that they start with a 3 and only have 15 digits in them. This will prevent a mis-swiped card.

Which leads to my second question about the add-on you are using. You _must_ be using an add-on to send the card and sale info to the Gateway if you are not using Vital. What is it?

You are correct in that you only get a response code back from the processor, either a decline message, call center message or an approval message with the approval number, but that's too late in the process. The credit card number is stored somewhere before and during the process, either in the database on the hard drive or in RAM memory of the computer running the transaction.

What you or New West need to figure out is where its stored and to save it somewhere. That's what I _thought_ the Card Vault did. Between the time of the swipe and sending of the info to the processor, Card Vault writes the info to the Card Vault file, where it can't/shouldn't be changed. When the approval comes back, the approval number then is stored in both the Card Vault table _and_ the RMS VisaNetAuthorization table. I will look at the Card Vault info again.

Also sounds like you need to talk with your ISO's salesman and find out why they didn't inform you as to the un-closed transactions. They know about them within 4 hours. If you do _any_ kind of business with them, I would _demand_ it!

I'd be looking for a new Cash Manager! RMS says you did $100,000 in sales but only $80,000 is deposited into the bank and s/he didn't notice, see ya!

Reply to
Jeff

Reply to
Mark S

We had a similar problem but caught it after the first troubled sale. For some reason we got an authorization for an incomplete card number.

Upon doing research as to why/where the error occurred, talking to our processor and Vital was like talking to a brick wall. They did NOT get the full number from RMS, but still issued an approval. They only had 13 digits on file and we had to research the missing 3 digits by using the bank part of the number and making a few phone calls. Our processor was showing a 13 digit number that got approved. "How could a 13 digit cc number even get an authorization?" no explanation...

If you ask your processor, I'd bet they approved an incomplete number.

The mathetical rhyme to a credit card numbers validity can be achieved by basic math. If you use this math on a number that is too short, the math can still add-up to be valid according to a basic validator. The only 2 stipulations to take into account aside from this is: 1) the first 6 digits are the bank number (which is not validatable, but would be required for approval) and 2) the overall length of a card number which is validatable.

ie. both of these numbers will work with exception to length: 123456 9979119 or 123456 7812345670

formatting link
I'd be willing to bet you got the first 6 digits each time, but were missing random other digits.

We changed our validation mask from 4* to 4############### to ensure the proper number of characters get recognized during a swipe. Problem solved....

Now for any lost sale, use the digits you did capture and track down your money :-) Your processor should be able to supply you with the faulty approved numbers..

Reply to
root

Reply to
Jocelyn

Reply to
Jocelyn

Reply to
Jocelyn

Reply to
Jocelyn

I'd agree with these guys, using a non-vital processor through RMS is not a good idea. They designed that to Vital's specs, and I doubt that other processors have the same exact specs as another processor. Not surprised you are having issues to be totally honest. Best of luck to ya!

Reply to
Jason

Luck is what we need now as Microsoft preemptively called us today to announce they were dumping our case three hours before our scheduled conference call. Should have seen that one coming 5 months ago.

I am thinking I will continue to use the few SQL script tricks that I know to rebatch and void the 'bad' transaction to allow the rest to pass through. But what gets me there, is that I can set the status = Void on a batched trx, but I do not know the SQL to remove that amount/tender from the Tender Summary or Sales. Anyone have parting thoughts on that?

Seriously guys, this has been fun, and thank you for all of your support, thoughts, ideas and luck. I am bank> RMS V 1.3 - Since we have made our switch to RMS V 1.3, we have been

Reply to
Jocelyn

Jocelyn,

Now I'm more confused. Paymentech is an approved processor when they use Vital.

Did you make this change all because you wanted to use the Valutec gift cards?

Reply to
Jeff

Reply to
Jocelyn

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.