KYC Testing for Mobile Apps: How to Test Identity Verification Flows on iOS and Android

Updated October 2026 by Team Mobot.

Quick answer: KYC testing checks that a mobile app's identity-verification flow works for every user path: document capture, selfie and liveness, data checks, retries, and pass, fail and manual-review outcomes. Test it on real iOS and Android devices with the vendor's sandbox and synthetic identities, never real customer data.

The hardest parts of a mobile KYC flow to test are the physical ones: pointing a real camera at an ID, taking a selfie in real light, and getting through permission prompts on the phones customers actually use. Mobot tests KYC flows with Mobot testing robots on real iOS and Android devices, and a Mobot QA analyst verifies every defect, with screenshots from the device and device logs, before it reaches your team.

What is a KYC test in a mobile app?

Know Your Customer (KYC) is the identity-verification process that regulated businesses use to confirm who their customers are. In a mobile app, a KYC flow usually has five parts:

• Data entry: name, date of birth, address, and a national ID or tax number where required.
• Document capture: a photo of a government-issued ID, front and back.
• Selfie and liveness: a photo or short video that the system compares with the ID photo and checks for a live person.
• Database and watchlist checks: server-side checks, usually run by an identity-verification vendor.
• Decision states: approved, rejected, sent to manual review, or asked to retry.

A KYC test checks that each part works and that the app handles every outcome correctly. This guide is about testing the flow, not about running KYC checks on customers.

Which apps need KYC testing?

Any app that verifies identity or age before a user can do something. That covers far more than banks:

• Fintech and banking apps (account opening, card issuing, transfers)
• Crypto and investing apps
• Marketplaces and resale apps (seller verification and payouts)
• Gig and delivery apps (driver and courier onboarding)
• Rideshare apps (driver checks)
• Sports, betting and gaming apps with age checks
• Telehealth apps (patient identity)
• Travel apps (traveler identity)

KYC rules differ by country and industry. Check the regulations where you operate, and treat testing as a way to find bugs, not as proof of compliance.

What should a KYC test plan cover?

Use this as your checklist. Each item is a test case, or a group of test cases, to run on both iOS and Android.

Document capture

