Hosted Flow vs Embedded SDK: Choosing the Right KYC Integration Pattern
Choosing a KYC integration pattern for its UI is how launches stall. Here's how to pick based on who can actually own the failure states.
This article reflects the public VOVE ID documentation available on that date and is not legal advice.
A hosted KYC flow fits teams that need a contained verification journey and a faster interface boundary. An embedded SDK fits teams that need more control over the in-product journey and can own the integration, testing, and release discipline that control requires.
VOVE ID helps regulated product and engineering teams put identity verification into onboarding without treating the interface as a separate compliance decision. The costly mistake is choosing a flow for appearance, then discovering that errors, redirects, consent, and handoffs have no clear owner.
This is exactly where verification launches stall.
This article covers the interface-pattern decision itself. Once you've picked one, our Sandbox to Production checklist covers the release mechanics of getting either pattern live.
The choice: interface ownership changes the operating model
A hosted flow puts the verification journey behind a link or redirect boundary. The product sends an applicant into a managed experience and receives a return status at the agreed handoff point.
An embedded SDK places the verification capability inside the web or mobile application. The product team controls more of the surrounding experience, while engineering owns the SDK lifecycle, state transitions, and release compatibility.
Neither model is automatically safer or more compliant. The relevant question is whether the team can operate the boundary it selects: session creation, customer messaging, status reconciliation, support, and audit evidence.
VOVE ID's public Web SDK documentation describes both an SDK integration and a link integration that passes session and environment parameters, while its Flutter documentation describes full-screen and custom UI options. The Web SDK documentation and Flutter documentation should be the implementation source of truth for the current options.
For the underlying identity-verification controls, see our KYC requirements framework.
Hosted flow: contain the journey, define the handoff
A hosted flow works well when the team wants to minimize front-end verification logic. It creates a clear boundary: create a session, send the applicant to the flow, receive a completion signal, and reconcile the authoritative result server-side.
The tradeoff is that the product needs a deliberate return path. A redirect status can improve the customer experience, but it should not be the only state used to grant access or move money. The backend must still retrieve and store the final verification result.
The public VOVE documentation shows a link-integration option and documents callback status handling. It also documents retrieving verification details after a webhook event, which gives teams a server-side reconciliation point rather than relying only on browser navigation. See the session retrieval guidance.
Embedded SDK: own the experience, own the integration surface
An embedded SDK fits when verification must behave like a native product step. It gives teams tighter control over language, navigation, accessibility context, retries, and how a partially completed journey returns to the surrounding product.
That control adds work. Teams need explicit ownership for SDK upgrades, supported platforms, permission states, network interruptions, error copy, analytics, and regression testing. A custom interface does not remove the identity-proofing requirements behind it.
NIST's current identity-proofing guidance distinguishes remote unattended and attended proofing and frames proofing as a process with evidence, verification, and enrollment controls. That is useful context: the screen is only one part of the operating process. NIST SP 800-63A-4 is a technical reference, not a universal legal rulebook.
A realistic launch failure: the handoff has no owner
A lending platform launches a hosted verification link for new borrowers.
The product has:
- a link from the application form
- a callback page in the mobile web journey
- a backend record created before the applicant starts
Then the inconsistency appears. An applicant completes the identity journey, closes the browser before the callback loads, and contacts support because the loan application still says "verification required."
The product team sees no redirect. The operations team sees an incomplete application. The backend has a verification event but no defined rule for reconciling it to the application state.
This is not a hosted-flow failure. It is a state-ownership failure.
The decision frame: select the smallest boundary you can operate
This means one thing: pick the model by the team's ability to own failure handling, not by the amount of UI it can build.
Use a hosted flow when the priority is a contained verification experience and the team can make the server-side result authoritative. Use an embedded SDK when the verification step must participate deeply in an existing app journey and the team can support its integration surface over time.
How VOVE ID fits: configure the proofing journey before the UI decision
VOVE ID's public documentation describes configurable verification flows, including selected document types, liveness, step order, and flow versions. That allows compliance and product teams to define the proofing journey, then decide whether a hosted link or SDK integration is the better delivery model. Review the current flow configuration documentation.
For either model, keep the backend responsible for creating the verification session, consuming trusted completion events, retrieving the result where needed, and recording the decision trail. Keep the front end responsible for explaining the next step, not for declaring the final compliance outcome.
Practical KYC integration checklist
Product
- Define the exact point where verification begins and where the applicant returns.
- Write the waiting, retry, and manual-review messages before implementation.
- Test the journey on the web and mobile contexts the product actually supports.
Engineering
- Create verification sessions from the backend rather than exposing privileged credentials.
- Treat a server-side result or verified event as the authoritative completion signal.
- Log the reference identifier that links the product record to the verification record.
Operations
- Define who owns applicants who finish proofing but do not return to the product.
- Give support teams a safe procedure for checking a verification state.
- Preserve the evidence needed to explain a decision without exposing sensitive data broadly.
Release management
- Test sandbox and production configurations separately.
- Document the SDK or hosted-flow version in the release record.
- Re-test the recovery path whenever the onboarding journey changes.
FAQ
Is a hosted KYC flow less secure than an embedded SDK?
Not inherently. Security depends on the complete implementation: session control, trusted server-side state, secure transport, event validation, and access controls around the result.
Can teams start with hosted and move to embedded later?
Yes, if they design the backend verification record and state model independently from the customer-facing interface. Confirm the current migration and platform details in the provider documentation before committing.
Should a redirect callback approve an applicant?
No. Treat it as a customer-experience signal. Use the verified result returned through the documented server-side process for an operational decision.
What is the best KYC integration pattern for a new product?
The best pattern is the one the team can support end to end. Start with the smallest interface boundary that still gives the product the recovery and control it needs.
What should teams test before launch?
Test completed, abandoned, interrupted, pending-review, and failed journeys. Test how each state reaches the product record and how support sees it.
Conclusion
KYC integration is not a hosted-versus-embedded beauty contest. It is a choice about who owns the journey and the failure states around it.
Teams should define the verification workflow first, make the backend result authoritative, and then choose the interface model that their product and engineering teams can operate. The interface, the decision, and the audit record are one workflow.
Want to see how VOVE ID can fit a hosted or embedded verification journey into your existing operating model?
This article is intended for general informational purposes only and does not constitute legal, financial, or regulatory advice. KYC/KYB/AML requirements may vary depending on jurisdiction, industry, and specific business circumstances. For up-to-date and binding compliance obligations, readers should refer to the relevant regulatory authorities or consult qualified professionals.
