E-Signatur-API: Dokumente nach KYC signieren

Mit der E-Signatur können Personen Ihre Dokumente direkt im selben Ablauf unterzeichnen. Sie gehen jedes Dokument durch, fügen ihre Signatur, Initialen und alle von Ihnen angeforderten Daten hinzu und bestätigen auf der Stufe Erweitert (AES) mit einem Einmalcode, der an die zuvor verifizierte E-Mail-Adresse oder Telefonnummer gesendet wird. Didit gibt jedes Dokument unterschrieben zurück, zusammen mit einem Nachweis-PDF, das festhält, wer wie signiert hat. Die E-Signatur bietet drei Stufen. Einfach ist der Standard und erfordert keine Ausweisverifizierung, E-Mail-Adresse oder Telefonnummer. Erweitert (AES) erfordert eine genehmigte Ausweisverifizierung sowie eine verifizierte E-Mail-Adresse oder Telefonnummer und verknüpft die Signatur mit der verifizierten Identität. Qualifiziert (QES) ist eine Erweiterung, die derzeit noch nicht verfügbar ist. Siehe Signaturstufen. Sie funktioniert sowohl für die Benutzerverifizierung (KYC), bei der die verifizierte Person selbst unterzeichnet, als auch für die Unternehmensverifizierung (KYB), bei der gesetzliche Vertreter oder Schlüsselpersonen im Namen des Unternehmens unterzeichnen.

Signaturstufen

Stufe	Voraussetzungen	Beschreibung
Einfach	Standard. Keine Ausweisverifizierung, E-Mail-Adresse oder Telefonnummer	Die Person signiert über den Sitzungslink ohne Ausweisverifizierung, E-Mail, Telefon oder Code. Wenn die Sitzung bereits einen verifizierten Namen enthält, wird dieser verwendet; andernfalls tippt die Person ihren Namen ein, und in der Signatur sowie im Bericht wird vermerkt, dass der Name eingetippt und nicht verifiziert wurde. Jeder, der den Sitzungslink besitzt, kann signieren. Wählen Sie Einfach daher für Vereinbarungen mit geringem Risiko; für regulierte oder hochwertige Verträge sollte Erweitert (AES) verwendet werden. Die signierte Datei ist ein PDF mit einer Nachweisseite und enthält keine digitale Signatur, kein Siegel und keinen Zeitstempel. Didit speichert den SHA-256-Hash des Datensatzes und jeder signierten Datei, sodass spätere Änderungen erkennbar sind.
Erweitert (AES), fortgeschrittene elektronische Signatur	Eine genehmigte Ausweisverifizierung und eine verifizierte E-Mail-Adresse oder Telefonnummer in derselben Sitzung	Jedes Dokument wird in PAdES signiert, dem PDF-Signaturformat, mit einem Profil für die Langzeitvalidierung (`PAdES-B-LT`): Die Signatur trägt einen von Didit ausgestellten RFC-3161-Zeitstempel und die Widerrufsdaten, die für eine spätere Validierung erforderlich sind. Sie ist über die verifizierte Identität und den bestätigten Einmalcode eindeutig mit dem Unterzeichner verknüpft, und jede Änderung am Dokument nach der Signierung macht sie ungültig.
Qualifiziert (QES), qualifizierte elektronische Signatur	Erweiterung, derzeit nicht verfügbar	Würde mit einem qualifizierten Zertifikat signiert, das für den Unterzeichner ausgestellt wurde. Die Konsole zeigt die Option als Demnächst an, und das Speichern von `signature_level: "qes"` über die API gibt `400` mit `qes_not_available` zurück. Sie wird niemals stillschweigend durch AES ersetzt.

Erweitert (AES) signiert ausschließlich in PAdES. Die signature_format-Werte xades und cades werden für AES mit signature_format_not_supported abgelehnt. Prüfen Sie signature_availability im Workflow, bevor Sie einen AES-Schritt speichern: Solange aes den Wert false hat, gibt das Speichern eines neuen Schritts 400 mit aes_not_available zurück.

Funktionsweise

Bei Erweitert (AES) verifiziert der Workflow zuerst den Unterzeichner

