The dreaded card declined transaction that the processor charged anyway…
If you are a merchant and you accept credit or debit cards, whether through your POS Software or a stand alone terminal on the side, you and your customers will experience this annoyance from time to time, simply because the internet isn’t perfect.
In very rare cases, for a very small amount of merchants (less than 1% of merchants), there seems to be an issue where a credit card is swiped and a DECLINED result is displayed on their POS System, after which the merchant simply tries again and the card goes through at the second attempt, but it seems that the processing bank charged both swipes successfully (double charged) even-though they reported the first attempt as a DECLINED outcome.
We can certainly try to explain this phenomenon to you, no matter what POS Software you are using, as best as we can, and give you some tips on preventing it, however, we must point out that this is not a problem on anyone’s side, it is not a problem that can be addressed by the developers of the POS Software, because they don’t own/create/control/understand the credit card processing part (even the credit card processing software code within their POS Software) – it belongs to the respective credit card processors. But also the credit card processors are not to blame, read on for the explanation as to why this is happening and how to best remedy it in the future…
Most lower level support staff at the processor’s tech support does not even have the capacity to understand this problem and they will give you the standard answer [an answer they use for whenever they do not have the answer/solution for you] : “It is not on our side, therefore, something must be wrong with the POS Software or that Merchant’s POS System”.
However, we have researched this a lot and pushed back on the issue with different processing partners, and some higher ranked techs and developers at our processing partners’ companies have advised us that the rare scenarios, where there may be a duplicate charge, where there wasn’t supposed to be one [because of a supposed DECLINE], result from situations where a card is first “falsely” reported as “declined” – because of breaking in the communication between the merchant’s PC or POS system and the remote credit card processing servers (this is communication that takes place over the Internet – and the Internet is not perfect – there are drops in connection sometimes). So this wasn’t an actual DECLINE, just your Internet connection to the processing server, was lost, for a split second and when the POS Software didn’t get a response from the processor for some time, it simply went to its response-time-out routine and pronounced the transaction as Declined, because there was just no answer from the processing servers. And then you swiped the card again or took another card from the customer thinking there must be something wrong with the first card, because of the initial DECLINE message, and then the second attempt went through as usual with a positive response, like APPROVED.
So the scenario is usually described as this :
1.) You swipe a card.
2.) The information is sent to the credit credit card processing server and your PC or POS System waits on the response.
3.) The credit card processing server receives your information fine and processes the card and is getting ready to send your POS Software a “success” or “processed” confirmation.
4.) Your Internet connection has an issue for even a tenth of a second and breaks the communication with the credit card processing server.
5.) Because of the drop of the communication link between your POS System and the credit card processing server, the response to this transaction’s outcome is never received by your PC.
6.) Enough time passes without any response, so the automatic “no-response” answer triggers in the POS Software, which is an automatic “DECLINE” message – due to the “no-response” state for a certain amount of time.
7.) You see the “DECLINED” message on your POS Software and assume it is a legitimately declined transaction of course (while this transaction was fully processed without a problem on the other side, but a proper status answer could not reach your PC and a Decline was triggered because of a time-out situation), and you charge the card again or take and charge another card, resulting in a second charge.
How do you check to see if this is your case and that your duplicate transaction problems occur when there was supposed to be a DECLINED transaction first and then a SUCCESSFUL transaction ? If your customer comes back and claims they were double charged, simply go to your POS software, go to its Reports, there needs to be something like a Transaction Log, and in there simply find the Invoice in question and see if the one log record is reported as DECLINED and the other as processed. If the one log record is reported as DECLINED and the other as processed, then you have confirmed the scenario as described above.
How to remedy this ?
This is what you should maybe consider sometime in the future:
– A break in an Internet communication can happen because of a bad connection to your Internet Router (whether wireless or wired), a bad router, a bad Ethernet/LAN element on your PC, a bad Internet connection or bad Internet service altogether. Consider replacing any of the above to see if your situation improves (we cannot guarantee any positive results from replacing equipment/services, do this at your own expense/risk, your Internet connectivity is not our liability nor responsibility in any sense).
This is what we strongly recommend as an established work habit for the future:
– After each work day is concluded, a manager should simply look at the total amount of charged cards in the Point of Sale software and compare it with the total of charges reported in the Merchant Portal website for their processing company. If the two totals that the POS Software and the Merchant Portal website are reporting, for the given day, match, then everything is 100% fine, without any problems for the day.
– If however, the two totals that the POS Software and the Merchant Portal website are reporting, for the given day, mismatch, then to find and remedy the problem, the closing manager should go to the Card Processing Transaction Log and see if there were any DECLINED transactions for that day. If the manager finds any DECLINED transactions, they should go to the Merchant Portal website for their processing company and see if a double charge occurred and refund any double charges before the customer finds out on their card statement and gets upset in the process. Of course, any DECLINED transactions that are not actually charged at the Merchant Portal’s website report, would indicate that they were proper and authentic DECLINED transactions (not due to an Internet connectivity issue).
And lastly, if you will refund the customer, you have to refund the approved and successful transaction, because a declined transaction usually is an unsuccessful transaction and as such it cannot be refunded through a POS software, you cannot refund a declined transaction to put it simply.