A payment can be
processing and normal, or processing and requires_intervention. The first is healthy. The second is not, and nothing about status tells you so.
Payment status
intent is receive or send, and does not change after creation.
Operational state
When
operationalState is not normal, operationalReasonCode names the cause. The ones worth handling in your own operations tooling:
Codes ending
_retry_scheduled are informational. Automation is still working.
Deposit status
For funds arriving at a reusable deposit address.Deposit address status
active or disabled. A disabled address stops being monitored for new deposits; deposits already in flight continue.
Reading state correctly
1
A webhook is a prompt
It tells you something changed. It does not tell you what is true now, and events can arrive out of order or more than once.
2
Read the resource
GET /v2/payments/{paymentId} is the answer. Act on what it returns, not on the event body.3
Check both axes
A terminal
status with operationalState: requires_intervention still needs attention.4
Treat terminal as final
A terminal status does not reopen. Late evidence changes operational state, not the financial result.
Next
Webhooks
Events, delivery and signature verification.
Errors
Why a request was rejected before any state existed.