How to Reduce Payment Failures Without Changing Your PSP Stack

Lower payment failures and stronger authorization rates usually come from tuning the fraud and authentication logic under your current checkout vendor, not from switching payment service providers. The main causes of payment failures are usually in that same fraud system - they can be corrected to increase your authorisation rates without having to change your PSP at all.

What Counts as a Payment Failure?

Any failure in which a customer's payment attempt does not lead to a successful authorisation is considered a payment failure. Payments that fail due to declined transactions, timeouts, or other failures during authentication are all considered payment failures. Payments that fail after they have been authorised are not considered payment failures.

Within payment failures, there are two different types of declines: hard and soft declines.

Treating both types of declines as if they are the same thing is one of the most common reasons for payment authorisation rates to be too low for a business.

Measuring the Authorisation Rate Before Changing a PSP

The authorisation rate for a payment processing vendor is the percentage of payments that were authorised compared to the total number of payments attempted. This is the single most important rate to track for any payment processing vendor before attempting to make any changes to the vendor's settings or functions. Any fixes to the vendor's settings that are described in the remainder of this article should provide some increase to the authorisation rate. If the authorisation rate does not increase with the described change, then the change was not worth making.

The authorisation rate alone is not the figure that best explains why an authorisation rate may be too low. Three other metrics are used to provide context for the authorisation rate.

A team that does not track these three additional metrics will not become familiar with the reasons for their low authorisation rates and will thus not be able to find the fixes for those issues.

The Most Common Causes of Payment Failures

Payments can fail due to four main causes. Each of these causes has a specific solution for increasing the number of authorised payments.

Issuer Declines

Issuer declines are declines that occur at the bank of the customer who attempted to complete the payment. Payments that decline due to insufficient funds, expired cards, or are declined by the bank during an initial authorisation are considered issuer declines. These declines cannot be fixed by the payment vendor, but the failure of those declines to be authorised during the first attempt may allow for those declined transactions to be authorised during a second attempt.

Fraud Declines

Fraud declines are cases in which a transaction is declined by the payment vendor's anti-fraud systems. These declines are applied to transactions to prevent fraud by the customer, but the transaction is genuine. For instance, vendors may apply these rules to high-value purchases or to customers making a cross-border purchase or buying for the first time, since those patterns look unfamiliar even when the transaction is legitimate. These declines can be fixed by adjusting the payment vendor's fraud rules settings.

Authentication Failures

Authentication failures are declines that occur when a customer fails to complete authentication requirements for the transaction. For instance, if the customer is required to enter a password or security code, but they do not successfully enter that information, the transaction will be declined. Not every transaction requires authentication, but requiring authentication for low-risk transactions can cause failures. These declines can be handled by the vendor without touching their anti-fraud systems.

Technical Declines

Technical declines are declines that occur before the vendor's payments are sent to the bank for authorisation. For instance, if the vendor's servers time out while attempting to communicate with the customer's bank, or if the transaction is sent to the wrong acquiring vendor, those declined payments can occur. These errors are generally outside the vendor and their anti-fraud systems, but the causes can be recognised by the vendor alone.

Highest-Impact Tactics to Reduce Payment Failures

There are five different tactics for reducing payment failures, but not all of them have the same impact on reducing those failures.

Tune Fraud Rules Instead of Loosening Them Blindly

Payment fraud rules should apply individually to each transaction rather than being applied as a blanket threshold for all transactions. Each transaction can be evaluated individually for characteristics that indicate fraudulent activity (or not) to allow the system to reject fraudulent transactions while allowing legitimate customers to successfully perform their purchase.

Instead of loosening the fraud rules applied to all transactions, the rules should be tuned to ensure that they do not reject legitimate transactions. By ensuring that each transaction is scored individually by the fraud rules system, it is possible to recover the approval rate for all transactions without creating a new path for fraudulent transactions.

Apply SCA Exemptions Where They're Legitimately Available

Strong Customer Authentication rules can be applied to transactions to exempt low-risk transactions from having to authenticate at all. An SCA exemption works through the checkout's 3D Secure v2 flow, the authentication protocol that decides whether a transaction needs a challenge step, so applying the exemption correctly means the challenge is skipped rather than failed. Many transactions will fall into the low-value threshold exemptions for SCA, meaning that they do not create any additional fraud risk for the company while reducing the likelihood that customers will abandon their carts due to authentication requirements.

Using an SCA threshold for transactions that indicates the risk of the transaction will allow for a reduction in abandoned shopping carts due to authentication.

Use Smart Retry Logic on Soft Declines

When transactions are rejected with a soft decline, it is possible to initiate a retry; however, blindly retrying those transactions will waste the opportunity to approve those transactions. Smart retry logic that matches a retry attempt to its specific reason code, rather than retrying on a fixed schedule, is what actually recovers the revenue from those transactions.

Additionally, there should be a cap on the number of times that each transaction can be attempted; retrying a transaction too many times within a short period may trigger a soft decline as a hard decline due to fraud detection created by the bank that initiated the soft decline.

Improve Data Quality at the Point of Authorisation

Improving the quality of the data submitted with each transaction will allow the bank that processes the transaction to more easily recognise the legitimacy of the transaction and authorise it. This fix does not require any changes to the logic or rules for the transaction; only improving the data quality will reduce the number of declined transactions.

Route Through the Right Acquirer Relationship

Banks and payment processors do not all approve the same percentage of transactions; they may have different relationships with acquiring companies. By directing transactions based on BIN (Beginning of Identification Number) values, a technique known as BIN routing, it is possible to route them through the acquirer relationship that is the most likely to approve the transaction. Importantly, this adjustment does not impact the current PSP or checkout system used by the merchant or customer.

Why This Doesn't Require Ripping Out Your PSP Stack

None of these fixes touches the payment service provider that is currently integrated into your checkout system by the customer. Each of these improvements operates at what is often called the payment orchestration layer, the routing and authorization logic that sits underneath the PSP and coordinates fraud rules, retry logic, and acquirer routing without touching the checkout integration itself. Companies like DECTA implement their own rule-based systems for fraud detection, 3D Secure authentication, and authorisation switching without impacting the merchant's current payment setup.

None of these suggestions requires the implementation of a new checkout system; they simply require adjusting the rules that control your current payment system.

Monitoring Progress After Implementing Changes

After implementing any of these suggested changes, monitoring the outcome of the change requires monitoring three different indicators of your current payment system.