Most KYC integrations fail not at the provider API, but at the moment a human says "actually, look again".
The provider side is the easy part. You send documents, you get a decision, you store it. What breaks is everything downstream of that decision.
Because verification is not a boolean. It is a state that moves — sometimes backwards. A user gets approved, then a document expires. A compliance officer reopens a case after a rescreen. A borderline profile sits in manual review while the user is already trying to move money.
I have built onramps where KYC moderation happened in real time, with a compliance team working a live queue. What made those systems survivable was refusing to collapse verification into a single flag on the user row.
Instead: a case with its own lifecycle, an append-only trail of who decided what and on which evidence, and a separate question the payment path asks — is this user allowed to do this specific action right now. Not "is_verified".
The difference shows up the first time you have to explain to a regulator, or to your own ops team, why a transaction was permitted eight months ago.
If you run KYC in production: what forced you to redesign first — re-verification, or the audit trail?