What is a Payment Gateway Error/Decline Code?

Код відхилення (або помилки) платіжного шлюзу являє собою стандартний тип відповіді від емітента картки або платіжного процесора під час транзакції, яку неможливо завершити. Ці коди надають пояснення щодо результату транзакції, наприклад, якщо термін дії картки закінчився, виникла пауза в обробці або існують певні вимоги, встановлені банком. Продавці переглядають ці коди, щоб краще зрозуміти результати платежів та вибрати свої подальші дії. У рамках послуг підписки ці коди допомагають скеровувати, як платіжні системи підходять до спроб платежів та повторних спроб.

Payment error codes represent a range of scenarios, so approaching each one the same way doesn’t provide the most suitable response.

A soft decline generally means the event is temporary, such as when an account doesn’t have available funds at the moment, the bank has temporarily held the payment, or the card issuer’s system requires another attempt. In many instances, resubmitting the transaction after some time may allow it to proceed.

Alternatively, a hard decline reflects a separate category – for instance, if an account has been updated, a card has reached expiration, or an issuer’s system sends a message to indicate a different handling is needed. For these types, further retries are generally not conducted, and the payment processor notes the decline result before moving on. 

Recognizing the category of each error code helps payment systems choose whether to schedule another attempt or, when appropriate, notify the customer to update their payment information.

For organizations working with recurring payments, renewal cycles regularly require analyzing decline codes. Involuntary churn can arise from payment outcomes, even in cases where there has been no direct cancellation. Looking at decline codes allows companies to assess whether another payment attempt or a payment information update request is appropriate as part of their billing process.

Decline codes also give information on fraud prevention and occasionally reveal patterns, like repeated declines with stolen cards. Reviewing the patterns of hard declines provides businesses with criteria for determining if further investigation of certain payment activities is needed.

Usage tips:

• Start by sorting each decline code into a soft or hard type to provide a better overview for логіки повторних спроб.
• Allow for some time between retries; trying платіжних методів again after a few days can present new outcomes compared to back-to-back attempts.
• Adjust the timing of retries in line with the customer’s likely payday or billing routines.
• Limit retries to a reasonable number, such as three or four, to stay consistent with issuer recommendations.
• Include clear customer communication with automated retries, suggesting a card update if needed.

Оновлювач рахунків послуги використовуються для обробки випадків, коли дані картки, що зберігаються у файлі, більше не є актуальними, що іноді може статися при спробі транзакції. Коли клієнту випускається нова картка (наприклад, після закінчення терміну дії, заміни або оновлення безпеки), інформація про стару картку видаляється з активного використання. У таких випадках інструменти Account Updater налаштовані для зв'язку з картковими брендами, такими як Visa та Mastercard, і надають оновлення збереженої інформації облікового запису, причому цей процес зазвичай відбувається незалежно від участі клієнта.

Карткові мережі such as Visa and Mastercard publish rules for how often a merchant can retry declined payments. Repeated attempts beyond these suggested thresholds, including with hard declines, can lead the networks to review activity or adjust standard charges. Following these rules when planning retries for soft declines is a way for businesses to stay within general industry practices. This is why SaaS companies choose a Merchant of Record to help manage retry approaches so that they reflect updated requirements.

Reviewing a few considerations can be useful before making any adjustments to your approach:

• Are you able to identify what share of your failed payments are soft compared to hard declines?
• Is it possible to locate and measure involuntary churn within your revenue data?
• Do you vary your retry process based on decline type, or follow the same pattern for each attempt?

Фактори прийняття рішень:

• How many transactions occur, and the share of involuntary churn in the context of your results
• The way your payment setup organizes decline information, and if different decline types are distinguished
• Whether automated card updater services are accessible for your business
• The current level of in-house engineering capacity available to set up or update retry logic
• Regulatory and card scheme obligations and limits that apply to your business activities