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

When you think about the time spent, the effort and the investment required to improve every point of your conversion rate and close a sale, making a payment error is a failure that is difficult to take in.
This failure rate is not an anecdote. It represents a significant shortfall.
The good news? It can be reduced.
A large part of errors is treated as a fatality by e-retailers, payment being often considered as a black box whose control is solely the responsibility of the PSP (Payment Service Provider), while an analytical and tooled approach makes it possible to recover a significant fraction of them.
‍
At Purse, we are working to reduce this rate a performance lever and a strategic challenge. A dedicated technical team analyzes payment errors every day to better understand them, categorize them, and identify solutions to reduce their impact in a process of continuous improvement, at the service of our customers.
To better understand these mechanisms, we interviewed our internal teams. This article offers you a complete decryption:

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

“Each error code is a weak signal that can be transformed into an opportunity for optimization. Our role is to interpret these signals, to anticipate incidents and to make payment processes reliable, regardless of the PSP.”

— Jean Laperre, Product Owner at Purse.

Decryption.

‍

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

There are many factors that can explain a payment error. Globally, they are divided into three main origins:

• Carrying side : the buyer takes too long to finalize the transaction, fails 3DS authentication, hits a ceiling, or misenters their card information.
• PSP side : the merchant's payment service provider (unavailability between the PSP and the acquiring bank, technical error, poor data formatting, etc.).
• Bank side : this may come from the cardholder's bank (strong authentication failure) or from the acquiring bank (, too long response time, unreachable servers...).

At Purse, we receive detailed feedback codes from PSPs that allow us to categorize errors.
We mainly work and analyze payment errors from PSPs, on which we have the most power to act. That is the main topic of this article. ‍

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

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

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

• Technical errors (type “error 500") : The PSP returns a system error.

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

• PSP-specific return codes : the partner returns an error message specific to their system.

These may be personalized messages (excluding HTTP standards) that indicate a technical rejection, a module under maintenance or any other incident known to the PSP.
💡 Good to know: our developers are constantly analyzing these return codes to automatically deduce partner behavior and classify errors accurately. As our solution is multi-PSP, we enrich this work on a daily basis.

‍

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

What Purse does in a way that is completely transparent to the merchant

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

Our role:

• Detect technical errors reported by PSPs.
• Interpret Finely the return codes to identify the root causes.
• Correct automatically or manually the errors that we can act on.

The objective: maximizing the chances of success of each transaction, without merchant intervention, and thus improve the acceptance rate global.

Two types of intervention:

• Automatic : when a type of error is recognized (e.g. timeout or error 500), our system can automatically replay the transaction according to predefined scenarios (retry or fallback).
• Manuelle : in the event of a complex or recurring anomaly, our technical team intervenes manually after analysis:
  
  • Or directly with the PSP concerned.
  • Or in contact with the merchant to adjust the parameters or configurations.

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

Smart Retry

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

• On the same PSP a few minutes or a few hours later: in the case of discounts, cancellations and refunds that do not require a response in real time. In this case the transaction goes through several technical statuses: “capture waiting”, “capture pending”, then ideally “success”.
  
  
• Or by fallback, that is to say by sending the transaction back to a other PSP set up by the merchant. This solution is applicable for authorization requests in real time, in the case where 3DS authentication has been managed by an external service provider, agnostic to the PSP.

Monitoring and classification

At Purse, we have real-time production monitoring tables that we follow on a daily basis to detect operating anomalies and identify the level of criticality of a possible incident. This allows us, for example, to take preventive or corrective measures quickly and/or to inform our customers and partners.

In asynchronous mode, we study the dashboards to see if the same type of error occurs again over a given period of time. If this is the case, our team takes charge of the subject:

• We do our analysis of the payment error situation according to our statistics.
• We hypothesize.
• We contact the service provider to work with them on improvement solutions.
• Depending on the situation, the solution is implemented by the service provider, or jointly with Purse.
• We are closely monitoring post-implementation statistics to measure the drop in the error rate and the impact on the acceptance rate.

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

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

What can a merchant do to improve their acceptance rate

While Purse takes care of much of the optimization, some best practices merchant side allow boost performance even more.

On the client side

Offer a second payment attempt to the customer: ensure that in the event of a payment failure linked to the cardholder's bank, the payment process makes it possible to propose a new attempt to pay with the same card, another card or another payment method depending on the payment context. Attention, it is essential to put a limit on the number of attempts to avoid fraud.

PSP side

Ensure that each PSP is set up correctly.
Verify the correct configuration of API keys, the configuration of return URLs and the management of notifications. Set up fault alerts if possible.

Analyzing chess returns

Mistakes are generally considered to be “rejections.” It is essential to have a detailed reading of error codes, andisolate technical errors from user or fraud errors.

Adopting a multi-channel and multi-PSP approach

Having a fallback plan or a multi-PSP strategy allows you to do not depend on a single provider, and to adapt its routing according to the performances observed. Beyond a certain volume of online transactions, it is essential to have several payment providers.

Conclusion: technique, a direct driver of performance

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

Each failure avoided, each transaction replayed, it is Recovered turnover. We are committed to supporting our customers in placing the technology at the service of business performance, and demonstrate that optimizing payments also involves better management of hidden details.

Do you want to audit your payment errors with us?

‍