Auf der Stufe Erweitert (AES) wird der Signaturschritt nach den Schritten ausgeführt, die feststellen, wer unterzeichnet: Ausweisverifizierung sowie E-Mail- oder Telefonverifizierung für den Kontaktkanal, an den der Code gesendet wird. Siehe Bevor Sie beginnen. Die Stufe Einfach erfordert keinen vorherigen Schritt.

Didit bereitet die Dokumente vor

Sobald der Unterzeichner den Schritt erreicht, kopiert Didit die Dokumente und deren Felder in die Sitzung und erfasst den SHA-256-Hash jedes Dokuments. Nachträgliche Änderungen am Workflow können nicht ändern, was dieser Unterzeichner sieht.

Der Unterzeichner geht jedes Dokument durch

Bei einem Dokument mit Feldern wird der Unterzeichner von Feld zu Feld geführt. Er fügt einmalig eine Signatur hinzu, die auf jedes Signatur- und Initialenfeld angewendet wird, und füllt Text- sowie Kontrollkästchen-Felder aus. Werte, die Didit aus der verifizierten Identität, der Sitzung oder Ihrem System übernimmt, sind bereits auf der Seite vorausgefüllt. Bei einem Dokument ohne Felder liest der Unterzeichner es und stimmt ihm zu.

Bei Erweitert (AES) bestätigt der Unterzeichner mit einem Code

Enthält ein Dokument Felder, willigt der Unterzeichner zunächst ein, die Dokumente elektronisch zu unterzeichnen. Auf der Stufe Erweitert (AES) sendet Didit dann einen sechsstelligen Code an die zuvor in der Sitzung verifizierte E-Mail-Adresse oder Telefonnummer; die Eingabe des Codes autorisiert die Signatur auf allen Dokumenten in diesem Schritt. Auf der Stufe Einfach gibt es keinen Code: Das Zustimmen autorisiert die Signatur direkt.

Didit signiert und siegelt

Didit trägt das Signaturdatum ein, stempelt jeden Feldwert in jedes PDF ein und hängt die Nachweisseite an. Auf der Stufe Erweitert (AES) wird anschließend die PAdES-Signatur und der Zeitstempel angewendet, sodass die Signatur alle Inhalte auf der Seite abdeckt. Auf der Stufe Einfach ist die Datei ein PDF mit der Nachweisseite und ohne digitale Signatur, Siegel oder Zeitstempel.

Sie erhalten die Ergebnisse

Die Entscheidungs- und die Sitzungs-Webhooks enthalten signatures[] mit dem Unterzeichner, der Bestätigung, dem Zertifikat, dem Zeitstempel, den Hashes jedes Dokuments und den Werten aller Felder. Sie laden die signierten PDFs und das Nachweis-PDF herunter, und Didit kann dem Unterzeichner eine Kopie per E-Mail senden.

Bevor Sie beginnen

Auf der Stufe „Advanced (AES)“ muss der Unterzeichner verifiziert werden, bevor er unterschreiben kann. Didit übernimmt dessen Namen und Kontaktdaten aus den verifizierten Datensätzen der Sitzung selbst und niemals aus Eingaben, die Sie oder der Unterzeichner vornehmen. Die Stufe „Simple“ erfordert nichts davon: Sie benötigt keine Ausweisverifizierung, keine E-Mail-Verifizierung, keine Telefonverifizierung und keinen Code und wird für KYB-Unterzeichner abgelehnt. Für die Benutzerverifizierung (KYC) fügen Sie diese Schritte vor der E-Signatur in den Workflow ein:

Ausweisverifizierung, genehmigt, mit einem lesbaren Namen. Ohne diese erfasst der Schritt SIGNATURE_IDENTITY_NOT_VERIFIED.
E-Mail-Verifizierung, wenn der Code per E-Mail gesendet wird (Standard), oder Telefonverifizierung, wenn er per SMS gesendet wird. Der Code wird nur an einen Kontakt gesendet, der in derselben Sitzung verifiziert wurde.
Wenn der Workflow auch Liveness-Erkennung enthält, muss diese genehmigt sein.

Um dem Unterzeichner eine Kopie der signierten Dokumente per E-Mail zu senden, benötigt die Sitzung ebenfalls eine verifizierte E-Mail-Adresse, selbst wenn der Code per SMS versendet wird. Für die Unternehmensverifizierung (KYB) sind die Unterzeichner die Schlüsselpersonen des Unternehmens, jeweils mit eigenem genehmigten KYC:

