Troubleshooting Credit Card Results From Mercury Payments

This article is similar to the publicly available article with some additional sections and examples. This is the place where we can document new customer scenarios etc, and still place information that we might not want a customer to see. Please take the time where relevant to update the public copies of this information so that our customers have the information that they need.

Is the receipt the only place we log responses?

No there is information on the transactions tab of the payment screen as well. You can also double click on the transaction to get this information. (from Craig in Programming)

Errors and Behaviors Explained

It is important to notice some subtle differences in the messages that we see. There are some in ALL CAPS. These messages seem to be coming from Mercury Payments normally. The ones that are in Proper Case seem to be coming from DataCap. Please see the descriptions with each error to get more specific information.

So what if your slips act differently, should you be worried. Probably not as there are some customizations to the behavior of credit card slips. Please see this article for more information on how this is setup.

AP NOT CAPTURED

This is an error message that shows on the slip receipt Click here to view information on this error

  • excerpt from Details:

This is an error message that shows on the slip receipt. I think this comes from Mercury. AP means authorization. I don't see the message in data caps “DSIClientX Interface Spec V04.23 - 20090529.pdf” document. What does AP mean in AP not captured? There is a CaptureStatus of Captured or Not Captured. This is in section 13.01 listed under Transaction Response under XML Responses.

Timeout on Response

This is an error message that shows on the slip receipt. There are scenarios where these transaction get processed and go through, and other scenarios where the do not go through.

Click here to view information on this error

Invalid Check Digit

This is an error message that shows on the slip receipt Click here to view information on this error

No Information Showing on the Receipt but sale processes

credit_card_information_not_showing_on_receipt_but_sale_processes

Error Merchant Setting Does Not Accept RecordNo. 4117

You are using tokenization on a Non-token merchant account.

Merchant Setting Does not Accept Encrypted Data

You are using the wrong Merchant account, Use the E2E, Tokenized Merchant Number for FIS/Mercury.

INVALID DATA

You are sending contactless / NFC transactions on a non-contactless merchant account.

A list of codes and messages from Mercury Payments

- CALL AE -Refer to American Express for Voice Authorization (800-528-2121) 
- CALL DISCOVER -Refer to Discover for Voice Authorization (800-944-1111) 
- CALL ND         -Refer to Visa/Mastercard for Voice Authorization (800-944-1111) 
- PIC UP -Authorization Declined (reported lost or stolen card) 
- DECLINE         -Authorization Declined 
- INVLD TRAN CODE         -Processing code entered is incorrect 
- INVLD ACCT -Account number is not valid and did not pass issuer’s edit checks 
- AP DUPE         -Transaction entered is a duplicate 
- INV ITEM NUM -The item number entered for a void or adjustment transaction is incorrect 
- INVALID DATA -Format of the transaction is incorrect 
- INVLD MERCH ID         -Invalid Merchant ID

Some Examples

There are additional details provided in the text window below. Here are some messages from that window below:

  • AP NOT CAPTURED
  • Transaction Failure - Retry…
  • Timeout on Response
  • Invalid Check Digit. Check Acct Name
  • DECLINE-TRY LATER
Below is a bunch of information from Merchant copies of the receipts. 
----- This charge went through at the bank - showed declined in Windward ??----- * "AP NOT CAPTURED"   - Main content, Date through amount shows properly   - RESULT ""   - AUTHORIZATION ""   - REFERENCE "" 
----- This charge went through at the bank - showed declined in Windward ----- * "Transaction Failure - Retry...:   - Main content, Date through amount shows properly   - RESULT "Error"   - AUTHORIZATION ""   - REFERENCE "" 
----- This Transaction was accepted in Windward ----- * "Timeout on Response"   - Main content, Date through amount shows properly   - RESULT "Error"   - AUTHORIZATION ""   - REFERENCE ""  * "Invalid Check Digit. Check Acct Name"   - Main content, Date through amount shows properly   - RESULT "Error"   - AUTHORIZATION ""   - REFERENCE "" ANS: This is what normally happens on a bad card swipe. If the incorrect card number    scans in, then the check digit is designed to detect this. 
----- This one was a customer copy ----- * "DECLINE-TRY LATER"   - Main content, Date through amount shows properly   - RESULT ""   - AUTHORIZATION ""   - REFERENCE ""  * No Card number expiry or name, but amount filled in   - DATE "10/10/2010"   - TIME "3:33:21 PM"   - TILL "1"   - CARD NUMBER ""   - EXPIRE "0000"   - CARD TYPE ""   - NAME ""   - AMOUNT "$5.21"   - RESULT "Approved"   - AUTHORIZATION "053924"   - REFERENCE 0289 
----- Mercury processing problem ----- * Basically the Authorization is MERCXX or 110TX. I think these are the ones where mercury covers it if less than $300   - Main content, Date through amount shows properly   - RESULT "Approved"   - AUTHORIZATION "MERCXX"   - REFERENCE "5619"

