Reducing payment failures: the hidden (and technical) side of your growth

Up to 10% of payments fail in e-commerce.
Did you know?

When you consider the time spent, the effort invested, and the resources required to improve every point of your conversion rate and close a sale, ending up with a payment error is a tough pill to swallow.
This failure rate is not insignificant. It represents a major loss of revenue.
The good news? It can be reduced.
Many e-commerce merchants treat these errors as inevitable, often viewing payment as a black box controlled solely by the PSP (Payment Service Provider), when in fact an analytical, tool-driven approach can recover a significant portion of them. 
‍
At Purse, we turn the reduction of this rate into a performance driver and a strategic priority. A dedicated technical team analyzes payment errors every day to better understand and categorize them, identifying solutions to reduce their impact through a process of continuous improvement, for the benefit of our clients.   
To better understand these mechanisms, we interviewed our internal teams. This article provides a comprehensive breakdown of:

• the most frequent types of PSP-side errors,
• the solutions we implement,
• and the best practices to adopt to maximize your acceptance rate.

"Every error code is a weak signal that can be turned into an optimization opportunity. Our role is to interpret these signals, anticipate incidents, and make payment journeys more reliable, regardless of the PSP.."

— Jean Laperre, Product Owner at Purse.

A closer look. 

What are the main types of payment errors in e-commerce?  

Many factors can explain a payment error. Overall, they fall into three main categories:

• Cardholder-side : the buyer takes too long to complete the transaction, fails 3DS authentication, hits a spending limit, or enters their card details incorrectly.
• PSP-side : the merchant's payment service provider (unavailability between the PSP and the acquiring bank, technical error, incorrect data formatting, etc.). 
• Bank-side : this can stem from the cardholder's bank (failed strong authentication) or the acquiring bank (excessive response time, unreachable servers, etc.).

At Purse, we receive detailed return codes from PSPs that allow us to categorize errors. 
We primarily work on and analyze payment errors originating from PSPs, as these are where we have the most leverage. This is the main focus of this article. ‍

‍
We have structured the errors originating from PSPs into three main families:

• TimeOut: the payment PSP does not respond in time. 

As a result, the transaction remains unanswered due to a lack of availability or responsiveness from the PSP. This generates an error status of type timeout, which is synonymous with abandonment for the user. 

• Technical errors (e.g., “500 error”) : the PSP returns a system error. 

These are the classic HTTP 500, 502, 503codes, which signal a temporary unavailability of the PSP's servers or applications (maintenance, overload, technical failure, etc.). 

• PSP-specific return codes : the partner sends back an error message specific to its system. 

These can be custom messages (outside of HTTP standards) that indicate a technical rejection, a module under maintenance, or any other incident known to the PSP.
💡 Good to know: our developers continuously analyze these return codes to automatically deduce partner behavior and accurately classify errors. Since our solution is multi-PSP, we enhance this work on a daily basis. 

Action plan: how to optimize payment errors and improve your acceptance rate

What Purse does completely transparently for the merchant

As a payment orchestrator, Purse acts as an intelligence layer between the merchant and their PSPs (payment service providers).

Our role:

• Detect technical errors reported by PSPs.
• Interpret return codes in detail to identify root causes.
• Correct errors we can act on, either automatically or manually.

The goal: maximize the success rate of every transaction, without merchant intervention, thereby improving the overall acceptance rate .

Two types of intervention:

• Automatic : when an error type is recognized (e.g., timeout or 500 error), our system can automatically retry the transaction based on predefined scenarios (retry or fallback).
• Manual : in the event of a complex or recurring anomaly, our technical team intervenes manually after analysis:
  
  • Either directly with the relevant PSP.
  • Or in coordination with the merchant to adjust settings or configurations.

In both cases, the merchant stays focused on their business, while we manage the robustness and performance of their payment infrastructure.

Smart retry

When a temporary error is detected (timeout, 500 code, etc.), the orchestrator can automatically retry the transaction if the error type allows it:  

• On the same PSP a few minutes or hours later: for settlements, cancellations, and refunds that do not require a real-time response. In this case, the transaction goes through several technical statuses: “capture waiting,” “capture pending,” and ideally, “success.” 
  
  
• Or via fallback, by routing the transaction to another PSP configured by the merchant. This solution is applicable for real-time authorization requests, provided that 3DS authentication was handled by an external, PSP-agnostic provider.  

Monitoring and classification 

At Purse, we use real-time production monitoring dashboards that we track daily to detect operational anomalies and identify the criticality level of any incident. This allows us, for example, to take preventive or corrective measures quickly and/or inform our clients and partners.

Asynchronously, we study the dashboards to see if the same type of error recurs over a given period. If so, our team takes charge: 

• We analyze the payment error situation based on our statistics. 
• We form hypotheses. 
• We contact the provider to work with them on improvement solutions. 
• Depending on the situation, the solution is implemented by the provider or jointly with Purse.
• We closely monitor post-implementation statistics to measure the reduction in the error rate and the impact on the acceptance rate.

Purse developers work in a closed loop with the product and data teams. Every technical fix (code, config, latency) is correlated with a business impact measured: number of recovered payments, improvement in acceptance rate, contribution to revenue.

This is how every bug fixed can become a recovered conversion point.

What merchants can do to improve their acceptance rate

Even though Purse handles a large part of the optimization, certain best practices on the merchant side help to boost performance even further.

On the customer side

Offer the customer a second payment attempt: ensure that in the event of a payment failure related to the cardholder's bank, the payment flow allows for a retry using the same card, a different card, or another payment method depending on the context. Note: it is essential to set a limit on the number of attempts to prevent fraud.   

On the PSP side

Ensure that each PSP is properly configured.
Verify the correct setup of API keys, return URL configuration, and notification management. Set up alerts for failures if possible.

Analyze failure feedback

Errors are generally viewed as "declines." It is essential to have a detailed reading of error codes, and toisolate technical errors from those related to the user or fraud. 

Adopt a multi-channel and multi-PSP approach

Having a fallback plan or a multi-PSP strategy allows you to avoid relying on a single provider, and to adapt your routing based on observed performance. Beyond a certain volume of online transactions, it is essential to have multiple payment providers. 

Conclusion: technology as a direct driver of performance 

Managing technical PSP errors should no longer be a blind spot in payment strategies. With a structured, data-driven approach supported by intelligent orchestration, it is possible to significantly improve your acceptance rate.

Every failure avoided and every transaction retried means recovered revenue. We are committed to helping our clients put technology at the service of business performance, and demonstrating that payment optimization also requires better management of the hidden details. 

Would you like to audit your payment errors with us?