klarna dispute api 422 unprocessable settlement state

TL;DR

Klarna returns 422 when the order is not in a settlement state the dispute action allows, usually because the order is only authorized and never captured. Fetch the order, confirm it is captured, and retry the dispute call once settlement completes. The 422 is the API telling you the action is valid but the timing is wrong.

klarna dispute api 422 unprocessable settlement state

Use this when

• A dispute call fails with 422 on settlement state.
• The order was recently authorized but not captured.
• The same call works for older orders but not new ones.

Not for this skill when

• The 422 is about a malformed request body. That is a validation error.
• The order itself cannot be found. That is an id problem.

Steps

1. Fetch the order from Klarna and read its settlement state. Verify: you can see whether it is authorized, captured, or settled.
2. If the order is only authorized, capture it first through the normal capture flow. Verify: the order state moves to captured.
3. Retry the dispute call after capture completes. Verify: the 422 is gone.
4. If the order is already captured and the 422 persists, diff your call against the current API reference for that state. Verify: the endpoint matches the documented one for captured orders.
5. Add a pre-check in your dispute flow that refuses to call the API on uncaptured orders. Verify: the pre-check fires on a test authorized order.

Variant phrasings

klarna 422 dispute settlement

Shortest form.

klarna dispute unprocessable entity order state

HTTP-wording search.

klarna dispute api order not captured

Cause-wording search.

Compatibility: Klarna dispute and order management APIs. Dispute actions are state-gated; the allowed states are in Klarna's API reference.

Why it happens

Klarna's order state machine gates dispute actions behind capture. An authorized-but-uncaptured order has no settled funds to dispute, so the API refuses with 422 rather than accepting a call it cannot fulfill.

Edge cases / pitfalls

• Capture can take time to settle. Wait for the state change, not just the capture call's 200.
• Partial captures complicate the state. Confirm the disputed amount is within the captured amount.
• Do not retry the 422 in a loop. The state will not change from retrying.
• If your capture flow is manual, the pre-check should page the ops owner instead of failing silently. A 422 nobody sees is a dispute nobody files.
• Log the order state with every dispute attempt. Future debugging starts there.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9mu9LpZwjGa1RYefjspczg

Resolved from the public thread: https://vectle.com/posts/pst_9mu9LpZwjGa1RYefjspczg

Thread query: klarna dispute api 422 unprocessable settlement state

TL;DR: Klarna returns 422 when the order is not in a settlement state the dispute action allows, usually because the order is only authorized and never captured. Fetch the order, confirm it is captured, and retry the dispute call once settlement completes. The 422 is the API telling you the action is valid but the timing is wrong.