`provider_operation_unsupported`

A typed 422 Unprocessable Entity returned by a payment lifecycle endpoint when the payment provider that handled a charge does not support the requested operation. The payment is left untouched.

Some providers do not expose every lifecycle operation. The clearest example is a provider that captures at authorization: there is no separate capture step to call, and there is nothing to void once the funds are already captured. Rather than surface an opaque provider error or a 502, Mooov returns this typed 422 so your integration can branch on a stable code.

When you hit it

You call a lifecycle endpoint that the routed provider does not implement. Today this applies to high-risk-routed payments, which capture at authorization:

POST /v1/payment_intents/{id}/capture — there is no separate capture; the charge is already captured when it succeeds.
POST /v1/payment_intents/{id}/void — voiding is not supported; reverse the payment with a refund instead.

Refunds are fully supported on these payments. Use POST /v1/payment_intents/{id}/refund (full or partial) to return funds.

Response shape

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json

{
  "error": {
    "code": "provider_operation_unsupported",
    "message": "This payment captures at authorization; a separate capture call is not supported.",
    "operation": "capture",
    "docs_url": "https://docs.mooov.money/errors/provider_operation_unsupported"
  }
}

Field reference:

Field	Always present	Notes
`code`	Yes	Stable string. Wire on this rather than the human `message`.
`message`	Yes	Human-readable. Subject to copy iteration; do not parse.
`operation`	Yes	The lifecycle operation that is unsupported (`capture`, `void`).
`docs_url`	Yes	Stable link to this page.

Wire on code and operation; both are stable. The human message is provider-specific copy and may change, so do not parse it.

What to do

Capture: treat a successful charge as already captured. Do not call capture for high-risk-routed payments.
Void: issue a refund instead. The refund window and currency rules of the route apply (for the high-risk route: within six months of the charge, in the original currency).

The payment state is never changed by a request that returns this error, so it is always safe to ignore and continue.