• Front and back of each supported document type (driver's license, passport, national ID)
• Glare, blur, shadow and a cropped or partly covered document
• Expired document
• Unsupported document type, and a document from an unsupported country
• A foreign document the app should accept
• Upload from the photo library, if the app allows it, and the error when it doesn't
• Auto-capture vs manual shutter, if the app offers both

Selfie and liveness

• Good light, low light and strong backlight
• Glasses, hats, face coverings and different skin tones
• Camera permission denied, then granted later from system settings
• Front camera unavailable or in use by another app
• Interruptions during capture (incoming call, notification, screen lock)
• Retry after a failed liveness check, and the limit on retries

Liveness and face-match checks often use machine-learning models. Test them across a wide range of faces, lighting and devices, and report any group that fails more often than others. Those are bugs in the flow, and they hit real users.

Data entry and validation

• Names with diacritics, apostrophes, hyphens, spaces and very long or very short names
• Address formats for each country you support
• Date-of-birth edge cases: under the minimum age, exactly the minimum age, invalid dates
• ID and tax number formats per region, including leading zeros
• Autofill, paste and keyboard type on each field

Decision states

• Approved: the user reaches the next step and the account state updates
• Rejected: the user sees a clear message and a path forward
• Manual review: the pending state survives an app restart, and the user is told what happens next
• Retry limits and resubmission
• Timeouts and vendor errors: the app shows a recoverable error, not a spinner that never ends

Interruptions and app state

• App sent to the background mid-capture, then resumed
• Incoming call during document or selfie capture
• Network drop and a Wi-Fi to cellular switch during upload
• App killed and relaunched mid-flow: does it resume or start over?
• Deep link back into the flow from an email or SMS reminder

Accessibility and localization

• VoiceOver (iOS) and TalkBack (Android) on capture screens, including the shutter and retry buttons
• Large text sizes on instructions and error messages
• Translated instructions, error messages and document names

Privacy and data handling

• No real customer data in test environments
• Images and ID numbers don't show up in app logs, crash reports or analytics
• Screenshots and test recordings are masked or stored under your retention policy
• Test data is deleted from test environments when you're done

How do you test KYC with a vendor sandbox?

Most apps use an identity-verification vendor for document checks, face match and watchlist screening. Most of these vendors offer a sandbox or test mode, with test documents or test identities that return a set result. Check your vendor's documentation for what its sandbox supports.

Use the sandbox to:

• Map every outcome to a UI state. For each result the sandbox can return (approved, rejected, needs review, error), check what the app shows and what it lets the user do next.
• Test webhooks and callbacks. Many decisions arrive later through a webhook. Check that your backend handles each event, handles duplicates and late events, and that the app updates when the decision arrives.
• Test failures. Force timeouts and error responses, and check that the app recovers.

What a sandbox doesn't cover: how well the camera captures a document or a face on a real phone, and how the flow performs on real devices. Those need real-device testing.

Why do KYC flows need real-device testing?

If you test in-house, expect most of the KYC failures that real users hit to show up in the camera steps and the permission prompts:

• Autofocus that hunts on a glossy card
• Glare from overhead lights
• Low light, or a backlit selfie
• Camera permission prompts and the "denied" path
• OS camera APIs that behave differently across versions
• Slow capture and upload on low-end Android phones

In your own testing, keep in mind that emulators and simulators replace the phone's camera with a mock feed, a virtual scene or your computer's webcam, so they don't show how a real phone camera behaves in real light. If you test in-house, run these steps on the phones your users have.

Mobot runs document capture, selfie checks and identity verification flows on real cameras and real devices. Mobot testing robots run the tests on the device. For the document and selfie steps, the test ID and face are presented to the real camera, so capture runs through the device's actual camera. A Mobot QA analyst reviews every failure before it reaches you, with screenshots from the device, logs and reproduction steps.

Read more about testing biometrics and payments on real devices, camera and sensor testing and verified defect reports.

To see Mobot test your own app on real devices, start a free trial.

How do you automate KYC tests without storing real PII?

• Use synthetic identities and vendor test documents. Never use real customer IDs or selfies, even internally.
• Test decision logic at the API level. Fast checks that each sandbox result produces the right account state.
• Test capture and states in the UI on real devices. Use the app's real camera screens, with the vendor in sandbox mode.
• Scrub logs. Keep ID numbers, names and images out of logs, crash reports and test artifacts.

Here's a short pseudo-code example. It maps each sandbox outcome to the state the app should show:

for outcome in [APPROVED, REJECTED, MANUAL_REVIEW, VENDOR_ERROR, TIMEOUT]:
    identity = synthetic_identity(outcome)        # vendor test identity or document
    start_kyc_flow(identity)
    submit_documents_and_selfie()
    wait_for_decision(timeout = <your SLA>)

    assert app_screen() == expected_screen[outcome]
    assert account_state() == expected_state[outcome]
    assert logs_contain_no_pii()

Run the API-level part on every build. Run the full UI flow on real devices before each release and whenever the KYC flow or vendor SDK changes.

How do you test KYC on iOS vs Android?

The test plan is the same, but each platform has its own failure points:

• Camera permission. iOS asks once, and after a denial the user has to go to Settings. Android lets the user deny, allow once, or allow while using the app, and the options depend on the OS version. Test every path on both.
• Camera hardware. Android phones vary widely in camera modules and in how vendors tune the camera, so test on several makes, including low-end models.
• Privacy prompts. iOS shows your camera usage text in the permission prompt. Check that it's present and clear.

iOS KYC test cases worth covering

Merged from our iOS KYC walkthrough. Test on physical iPhones across the iOS versions your users run, with synthetic test documents (valid and invalid IDs, passports and proof-of-address files):

• Successful submission. Valid documents and a clear selfie complete the flow and land on the approved state.
• Incomplete submission. The user submits only part of what's required, such as an ID without proof of address. The app should say what's missing.
• Unsupported or low-quality documents. Unsupported file formats or low-resolution captures are caught, with a clear prompt to retry.
• Biometric or selfie failure. Poor lighting or a badly positioned face fails the check. The app should give clear instructions and a retry path.
• Network drop during upload. The connection drops mid-upload. The app should handle it gracefully and let the user retry without starting over.
• Backend responses. Check each vendor sandbox outcome (approved, rejected, manual review) maps to the right screen, and use a proxy such as Charles Proxy to confirm data in transit is encrypted and correctly formatted.

Related guides: how to test Face ID and Touch ID, testing 2FA and testing SMS one-time codes.

FAQ

What is a KYC test?

A KYC test checks that an app's identity-verification flow works: data entry, document capture, selfie and liveness, and the approved, rejected, manual-review and retry outcomes. It tests the app, not the customer. Run it with synthetic identities and the vendor's sandbox, on real iOS and Android devices.

How do you test a KYC flow in a mobile app?

Write test cases for each part of the flow: document capture, selfie and liveness, data entry, decision states, interruptions, accessibility and privacy. Map every vendor sandbox outcome to the screen the app should show. Then run the camera and permission steps on real iOS and Android devices, where capture problems show up.

Can you automate KYC testing?

Yes. Automate decision logic at the API level with vendor sandbox outcomes, and automate UI tests of the capture screens and decision states on real devices. Keep synthetic data in every test and scrub logs of personal data. Re-run the full flow before each release and whenever the vendor SDK changes.

Should you use real IDs in KYC testing?

No. Use synthetic identities and the test documents or test identities your identity-verification vendor provides. Real customer IDs and selfies don't belong in test environments, logs or recordings. Mask or delete any test images and recordings when you're done, and check the regulations where you operate.

How do you test selfie and liveness checks?

Test good light, low light and backlight, glasses and hats, a wide range of faces, a denied camera permission, and interruptions during capture. Check the retry path and the retry limit. Run these tests on real phones, because emulators replace the camera with a mock feed and don't show how real hardware performs.

Can Mobot test KYC flows on real devices?

Yes. Mobot runs document capture, selfie checks and identity verification flows on real cameras and real iOS and Android devices. Mobot testing robots run the tests on the device. For the document and selfie steps, the test ID and face are presented to the real camera, so capture runs through the device's actual camera. A Mobot QA analyst verifies every defect with screenshots from the device and logs before it reaches your team.

Ship KYC with fewer surprises

A KYC flow is only as reliable as its worst camera, its slowest network and its least clear error message. Test every outcome with synthetic data, and test the capture steps on the phones your customers use.

To see Mobot test your own app on real devices, start a free trial.