Most KYC integrations don't fail on the happy path. They fail on the states nobody modelled.
Teams treat verification as a gate: the user submits documents, the provider answers, you set verified = true and move on. That works until production.
Then you meet the middle. A provider returns pending and never calls back. A document expires while the account is live. A manual reviewer wants more information. A user who passed six months ago trips a sanctions re-screen. None of that is approved or rejected, and a boolean has nowhere to put it.
What I do instead: model verification as its own state machine with explicit intermediate states, each one persisted with the reason it was entered and who or what can move it forward. Provider responses are events applied to that state, not the state itself. Re-verification is a normal transition, not an exception.
The practical payoff is the moderation queue. A compliance reviewer opens a case and sees the current state plus the justification for it, instead of reconstructing history from provider logs. And when a user is stuck, you can answer why in one query.
The other benefit: onramps and payouts get to ask one question, is this user permitted to do this action right now, rather than every service inventing its own reading of a flag.
If you run KYC in production, there's probably one intermediate state that cost you real money before you gave it a name...