# CARD_LOST_OR_STOLEN

# CARD_LOST_OR_STOLEN

The card has been reported lost or stolen and the issuer has blocked it. This is a permanent decision about the credential.

## Summary

| Field | Value |
|---|---|
| Appears as | `errors[].code` |
| Response | HTTP `200` — `Order` with `isValid: false` and a populated `errors[]` |
| Retry the same card | Never |

:::note[This is a reason code, not a top-level error code]
`CARD_LOST_OR_STOLEN` is an `errors[].code` value on the order. It is **not** a top-level
`ProblemDetail.errorCode`, so it carries no HTTP status, `errorCategory`, or `retryable` field of its
own. See [Unified OrderError shape](/distribution-partners/marketfront-api/guides/order-lifecycle#unified-ordererror-shape).
:::

## When This Fires

- **`POST /v1/marketfront/orders/place`** — a payment refusal identified the card itself as blocked.

Expect this code to be rare. Issuers seldom disclose that a card is flagged — a blocked card is
normally refused with an unattributed decline, which reaches you as
[`PAYMENT_FAILED`](/errors/PAYMENT_FAILED). Handle `CARD_LOST_OR_STOLEN` as the case where the reason
*was* disclosed, not as the code you will see whenever a card is blocked.

## Recommended Action

Fail the payment, ask for a different payment method, and never resubmit this credential. Unlike the other decline reasons, retrying is not merely futile — reattempting an authorization against a card the issuer will never approve can carry card-scheme penalties.

:::warning[Do not tell the customer why]
Show a **generic** payment failure. Do not render this code's name, and do not explain that the card
is reported lost or stolen — whoever is holding the card may not be its owner.

This is why the `message` we return for `CARD_LOST_OR_STOLEN` is deliberately identical in shape to a
plain [`PAYMENT_FAILED`](/errors/PAYMENT_FAILED) message. The split is intentional: the
machine-readable `code` tells *you* the truth so you can suppress the retry, while the
human-readable `message` is the text meant for the customer. Render `message`, not `code`.

Card networks require that you not complete the transaction. The stricter practice of withholding
the reason from the cardholder is standard payment-processor guidance rather than a published
network rule, but it is the behaviour our curated messages assume.
:::

## Example

```json
{
  "isValid": false,
  "errors": [
    {
      "code": "CARD_LOST_OR_STOLEN",
      "message": "We couldn't process your payment. Please try a different payment method.",
      "pointer": null
    }
  ]
}
```

Note that `message` says nothing about the card being flagged. That is deliberate — see the warning above.
