QCDS Identity Verification: Level 2 Overview and Plan Requirements

QCDS Level 2 adds provider-backed identity verification before a selected signer is allowed to sign. It is available when the installation’s effective QCDS plan is Pro, Max, or All Access and currently supports Didit and Shufti provider profiles.

What Level 2 Adds

Normal QCDS signing already uses a participant-specific secure invitation and no-login signer session. Level 2 adds a separate identity-verification gate for the participants you mark as requiring it. Until that provider-backed verification reaches a verified state, QCDS does not allow that participant to sign or submit the Request.

Level 2 does not replace the secure signer link. The signer still enters through the personal QCDS invitation; Identity Verification is an additional assurance step inside that transaction.

Plan Requirements

Identity Verification is licensed on the installation’s effective Pro, Max, or All Access plan. Effective Basic does not provide Level 2. Because QCDS plan checks use the effective entitlement, a valid entitlement state that elevates the effective plan controls current feature access rather than an old saved license-key value.

Contacts, Templates, and ordinary secure-link signing remain separate from this Level 2 feature gate.

Supported Providers

• Didit: uses the provider’s hosted verification experience. QCDS sends the signer into that hosted flow and processes the provider result/webhook without storing Didit raw ID/face capture media locally.
• Shufti: supports the QCDS capture-and-provider flow for government ID evidence and live face verification. Local capture media is temporary; provider results/evidence state are retained rather than treating raw capture files as permanent QCDS documents.

Provider credentials belong to the site/customer and are stored encrypted by QCDS. A provider account can be configured globally for the Joomla site or at the creator/account level. When an enabled Global profile exists, it takes precedence for new Level 2 Requests.

The Provider Must Be Ready Before Send

For a new Request that requires Identity Verification, QCDS requires an enabled, tested provider profile that is ready for verification. Trial/Test provider mode is allowed for end-to-end sandbox testing; Production mode is used for live provider operation.

If the effective plan is not eligible, no usable profile is configured, or the selected provider connection is not ready, QCDS blocks sending a Request that requires Level 2 rather than silently downgrading the requirement.

What QCDS Freezes at Send

For each required signing participant—not CC/completion-only recipients—QCDS binds the sent Request to the exact provider profile resolved at Send. The verification record also carries the Request snapshot hash and document-association hash so later provider-setting changes do not silently rewrite which identity configuration belonged to that transaction.

What the Signer Experiences

A signer without a Level 2 requirement proceeds through the ordinary secure-link workflow. A Level 2 signer sees the identity state and must reach Verified before signing is enabled. Pending, in-progress, failed, or unavailable verification remains distinct from a successful signing action.

Community Discussion

Want to compare workflows, share practical tips, or discuss how you use this QCDS feature? Visit the QC Digital Signature Community. For private support, bug reports, account-specific issues, or feature requests, use the QuantaCade support system.