`signature_signer`	Wer unterzeichnet
`legal_representative`	Jede Schlüsselperson mit der Rolle `representative` oder `authorized_signatory`
`key_people`	Jede einzelne Schlüsselperson mit einer KYC-Sitzung

Ein KYB-Schritt hat zwischen 1 und 20 Unterzeichner, und jeder von ihnen benötigt zum Zeitpunkt der Signatur ein genehmigtes KYC. Jeder unterzeichnet seine eigene Kopie der Dokumente und bestätigt dies mit einem Code, der an den in seiner eigenen KYC-Sitzung verifizierten Kontakt gesendet wird. Der für die Schlüsselperson angegebene Name muss mit ihrem verifizierten Namen übereinstimmen (Groß-/Kleinschreibung und Leerzeichen werden ignoriert), andernfalls erfasst der Schritt SIGNATURE_NAME_MISMATCH. Der Schritt ist abgeschlossen, sobald jeder Unterzeichner signiert oder abgelehnt hat.

Dokumente

Woher die Dokumente stammen

signature_documents_source legt fest, woher ein Schritt seine Dokumente bezieht:

Wert	Dokumente
`workflow` (Standard)	Die Dokumente, die Sie in der Konsole in den Workflow hochgeladen haben. Jede Sitzung unterzeichnet dieselben Dokumente.
`session`	Die Dokumente, die Sie in `sign.documents` übergeben, wenn Sie die Sitzung erstellen. Jede Sitzung unterzeichnet ihre eigenen Dokumente.
`both`	Zuerst die Workflow-Dokumente, danach die Dokumente der Sitzung.

Dokumente pro Sitzung sind die Lösung, wenn eine Person einen Vertrag unterzeichnen soll, in dem Name, Betrag oder Bedingungen bereits durch Ihr System vorausgefüllt sind.

Unterstützte Dateien

	Limit
PDF	Bis zu 20 MB und jeweils 100 Seiten. Ohne Passwort, Skripte oder Dateianhänge.
Word (`.docx`)	Bis zu 20 MB. Wird beim Hochladen oder Erstellen der Sitzung in ein PDF konvertiert; für das konvertierte PDF gelten dieselben Limits wie für ein PDF. `.doc`-, `.docm`-, `.odt`- und `.rtf`-Dateien werden mit `unsupported_type` abgelehnt.
Pro Unterzeichner	Bis zu 20 Dokumente und insgesamt 50 MB.

Wenn Sie ein Word-Dokument hochladen, konvertiert Didit dieses während des Uploads innerhalb von maximal 60 Sekunden in ein PDF. Die konvertierten Seiten sind das, was der Unterzeichner sieht und unterschreibt; prüfen Sie diese daher, bevor Sie Felder platzieren: Zeilenumbrüche können leicht von Word abweichen. Die Word-Datei und ihr PDF gehören zum selben Dokument und werden gemeinsam mit diesem gelöscht. Das Nachweis-PDF dokumentiert die Konvertierung und den SHA-256-Hash beider Dateien. Didit lehnt eine Word-Datei mit signature_document_not_supported und einem reason ab, wenn der zu unterzeichnende Inhalt uneindeutig ist: Sie enthält Makros (macros), nicht angenommene nachverfolgte Änderungen (tracked_changes), Links zu externen Inhalten (external_links) oder eingebettete Objekte (embedded_objects). Nehmen Sie nachverfolgte Änderungen vor dem Hochladen an oder lehnen Sie diese ab, damit das PDF den vereinbarten Text anzeigt. Eine Datei, die nicht konvertiert werden kann, wird mit signature_document_conversion_failed und einem der folgenden Gründe abgelehnt:

`reason`	Was schiefgelaufen ist
`docx_password_protected`	Die Datei ist passwortgeschützt. Entfernen Sie das Passwort und laden Sie die Datei erneut hoch.
`docx_unreadable`	Die Datei ist kein lesbares Word-Dokument.
`docx_too_many_pages`	Das konvertierte PDF hat mehr als 100 Seiten.
`docx_too_large`	Die Datei ist zu groß für die Konvertierung.
`conversion_timeout`	Die Konvertierung hat zu lange gedauert. Versuchen Sie es erneut oder laden Sie das Dokument als PDF hoch.

