Denver Research
General Category => ezPower => Topic started by: SteveH on April 19, 2011, 07:22:39 AM
-
We had a rather serious issue with a CC charge over the weekend. We made a hand keyed transaction which resulted in a pop-up window indicating an error "Error processing card: *AP" with a press ok button. My cashier pressed ok and tried the card again. A similar error was reported. The transaction did not appear to complete so we told the customer it was declined again and asked for a different card. The new card went through fine, receipts printed, and we were done. All of this happened in the context of the same POS transaction.
I then decided to go onto Mercury's site to see if I could tell what the AP* error meant and found that the first charge was voided, the second was processed, and so was the third. So we charged this customer twice - all on the same transaction. Again, the invoice number recorded for all three transactions was the same!
I spoke with Mercury about what was going on. They said that it appeared that the first transaction was accepted, the second one was processed as a duplicate (which results in automatically voiding the first transaction), and the third being on a different card went through as well.
Why did the first transaction appear on our end to be declined (*AP error). What is that and why would it result in a transaction going through but not registering as such with ezPower? The only card related details involved were that the woman said it was a new card but she had just used it successfully elsewhere. In the first attempt, we entered the billing zip code but did not enter it in the next two. Mercury claimed that the AVS passed with the zip we entered on the first attempt.
-
Mercury handles duplicate credit card charges by voiding out the first charge and allowing the second to go through.
We do occasionally have charges made on the same card for the same amount. PCCharge would ask, "is this is something you really wanted to do or is it was a mistake?" The cashier would click yes or no and all was well. Mercury does not appear to provide that option. You either have duplicate detection enabled or not.
After drilling down into this with Mercury, it appears that a duplicate requires that all of the information pos supplies is the same including the invoice number. Typically in a valid duplicate (i.e. buying the same widget twice), the invoice number would be different.
Can you verify that ezPower handles duplicates in this way? If I have someone buy a widget for $30, then a minute later decide to buy a second one, it would be a major bug if it voided the first purchase!
Is there anyway to handle it the way PCCharge did? If a charge is made for the same amount on the same card, ask the cashier if this is a mistake? This may require a fix on Mercury's end as it did not appear that they support that kind of feedback.
-
My understand is you won't get a duplicate error because the Invoice# will be different. The error messages are all from the processor. ezPower only relays the message. If the card is declined for any reason by the processor then ezPower gets a declined message and won't finish the order. I will take a look at the error code to see if that gives any more information as to what happened. On the first attempt you recieved this message "Error processing card: *AP"? What kind of card was it? What kind of card went through? The card type doesn't make any difference to ezPower. So, that is strange.
-
I don't think card type has anything to do with it. The first two attempts were with a MasterCard. The third was with a Visa.
The whole problem started with the first error of "AP*". That is the one that I need to figure out. Mercury claims there were no errors that they see on that transaction. Something abnormal happened with it though.
The second error may have been a duplicate indicator. ezPower didn't handle that correctly. It assumed the trans failed yet Mercury charged the card.
-
while the card is processing POS is waiting for the response from the processor and sometimes the response doesn’t reach to the POS it just gets lost in the internet traffic or reaches late to the POS in this situation POS takes it as decline. And it can happen in any POS or Processor
We also go through same kind of problem like couple times a year. In this situation we check the last transaction that was posted in the processor software just to make sure if it went through or not.
May be this is what happened to you as well.
-
Vishal, I understand what you are saying - though any transaction oriented processor should be able to handle this gracefully. If the first transaction timed out and ezPower handled it as a decline, and the second transaction (same card, same invoice) completed with a "Duplicate transaction" (as returned from Mercury), then ezPower should recognize this and treat the duplicate as a success (This assumes Mercury only flags a duplicate if it is the same card, same invoice).
As it is currently operating - ezPower treats the first error (whatever it is) as a decline, and the duplicate transaction response as a decline. Mercury on the other hand processed the first transaction (presumably without an error), then accepted the duplicate and voided the first. Now I have ezPower telling me the card is no good, and Mercury is off happy to take the charge.
I should never have to call the Merchant Processor to see if a declined card was actually accepted.
-
Something is not adding up. From Mercury's documentation you will only get a AP* when attempting a duplicate charge. You can not get this error code on the first attempt. If I understand your description you got the AP* on the first attempt. This doens't make sense.
"Mercury‘s Duplicate Logic
When a POS submits a transaction request which exactly repeats the same amount, card number and invoice number of an already-approved transaction in the current batch, the second transaction is considered a duplicate request.
In order to prevent a merchant from unintentionally sending through the same transaction more than once, Mercury uses what we term an enhanced duplicate logic. This logic assumes that the second transaction is a true duplicate and responds by replacing the duplicate request with the original transaction. In this process, the host approves the second duplicate transaction without actually charging the card a second time. Instead, the host response includes the text string ―AP*‖ and uses the same the AuthCode and RefNo of the original approved transaction."
-
When a POS submits a transaction request which exactly repeats the same amount, card number and invoice number of an already-approved transaction in the current batch, the second transaction is considered a duplicate request
I think their is bug at Mercury end and in EzPower as well:
Mercury should only look for Invoice number regardless of the amount and card number. The reason I want to keep the amount out is because after the first attempt if customer changes it mind and want to deduct or add any item in the transaction before trying the card second time then the amount will be different but the invoice number will be same. So keep the amount and card number out just look for invoice number. If the invoice number is same then take it as duplicate because there is no way anyone can have duplicate invoice number in same batch.
The second attempt from the POS is going to be only in 1 situation only if for some reason POS didn’t get the response from the processor that it is looking for to complete the transaction in first place.
And how EzPower going to handle duplicate error message it is going to be in never ending loop.
Am I right???
-
RE Ronald: I suppose it doesn't really matter what my first error was, POS declined it. When we reentered the card information and Mercury responded with a Duplicate indicator, POS should assume the card was accepted because that is what Mercury did. The two must be in sync with this outcome. I think fixing ezPower to accept the duplicate indication and maybe display a warning or informational message to that effect, that would fix this problem.
RE Vishal: I do not think that the price factors in. If we complete a transaction and then want to change it, we typically void the first one and reenter it as a new transaction/invoice. I think this error situation described above is rare enough that adding new variables to it is not worthwhile.
The one piece that I am worried about is the case when there are two invoices, for the same card, and same amount. In the old days PCCharge would flag this as a duplicate, POS would ask if you really want to do this, and you could proceed or cancel the transaction. That behavior was fine in that the retailer was in control of the outcome.
What does Mercury respond with if the invoice is DIFFERENT, but the card and amount are the same. If it just ignores this case then that is ok. We'll take our lumps if we entered the second transaction incorrectly. If it proceeded to void the first like it does when the invoice is the same, that would be a problem.
-
SteveH: "I suppose it doesn't really matter what my first error was, POS declined it." It matters completely. Without knowing how we got to this point we can't do anything. Here is what we know:
- AP* means declined. Mercury thinks this is a dublicate and is not processing any new charges.
- You will not get AP* with different Invoice#'s or with different amounts on the same card.
-
Ron: - AP* means declined. Mercury thinks this is a dublicate and is not processing any new charges.
This is not exactly the case. Mercury voided the first charge, and accepted the second with the duplicate response. They claim this is how a duplicate is handled - and this is what showed in my account.
I agree with you that it would be nice to understand why ezPower rejected the first charge when Mercury had accepted it. Mercury didn't seem to have any idea.
Is there an ezPower log that could be looked at?
What happens now in ezPower if a timeout occurs? What sort of error is reported and what options are given. I was going on the assumption that the duplicate only appeared if the first charge had been accepted and the second was in fact a duplicate. You are right that this may not always be the case.
Steve.
-
Any ideas on this one? We've tried reproducing the timeout and it does cause a failure with Mercury processing the charge - which is a real pain because there is no way to void the sale except to call the merchant processor. Sales made through POS can only be voided through POS.
-
I don't understand. This sounds like something different with Timeouts? Did you get another AP*? You can void a charge on their website.
-
Yesterday a sale was transacted and paid for with a Discover card. The ezPos software did not register the payment and the transaction is listed as "Not Paid". The card was run a second time to make the payment and it was reported as a "duplicate transaction", which it would have been.
This morning I find that the Discover card was processed as the funds have been deposited into my checking account. However, the payment has not been recognized by the ezPos.
How should I proceed to close this transaction and print the appropriate receipts?
-
How was the credit card process? Can you tell me any more information. You can turn off Process Credit card in the payment window. Finish the sale. Then turn processing back on. Maybe you should give us a call to walk you through it.
-
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.
-
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 ;-))
-
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?
-
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.
-
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!
-
What did you think of my idea with AP* in my previous post?
-
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.
-
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.
-
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...
-
Sent you an update to try
-
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.
-
I'm impressed at how much information you have dug up.