Handling Identity Mismatch Errors

❗️

For our API customers with the QES feature activated before 21 July, please contact [email protected] to give your approval to activate the feature for your organisation.

Why do we need a perfect match?

To ensure the legal validity of a Qualified Electronic Signature (QES), the Signature Certificate must be issued with a name that exactly matches the one on the verified ID document.

If a minor mismatch is detected, we will return an error along with the expected name details from the ID document to be used to correct the Signer's information and enable them to make an optimised next attempt.

There are two types of name mismatches.

• Major mismatch: the first is when a first name or last name is radically different from the one on the ID document. Example: Hortense when Pauline is mentioned on the ID document. This case isn't concerned by this feature! ⚠️ The identity is too different and will be blocked by our identity verification provider.
• Minor mismatch: when a first name or surname does not strictly match what is on the identity document because a character is missing or a part is missing. Example: Nicola for Nicolas or Jean when Jean-Baptiste is expected according to the ID document.

Understanding the blocking mechanism after a name mismatch

When an identification attempt fails due to a mismatch between the information declared by the Sender and the data extracted from the Signer's ID document, the Signer will be automatically blocked. This mechanism ensures:

• Optimized chances of success on the next identification attempt.
• Reduced credit consumption when identification is bound to fail due to mismatched information. If the information does not match, it will not match later if the nominative information is the same. We want to prevent a Signer from trying again and consuming credits when no corrections have been made.

You can see the errors concerned on this section. Please note that the firstname_missing error isn't concerned by the feature, as a Signer cannot have an empty first name. Once blocked, the Signer will see a waiting page and will be instructed to contact the Sender to resolve the issue.

How to Correct a Signer's Information After a Matching Error

To allow the Signer to attempt identification again, the Sender/Integrator must follow this three-step process:

1. When the identification fails, you will continue to receive the webhook signer.identification_failed as is already the case;
2. In the case of a first name or last name error, and after the Signer clicks on the consent button to share the extracted information, you'll receive the signer.identification_blocked webhook containing the extracted first name (expected_first_name) and last name (expected_last_name);
3. Unblock the Signer with the dedicated endpoint POST /signature_requests/{{signatureRequestId}}/signers/{{signerId}}/unblock_identification. Signers can't be updated if they've the blocked status;
4. Update the Signer information with the names provided thanks to the webhook with the dedicated endpoint PATCH /signature_requests/{{signatureRequestId}}/signers/{{signerId}}.

Please note that the Signer must absolutely re-use the same identity document to ensure that the next attempt is optimised. We recommend that you use the webhook to check the extracted Signer's identity first and then accept the change.

✅ Important: The identification process cannot resume until these steps are completed (so the Signer will remain blocked until it is at least unblocked). Make sure you implement this logic to ensure a smooth user experience and prevent credit waste.