Felder auf dem Dokument

Felder verwandeln ein Dokument in eine Vorlage, die der Unterzeichner ausfüllt – ähnlich wie bei der Vorbereitung eines Umschlags in einem Desktop-Signatur-Tool. Ein Dokument ohne Felder behält den einfacheren Ablauf: Der Unterzeichner liest es und stimmt zu.

Typ	Was der Unterzeichner tut	Wert
`signature`	Tippt darauf, um die übernommene Signatur einzufügen. Das erste Signatur- oder Initialen-Feld öffnet den Schritt, in dem die Signatur übernommen wird.	`true`, sobald angewendet
`initials`	Tippt darauf, um die übernommenen Initialen einzufügen.	`true`, sobald angewendet
`text`	Gibt einen Wert ein, der anhand der Validierung des Felds geprüft wird. Kann vorausgefüllt sein.	String
`checkbox`	Aktiviert oder deaktiviert das Kontrollkästchen. Ein erforderliches Kontrollkästchen muss aktiviert sein.	Boolean
`email`	Nichts, wenn die Sitzung eine verifizierte E-Mail-Adresse enthält, die schreibgeschützt eingefügt wird. Andernfalls wird sie eingegeben.	String
`full_name`	Nichts: Didit fügt den verifizierten Namen schreibgeschützt ein.	String
`date_signed`	Nichts: Didit fügt das Datum ein, an dem die Dokumente unterzeichnet werden.	String
`data`	Nichts: Didit fügt einen Wert aus der verifizierten Identität, der Sitzung oder Ihrem System schreibgeschützt ein. Woher er stammt, legen Sie in `prefill` fest.	String

In dieser Version gibt es keine Datumsauswahl. Verwenden Sie für ein vom Unterzeichner eingegebenes Datum ein text-Feld. Ein Feld hat folgende Eigenschaften:

Eigenschaft	Regeln
`id`	Wird von Didit festgelegt.
`key`	Benennt das Feld in den Ergebnissen und in `sign.field_values`. Kleinbuchstaben, Ziffern und Unterstriche, beginnend mit einem Buchstaben, bis zu 64 Zeichen (`^[a-z][a-z0-9_]{0,63}$`) und eindeutig innerhalb des Dokuments.
`type`	Einer der oben genannten Typen.
`role`	Wer es ausfüllt, mit den Werten von `signature_signer`: `verified_person`, `legal_representative` oder `key_people`. Bei einem Sitzungsdokument ist standardmäßig der Unterzeichner des Schritts eingestellt.
`page`	Von 1 bis zur Seitenzahl des Dokuments. Bei einem Word-Dokument eine Seite des konvertierten PDFs.
`x`, `y`, `width`, `height`	Anteile der dargestellten Seite (von `0` bis `1`), gemessen von der oberen linken Ecke und auf 4 Nachkommastellen gerundet. Das Feld muss innerhalb der Seite liegen. Es ist mindestens `0.02` breit und `0.012` hoch, eine Signatur mindestens `0.12` mal `0.035`.
`required`	`signature` und `initials` sind erforderlich, sofern nicht `false` festgelegt ist. `full_name`, `date_signed` und `data` sind immer erforderlich.
`label`	1 bis 80 Zeichen, wird dem Unterzeichner und in den Ergebnissen angezeigt.
`placeholder`	Nur bei `text` und `email`. Bis zu 80 Zeichen.
`position`	Die Reihenfolge, in der der Unterzeichner geführt wird, beginnend bei `0`. Didit bestimmt diese anhand der Position des Felds: nach Seite, dann von oben nach unten, dann von links nach rechts.
`validation`	Nur bei `text`. Siehe Validierung.
`prefill`	Woher der Wert stammt. Siehe Vorausgefüllte Werte.
`editable_when_prefilled`	Nur bei `text` und `email`: Der Unterzeichner kann einen vorausgefüllten Wert ändern. Standardwert: `false`.
`checked_by_default`	Nur bei `checkbox`: Das Kontrollkästchen ist standardmäßig aktiviert.
`date_format`	Nur bei `date_signed`: `DD/MM/YYYY` (Standard), `MM/DD/YYYY`, `YYYY-MM-DD` oder `D MMMM YYYY`.

