Skip to content

How to Handle and Prevent Credit Card Duplicate Charges

Release Date: 08/31/2018

How Did Credit Card Duplicate Charges Happen?
Most of the time, duplicate credit card charges are caused by network (Internet) error.  Elliott online credit card processing utilizes Payware Connect as the payment gateway.  If Elliott sends a request to Payware Connect and, for whatever reason, we can't receive the answer back from their server, Elliott is either going to time out or give the user a communication error message.  Elliott considers this charge as unsuccessful so there's no payment received as far as Elliott goes.

But on the other hand, it is possible that the Payment Gateway did receive the request to charge, or it may take a long time to process the request during a busy time period, or the successful process message was sent back to Elliott but due to Internet error (most likely, the fault of your ISP providing an unreliable Internet connection). In these instances, Elliott never received the acknowledgement that the charge was successful. From the Elliott user's point of view, the credit card charges were not successful, so they try to charge the credit card again. That causes the duplicate charges.

So the bottom line is when you receive a network communication error when charging a credit card, or a time out error message, it does not necessarily mean the credit card charges did not go through.  The only way you can confirm if the credit card charges did go through or not is by logging onto your merchant account portal to check.  But since this is usually an admin function in most organizations, the user who performs the credit card charge is unlikely to have this privilege.  Furthermore, the user is under time pressure to complete the credit card charges (this is especially for point of sales [POS] users). So most likely, the user will attempt to charge again.

How to Detect Duplicate Charges When They Happen
In Elliott, you can go to A/R -> Reports -> Credit Card Log Report to see a list of credit card charges from Elliott's point of view. We recommend that you run this report every day for the credit card charges of the prior day.  See sample screen below:


Also, the primary contact person in your organization should receive an email from Payware Connect every night when the Payment Gateway performs the credit card settlement.  The value of this email should match with the credit card log report.  If they don't, then you have a problem.  You should then logon to the Payment Portal to get a detail of the settlement transactions. This is a necessary credit card reconciliation process that you should do on a daily basis.

In this reconciliation process, if the cause is due to duplicate charges, they are usually rather obvious by seeing the report.

How to Fix Duplicate Charges
The easiest way to fix the duplicate credit card charges is to logon to the Payment Gateway portal. Since the duplicate charges are settled already, you will have to perform a refund on the Payment Gateway portal.

If you have a lot of duplicate charges due to a network issue, then you may consider performing the reconciliation at the end of the day, instead of the next day. The benefit of doing so is when you discover the duplicate charges, you can logon to the Payment Gateway portal and use the "Void" function instead of "Refund."

The "Void" function can only be used for credit card charges that have not been settled yet (at the end of the day).  Therefore, you can void any credit card charges before the end of the day.  The difference between "Void" and "Refund" is that the voided credit card charges will not even show up on the customer's credit card statement, so it is less likely to become a customer relations problem.

How to Prevent Duplicate Charges in the Future

Our theory is that most of the duplicate charges are caused by Internet network error.  You can look at the XML2PWC.LOG file in your Elliott LOG folder like <ElliottRoot>\LOG\<CompanyNo>\XML2PWC.LOG file.  Look for any entries that match "Error."  The following are some examples:

Example 1
Error : System.Net.WebException: The operation has timed out
  at System.Net.HttpWebRequest.GetResponse()
  at El7Net.EL8PWPNT.SendXMLToPWC(String _XMLString, String url) in G:\NSI.SRC\nw82\EL8PWPNT\ELPWCPNT\EL8PWPNT.vb:line 1704

Example 2
Error : System.Net.WebException: The underlying connection was closed: A connection that was expected to be kept alive was closed by the server. ---> System.IO.IOException: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
  at System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
  at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
  --- End of inner exception stack trace ---
  at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
  at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)
  at System.Net.Security._SslStream.StartFrameHeader(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
  at System.Net.Security._SslStream.StartReading(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
  at System.Net.Security._SslStream.ProcessRead(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
  at System.Net.TlsStream.Read(Byte[] buffer, Int32 offset, Int32 size)
  at System.Net.PooledStream.Read(Byte[] buffer, Int32 offset, Int32 size)
  at System.Net.Connection.SyncRead(HttpWebRequest request, Boolean userRetrievedStream, Boolean probeRead)
  --- End of inner exception stack trace ---
  at System.Net.HttpWebRequest.GetResponse()
  at El7Net.EL8PWPNT.SendXMLToPWC(String _XMLString, String url) in G:\NSI.SRC\nw82\EL8PWPNT\ELPWCPNT\EL8PWPNT.vb:line 1704

These are indications that you may have an Internet network error.  To confirm, you may do a ping test with www.google.com (most websites block you from pinging them, but google does not).  Type of the following on your command prompt:
    ping -t www.google.com
Test it for at least 15 minutes and press CTL-C to end.  You should see something like the following:


Generally speaking, you should not experience any lost pings.  It is our opinion that if you have 1% or more pings lost, it is definitively a problem.  If you have more than 0.1% pings lost, then you have a somewhat unreliable Internet connection.  

Also, your average ping time should below 100 ms.  The following is an example of some test traffic that have a long ping time:

The following is another example of a fast Internet with unreliable connection. It shows in the long ping time with speedtest.net:


This type of long ping time is known to cause the inconsistent error 2029999.  See the following KB article on error 2029999 with credit card charges:

Because Elliott's credit card processing relies on communicating with the Payware Connect Payment Portal through your Internet connection, if your Internet connection is not reliable, it will affect the reliability of Elliott's credit card processing.  In that case, you should contact your Internet Service Provider to resolve this problem.


EMK

Feedback and Knowledge Base