TL;DR —
resolution: "operator" means a configuration change is needed, not a retry. Contact support with the request_id.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 before requesting enablement, since refunds are disabled by default.
What you see
What to do
1
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.2
Contact support with the request_id
Contact support with the failing operation and the
request_id from the response, so they can check enablement for your outlet/terminal.3
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 and work through the go-live checklist before launch.
Related
Charge or authorize a payment
Where this can surface on a create-type call.
Supported payment methods
Which operations and methods need enablement.
API errors
The full routing/capability error table.
Support
Request enablement or report a routing gap.