{
  "id": "6a2f1c0e-4d8b-4f5e-9a51-0c7b2e9d3f10",
  "key": "occupation",
  "type": "text",
  "role": "verified_person",
  "page": 1,
  "x": 0.34,
  "y": 0.4618,
  "width": 0.57,
  "height": 0.0325,
  "required": true,
  "label": "Occupation",
  "placeholder": "For example, nurse",
  "position": 5,
  "validation": { "kind": "any", "min_length": 0, "max_length": 80, "pattern": null, "message": null },
  "prefill": null,
  "editable_when_prefilled": false,
  "checked_by_default": false,
  "date_format": null
}

Ein Dokument kann bis zu 200 Felder enthalten, und ein Unterzeichner kann über alle seine Dokumente hinweg bis zu 500 Felder haben. Ein Schritt füllt und stempelt nur die Felder seines eigenen Unterzeichners. Ein Dokument kann nur dann Felder für mehrere Rollen enthalten, wenn mehrere Signatur-Schritte des Workflows es verwenden: Jeder Schritt füllt die Felder seiner eigenen Rolle aus und belässt die anderen auf seiner Kopie leer. Ein Feld für eine Rolle, die von keinem Signatur-Schritt des Workflows verwendet wird, wird mit role_not_used abgelehnt. Jede Rolle, die Felder auf einem Dokument hat, benötigt dort mindestens ein signature- oder initials-Feld, andernfalls kann die Workflow-Version nicht veröffentlicht werden (signature_field_missing).

Validierung

validation gilt für text-Felder:

{ "kind": "any", "min_length": 0, "max_length": 80, "pattern": null, "message": null }

kind: any; letters (Buchstaben in jedem Schriftsystem, Leerzeichen, Bindestriche und Apostrophe); number (Ziffern mit einem optionalen Dezimaltrennzeichen); email; oder pattern.
min_length: von 0 bis zu max_length.
max_length: von 1 bis 500. Standardmäßig 120.
pattern: erforderlich bei kind: "pattern". Ein regulärer Ausdruck mit bis zu 200 Zeichen, mit dem der gesamte Wert übereinstimmen muss. Lookarounds und Rückwärtsreferenzen werden nicht unterstützt.
message: bis zu 120 Zeichen, wird anstelle des Standardfehlers angezeigt.

Die Konsolenvorschau, der Signierablauf und die API wenden dieselben Regeln an.

Vorausgefüllte Werte

prefill gibt die Quelle für den Wert eines Feldes an:

`prefill`	Wert
`identity.full_name`, `identity.first_name`, `identity.last_name`	Der Name, wie er auf dem verifizierten Ausweisdokument des Unterzeichners steht.
`identity.date_of_birth`	Aus dem verifizierten Ausweisdokument als `DD/MM/YYYY`.
`identity.nationality`, `identity.document_number`, `identity.document_type`, `identity.issuing_country`	Aus dem verifizierten Ausweisdokument.
`identity.address`	Die formatierte Adresse aus dem verifizierten Ausweisdokument oder aus einem Adressnachweis in derselben Sitzung.
`contact.email`, `contact.phone`	Die verifizierte E-Mail-Adresse oder Telefonnummer des Unterzeichners.
`company.name`, `company.registration_number`, `company.address`, `company.country`	Das für KYB verifizierte Unternehmen.
`session.vendor_data`	`vendor_data` der Sitzung.
`metadata.<key>`	Der Wert von `<key>` in `metadata` der Sitzung als Zeichenkette.
`api.<key>`	Der Wert von `<key>` in `sign.field_values`, der gesendet wird, wenn Sie die Sitzung erstellen.

Ein data-Feld muss ein prefill haben. Ein full_name-Feld verwendet immer identity.full_name und ein email-Feld contact.email; ein text-Feld kann ebenfalls eines haben. Die Werte von data-, full_name- und verifizierten email-Feldern werden festgelegt, sobald der Unterzeichner mit dem Signieren beginnt: Spätere Änderungen an der Sitzung ändern diese nicht mehr. Ein vorausgefülltes text- oder email-Feld ist schreibgeschützt, es sei denn, Sie setzen editable_when_prefilled. Wenn die Quelle eines erforderlichen Feldes zu diesem Zeitpunkt keinen Wert aufweist, beispielsweise bei einer Sitzung ohne Adresse, bleibt das Feld leer und der Unterzeichner kann dennoch unterschreiben. Es wird keine Warnung ausgelöst, und value_unavailable_reason im Bericht nennt die Ursache.

