When is direct verification integration the simpler choice?
A small B2B team needs hosted identity onboarding for new sellers. It already has, or is about to open, its own account with a verification provider. The decision is whether to integrate that provider directly or to route through an orchestration layer such as GridZen under a Bring Your Own Provider (BYOP) arrangement. This article works through one hypothetical scenario and lists the tradeoffs. It separates product facts, taken from the GridZen guide and capability notes dated 2026-10-17, from engineering advice. You can check the advice against the synthetic fixture before making any account or provider decision.
curl https://gridzen.ai/console/api/quickstart/trial \
-H 'Content-Type: application/json' \
-d '{"task": "identity_onboarding", "scenario": "success"}'The decision in one hypothetical scenario
Hypothetical: a two-developer team runs a marketplace in one country. It onboards a few sellers a week and needs exactly one verification event, a hosted identity check before a seller can list items. The team already holds a provider account and has read the provider's webhook documentation. No phone checks, IP risk or payout matching are planned. Advice: for a team like this, direct integration is often simpler. There is one provider, one event and one callback endpoint, and nothing needs to be normalized across vendors. An orchestration layer earns its place when the team expects several providers or events, needs normalized evidence across them, or wants route allowlists and audit handled outside its own code. Neither path removes the work described in the next sections. Direct integration only changes who writes that work.
Product facts versus advice
Facts from the guide: under BYOP, the customer keeps its own provider relationship and authorizes a defined integration scope. GridZen uses an approved adapter and route to normalize evidence. The current alpha does not accept arbitrary provider keys in a browser or request body. A public API or an available account is not evidence of permission to sell the resulting data. Each new provider product needs its own adapter and scope check. The controlled-pilot deployment has account authorization, route allowlists, encrypted audit and rate limiting, but that does not establish general production readiness. Facts from the capability notes: eligible US/GB businesses can self-enroll in a real hosted identity trial. The trial allows 2 requests per verified business domain and 10 shared lifetime requests, and it requires separate acceptance of the Didit addendum. Real session creation, signed notifications, authoritative reads and expiry are evidenced. A newly Approved user and the customer's own business action after approval remain unverified. Customer payments are disabled. Everything else in this article is advice.
What you own if you integrate directly
Advice: with a direct integration, your code owns all of the following: - Verifying production signatures on provider callbacks. - Deduplicating replayed events. - Binding each session to the correct tenant and subject. - Handling corrections, such as Approved followed later by Declined. - Expiring sessions that never complete. - Keeping the verification result separate from business permission. The guide's preparation list applies either way. Record the provider product, country, event, permitted identifiers, account owner, credential handling and downstream evidence scope. Confirm whether server-side processing on the customer's behalf is allowed. Approve retention, deletion, access logging, policy ownership and operational recovery before any live use.
Rehearse the failure handling with the synthetic fixture
The downloadable fixture has two parts. The identity part, Identity, stores fixture state in SQLite. The four-branch phone example is a separate part. Neither part is a live adapter or the anonymous HTTP trial. Its identity flow produces these tested outputs: - create returns state "simulated", session "fixture-session", hosted_link at example.invalid, link_executable false, and next "send_real_provider_link_only_after_authorization". - Approval with policy=True returns status "approved", deadline 60, permission_granted true, grant_count 1 and live_permission_changed false. - Replaying the same event returns the identical record, with grant_count still 1. - A Declined correction returns status "declined" and permission_granted false, while grant_count stays 1. - On a fresh pending session, recover at now=61 returns status "expired", permission_granted false, grant_count 0, next "review_or_authorized_provider_refresh" and provider_polled false. - An event for an unknown session raises BINDING_MISMATCH. Reading an unknown session raises SESSION_NOT_FOUND. Use these outputs as the specification your direct integration must reproduce.
Limits of the fixture
Implemented behavior: - The fixture accepts only synthetic callbacks: mode "synthetic_fixture", source "fixture_callback", and event IDs prefixed "fixture-". - Any other mode or source raises PRODUCTION_SIGNATURE_VERIFIER_NOT_IMPLEMENTED. It verifies no real signatures. - recover expires sessions locally and never polls a provider. - permission_granted is a local fixture flag. It is not live business permission, and live_permission_changed is always false. Your direct integration must supply the real signature verifier and the authoritative re-fetch of the provider's decision itself.
Acceptance checklist
- The scope record is complete, and server-side processing is confirmed as allowed. - Callback signatures are verified with the provider's real mechanism, and a missing or invalid signature causes rejection. - A duplicate event leaves grant_count unchanged. - A tenant or subject mismatch is rejected. - A Declined correction revokes permission. - A late event after the deadline cannot grant permission. - Expiry routes the session to review or to an authorized provider refresh. - Approved alone never grants permission; an explicit policy decision is also required. - Traces contain no raw identifiers. - Retention, deletion and recovery owners are named. If every item is easy for your team to own, direct integration is likely the simpler choice. If several items keep recurring across providers, evaluate a sandbox BYOP route next.
Run the checked synthetic example
Download and extract https://gridzen.ai/downloads/verification-delivery.zip, enter verification_delivery, then run with Python 3.10+. This local example makes no network calls. Use a fresh database for an independent identity run.
python3 delivery.py identity --db /tmp/gridzen-article-fixture.sqliteSources and scope
https://gridzen.ai/guides/bring-your-own-provider/ https://gridzen.ai/guides/current-capabilities/ Based on the checked source snapshot and local fixture; proposed application rules are design advice, not proven production behavior. Written with AI assistance and reviewed independently.
Separately try three sandbox outcomes Create an account to continue integrating
A download does not prove a successful run. Local examples and the online sandbox are tested separately.