# PROCESSING_ERROR

# PROCESSING_ERROR

The payment could not be processed because of a temporary fault somewhere in the processing chain — a terminal, gateway, or processor timeout, or an unreachable issuer. **No decision was made about the card.**

## Summary

| Field | Value |
|---|---|
| Appears as | `errors[].code` |
| Response | HTTP `200` — `Order` with `isValid: false` and a populated `errors[]` |
| Retry the same card | Yes — after a short delay, and only after checking for an existing payment |

:::note[This is a reason code, not a top-level error code]
`PROCESSING_ERROR` 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`** — payment processing failed transiently rather than being declined.

## Recommended Action

This is the **only** payment reason code where retrying the same card is honest advice. Everything else in this group is a decision about the card; this one is a fault in the machinery.

1. Wait briefly (1–3s with jitter).
2. Resubmit `POST /v1/marketfront/orders/place` with a **fresh** `Idempotency-Key`. You received a
   response, so that attempt is finished — see
   [Idempotency](/distribution-partners/marketfront-api/guides/order-lifecycle#idempotency) for the
   rule and why replaying the old key cannot work here.
3. After 2–3 failed attempts, stop and offer a different payment method or ask the customer to contact their issuer.

:::warning[Re-attempting is not free — this code carries a real charge risk]
A processor or terminal timeout is precisely the case where the authorization **may already have
succeeded** at the processor even though the order came back failed. A fresh-key re-attempt can
therefore charge the customer twice, and no `Idempotency-Key` can prevent it — our idempotency
record covers *our* order, not the processor's authorization.

Retry at most 2–3 times, and reconcile first where you can. If a customer reports a charge for an
order you never saw succeed, treat this code as the likely cause and contact support with the
`requestId`.
:::

Do not describe this to the customer as a decline. The card was never refused, and sending them to
find a different card is the wrong instruction for a fault that will likely clear on its own.

## Example

```json
{
  "isValid": false,
  "errors": [
    {
      "code": "PROCESSING_ERROR",
      "message": "We couldn't process your payment right now. Please try again in a moment.",
      "pointer": null
    }
  ]
}
```