In der Konsole einrichten

Gehen Sie zu Workflows, öffnen Sie einen Workflow und fügen Sie den Schritt E-Signatur nach den Schritten ein, die den Unterzeichner verifizieren.
Wählen Sie unter Dokumente die Option Hochladen, um PDF- oder Word-Dateien hinzuzufügen, und ziehen Sie diese in die Reihenfolge, in der der Unterzeichner sie sieht. Word-Dateien werden in PDF konvertiert: Überprüfen Sie die konvertierten Seiten, bevor Sie Felder platzieren. Ersetzen tauscht die Datei eines Dokuments aus und behält dessen Felder bei – mit Ausnahme derjenigen auf Seiten, die in der neuen Datei nicht mehr vorhanden sind.
Wählen Sie unter Felder auf den Dokumenten platzieren die Option Editor öffnen. Ziehen Sie ein Feld aus der Palette auf die Seite oder wählen Sie es aus und klicken Sie auf die gewünschte Stelle, um es anschließend zu verschieben und in der Größe anzupassen. Legen Sie für jedes Feld fest: Wer es ausfüllt, seine Beschriftung, ob es Erforderlich ist, welche Eingaben es akzeptiert, woher sein Wert stammt und seinen API-Schlüssel (der key des Feldes). Vorschau als Unterzeichner zeigt das Dokument so an, wie der Unterzeichner es auf einem Smartphone oder Desktop sieht. Der Editor speichert während der Bearbeitung automatisch (Im Entwurf gespeichert) und listet auf, was noch behoben werden muss, bevor Sie Fertig auswählen.
Wählen Sie weiterhin unter Dokumente, woher die Dokumente stammen: Dieser Workflow, Jede Sitzung oder Beides. Legen Sie für Dokumente ohne Felder fest, ob der Unterzeichner diese Vor dem Unterschreiben vollständig lesen und Eine Einwilligung pro Dokument erteilen muss.
Wählen Sie unter Unterschrift den Unterzeichner, das Niveau (Einfach, standardmäßig, oder Fortgeschritten (AES); Qualifiziert (QES) wird als Demnächst angezeigt), das Format und wohin der Code gesendet wird (Einmalcode per).
Legen Sie unter Regeln fest, wie sich jede Warnung auf die Entscheidung auswirkt.
Wählen Sie unter Erweitert, ob Sie die Signierte Kopie per E-Mail senden und eine Nachweisseite hinzufügen möchten sowie wie viele Tage der Signierlink gültig bleibt. Sie können auch benutzerdefinierte Statusregeln hinzufügen.
Speichern Sie den Workflow.

Informationen zur Konfiguration desselben Schritts über die API finden Sie unter Workflow-Funktionskonfigurationen. Workflow-Dokumente und deren Felder werden in der Konsole verwaltet; über die API übergeben Sie Dokumente und Felder pro Sitzung.

Das Signiererlebnis

Der Signierschritt läuft auf der gehosteten Verifizierungsseite, im Web SDK und in den nativen SDKs, sowohl auf dem Desktop als auch auf Smartphones. Sie müssen keine eigene Benutzeroberfläche für das Signieren erstellen.

