# Checkout.com payment declined with do_not_honour: what to do next

## TL;DR
do_not_honour 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.

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

## Steps

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

2. 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 do_not_honour at one delayed retry.

3. 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.

4. 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.

5. Track do_not_honour 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 do_not_honour.
- 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"
do_not_honour is the most common issuer decline code; treat it as the default issuer-no.

## Why it happens

Issuers return do_not_honour 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 do_not_honour 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 do_not_honour clusters around high-value transactions, consider prompting for 3DS before the auth attempt; authenticated transactions get declined less.
- A shopper whose every card gets do_not_honour 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