Optimizing Your Retry Strategy

It’s not fun, but it’s true: transaction declines are an inevitability for any business accepting payments. It doesn’t matter how big of an operation you’re running, you’re going to see transactions fail for a variety of reasons, some of which are addressable. Maybe a customer doesn’t have enough money in their account to cover the transaction amount, or they entered their card details incorrectly; declines can even occur when processors, card brands, or issuing banks experience outages or when you send the wrong data with a transaction. Regardless, a decline tells you that someone wanted to patronize your business and they couldn’t.

While this situation is inevitable, the story doesn’t have to end there, because there’s another fundamental truth in payments: not all declines are equal or final. Depending on the reason behind a decline, you may want to try the transaction again in hopes that subsequent attempts result in a success—and money in your pocket. In an analysis of the billions of transaction events ingested into Pagos, the first retry attempt of a declined transaction has an average approval rate of 25-35%. That number tells us that by not retrying failed transactions, you’re absolutely leaving money on the table and disappointing customers who presumably still want your product or service!

The approach you take to choosing which transactions to retry, when, and how many times is known as your retry strategy. While retry strategies are especially important for recurring and subscription business models, every business can benefit from giving certain declined transactions another try. In this post, we’ll explore how you can use your payments data to analyze and improve your retry strategy and get one step closer to achieving payments optimization.

Tracking Retries

Before you can thoroughly assess your retry strategy, you need to diligently track your transaction retries and create a baseline. One way to do this is by tagging retry attempts with metadata. Metadata are custom labels added to transactions—typically in collaboration with your payment processor—for the purpose of segmenting data into identifiable groups. Some processors will do this for you (more on this later), but more often it’s on you to design a metadata strategy for tagging retries.

To properly use metadata, you’ll establish both a metadata field and an associated set of metadata values with your processor. For example, you could create a metadata field called retry_attempt with associated metadata values to identify the type of retry your transaction is (initial_attempt, first_retry, second_retry, etc.). Learn more about metadata in our Pagos Product Documentation.

Establishing a Baseline

If you subscribe to Peacock by Pagos, our payments aggregation and visualization tool, we’ll ingest all your payments data and present it back to you in a series of dashboards. Within this powerful tool, you can then filter any dashboard by your custom metadata to see trends in approvals, declines, refunds, and chargebacks for each individual retry attempt. For example, you can filter the Processors dashboard to only show transactions tagged with the metadata value of first_retry and immediately see your approval rate by processor for these transaction retries. Similarly, if you filter the Declines dashboard to only show first or second retry attempts, you can see the total number of retries that were ultimately declined, broken down by the assigned decline code. 

Using this data, you can quickly establish a baseline of your retry volume, such as:

• Approval rates for initial transactions and each individual retry attempt, broken down by processor, payment method type, card brand, and more

• Decline reason codes for all initial transactions and retry attempts that ultimately fail

• Volume of transactions tagged with each retry attempt metadata value (i.e. number and combined value of transactions tagged as initial, first retry, second retry, etc.)

Peacock also includes a feature known as custom dashboards. Within a single custom dashboard, you can add the same data visualization multiple times, and filter each to show a different segment of data. Say your current retry strategy involves retrying every declined transaction two times; you could build out a custom dashboard containing three approval rate charts, each filtered to show the data for initial transactions, first retries, and second retries respectively. Suddenly you have a single place to look to understand the success rates of each attempt side by side. With this dashboard alone, you can quickly analyze the effectiveness of your current strategy. You can even find answers to questions such as does time of day or day in the month impact your success rate—all the way down to an issuer level!

Analyzing your retry data can also help you identify where you’re wasting time and money retrying transactions that will never be successful. When drilling down into the details of your initial declines you can identify patterns in certain declines that have a very low retry success rate and adjust your retry logic accordingly. For example, you may see that initial transactions made cards from a particular issuing bank are always declined due to insufficient funds; these transactions have a low likelihood of success, no matter how many times you retry them. If you see these types of transactions in your data, you may want to exclude them from your retry strategy.

What Do I Do Next?

If you’re tracking your retries and looking at the data, you may find yourself thinking: can someone just tell me what to do? That’s a completely fair response, especially if you’re new to transaction data deep dives. How are you supposed to know what transactions to retry? How do you determine the number of times to keep retrying a transaction before you give up?

Decline Code Guidance 

The primary place to look for guidance when assessing and restructuring your retry strategy is the decline codes assigned to both initial transaction declines and subsequent retry attempts. Some types of declines are categorized as “hard declines,” meaning there’s a very good reason they didn't go through, and all future retries of the same transaction with the same payment method will similarly fail. These include declines like account_closed, pick_up_card_fraud, and invalid_account_no_number. Creating retry rules that automatically rule out such declines from being retried will save your business the money you’d otherwise spend re-attempting transactions that are bound to keep failing.

Guidance in Your Own Data

If you subscribe to Puffin, our payments data streaming service, you can download your own transaction-level data from any chart in Peacock or stream directly to your data lake. In this data, you’ll see every transaction used to generate the associated visualization in Peacock, and the full details surrounding each individual transaction. If you download the Puffin data from a declines chart, you’ll also see additional details around the decline that can guide your retry strategy. Examples include:

• Processor Response Text: When we ingest your decline code data from your payment processors, we normalize that data so you can see declines from each processor aggregated into a single feed. While this is extremely helpful for viewing and analyzing your collective payments data, the actual response values sent by each individual processor are important to have when initiating conversations with the processors themselves. You can also see this breakdown in the Raw Decline Code Count by Processor sub-chart under the Processor Decline Codes chart in Peacock. Take these raw responses to your declined retries to the relevant processor and ask them for retry behavior guidance.

• Additional Response: Sometimes the processor will pass additional details or guidance from the card brand on what to do with certain types of decline. Mastercard, for example, passes retry guidance as specific as “Retry in 1 hour” or “Retry in 6 days”. Whenever this level of detail is passed with a transaction and ingested into Pagos, we will include it in the Additional_Response column of the transaction-level data download available through Puffin.

Processor Guidance

It’s always worth your time to reach out to your processors directly to learn more about their own retry logic—if they have one. Depending on the processor, they may already have a retry strategy in place for your business that you can work with them to adjust as needed. Additionally, some processors already tag retries with their own system independent of your metadata; knowing their tagging structure can help you segment out these processor-initiated retries in your payments data analysis.

At the very least, most processors employ a basic logic to retry transactions at a later time in the event of system errors or outages, but they may be doing more. For example, Adyen has an excessive retry prevention service that immediately blocks any transaction retry attempts that are considered excessive and likely to incur a penalty fee. Adyen also retries some transactions repeatedly according to their own internal logic; learn more in the Pagos Product Documentation about how you can track those retry attempts in Peacock.

While your processor can give you some generic retry guidance, always remember that it’s ultimately up to you to decide how your business handles retries. It’s valuable to keep on top of any changes your processors make so you can hold them accountable for maintaining whatever retry strategy you’ve customized for your own business.

Optimizing Payments with Strategic Retries

Optimizing your retry strategy is crucial for maximizing revenue and minimizing unnecessary transaction retry declines. Leveraging data insights and visualization tools such as Peacock and Puffin enables you to establish a comprehensive baseline of retry volume and approval rates, identify decline code patterns for each type of retry, and ultimately adapt your retry logic over time. With guidance from decline code data and your processors, you can refine your strategy further by identifying which transactions to even attempt to retry and when. A well-informed and adaptive retry strategy not only improves transaction success rates but also contributes to the financial health and operational efficiency of your business, allowing you to navigate declines confidently and optimize revenue generation opportunities.