Mercury Processing Issue

[SteveH]

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.

[SteveH]

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.

[ronaldrwl]

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.

[SteveH]

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.

[vishal]

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.

[SteveH]

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.

[ronaldrwl]

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."

[vishal]

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???

[SteveH]

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.

[ronaldrwl]

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.

[SteveH]

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.

[SteveH]

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.

[ronaldrwl]

I don't understand.  This sounds like something different with Timeouts?  Did you get another AP*?  You can void a charge on their website.

[Lee]

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?

[ronaldrwl]

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.