Qualified Electronic Signature Integration
Integration Guides
Setup
This page provides guidance on preparing to integrate Qualified Electronic Signature via the App Drop-in, Web SDK, or the API.
Before you begin your integration, make sure you have the following in place:
Prerequisites
- You need your Fourthline API credentials.
- The client must have a pending or successfully completed Identity Verification case with Fourthline.
- Agree with your Fourthline delivery manager the identifiers of your product and country-specific workflows. For default options, see Create workflow.
- For Fourthline QTSP, for the Mobile SDK, update to the latest version:
- Native (iOS/Android): 3.6.0 or later.
- Cross-platform: 2.6.0 or later.
Statuses
Set up handling for Qualified Electronic Signature statuses.
Webhook
Set up a webhook and handle Qualified Electronic Signature notifications.
Configuration
Discuss with your Fourthline delivery manager the following configuration options:
Signature flow
Required
In general, we recommend configuring the pending verification flow:
| Pending verification | |
|---|---|
| Description | The signature flow starts while the Identity Verification case is being processed. |
| Benefit | The user experience is smoother as the client can continue the signature flow immediately after the Identity Verification flow, without waiting for case processing. |
| Trade-off | The client may need to re-do the signature flow if inconsistent data is identified during case processing. |
| Configuration | If you use Web SDK integration, you can ensure the client always finishes the signature flow even if the associated Identity Verification case is unsuccessful, e.g.: case status inconsistent_data, invalid_data, or completed_unacceptable_risk. This offers a more cohesive user experience than discontinuing the signature flow. With your Fourthline delivery manager, configure to delay triggering signature status kyc_required until after reaching pending_verification status. |
The pending verification flow is as follows: the first diagram shows the Fourthline QTSP flow, and the second shows a third-party QTSP flow.
Click to magnify
If many ID documents in your target market do not contain an MRZ or require careful analysis, we recommend the completed verification flow:
| Completed verification | |
|---|---|
| Description | The signature flow starts after the Identity Verification case has been processed. |
| Benefits | The signature flow can only start if the client is eligible, which ensures higher conversion. The QEC data is confirmed in case processing . |
| Trade-off | The client must wait for the case to be processed before they can start the signature flow. |
The completed verification flow is as follows: the first diagram shows the Fourthline QTSP flow, and the second shows a third-party QTSP flow.
Click to magnify
QTSPs
Required
From August 2026, you can use Fourthline as the QTSP for Identity Verification with QES workflows. Unlike the third-party QTSP flow, the Fourthline QTSP flow does not require a one-time passcode.
To get started, contact your Fourthline success manager, or get in touch.
Important
QES-only workflows continue to use third-party QTSPs. Support for Fourthline as the QTSP in QES-only workflows will be added at a later date.
Fourthline uses three QTSP - Fourthline, Namirial, and InfoCert - to provide fallback options. If one QTSP is temporarily unavailable, clients are automatically redirected to another available QTSP to minimize disruption to the signature flow.
There are the following differences between the QTSPs:
Legal conditions
Clients must accept the following legal conditions per QTSP:
| Fourthline | InfoCert | Namirial |
|---|---|---|
| Fourthline Terms & Conditions | InfoCert Terms & Conditions | Namirial Terms & Conditions |
| Fourthline Privacy Statement | InfoCert Privacy Statement | Fourthline Privacy Statement |
| InfoCert PKI Disclosure Statement | ||
| InfoCert legal clauses |
For SDK integration, Fourthline's UI dynamically displays the relevant legal conditions per QTSP on the Document approval screen.
If using API-only integration and your own UI, the relevant QTSP legal conditions for a specific signature flow are returned in the Get signature details response. The following requirements apply:
| Document approval screen | Required |
|---|---|
| Dynamically display the QTSP legal conditions, which the client must actively accept and be able to download. | |
| Display InfoCert's legal clauses, which the client must actively accept. | |
InfoCert contract
InfoCert generates a personalized contract for the client, which you must download via a Get InfoCert contract request and share with the client.
One-time passcode
Namirial's one-time passcode is 6 digits long and InfoCert's 8 digits long.
For SDK integration, Fourthline's UI dynamically displays the relevant number of passcode digits per QTSP on the Signature confirmation screen.
For API-only integration, the relevant QTSP passcode length for a specific signature flow is returned in the Get signature details response. The following requirements apply:
| Signature confirmation screen | Required |
|---|---|
| Display the titles of the documents to sign. | |
| Dynamically change the passcode mask to the right number of digits per QTSP. | |
Legal conditions
Required
The client must accept the following legal conditions per party:
| Fourthline | |
|---|---|
| Legal conditions | Fourthline Terms & Conditions |
| Display when | Before starting the Identity Verification flow, and during the document approval step (if Fourthline is the QTSP) |
| Source | Request from Fourthline delivery manager |
| Responsibility | You display them to the client in your UI. If Fourthline is the QTSP:
|
| InfoCert | |
|---|---|
| Legal conditions | InfoCert Terms & Conditions InfoCert Privacy Statement InfoCert PKI Disclosure Statement InfoCert legal clauses |
| Display when | Document approval step |
| Source | Get signature details request |
| Responsibility | App Drop-in & Web SDK: Fourthline displays them to the client in our UI. App Components & API: You display them to the client in your UI. |
| Namirial | |
|---|---|
| Legal conditions | Namirial Terms & Conditions Namirial Privacy Statement Fourthline Privacy Statement |
| Display when | Document approval step |
| Source | Get signature details request |
| Responsibility | App Drop-in & Web SDK: Fourthline displays them to the client in our UI. App Components & API: You display them to the client in your UI. |
Legal conditions language
When retrieving legal conditions via the Get signature details request, you can also optionally specify the language:
- English (default)
- French
- German
- Italian
- Polish
- Portuguese
- Romanian
- Spanish
Note
Depending on the documents, legal condition documents may not be available in all languages listed above. If a document is not available in the specified language, it will default to English.This setting also determines the language of the passcode SMS.
One-time passcode required for third-party QTSPs
Required
Important
From August 2026, you can use Fourthline as the QTSP for Identity Verification with QES workflows. Unlike the third-party QTSP flow, the Fourthline QTSP flow does not require a one-time passcode. To get started, contact your Fourthline success manager, or get in touch.
When using Namirial or InfoCert as the QTSP, the QTSP sends the client a one-time passcode by SMS when they confirm the signature.
The number of passcode digits differs per QTSP:
| QTSP | Agreements |
|---|---|
| Namirial | 6 digits |
| InfoCert | 8 digits |
The SMS can be sent in the following languages:
- English (default)
- French
- German
- Italian
- Polish
- Romanian
- Spanish
You can specify the SMS language in the Get signature details request.
Note
This setting also determines the language of the legal conditions.
ID documents
Required
Fourthline supports passports, national ID cards, residence permits, and driving licenses. Supported documents must meet the following requirements:
-
Travel documents (passports, national ID cards, and residence permits) must comply with the ICAO 9303 standard for machine readable travel documents (MRTDs), endorsed by ISO as ISO/IEC 7501.
-
Include detectable security features (such as holograms, watermarks, UV inks, etc.) as configured for the specific document type and issuing country, in accordance with ICAO 9303.
-
Include an MRZ as defined in ICAO 9303, with document type codes indicating the type of document (for example,
P<for passport) as specified by the standard.
Note
Driving licences may include an MRZ in some jurisdictions. However, this is not required because they typically follow national document standards rather than ICAO 9303. See the table below for more information.
- Adhere to the configured combinations of issuing country and document type for each Business Partner.
The following ID documents do not contain an MRZ, which in the pending verification flow can lead to invalid_signature status. This is because we extract the details for the certificate from the VIZ, which is less reliable.
Decide with your Fourthline delivery manager if you want to support the following documents or not.
| Document type | Code |
|---|---|
| Austrian driving license | AUT-FO-04001 AUT-FO-05001 AUT-FO-05002 |
| Greek identity card | GRC-BO-01001 GRC-BO-01004 |
| Italian driving license | ITA-FO-05001 ITA-FO-05001 |
| Italian paper ID | ITA-BO-03001 ITA-BO-03002 ITA-BO-03003 ITA-BO-03004 |
| UK driving license | GBR-FO-05001 GBR-FO-05003 GBR-FO-06001 GBR-FO-07001 GBR-FO-08001 GBR-FO-08002 GBR-FO-09001 GBR-FO-09002 GBR-FO-09003 GBR-FP-05001 GBR-FP-06001 |
Sanctions check
Optional
During the signature flow, check if the client is potentially sanctioned when you want them to sign documents. The client is only eligible for a signature if there are no hits for them in your selected AML> database.
If including this check, we recommend using the pending verification flow to avoid clients getting stuck at kyc_required status.
Important
This check is triggered only if the client's most recent Identity Verification case that included an AML screening was completed more than 24 hours ago.
Fourthline can perform the sanctions check via either AML Monitoring or a one-time sanctions check:
AML Monitoring
We monitor the client against your selected AML database daily. During the signature flow, we check the client's sanctions status for that day.
If we find a potential hit, we investigate the case. When the investigation is completed, we send you the outcome via a webhook notification.
You always have an up-to-date screening status for the client and can act accordingly, e.g. offboard a sanctioned client.
Tip
Consider configuring your application to prevent sanctioned clients from starting a signature flow.
One-time sanctions check
Screen your selected AML database for potential hits during the signature flow.
Fourthline doesn't perform an investigation. If we find potential hits, the client is ineligible for a signature.
Flow language
Optional
For App Drop-in or Web SDK integration, you can set the language of the signature flow UI when you create the SDK session.
For the supported languages and instructions, see:
- App UI Customization – Localization
- Web SDK Setup – Localize the UI
If you do not set the UI language or the language isn't supported, the default is English.
Signature position
Optional
You can configure if you want the signature to be visible on signed documents and on which page.
Specify its size and position in PDF units. There are 72 PDF units per inch (") / 2.83 per millimeter (mm), e.g.:
- US letter page size of 8.5" x 11"= 612 x 792 PDF units
- A4 page size of 210mm x 297mm= 595 x 842 PDF units
Signature position
Configure the signature visibility and position in the Upload documents to sign request.
Testing
We offer the following endpoints for testing signature flows in the Sandbox environment only:
| Endpoint | Description |
|---|---|
| Test signature flow | Start the signature flow for a test signature with a target status. |
| Get test passcode | Get a one-time passcode to confirm a test signature, without requiring a valid mobile phone number.  Important: If you have InfoCert configured as one of your QTSPs, you do not need to make this request because the passcode is the same as the last 8 digits of the mobile phone number. Example: • Phone number: +39 11111112222 • Passcode: 11112222 |
FAQ
Why does my PDF signature appear as unverified?
The PDF viewer you are using may not support the signature-validation capabilities required to verify the document.
A signature appearing as unverified does not by itself mean that the signature is invalid or that the document has been modified.
How can I verify the signature?
Open the PDF in Adobe Acrobat or Adobe Acrobat Reader and check the signature status there.
What about browsers and macOS Preview?
Chrome, Firefox, Safari, and macOS Preview should not be used to verify Fourthline PDF signatures. They may display the PDF without providing the signature-validation information available in Adobe Acrobat or Reader.
What your clients need to know?
Clients should open the PDF in Adobe Acrobat Reader to verify its digital signature. Web browsers and macOS Preview may not display the signature's verification status correctly.
Why doesn't Adobe Acrobat recognize a newly approved QTSP?
Adobe Acrobat does not check the live EU Trusted Lists when validating a signature. Instead, it uses a local snapshot of qualified trust providers derived from the EU Trusted Lists and updated periodically by Adobe.
As a result, a newly approved Qualified Trust Service Provider (QTSP) may not be recognized in Acrobat immediately after being added to a Member State Trusted List.
How long can it take for Adobe Acrobat to recognize a new QTSP?
Adobe typically publishes an updated EUTL-derived trust snapshot once a month, usually during the first week of the month.
It can take up to approximately 30 days for a change to a Member State Trusted List to be reflected in Adobe's trust data. After Adobe publishes the update, an Acrobat installation may take up to an additional 14 days to download the updated trust data.
What contact details are required for QES?
When using Fourthline as the QTSP, you must provide either the client's phone number or email address. We recommend providing a phone number whenever possible because it is supported by a wider range of QTSPs.
For API integrations, provide the client's contact details before the client reaches the contact details screen. If the contact details have already been provided, the SDK skips this screen.
Support
For any questions, contact your Fourthline delivery manager.
Updated 2 days ago