GUEST BLOG Part III: Why card issuers decline transactions and what to do about it

By David Goodale,¬†Merchant Accounts.ca 

Humans are habitual and have patterns that can be observed. This may or may not be considered an invasion of privacy, but in the world of card issuing it is fortunate in that it can help a card issuer detect unusual activity for a particular cardholder. 

For example, a bank may have issued a credit card to a senior citizen. This senior citizen may have been a cardholder for more than 10 years, using the card an average of three times per month. These purchases might always be less than 100 dollars, and always local to where the cardholder lives. In this example, the card may have not ever been used in an online (card not present) scenario before. If that same credit card was suddenly charged for 10,000 dollars at an online casino website based in the Caribbean, it would be an obvious trigger to suspicious activity. This would almost certainly be picked up by the card issuing bank and blocked. The trick for the card issuing bank is to implement protections for the cardholder that will protect them in less obvious situations, while not overly inconveniencing the cardholder from doing what they want with their card on a day-to-day basis. 

Each card issuing bank will protect its algorithm used to prevent and defeat fraud. Releasing such information would only empower fraudsters and help them bypass such protections. However, we can examine some of the more obvious checks and balances that card issuers employ to protect cardholders. 

Insufficient funds:  This is the obvious cause of a decline. In some cases the cardholder may have been spending more freely than he had realized, and the card balance may simply be over its limit. 

Expired card: Another obvious reason for a decline. If the card is expired the card issuer will probably decline the transaction. However, it is worth noting that a card issuer actually can still approve a credit card with an expiry date that has elapsed. 

History of international purchases: If a cardholder has never purchased outside of a geographic region before and suddenly does so for the first time, it could be an indicator of a stolen card. 

History of online purchases: If a cardholder has never purchased online before and suddenly does so it could be an indicator of a stolen card. 

Transaction size limits: If a cardholder has never used their credit card for a big ticket purchase before and does so for the first time, it could be an indicator of a stolen card.

Multiple purchases from different locations at the same time:  If a cardholder is using a credit card in Toronto, Ontario, in the morning it makes sense that she can't also be using the same card in Miami, Florida, later the same morning. This is a strong indicator of a stolen credit card (and is also why you should always notify your bank if you will be traveling. Otherwise you may find your card blocked!) 

Card has been determined or reported stolen: Card issuing banks must react quickly to stop fraudsters and protect cardholders. In some situations a credit card may have been determined to have been compromised, and the card issuer will put a block on the card even before notifying the card holder. In these cases a phone call will usually be placed to notify the cardholder, and a new card shipped out. 

In contrast to what we are discussing in this article, in rare situations some merchants actually want to assume transactions are good and not submit them to be processed in real time, but wait and batch them out later at a less busy time. 

This may sound like the height of insanity, but let's explore with an example. A very large chain retailer might establish a limit on certain card types during the holiday season to just approve transactions under 10 dollars. Why would a merchant ever assume a card is good?¬† In the holiday season, if a very large merchant has hundreds of stores with thousands of POS machines, they could be hammering a processing platform, which could cause a backlog or instability on the network. The real issue though is not so much technical but human in nature. The retailer wants the lines short to speed sales through. If a retailer can get more sales done during business hours, it may be worth the relatively small chance of a declined order when batching later to keep customers zipping through the checkout. Another example of this could be on an airline in which you purchase a sandwich, but the POS machine cannot establish an internet connection during flight. Logic stands to reason that if you can afford a flight that you can afford a sandwich on the journey. There are cases in which it's not worth risking a decline in order to get more business put through the system. 

Whenever a transaction is being declined by a card issuer the solution is always the same. There's very little that you as the merchant can do despite the cardholder protesting to you that his card, "...should be working!" The cardholder must contact his¬†card issuing bank to determine why the transaction is being declined. The cardholder should start by asking if the transaction in question can be seen on the system. (That way we can make sure the bank is seeing the transaction and it is not a gateway-side error). If the bank responds in the affirmative, the cardholder must ask if the transaction was blocked by the bank. If so, he must ask for the bank to release the block. At that point the cardholder can re-attempt the transaction and it will be successful. (In the next ¬†post in this series, I'll cover best practices¬†that will help you recover lost sales in the event of card issuer declines.) 

Other reasons credit card transactions can be declined 

If you think of the payment process as a chain of events, there are several "handshakes" that must occur in order for a transaction to complete. If any one of these parties in the chain is down, interrupted or unavailable during the transaction resolution, a problem will occur. 

The process starts at the payment gateway. The payment gateway will send transaction information to the processor. The processor handles the batching of transaction data and settlement files over the Visa and MasterCard network to the card issuers. This is a potential point of failure. 

Another point of failure is the card issuer itself. If the card issuer is down a transaction can be declined. In some cases the card brands themselves may intercede to provide network continuity and approve or decline transactions to prevent downtime. The card brand, if standing in to approve a transaction does not have as much information as the card issuer, so this could still result in declines because it may implement a lowered maximum transaction limit cap during this window of downtime. 

The card networks and card issuers realize that uptime is critical. Such service interruptions are rare. In fact, Visa and MasterCard maintain a systems freeze during the months leading up to Christmas in order to minimize the chances of downtime occurring due to system glitches or human errors. However, no matter how redundant a system is, downtime can occur. That is why it is best to have a procedure in place to monitor declines and try to recapture lost sales. We'll cover that in the next and final post in this series.

‍

Download the Payments Orchestration eBook Below