What to tell a customer after a decline: safe messages and next steps

A decline is the moment a customer who wanted to pay finds out they cannot. What happens next depends on one short message. Baymard Institute says payment errors have a low recovery rate in testing, and 10% of US shoppers in its abandonment data, excluding those just browsing, said they left because their card was declined. A clearer message gives some of them a way to finish.

This article covers what to tell the customer: which details are safe to show, why fraud reasons stay hidden, what each message should say, and how to offer a way forward. It deals with the words on the screen. Which codes to retry is covered in soft and hard declines, and how to spot wrong declines in what false declines cost.

What should you tell a customer after a declined payment?

Three things: the payment did not go through, what they can do now, and that another way to pay is available. Most customers do not need the reason. They need a next step.

The rule that resolves most wording questions is to describe the action, not the cause. “Please use another card or payment method” is useful and safe. “Your card has been flagged” is neither. The provider’s reason belongs in your logs and your support tools, not on the checkout page.

Stripe’s documentation makes the split clear, because it gives a next step for every decline code. Many are one of four actions: try again with corrected details, try again, contact the card issuer, or use another payment method. Your messages can follow the same four paths.

Which decline details are safe to show?

Fewer than your provider sends you. The clearest guidance on wording comes from providers.

• Adyen says on its refusal reasons page that, to prevent malicious use, you should “not expose the details of the refusal reason to shoppers”. The instruction covers all refusal reasons, not only fraud ones.
• Stripe says not to report more detail for fraudulent, stolen_card and merchant_blacklist declines, and to present them in the same way as a generic decline. It says the same of lost_card.
• PayPal’s Braintree says merchants typically show a relatively generic message when a payment method is declined, to help mitigate fraud.

Visa’s Dispute Management Guide for Merchants, updated in October 2026, covers the merchant’s duty rather than the wording: never complete a transaction after a decline, and ask for a different form of payment. We found no public Visa rule on what the message must say. Check your scheme rules with your acquirer, and read your provider agreements, which may set their own terms.

The reason for caution is practical. Someone testing stolen cards learns from every response. A message that separates “reported stolen” from “not enough funds” tells them which cards are live and which are burned. Honest customers lose nothing, since the card issuer can tell them more. Stripe notes that, for privacy and security reasons, issuers discuss the specifics of a decline only with their cardholders.

There is also a fairness reason. Some fraud declines are wrong. Telling a genuine customer that their payment looked fraudulent accuses them of something they did not do, and it does not help them pay.

Accessibility guidance reaches a similar balance. WCAG 2.2 success criterion 3.3.3 says that when an input error is detected and a correction is known, the suggestion should be given, unless it would jeopardise security or the purpose of the content.

Why do generic messages still lose customers?

Because “generic” can mean “useless”. Hiding the reason is right. Hiding the next step is not.

Baymard reports that 98% of benchmarked sites use generic error messaging, and that unclear card decline messages were a common problem on EU sites. One participant said a decline message could have meant almost anything. Another, at a UK retailer, read a vague card error as a funds problem when the real issue was a small typing mistake. When people cannot tell what went wrong, they change things that were correct, or they leave.

So there are two kinds of generic. A bad one is “An error occurred.” A good one is “Your bank did not approve this payment. Contact your bank or choose another payment method.” Neither reveals the reason. Only the second tells the customer what to do.

The specific wording belongs earlier, where it is safe. Errors your own form catches before anything is sent, such as a short card number or an expiry date in the past, come from what the customer typed. Naming that field reveals nothing an issuer said. Our guide to checkout form design covers these messages.

What should each decline message say?

The table groups common declines by what the customer can do. Codes are Stripe’s names, and your provider’s will differ. The wording is our suggestion, so test it and translate it.

Decline type	Example codes	Show	Suggested wording
Typing error caught by your form	None: nothing was sent	Name the field	“Your card number is incomplete.”
Details rejected by the issuer	incorrect_cvc, incorrect_number, expired_card	Ask for a check, name no field	“Those card details did not work. Check them and try again, or use another card.”
Funds or limits	insufficient_funds, card_velocity_exceeded	Offer another way to pay	“This card could not be used for this payment. Try another card or payment method.”
Authentication needed	authentication_required	Explain the step	“Your bank needs you to confirm this payment. Try again and approve it when asked.”
Temporary problem	issuer_not_available, processing_error	Invite a retry	“We could not complete this just now. Please try again in a moment.”
Card not usable here	card_not_supported, currency_not_supported	Offer another way to pay	“This card cannot be used for this purchase. Please choose another payment method.”
Unknown reason	generic_decline, do_not_honor, call_issuer	Bank or another method	“Your bank did not approve this payment. Contact your bank or choose another payment method.”
Fraud, lost, stolen, blocklist	fraudulent, lost_card, stolen_card, merchant_blacklist	Identical to unknown reason	“Your bank did not approve this payment. Contact your bank or choose another payment method.”

