How To Improve Authorization Rates by Understanding Refusal Reasons
How To Improve Authorization Rates by Understanding Refusal Reasons
Bridging the Mapping Gap for Better Authorization Rates
In this newsletter, I will share how Payment Service Providers and Acquirers can improve their Authorization Rates by better understanding refusal reasons.
Payments Performance has received a lot of attention in the last few years. Some have used it to brand their companies, trying to create a differentiating factor, while others have worked on adding feature after feature to help merchants gain a few basis points in authorization improvement.
However, to improve Authorization Rates, we need to start with the most fundamental understanding: what it means when a transaction is declined. In other words, we need to understand refusal reasons and what they really mean.
Let me explain...
The Importance of Refusal Reason Analysis
Understanding refusal reasons is crucial for Payments Service Providers (PSPs) and Acquirers. Each transaction refusal provides valuable data about why a transaction was not approved. This information can drive significant improvements in decision-making, operational efficiency, and customer experience.
Enhanced Decision-Making
Analyzing refusal reasons allows PSPs and Acquirers to identify patterns and trends in transaction declines, enabling informed decisions about risk management and authorization policies. By understanding specific refusal reasons, companies can start to understand how issuers are setting up their fraud detection and prevention measures and take the necessary actions to comply with them. For instance, if a pattern of refusals is identified that only seems to come back due to what can be considered a high-risk merchant category code (MCC), the PSP/Acquirer could add additional measures, such as Dynamic 3DS, to better handle the responses to those transactions.
Operational Efficiency
By working with detailed refusal data, PSPs and Acquirers can streamline operations by pinpointing areas that require attention. For example, if a significant number of transactions are declined due to invalid CVV codes, efforts can be made to improve the accuracy of CVV entry at the point of sale. This targeted approach reduces the incidence of declined transactions, thereby lowering the operational costs associated with handling these declines and subsequent customer inquiries. Furthermore, by reducing the number of unnecessary declines, PSPs/Acquirers can focus their resources on more critical operational tasks, enhancing overall efficiency.
Customer Experience
Clear communication of refusal reasons to customers can enhance transparency and trust. Customers are more likely to remain loyal When they understand why their transactions were declined and what steps they can take to resolve the issue. Providing accurate refusal reasons enables customer service teams to offer more effective support, addressing customer concerns promptly and accurately. This improved communication can lead to higher customer satisfaction, as customers feel informed and supported by their payment service provider.
Overall, a thorough understanding of refusal reasons empowers PSPs and Acquirers to make better decisions, operate more efficiently, and provide a superior customer experience.
The Disconnect in Refusal Mapping
However, there is often still a disconnect between the way issuers internally map refuses and what is externally communicated through refusal codes. Which makes understanding refusal reasons an even harder challenge.
When looking at the internal codes, it is relatively easy to understand the underlying issues, such as "110: Credit not available," which directly indicates that the client’s credit is exhausted. In contrast, external refusal codes are more generic and “designed” for easier communication with external parties.
For instance, the internal code "110: Credit not available" might be mapped to the external code "51: Insufficient funds," which simplifies the reason for the refusal but fails to convey the specific issue accurately.
This simplification often obscures the underlying problems that led to the refusal, making it difficult for external parties to address and resolve these issues effectively.
Another example, an internal code "204: Invalid CVV" might be translated to "N7: Decline for CVV2 failure," while another internal code "300: Expired card" might simply be communicated as "54: Card expired."
In each case, the detailed and precise internal codes are condensed into broader categories that do not capture the nuances of the refusal reasons.
Further, an internal code like "500: Suspected fraud" could be mapped to an external code such as "59: Suspected fraud," maintaining some specificity but often lacking the detailed context provided by the internal systems.
Similarly, an internal reason of "600: Account closed" could be generalized to an external code "05: Do not honor," which offers little insight into the actual problem.
This disconnect between the detailed internal codes and the generic external codes creates a significant gap in understanding and addressing the issues leading to transaction refusals. It makes it challenging for PSPs and Acquirers to take targeted actions based on refusal reasons because the generic external codes do not provide enough detail to identify the root causes effectively. This lack of detailed information can lead to repeated transaction declines for the same underlying reasons, causing frustration for both merchants and customers.
To bridge this gap, it is crucial for PSPs/Acquirers to delve deeper into the internal refusal reasons and seek more detailed information from issuers. By understanding the specific internal reasons behind transaction declines, PSPs/Acquirers can develop more effective strategies to address these issues, improve authorization rates, and enhance the overall customer experience.
Below is a Heatmap visualization showing the internal codes used by an issuer on the left and the actual external code shared with the acquirer on the bottom. The one thing that stands out is the number of codes mapped to “05 Do Not Honor.”
Steps to Map Refusal Reasons
Optimizing authorization rates requires a detailed understanding of refusal reasons and the ability to effectively map these reasons from internal systems to external communications.
Here’s a practical step-by-step approach to dealing with mapping refusal reasons, mind you we are reverse engineering the logic here:
Step 1: Learn and Document Internal Refusal Codes.
Begin by thoroughly understanding how your company processes incoming refusal codes used within your payment system. Refusal reasons originate from the issuer but are mapped to a generic response, which the scheme passes on to the acquirer, who, in turn, either maps it or passes on the raw response.
For example, a "110: Credit not available" could be mapped to "51: Insufficient funds," which could be a “Decline” in your PSPs transaction report. You can create a comprehensive reference guide by documenting these codes and their specific meanings.
Step 2: Analyze the Mapping to External Codes.
Examine how these received refusal codes from your acquirer have been translated into the refusal codes you have access to. This mapping could detail how the received raw response has been mapped in your organization. Do this by creating a mapping table showing each internal code and its corresponding external code.
Step 3: Identify Common External Refusal Codes.
Next, familiarize yourself with the most commonly received refusal codes. These are the codes that receiving parties typically see and need to understand. Common external refusal codes include "51: Insufficient funds," "N7: Decline for CVV2 failure," and "05: Do not honor." By knowing these codes and their meanings, you can better interpret the information received from external sources.
Step 4: Recognize and Address the Disconnect.
Acknowledge the gap between the detailed internal codes and the more generic external codes. This disconnect can lead to confusion and inefficiency because external parties often receive insufficient information to address specific issues. By recognizing this gap, you can take steps to mitigate its impact. This might involve providing additional context or clarification when communicating with external parties.
Step 5: Bridge the Gap with Effective Communication
Use your understanding of the internal-external mapping process to improve communication with issuers and acquirers. Ask the right questions to get detailed information about refusal reasons. For example, if you receive a generic refusal code like "51: Insufficient funds," inquire further to determine whether the issue is due to credit exhaustion, card limits, or another specific reason. By seeking detailed information, you can better address refusal reasons, develop targeted strategies to resolve issues, and ultimately improve transaction approval rates.
By following these steps, you can create a more effective process for understanding and mapping refusal reasons.
Below is a table of the external code most PSPs receive, mapped to the internal codes provided to me by an issuer.
Practical Implementation of Refusal Mapping
Now, let’s assume that you are looking to do the same in an effort to improve authorization rates. We began by leveraging the internal data available to us. In most cases, there will be one too many acquirers and or your own acquiring operations. Using the data from processed transactions, we can develop a comprehensive mapping framework that starts with generic refusal reasons. For some acquirers, you might have access to broader set of mappings than others, we can use those to categorize and match them to the internal refusal codes of issuers.
The raw acquirer refusal reason provided to acquirers often has the widest range of refusal codes, covering approximately 80% of all responses. By using this broad dataset, you will be able to map much more easily. However, if you don’t, you should contact your acquirer to request them. An additional method to better understand the refusal reasons is by initiating an issuer outreach program.
Issuer Outreach Program
An issuer outreach program involves engaging with several key and hopefully large issuers, including as many issuers as you have been processing transactions for. When I did issuer outreach, I conducted a series of structured interviews and worked on key issuers sharing their data and insights about transactions we processed. By collaborating closely with these issuers, we significantly enhanced our mapping accuracy to almost 100%.
Steps Taken During the Issuer Outreach Program:
Data Collection and Analysis: We began by collecting detailed refusal data from our acquirers and categorizing it based on our internal refusal codes. This initial step involved a thorough analysis of the raw data to identify common refusal patterns and their corresponding generic external codes.
Interviews with Issuers: We conducted in-depth interviews with key issuers to understand their refusal codes and the rationale behind specific transaction declines. These interviews provided valuable insights into the issuer’s decision-making processes and their specific criteria for refusing transactions.
Confidential Data Sharing: As part of our outreach program, we facilitated confidential data-sharing agreements with participating issuers. This allowed us to access detailed refusal data directly from the issuers, which was instrumental in refining our mapping framework.
Developing a Comprehensive Mapping Framework: With the insights gained from issuer interviews and the detailed data collected, we developed a comprehensive mapping framework that aligned internal refusal reasons with their corresponding external codes. This framework was designed to be adaptable, allowing us to incorporate additional data as it became available.
Validation and Continuous Improvement: Once our initial mapping framework was in place, we validated it through continuous testing and feedback from issuers. This iterative process ensured that our mappings remained accurate and up-to-date, reflecting any changes in issuer policies or refusal criteria.
Results and Impact
Implementing this detailed mapping framework significantly impacted the operations of the acquirer I worked for. By accurately mapping refusal reasons, we were able to:
Improve Authorization Rates: By better understanding the specific reasons behind transaction declines, we could implement targeted strategies to address these issues and reduce the number of declined transactions.
Enhance Customer Satisfaction: Clearer communication of refusal reasons to our customers helped build trust and improve overall customer experience.
Optimize Operational Efficiency: Streamlining our refusal mapping process allowed us to allocate resources more effectively and reduce the operational costs associated with handling declined transactions.
This comprehensive mapping of refusal reasons also paved the way for further improvements in our authorization processes. By analyzing the submitted authorization data (a topic for another time), we gained even deeper insights into transaction behaviors and refined our strategies further.
In conclusion, my experience with refusal reason mapping demonstrated the importance of leveraging internal data, collaborating with issuers, and continuously refining our processes. Efforts like this will significantly enhance your ability to understand and address transaction refusals, ultimately leading to better outcomes for our business and our customers.
Thank You for Reading. Feel free to Like, Comment, Share, or Post on Your Socials, as I appreciate all the feedback I can get.
P.S. Whenever you're ready, this is how I can help you:
1-on-1 Video Call with Dwayne Gefferie: If you want to solve your Payments challenge quickly, get direct answers based on 20 years of experience and continuous market research, develop a Strategy, validate your idea, or discuss a product feature. Book a 1-on-1 Video with me. [Limited Available Slots].
If you want to work with me in a larger capacity, either speaking, advisory, or consulting, feel free to email or DM me.
Disclaimer: The data used in these examples is several years old. I don’t currently have access to live transactional data or manuals, so mappings could have drastically expanded.