AVS 0 Response Not Sent

Address Verification Service (AVS) is a process by which we send the Customers Address information along with the credit card authorization request so that we can see that we are indeed processing the correct credit card for the correct customer.

  • I am waiting for confirmation on from Francis on STAR COSTUME getting this message when they test their CC transactions. I am thinking that not having a customer attached or the terminators etc on the swipe might not be properly programmed on their Cherry keyboard. (Feb 07, 2010-cm)
  • Excerpt from help file
Use AVS (Address Verification Service). This service is for mail/phone/internet orders for card numbers that are not swiped. This should normally be turned on even if you are not using the feature. Canadian processing may not use this feature. 
3. Taking a payment using Keyed Entry. You can not make a debit card transaction with this method. There are two reasons you would want to make a payment using a keyed entry, one the magnetic stripe on the customer's card does not work, and two, you are taking a phone, mail or Internet transaction.  Customer Present Keyed Entry. This entry is used when the customer's magnetic stripe is damaged. Enter the amount in the tender screen as above. Then type in the card number and expiry date. You should then enter the 3 or 4 digit CVV or CVV2 number that is on the back of the card in the signature strip.
Mail Order / Telephone or eCommerce Entry. If you are taking a payment over the phone, mail order or e-commerce you can help reduce fraud by using the Address Verification Service (AVS). When making these sales, ensure that the invoice has a customer defined and that the customer's address and zip/postal code are defined. You should also ensure that you have selected the correct transaction type. 
The AVS service will not prevent a card from Authorizing, but will warn you if there is no match. It is then up to the clerk to void or reverse the transaction if they suspect fraud. 

Troubleshooting Failed Reversal Results From Mercury Payments due to timeout issues

There are some issues that have been coming up where timeouts occur when doing EMV transactions. Then a reversal is initiated.

  • Here are some comments from Craig in programming about the communication path for data in different authorization scenarios when using Mercury Payments:
(14:11) Clifford: does mervcury payments connect to data cap or global payments? I don't remember which and am having trouble looking up the answer. THanks (14:20) cralph: Mercury normally connects with mercury then global. Dialup, EMV is questionable. (14:20) Clifford: kk, thanks. (14:21) cralph: emv is datacap netepay -> mercury (14:22) cralph: non emv is direct to mercury, then global (14:22) Clifford: kk (14:22) cralph: dialup appears to be global

No response from PIN Pad

Ensure your a not running your PINPAD over wireless. We support Terminal Services via wireless, because there is not data being transmitted, just screen and keyboard, however PINPADs transmit data. Wireless networks will drop or delay data much more often than wired networks.

D14 INTERAC ERROR 05

The datacap netepay is not running correctly. Restart and ensure there is not an SQL Error. Download new parameters from the server. You can try recreating the database using the re-creation tool in C:\Program Files (x86)\Datacap Systems\NETePayEMV

  • Double click on EMVDBManager
  • Then click “Connect” button
  • Click on Create New Database
  • Just click “Yes” when prompted to ask “Are you sure to create New Database”
  • then exit out to close EMVDBManager
  • Run Netepay server and reload parameter download
  • at the station you should be able to perform EMV parameter download