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.

Field	Description
`status`	`Declined` for a declined payment.
`responseCode`	The integer code for why the payment failed. See Payment Response Codes.
`authMessage`	Human-readable description of the outcome (for example, "Insufficient funds/over credit limit").
`IssuerResponseCode`	The issuer's own two-digit code, when the issuer provides one.

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.

Decline reason	Example `responseCode`	Recommended action
Insufficient funds	`51`	Ask the customer to use a different card or payment method. Don't retry the same card immediately.
Invalid card details (number, expiry, CVV)	`14`, `135`, `113`	Prompt the customer to re-enter their card details carefully.
Do not honor / generic decline	`5`, `102`	If the details are correct, ask the customer to contact their issuer. Don't keep retrying.
Suspected fraud	`34`, `59`	Ask the customer to verify the transaction with their issuer, then retry once resolved.
Expired card	`33`, `54`	Ask the customer for an updated expiry date or a different card.
Restricted / not permitted	`36`, `57`, `62`	The card may be blocked for this use. Ask the customer to contact their issuer or use another card.
Lost or stolen card	`41`, `43`	Do not retry. Ask for a different payment method.
Failed AVS or CVV check	`401`	Ask the customer to verify their billing address and security code before retrying.
System or issuer unavailable	`91`, `92`, `96`	A temporary condition. Retry after a short delay, within network limits.

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.

Only retry declines whose reason is transient (for example, a temporary issuer or system condition). Don't retry hard declines such as lost/stolen card or "do not honor."
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.

Handling Declines