How to add verification to your app with Myaza Trust
Add verification to your app using a published workflow and a supported SDK or hosted session. Keep capture in the customer journey and final result handling on your backend.
Charles Archibong, Co-founder
· 3 min read
Key takeaways
- The app opens the intended published workflow.
- Secret credentials stay on the backend.
- Cancelled, expired and abandoned journeys are handled.
- Final outcomes map to the intended customer.
- Production uses its own workflow, keys and receiver.
Add verification to your app using a published workflow and a supported SDK or hosted session. Keep capture in the customer journey and final result handling on your backend.
Before you begin
A published workflow
The supported SDK or hosted session path
Your server retrieves the final result
Use a team member with permission for this control. Check the organisation and environment before changing a setting. Review the current price before a paid check or ongoing enrolment. Screenshots show an example workspace or the public integration reference; they do not show a real customer or a completed paid check.
Set up and use the capability
Step 1: Publish the workflow customers should use
Open Configuration → Workflows in Sandbox. Create or open the appropriate individual, business or scoped workflow. Configure only the required capture and review checks. Save and publish it, then copy the workflow ID. Check the organisation and environment before integrating. An unpublished workflow is not a reusable live capture configuration.
Dashboard example: Publish the workflow customers should use
Step 2: Choose embedded capture or a hosted session
Use the Web SDK for browser capture, React Native or Flutter for native mobile capture, and a hosted session when you need a link for a known applicant. Native-only capabilities such as NFC require a native path. A shared workflow link serves many applicants; a server-created session belongs to one applicant. Choose the path that matches your product rather than mixing their credentials.
Integration reference: Three ways to run a workflow
Step 3: Install the current supported SDK and configure capture
Follow your platform’s SDK guide for the supported package, required peer dependencies and permission declarations. Pass workflowId, the matching publishable apiKey and your stable userId. The workflow supplies the configured steps; runtime subject data stays with your app. Check the documented minimum workflow-enabled version before troubleshooting a flow that ignores the workflow ID.
Integration reference: Workflows
Step 4: For hosted capture, mint the session on your backend
Call POST /api/kyc/sessions with a secret key, published workflow ID and intended externalUserId. Add permitted prefills and metadata only when needed. Store the session reference and give the private URL to the intended applicant. The workflow snapshot is fixed at mint time. Do not place a secret key in a WebView, mobile build or browser bundle.
Integration reference: Request
Step 5: Record submission, then wait for the outcome
The SDK’s submission callback identifies a submission; it is not the final approval callback. Store its verification reference on your backend. Read current status with the permitted API or receive signed webhooks. Keep processing, human review, awaiting resubmission, error and final outcomes distinct. Read final status with checkStatus and its explanation, especially when decisioning waits on other checks.
Integration reference: States
Step 6: Test the full journey and prepare Production separately
Use supported Sandbox IDs and fixtures for capture, status and receiver tests. Exercise permission refusal, abandonment, retries, Review and declines. For Production, obtain business approval, publish the Production workflow, configure environment-matched keys and result receiver, and review current pricing. A Sandbox pass validates your handling; it is not proof that every live check or device works.
Integration reference: Checklist for going live
Get more from the capability
Let workflow publication change capture configuration without duplicating that configuration in every app build.
Use metadata for permitted correlation such as an application reference, keeping it within the documented bounds.
Test phone handoff, permission recovery and browser-hosted events for the journey you actually ship.
Test before relying on it
Run the supported Sandbox or simulator scenarios for this product. Where a tool is Production only, check access and scope first, then use only a permitted, deliberately reviewed Production test. A documentation screenshot or a successful page load is not an end-to-end integration test.
The app opens the intended published workflow.
Secret credentials stay on the backend.
Cancelled, expired and abandoned journeys are handled.
Final outcomes map to the intended customer.
Production uses its own workflow, keys and receiver.
Troubleshooting
The SDK ignores workflowId
Check the installed package version against the documented minimum and verify the published workflow.
The workflow is not found
Match key, organisation, environment and published ID.
My app onboarded immediately after onSubmit
Wait for final authoritative status instead of treating capture submission as approval.
Open the setup and integration references
Read the integration reference
Back to Solutions. Choose the capability you want to activate, then follow its own guide.
Sources
Charles Archibong
Co-founder
Charles Archibong co-founded Myaza Trust. He writes about identity verification, financial technology, and the practical work of building trusted digital services.
