In payments, some transaction declines are inevitable. Some declines are “hard declines” – no matter what you do, that transaction will never be authorized. For example an issuer might decline a transaction because the account has recently been closed. Others, however, are “soft declines” and can be retried or, better yet, prevented. For example, a customer could have made a typo on the checkout page, or an issuing bank might have had an outage, or an error might have happened at your PSP. For merchants, understanding why declines are happening and what action could prevent them, is a key part of optimizing their payments processing and improving approval rates.
Why understanding decline reason codes can be challenging
The gateway, acquiring bank/payment service provider (PSP), fraud solution provider, and customer’s issuing bank all have the power to decline a transaction. If a transaction is declined, then whoever decisioned the transaction will send a decline reason code that is attached to the transaction data. There are a couple of key challenges in understanding this data.
For one, different players within the payments ecosystem often ‘normalize’ reason codes received from issuing banks and therefore utilize different codes and language to describe the same bank decline reason. For merchants, this makes reconciling data across players, and truly understanding the reasons for declines, particularly challenging. This problem is not limited to only bank decline reason codes. Check out how Pagos is supporting data reconciliation efforts in BIN data in this article.
Another key challenge in understanding decline reason codes is simply the number of reasons a transaction may be declined. There are dozens of decline reason codes, and it’s not always clear if the decline is hard or soft. Let’s look at reason codes that focus on fraud prevention as an example.
You can see here that although the reason may sound the same, the first flag is a hard decline and cannot be retried. The second is a soft decline and can be retried. This example also displays a third challenge with understanding decline reason codes: language clarity. The language of the first decline reason code may not immediately indicate fraud to a novice payments professional. Particularly for ecommerce merchants: PICK UP CARD is a request of an in-store merchant (card present transaction) to keep the card from the customer.
That being said, at least in the example above, we can eventually understand the reason behind the bank decline and if the transaction can be retried. Often, however, many decline reasons are bucketed into the same, generic bank decline reason code. Depending on the market, bank and even card product, often more than half of decline transactions may be labelled with bank reason code 05 DO NOT HONOR. This language is far too generic and broadly applied to understand anything about the reason for the decline or if it could be retried. In order for a merchant to understand and take action on their declines, there is no way to avoid, a conversation with their payments service provider to gather more information from the networks and issuing banks. This is a cumbersome process and can add significant delays in understanding and taking action to improve performance.
What the industry is doing about it
This is a well understood and evolving challenge that has a material impact on reducing the number of false positive declines that are especially rampant in card-not-present. More false positives means less happy customers, and less sales for merchants. According to Forter, merchants can lose up to 75 times more revenue from false declines than they do to fraud. Over the years, acquirers, gateways, and issuing banks have gotten much better at using a standard set of decline reason codes to address some of the challenges above.
In order to empower even more understanding for merchants, networks have begun grouping decline reason codes by the inevitable outcome for merchants. For example, Visa released guidance this year to group decline codes into less granular, but more clear cohorts. Specific decline codes – like the two listed above – are grouped by whether or not the decline can be retried or if they are high risk declines for the merchant. This effort, although not fully implemented, is a great way to drive simplicity and clarity behind decline reason codes. It also allows merchants to have clear guidance for retries and approval rate optimization.
Pagos is here to help
At Pagos, we know that creating actionable insights is serious work. As experts in payments data analysis and advice, we work continuously to find new ways to transform your payments data into easy to use, digestible content so that you always know what’s happening in your business. Peacock by Pagos can help you visualize not only your decline reason codes, but also many more core payments metrics, like authorization rates, transaction volume, processor share, and more.
Do you want to learn about other key payments topics? Contact us and share what’s on your mind!
If you haven’t yet registered for our No-Code Beta or custom
API integration, sign up today!