A decline is a payment the card issuer turned down. It arrives on the payment response with status: Declined, a responseCode, and an authMessage explaining why. Reading these fields and responding correctly improves your approval rate, reduces customer friction, and keeps your retries within card network rules.

---

What a decline is

When a card payment is attempted, the issuer evaluates the request with automated risk systems that weigh signals such as available balance or credit limit, card details (expiry, CVV, billing address), and fraud indicators. If the issuer doesn't approve it, PCE returns the outcome on the payment response as status: Declined.

Issuers share detailed reasons only with the cardholder. Many declines are generic (for example, "Do not honor") where the exact reason isn't disclosed to the merchant.

---

Fields to review on a decline

Read these fields on the payment response to decide what to do next.

---

Common decline reasons and what to do

The responseCode maps to a reason on Payment Response Codes. Use the reason to choose the right response instead of blindly retrying.

---

Managing declines by customer presence

On-session (customer present). When the customer is in the checkout flow, prompt them to retry, request corrected or verified card details, or let them choose an alternative payment method.

Off-session (customer not present). For a declined subscription or recurring charge, notify the customer by email or in-app message and give them a secure way to update their payment method. Retry only when the decline reason allows it.

---

Retry guidelines

Card networks limit how often a declined charge can be retried, and excessive retries can get legitimate transactions flagged as fraud. Distinguish soft declines (temporary, retriable after a delay) from hard declines (permanent, do not retry).

• Soft declines — retry after a delay, within network limits. These include insufficient funds (51) and temporary issuer/system conditions (91, 92, 96). The condition may clear on its own.
• Hard declines — do not retry. These include lost/stolen card (41, 43), suspected fraud (34, 59), "do not honor" (5), and restricted/not-permitted cards. Ask for a different payment method.
• Space retries out; avoid rapid, repeated attempts on the same card.
• For recurring billing, prefer prompting the customer to update their card over automatic retries.

---

Best practices to reduce declines

• Collect CVV and billing postal code at checkout and pass them on the payment.
• Validate card details client-side before submitting.
• Review AVS and CVV results (in the response risk object) and prompt customers to correct failed checks.
• Show clear, actionable messages at checkout so customers can fix recoverable declines themselves.

---

See also

• Payment Response Codes: full responseCode reference
• Error & Decline Handling: validation errors vs declines
• Test Data: sandbox cards that reproduce specific declines
• Payment Lifecycle: statuses and tracking