Mercury Processing Issue

[Lee]

As it was explained to me... the Discover card was processed as usual and the animated "processing transaction" (or whatever it says) came up and stayed up "for a long time".  I have the timeout set at 600 sec. and it could have been ten minutes.  Then the window went blank except for the "continue" button which was pressed. 

Now there are times, when this happens, that the software seems to have hung up and pressing this button causes the printer to print the receipt and the sale is completed.  In this case, the screen just went away and the sale was still open.  Running the card again yielded a duplicate transaction warning and the charge was aborted (avoiding the duplicate charge).

The charge was completed but ezPos doesn't know that, leaving the transaction "Not Paid".  I see no option to turn off Process Credit card in the payment window.

[SteveH]

I did not get the AP* or the usual timeout because to simulate the timeout situation I pulled the ethernet cable from the PC out of the router. The result was a socket error rather than a timeout. I should have pulled a cable further upstream. The result was the same but the error was different.

You can't void a sale on Mercury's web site that was made from POS. Their interface is a "virtual terminal" that you can make and deal with charges as you would with POS but you can't modify any charges made outside of their interface. They told me that the POS provider needs to have that interface.... pass the buck to the other guy ;-))

[ronaldrwl]

I've been thinking about this for awhile.  The only solution I can come up with is when a "AP*" is received is to accept this as a valid payment.  And give a warning message to verify that the charge went through.  What do you think?

[SteveH]

We had this happen again. This time the card (we had the card) returned an error that my cashier did not capture. He ran it again, another error... and a third time - no luck.

Looking in our Mercury log I did find something interesting. The first response came back the AP-NEW INFO, the second and third came back with AP-DUP in the raw response (found on Mercury's site.). I called Mercury and they had no idea what AP-NEW INFO meant (it's late and the woman was extremely helpful so I was pleased. I am going to follow up tomorrow with a call in to their Tech Support to get an answer on the first error.

My guess is that ezPower doesn't handle anything other than a total success (whatever that means in this case). the Duplicate error is a feature of their interface that ezPower needs to handle in a proper way - I'll have to think about that a bit more to decide what might be the correct handling. I liked the old method with PCCharge where you gave us the option to accept or decline it. I'm not sure with the new interface that you really even have that option open to you. A blanket accept on all Duplicates may be the only valid solution - it is what Mercury is assuming you'll do.

The AP-MORE INFO response needs an explanation from them.

Steve.

[SteveH]

Status update - I've been on the phone with Mercury Technical Support and they are trying to figure out what the AP-NEW INFO response means. I'm betting that this is being stuffed into the CmdStatus field of the RStream CmdResponse block and ezPower is tripping on it. The DCIClientX documentation states the CmdStatus field has 4 codes ("Success", "Approved", "Declined", and "Error"). I told them it looks like there are at LEAST two variants of APPROVED (AP-DUPE and AP-NEW INFO) that need to be handled and documented.

I'll update when they figure out what their response codes mean!

[ronaldrwl]

What did you think of my idea with AP* in my previous post?

[SteveH]

I think your previous idea is probably the way to go. Does AP* mean "Approved-xxx" where xxx is one of DUPE, or my new NEW-INFO? I'm guessing it does. I'd like to hear what Mercury has to say about this. My batch log of all of these AP-xxx codes show as simply Approved in the batch - leading me to think they are assuming you'll view it as approved also.

[SteveH]

Mercury's response is that the "AP-NEW INFO" is passed along from the issuing bank. They do not generate this message. I pointed out that from the POS programs point of view it doesn't matter who generates the status, it needs to be documented how to handle them.

So how does this work. What comes back in the transaction response? Is it an "Approved" status with Extra information in the text or error fields or or is it some undocumented status? What causes ezPower to reject these approved transactions? Can and should they simple be accepted?

AP-DUPE definitely needs to be treated as an Approved response.

[SteveH]

This sounds exactly like the result of the problem described in the "Mercury Processing Issue" thread.

The initial error may have been a response timeout - i.e. short lived network issue perhaps.

I assume you are using Mercury...

[ronaldrwl]

Sent you an update to try

[SteveH]

Thanks Ronald,

I think this fix is the way to go but I wanted to get confirmation from Mercury on this. It's no wonder there is confusion. These guys at Mercury don't know what to do. The only AP-xxx status they've ever seen is AP-DUPE and they felt this was a status you wouldn't want to approve. I asked why not! Mercury has charged the customers card. He stumbled and had no answer to that. I'm waiting for more input from their engineers.

I called DataCap and they suggested that you folks contact their engineers on this. The guy I spoke to seemed pretty knowledgeable but I didn't have the integration information he needed to make any recommendations.

[ronaldrwl]

I'm impressed at how much information you have dug up.