Intro. Die unterzeichnende Person sieht die Dokumente, die sie gleich signieren wird.
Jedes Dokument der Reihe nach. Bei einem Dokument mit Feldern wird die unterzeichnende Person in der Reihenfolge von position durch dessen Felder geführt. Das erste Feld für eine Unterschrift oder Initialen öffnet einen Dialog, in dem sie eine Signatur festlegt. Optionale Felder sind als Optional gekennzeichnet. Werte, die Didit vorausgefüllt hat, werden auf der Seite mit einem Schloss-Symbol angezeigt und stellen keine separaten Schritte dar. Das Antippen eines Felds auf der Seite springt direkt dorthin. Auf einem Smartphone wird jeweils ein Feld in einem Bereich angezeigt, der oberhalb der Tastatur fixiert bleibt. Auf einem Bildschirm mit einer Breite von mindestens 1200 px wird die Seite neben der Liste der Felder dargestellt. Wird ein Dokument abgeschlossen, während ein Pflichtfeld noch leer ist, wird angezeigt, wie viele Felder noch fehlen, und es wird zum ersten offenen Feld gesprungen. Ein Dokument ohne Felder wird gelesen und akzeptiert, so wie von Ihnen konfiguriert.
Prüfung. Die unterzeichnende Person sieht die Dokumente noch einmal und stimmt – sofern eines davon Felder enthält – zu, diese elektronisch zu signieren.
Code (nur auf der Stufe „Advanced (AES)“). Die unterzeichnende Person fordert ihren Code an. Dieser ist 5 Minuten lang gültig, ein neuer Code kann nach 60 Sekunden gesendet werden, und eine unterzeichnende Person erhält bis zu 5 Codes und 3 Fehlversuche. Wenn die Codes oder Fehlversuche aufgebraucht sind, wird SIGNATURE_OTP_FAILED erfasst. Auf der Stufe „Simple“ gibt es keinen Code: Die unterzeichnende Person gelangt direkt von der Prüfung zum Signieren.
Signiert. Nach dem Signieren kann die unterzeichnende Person ihre signierten Dokumente herunterladen. Wenn Sie dies aktiviert haben, sendet Didit ihr zusätzlich eine Kopie per E-Mail.
Ablehnen. Die unterzeichnende Person kann den Vorgang ablehnen, anstatt zu signieren. Dabei wird SIGNATURE_DECLINED erfasst. Eine Ablehnung kann wieder geöffnet werden, solange der Signierlink gültig ist, sodass die Person doch noch signieren kann, falls sie ihre Meinung ändert.

Der Ablauf benachrichtigt die unterzeichnende Person, wenn ihr Code abgelaufen ist, ein Dokument geändert wurde, das Signieren fehlgeschlagen ist oder der Signierlink abgelaufen ist. Der Signierlink bleibt für signature_link_validity_days (1 bis 30, standardmäßig 7) gültig, gezählt ab der Erstellung der Sitzung. Die Sitzung bleibt mindestens so lange geöffnet.

Native SDKs zeigen den Signierschritt ab der Version an, die ihn einführt – gelistet in der Übersicht der nativen SDKs, sobald sie veröffentlicht ist. Dokumente mit Feldern erfordern eine Version, die Felder unterstützt: Eine ältere Version kann diese nicht anzeigen, und der Schritt gibt stattdessen einen Fehler aus. Dokumente ohne Felder funktionieren in jeder Version, die den Signierschritt enthält. Bis Ihre Anwendung eine Version ausführt, die den Anforderungen Ihres Workflows entspricht, leiten Sie Personen auf die gehostete Seite oder das Web SDK weiter.

Signatur festlegen

Die unterzeichnende Person legt ihre Signatur und Initialen einmalig in einem gemeinsamen Dialog fest, wenn ein Dokument erstmals eines der beiden Felder anfordert:

Getippt: ihr verifizierter Name in einem frei wählbaren Handschrift-Stil, gekennzeichnet mit Aus Ihrem Ausweisdokument. Sie kann keinen anderen Namen eingeben. Getippte Initialen sind die Anfangsbuchstaben dieses Namens.
Gezeichnet: mit dem Finger oder der Maus gezeichnet, sowohl für die Signatur als auch für die Initialen.

Jedes spätere Feld für eine Unterschrift oder Initialen wird mit einer einzigen Aktion ausgefüllt; erneutes Antippen eines bereits ausgefüllten Felds entfernt die Angabe wieder.

Ergebnisse