The last two rows must match exactly. Same words, same layout, same timing. If a fraud decline looks different, the difference is itself a signal. The same goes for payments blocked by your own rules, which never reach the issuer: Stripe groups Radar blocks under generic_decline.

The second row is a judgement call, and it is where the sources pull apart. Stripe’s next step for incorrect_cvc is that the customer tries again with the correct code, while Adyen advises against exposing refusal details. Asking the customer to check all their card details gives a genuine customer what they need without confirming which field failed.

Some codes in the table need care. Stripe says pickup_card and restricted_card may mean a card was reported lost or stolen, so treat them as the unknown row. For the Braintree equivalent, code 2047, PayPal’s guidance is to get a different payment method from the customer.

What next step should the customer see?

The message is only half of the recovery. Use this list on the page around it.

1. Stay on the payment step. Do not send the customer back to the cart or to an error page.
2. Keep their entries. Baymard reports that 34% of sites do not keep card numbers when errors occur, and that clearing them directly caused abandonment. Retained details also help people work out whether they mistyped something.
3. Show one clear action. Lead with the path that can work: fix the details, try again or switch.
4. Offer another method on the same screen. Visa’s guide says that if a card cannot be authorised, the merchant should ask the customer to use an alternative method. Stripe suggests the same for customers in the checkout flow. Show the methods most used in that market.
5. Match the alternative to the problem. Stripe suggests buy now, pay later options to help with declines from insufficient funds, and points to Apple Pay and Google Pay as alternatives.
6. Offer a retry only where it can work. Stripe’s do_not_try_again advice code means the card should not be used again for that transaction. Our soft and hard declines article has the detail.
7. Answer “was I charged?”. Stripe says some customers may see an authorisation on their statement after a blocked payment, and that the issuer typically removes it within a few days.
8. Give a reference for support. An order or payment reference lets an agent find the attempt quickly.
9. Watch for double payment. Stripe’s duplicate_transaction code means an identical transaction was just submitted, so check for an existing payment before asking the customer to pay again.

How should messages work for wallets and local methods?

The same principle applies, but the reasons differ, and many are not declines at all.

Apple Pay and Google Pay carry a card underneath, so a card decline can still come back. Offer a different card or method, using the same wording as above.

Local methods often fail in ways the customer can fix. Stripe’s list of local method codes shows the range. A BLIK code that has expired needs a new one, and Stripe notes that BLIK codes expire after 2 minutes, so “That code has expired. Get a new code in your banking app” is both specific and safe. When a customer cancels a payment themselves, say so plainly instead of calling it a decline. A Klarna decision is Klarna’s, so offer another method.

The fraud rule still holds. Stripe says lost_or_stolen_card on a local method should be presented as a generic decline, and a code such as partner_high_risk_customer belongs in the same group.

Methods that finish on another device need different wording. A pending payment is not a failure, so do not tell a customer it failed while they are approving it. Our guide to mobile money at checkout covers those flows. Every message should also appear in the language of the checkout, since a decline is a poor moment for a sentence the customer cannot read.

What are the common mistakes?

• Showing the provider’s raw text. Provider responses are written for developers and can include the real reason. Map every code to your own message, with a safe default for any code you have not mapped.
• Naming fraud. “Flagged as suspicious” helps a fraudster and insults a genuine customer.
• Ending on an error. “Something went wrong” with no action leaves the customer guessing.
• Making fraud declines look different. A separate message, delay or redirect gives the reason away.
• Clearing the card fields. It forces extra work at the worst moment, and customers may refuse to repeat it.
• Blaming the customer. “Your card was rejected” reads as an accusation. “This payment did not go through” does not.
• Promising what you cannot know. Do not write “contact your bank and it will work”. Say the bank can explain.
• Leaving support without a script. Agents who see the real reason need to know what they may say.

How does Omno help with decline messages?

Omno’s risk settings include custom decline messages, so you control what customers read. If a provider is unavailable or rejects the request, the payment moves to the next provider in the rule until one accepts, so a customer sees a decline only when no provider in the rule accepts. The hosted checkout can then offer other methods, and the full transaction trail keeps every attempt and provider response for your support team. The risk controls page lists the settings.