Soft vs. Hard Payment Declines: Retry, Recover or Ask the Customer

Use the code to decide what happens next#

A customer’s payment fails at checkout. Calling it soft or hard is useful only if the label leads to the right action. Authentication required, a mistyped CVC and a reported-lost card are all refusals, but they do not share one recovery path.

In common operational use, soft suggests a potentially recoverable refusal and hard suggests that retrying the same conditions will not help. Providers can use these terms differently. Keep the raw response code, payment state and any advice code, and map them under the selected product’s documentation instead of letting the label itself authorize a retry.

This guide concerns inbound collections from customers. Bank rejection of an outbound seller or contractor payout is a separate workflow with its own codes, funding and beneficiary evidence.

Separate confirmed refusal from unknown execution#

An HTTP error is not enough to establish a declined card. Stripe’s advanced error guidance warns that a server error can have side effects. Treat the result as unresolved until the original request, resource or reconciliation evidence establishes what happened.

A code-specific example using Stripe#

These actions are scoped to Stripe’s card decline codes, checked October 3, 2026. They do not define bank-payout recovery or every alternative payment method. Where advice codes or network restrictions provide a more specific instruction, apply that instruction to the actual account and product.

Distinguish replay from a new authorization#

A transport replay repeats the same supported request to recover its result. A new authorization asks the payment system to attempt collection again. The business invoice can stay the same, but the financial attempt is different. Keep both IDs so support can see whether it is recovering an existing result or trying another collection.

For a supported network-error replay, keep the original provider key and parameters. If you change payment details after a confirmed refusal, follow the resource’s update/reconfirmation rules and record the new attempt. Do not change a still-unknown request or create a fresh key solely to escape a cached response.

Stripe’s PaymentIntent guidance recommends reusing the intent when a checkout resumes. Treat the intent’s current state as the starting point for recovery. A page refresh should retrieve the existing payment, not create another independent collection for the same purchase.

Work through a missing response#

Suppose an invoice is for 120 and the collection call times out. The invoice remains unpaid locally, but that does not establish an issuer refusal. The service records the attempt as outcome unknown and recovers the original resource using supported lookup or same-request replay.

If the original succeeded, attach that result to the invoice and stop replacement collection. If it is conclusively refused, apply its code-specific next step and permit a new attempt only under the applicable rules. If it remains unresolved, show the customer a payment-being-checked state rather than a button that blindly starts another charge. These are illustrative design choices, not a promise that every provider exposes identical recovery APIs.

Put retry policy beside the payment product#

Define which codes permit an automated new attempt, its timing and applicable maximums from the provider/network rules for that flow. Separate one-time checkout from recurring off-session billing. The customer’s consent and a valid mandate do not override a do-not-retry instruction or permit repeated attempts without the required authentication.

Use backoff for transient transport failures under the same-request contract. Use a billing recovery schedule for genuinely failed recurring collections where permitted. Do not copy a transport retry count into an issuer reauthorization schedule, or invent a global rule that insufficient funds always allows exactly one retry.

An alternative provider should not bypass a blocked card, risk decision or network restriction. Before a new route, establish the original outcome and the rules that permit a new attempt. A shared platform operation ID helps control business duplication; provider keys do not protect across providers.

Make events update the same payment history#

Authenticate incoming events, commit durable intake, then acknowledge before complex downstream work. Process the local financial effect and its marker atomically. Separate event IDs may refer to the same successful collection, so also guard the invoice’s remaining amount and business effect.

Check out-of-order events against the current resource and permitted transitions. A late failure message for an earlier attempt must not overwrite a later success. Preserve the attempt history so the customer’s next action is based on the current payment state.

Give the customer a useful next action#

Measure recovery without rewarding retry volume#

Track eventual paid invoices, customer actions completed, unnecessary reattempts, unresolved-outcome age and duplicate-collection incidents. Keep provider code, attempt count and product scope in the analysis. More successful HTTP responses or more attempts do not by themselves establish better collection recovery.

The practical goal is a controlled next step for each result. Use the issuer/provider’s instructions for a confirmed refusal and the original operation’s evidence for uncertainty. That distinction keeps checkout useful while preventing a retry loop from turning into duplicate money movement.