Das Ergebnis jeder unterzeichnenden Person ist ein Element in signatures[] in der Sitzungsentscheidung sowie in der decision von Sitzungs-Webhooks. Es gibt keinen separaten Signatur-Webhook: Das Ereignis status.updated der Sitzung teilt Ihnen mit, wann die Entscheidung abgerufen werden kann. Sie erhalten das signierte PDF jedes Dokuments, ein Nachweis-PDF für jede unterzeichnende Person und den SHA-256-Wert jeder Original- und signierten Datei, damit Sie später belegen können, dass nichts verändert wurde. Bei Dokumenten mit Feldern erhalten Sie außerdem den Wert jedes Felds, dessen Herkunft und den Zeitpunkt des Ausfüllens sowie die festgelegte Signatur und den Zeitpunkt, zu dem die Person dem elektronischen Signieren zugestimmt hat. Im E-Signatur-Bericht finden Sie Details zu jedem Feld, den Downloads und dazu, wie Sie eine Signatur erneut validieren. In der Konsole zeigt der Tab Signatur der Sitzung die Dokumente, gefolgt von einem Block namens Felder mit einer Vorschau jeder Seite, der festgelegten Signatur und Initialen sowie Wert, Zeitpunkt und Quelle jedes Felds. Der PDF-Bericht enthält einen Signatur-Abschnitt sowie eine Seite E-Signatur · Felder, sofern die Dokumente Felder enthalten.

Preise

Die E-Signatur kostet $0.10 pro signierter Sitzung, enthalten in Ihren kostenlosen Credits – unabhängig von der Anzahl der Dokumente innerhalb eines Signiervorgangs und davon, ob die Stufe Simple oder Advanced (AES) gewählt wurde. Eine Signatur, die abgelehnt wird, fehlschlägt oder abläuft, wird nicht in Rechnung gestellt. Die qualifizierte elektronische Signatur (QES) ist ein derzeit noch nicht verfügbares Add-on ohne Preis.

Signaturdaten löschen

Wenn Sie eine Sitzung löschen, werden deren Signaturdaten mit ihr gelöscht: die mit der Sitzung übermittelten Dokumente und deren ursprüngliche Word-Dateien, die für jede unterzeichnende Person vorbereiteten Kopien, die signierten PDFs, die Nachweis-PDFs, die Bilddateien der übernommenen Signatur und Initialen sowie jeder Feldwert. Deren Download-Links verlieren ihre Gültigkeit. Dasselbe geschieht, wenn eine Sitzung am Ende Ihrer Datenaufbewahrungsfrist gelöscht wird. Da das Löschen nicht rückgängig gemacht werden kann, laden Sie alle benötigten Daten vorab herunter.

Die signierten Dokumente einer Unternehmensverifizierung (KYB) gehören zur Sitzung des Unternehmens. Das Löschen dieser Sitzung löscht auch die Dokumente.
Das Entfernen eines Dokuments aus einem Workflow löscht dieses samt seinen Feldern und der ursprünglichen Word-Datei. Eine unterzeichnende Person, die den Signiervorgang bereits begonnen hat, behält die ihr angezeigte Kopie als Teil ihrer Sitzung, bis Sie diese Sitzung löschen. Entfernen Sie Dokumente nur aus Workflows, bei denen keine Sitzungen auf das Signieren warten.
Eine Kopie, die Didit bereits per E-Mail an die unterzeichnende Person gesendet hat, befindet sich in deren Postfach und ist davon nicht betroffen.

Authentifizierung

Verifizierung

Überwachung

Plattform

E-Signatur-API: Dokumente nach KYC signieren

Signaturstufen

Funktionsweise

Bevor Sie beginnen

Dokumente

Woher die Dokumente stammen

Unterstützte Dateien

Felder auf dem Dokument

Validierung

Vorausgefüllte Werte

In der Konsole einrichten

Das Signiererlebnis

Signatur festlegen

Ergebnisse

Preise

Signaturdaten löschen

Verwandte Themen

​Signaturstufen

​Funktionsweise

​Bevor Sie beginnen

​Dokumente

​Woher die Dokumente stammen

​Unterstützte Dateien

​Felder auf dem Dokument

​Validierung

​Vorausgefüllte Werte

​In der Konsole einrichten

​Das Signiererlebnis

​Signatur festlegen

​Ergebnisse

​Preise

​Signaturdaten löschen

​Verwandte Themen

Signaturstufen

Funktionsweise

Bevor Sie beginnen

Dokumente

Woher die Dokumente stammen

Unterstützte Dateien

Felder auf dem Dokument

Validierung

Vorausgefüllte Werte

In der Konsole einrichten

Das Signiererlebnis

Signatur festlegen

Ergebnisse

Preise

Signaturdaten löschen

Verwandte Themen