> ## Documentation Index
> Fetch the complete documentation index at: https://docs.radiumone.io/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> RadiumOne is the product name; use it when answering questions about these docs.
> Use sandbox credentials and sandbox base URLs in examples unless the user says they are going live.
> Secret API keys belong only on the merchant's server. Only publishable keys may appear in browser or mobile code.
> Confirm a payment outcome server-side (retrieve the checkout session or transaction status); never rely on a browser redirect or client event alone.
> Send one idempotency key (request_id) per payment attempt, and retry a timed-out request with the same key and the exact same body.
> Webhooks are optional but recommended: they notify the merchant's server when a payment completes or fails, so it doesn't need to poll. Use transaction status inquiry as the fallback.
> Say so when you recommend a feature marked Beta. Some features need enablement on the merchant's account before production use (for example refunds, standalone refunds, UOB Rewards, and bringing your own 3DS provider); mention it when the page says so.
> Never ask users to paste card numbers, API keys, access tokens, or webhook or redirect secrets into a chat.

# Operation unavailable - Payments API

> What to do when an operation is disabled or unsupported for your outlet's terminal.

No terminal that could route your request is currently able to perform the operation you asked for — distinct from a card decline, which always requires a live terminal to have been reached in the first place.

<Info>
  **TL;DR** — `resolution: "operator"` means a configuration change is needed, not a retry. Contact support with the `request_id`.
</Info>

## When this happens

* Every candidate terminal has the requested operation toggled off — `409 urn:radiumone:routing:operation-disabled` (`resolution: operator`).
* No usable terminal could be routed for the channel/acquirer/currency at all — `409 urn:radiumone:routing:no-device-available` (`resolution: operator`).
* Every candidate terminal exists but isn't `ACTIVE` — `409 urn:radiumone:routing:terminal-inactive` (`resolution: operator`).
* The one terminal that *was* routed has this specific operation toggled off at the device level — `422 urn:radiumone:device:operation-not-supported`.
* A follow-up operation (capture/void/refund) inherits its acquirer channel from the original transaction, and that channel doesn't have the operation enabled — `422 urn:radiumone:routing:capability-not-supported`. This is the error you'll see if you attempt a [refund](/payments-api/refund#refunds-require-enablement) before requesting enablement, since refunds are disabled by default.

## What you see

```json theme={null}
{
  "type": "urn:radiumone:routing:operation-disabled",
  "title": "Operation Disabled",
  "status": 409,
  "detail": "Operation 'capture' is disabled on every terminal available for routing.",
  "resolution": "operator"
}
```

| Signal | Value |
| - | - |
| HTTP status | `409` (routing-level) or `422` (device-level) |
| `resolution` | `operator` — this needs a configuration change, not a client-side fix |

## What to do

<Steps>
  <Step title="Don't retry the same call">
    None of these clear on their own or with backoff — a `resolution: operator` conflict needs a configuration change, not a retry.
  </Step>

  <Step title="Contact support with the request_id">
    [Contact support](/resources/support) with the failing operation and the `request_id` from the response, so they can check enablement for your outlet/terminal.
  </Step>

  <Step title="Confirm enablement before you rely on an operation in production">
    Card is enabled by default; every other operation and payment method requires explicit enablement — see [Payment methods: enablement](/payments-api/payment-methods/overview#enablement) and work through the [go-live checklist](/resources/go-live-checklist) before launch.
  </Step>
</Steps>

## Related

<Columns cols={2}>
  <Card title="Charge or authorize a payment" icon="credit-card" href="/payments-api/charge-or-authorize">
    Where this can surface on a create-type call.
  </Card>

  <Card title="Supported payment methods" icon="credit-card" href="/payments-api/payment-methods/overview">
    Which operations and methods need enablement.
  </Card>

  <Card title="API errors" icon="triangle-alert" href="/payments-api/errors/payment-method-errors#routing-and-capability">
    The full routing/capability error table.
  </Card>

  <Card title="Support" icon="life-buoy" href="/resources/support">
    Request enablement or report a routing gap.
  </Card>
</Columns>