checkout.com payment declined with do_not_honour: what to do next

Checkout.com payment declined with donothonour: what to do next

TL;DR

donothonour is the issuer's generic "no" with no specific reason attached. Do not hammer retries; the issuer will keep saying no. Tell the shopper their bank declined the payment, suggest trying a different card or contacting their bank, and allow at most one careful retry after a delay. Then move on.

checkout.com payment declined with do_not_honour: what to do next

Steps

1. Confirm the decline code is donothonour (sometimes rendered donothonor) in the payment response. Success check: your logs show this exact code, not a CVV, AVS, or 3DS code.

1. Do not auto-retry immediately. Schedule at most one retry after a delay, or better, let the shopper trigger it. Success check: your retry logic caps donothonour at one delayed retry.

1. Show the shopper honest messaging: "Your bank declined this payment. Please try a different card or contact your bank." Success check: the UI does not blame your site or suggest the shopper "just try again" repeatedly.

1. Offer an alternative payment method on the decline screen (different card, wallet, bank redirect). Success check: a declined shopper can complete the order another way in the same session.

1. Track donothonour rates per issuer and per BIN. A sudden spike from one issuer usually means the issuer changed risk rules, not that your integration broke. Success check: your dashboard can slice declines by issuer.

When this applies

• Checkout.com returns a declined payment with response code donothonour.
• You need a retry policy for generic issuer declines.
• An agent flow retries every decline the same way and you want to fix that.

When it doesn't

• CVV or AVS hard rejects; those have specific fixes (re-collect the data).
• 3DS failures; those are authentication flow problems.
• Fraud or risk-flag declines from Checkout.com's own risk engine.

Tool + version compatibility

Checkout.com Payments API (all current versions), card payments via Frames or API.

"checkout.com do not honor declined"

Same code, alternate spelling. Handling is identical.

"checkout.com generic decline retry"

One delayed retry max. Generic declines do not get better with volume.

"checkout.com issuer declined payment"

donothonour is the most common issuer decline code; treat it as the default issuer-no.

Why it happens

Issuers return donothonour when they will not authorize the transaction but will not say why: it can be risk scoring, velocity limits, card state, or policy. The vagueness is deliberate on the issuer's side. Because there is no actionable reason code, no client-side fix (new CVV, new expiry) addresses it, which is why retries are futile and the shopper needs to involve their bank or switch cards.

Edge cases / pitfalls

• Retry storms on donothonour can get your merchant flagged by the issuer; cap retries and space them out.
• Do not log or display full card numbers when debugging declines; the response code is all you need.
• If donothonour clusters around high-value transactions, consider prompting for 3DS before the auth attempt; authenticated transactions get declined less.
• A shopper whose every card gets donothonour is usually facing an issuer-side block; no payment-method juggling on your side fixes that.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Y46Bh2M4zAVDLWirEvLDJQ