What is a Payment Gateway Error/Decline Code?

Um código de recusa (ou erro) de gateway de pagamento representa um tipo padrão de resposta de um emissor de cartão ou processador de pagamento durante uma transação que não pode ser concluída. Esses códigos oferecem uma explicação para o resultado de uma transação, como se um cartão expirou, ocorre uma pausa no processamento, ou existem certos requisitos definidos pelo banco. Os comerciantes analisam esses códigos para entender melhor os resultados dos pagamentos e decidir seus próximos passos. Em serviços de assinatura, esses códigos ajudam a guiar como os sistemas de cobrança abordam as tentativas de pagamento e as novas tentativas.

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 da lógica de retentativa.
• Allow for some time between retries; trying métodos de pagamento 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.

Atualizador de Contas Os serviços são utilizados para lidar com situações em que os dados do cartão armazenados em arquivo não estão mais atualizados, o que às vezes pode ocorrer com transações tentadas. Quando um novo cartão é emitido para um cliente (por exemplo, após uma expiração, substituição ou atualização de segurança), as informações do cartão antigo são removidas do uso ativo. Nestes casos, as ferramentas de Account Updater são configuradas para se comunicar com bandeiras de cartão como Visa e Mastercard e fornecer atualizações para informações de conta salvas, e este processo geralmente opera independentemente do envolvimento do cliente.

Redes de cartões 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?

Fatores de decisão:

• 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