> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# 电子签名 API：KYC 验证后签署文件

> 在 Didit 验证流程中，让已验证的个人或企业代表签署 PDF 和 Word 文档，支持简单电子签名或高级电子签名（AES）级别。

电子签名允许用户在同一流程中签署您的文件。他们逐一浏览每份文件，添加签名、姓名缩写以及您要求的任何数据，并在高级（AES）等级下，通过发送到其先前验证过的邮箱或电话的一次性验证码进行确认。Didit 将返回每份已签署的文件，以及一份记录了签署人身份和签署方式的证据 PDF。电子签名包含三个等级。**简单**为默认等级，不需要身份证件验证、邮箱或电话。**高级（AES）**需要已通过的身份证件验证以及已验证的邮箱或电话，并将签名与已验证的身份绑定。**合格（QES）**是一项附加功能，目前尚不可用。请参阅[签名等级](#签名等级)。它适用于用户验证（KYC）（由已验证的人员签署），也适用于企业验证（KYB）（由公司的法定代表人或关键人员代表企业签署）。

电子签名集成提示词
        将提示词复制到剪贴板



      
      

\<pre>

\`Goal:
Add Didit E-signature to a verification workflow: the verified person (KYC) or a company's representatives (KYB) sign PDF or Word documents inside the Didit flow, and your backend receives the signed PDFs and the evidence.

Delivery mode:
E-signature is a workflow step (feature SIGNATURE). There is no standalone signing API: the signer signs inside the hosted Didit flow, the Web SDK or a native SDK.

Prerequisites in the workflow (Advanced (AES) level only; the default Simple level needs no earlier step and no code):
\- KYC: an ID Verification step before the signature step (the signer's identity must be Approved), plus Email Verification (email codes, the default) or Phone Verification (SMS codes) so the code goes to a verified contact. If the workflow has Liveness, it must be Approved too.
\- KYB: a Key People step whose people complete their own KYC with the same prerequisites. signature_signer "legal_representative" picks the key people with the role representative or authorized_signatory; "key_people" picks every eligible key person (1 to 20 signers). For these KYB signers always set signature_level to "aes": "simple" is refused with signature_simple_requires_verified_person, so the workflow cannot be saved.

Steps:
1\. Add the E-signature step to the workflow in the Business Console (or POST /v3/workflows/ with {"feature": "SIGNATURE", "config": {...}}). Upload the documents in the console, or set signature_documents_source to "session" (or "both") to send them per session.
2\. Optional: place fields on each document: signature, initials, full_name, date_signed, text, checkbox, email and read-only data. Workflow documents get their fields in the console's template editor. Session documents carry them in sign.documents[].fields, placed by page and position or by anchor text. Every field has a key; a field with prefill "api.<key>" takes its value from sign.field_values.
3\. Create a session. For per-session documents, send sign.documents with base64 content:

curl -X POST 'https://verification.didit.me/v3/session/' \
-H 'x-api-key: YOUR_API_KEY' \
-H 'Content-Type: application/json' \
-d '{
"workflow_id": "YOUR_WORKFLOW_ID",
"vendor_data": "user-1234",
"sign": {
  "documents": [
    \{
      "title": "Account agreement",
      "file_name": "agreement.pdf",
      "content_base64": "<base64 of the PDF>",
      "fields": [
        \{ "key": "signature", "type": "signature", "page": 3, "x": 0.09, "y": 0.62, "width": 0.36, "height": 0.085 },
        \{ "key": "credit_limit", "type": "data", "page": 1, "x": 0.34, "y": 0.31, "width": 0.3, "height": 0.03, "prefill": "api.credit_limit" }
      ]
    }
  ],
  "field_values": { "credit_limit": "3,000 EUR" }
}
}'

4\. Send the user to session.url (or open it with the Web or native SDK). Documents with fields need a native SDK release that supports fields; the hosted page and the Web SDK always do.
5\. Wait for the status.updated webhook, then GET /v3/session/{session_id}/decision/.

Decision surface:
signatures[] (one item per signer and signature step). Read:
\- status: the signing stage (intro, review, code, signing, signed, declined).
\- verdict: Not Finished | Approved | In Review | Declined.
\- level ("simple" or "aes"), format ("pdf" for simple, "pades" for aes), profile ("PAdES-B-LT" once an aes step is signed, otherwise null).
\- signer, identity_used, confirmation, certificate, timestamp, adopted_signature, electronic_signature_consent_at.
\- documents[]: mode ("fields" or "read_and_agree"), sha256_original, sha256_signed, status, signed_file (download path), source_format, conversion, fields[] (key, type, value, display_value, value_source, filled_at, image_url).
\- evidence_file (download path), warnings[] ({code, node_id}).

Downloads (x-api-key works):
\- GET /v3/session/{session_id}/signatures/{node_id}/documents/{document_id}/file/ -> signed PDF
\- GET /v3/session/{session_id}/signatures/{node_id}/evidence/?signature_id={id} -> evidence PDF
\- GET /v3/session/{session_id}/signatures/{node_id}/fields/{field_id}/image/ -> applied signature or initials (PNG); use the image_url of the field
\- POST /v3/session/{session_id}/signatures/{node_id}/validate/ -> re-checks the stored signatures

Warnings:
SIGNATURE_DECLINED (default REVIEW), SIGNATURE_OTP_FAILED, SIGNATURE_NAME_MISMATCH, SIGNATURE_IDENTITY_NOT_VERIFIED, SIGNATURE_DOCUMENT_CHANGED (default DECLINE). Each maps to a signature_*_action setting.

Rules:
\- Level: "simple" (default) or "aes". "qes" is an add-on that is not available yet and saving it returns 400 qes_not_available. While signature_availability.aes is false on the workflow, saving a new "aes" step returns 400 aes_not_available.
\- PDF: up to 20 MB and 100 pages each, no password, scripts or attachments. Up to 20 documents and 50 MB per signer.
\- Word: .docx only (.doc, .docm, .odt and .rtf are refused with unsupported_type), up to 20 MB, converted to PDF while the upload or create-session request runs. Fields refer to the converted pages. Macros, tracked changes, external links and embedded objects are refused with signature_document_not_supported; a file that can't be converted returns signature_document_conversion_failed. Both carry a reason.
\- Fields: key matches ^[a-z][a-z0-9_]{0,63}$ and is unique in its document; role defaults to the step's signer; up to 200 fields per document and 500 per signer. Every role with fields on a document needs a signature or initials field. There is no date picker type: use text.
\- Never show success until status is "signed". That is the check at every level. For an aes signature a null certificate, timestamp or signed_file also means "not signed"; a signed simple signature has a signed_file but a null certificate and timestamp.

See also:
\- /core-technology/electronic-signature/report-electronic-signature
\- /core-technology/electronic-signature/warnings-electronic-signature
\- /management-api/workflows/feature-configs#e-signature`

\</pre>



      
      

粘贴到

## 签名等级| 等级 | 要求 | 说明 |
| - | - | - |
| **简单** | 默认。无需身份证件验证、邮箱或电话 | 用户通过会话链接进行签署，无需身份证件验证、邮箱、电话或验证码。若会话中已有已验证的姓名，则会直接使用；否则用户需手动输入姓名，且签名和报告中会注明该姓名系手动输入且未经核验。任何持有该会话链接的人均可签署，因此请在低风险协议中选择简单等级；受监管或高价值合同应使用高级（AES）。签署完成的文件为带有证据页的 PDF，不包含数字签名、印章或时间戳。Didit 会保留该记录的 SHA-256 哈希值及每份已签署文件的 SHA-256 哈希值，以便检测后续的任何篡改。 |
| **高级（AES）**，高级电子签名 | 同一会话中包含已通过的身份证件验证以及已验证的邮箱或电话 | 每份文件均以 PDF 签名格式 PAdES 签署，并采用长期有效验证配置（`PAdES-B-LT`）：签名包含由 Didit 签发的 RFC 3161 时间戳，以及后续验证所需的吊销数据。它通过已验证的身份和确认的一次性验证码与签署人唯一关联，签署后对文件的任何修改都会使签名失效。 |
| **合格（QES）**，合格电子签名 | 附加功能，目前尚不可用 | 将使用签发给签署人的合格证书进行签署。控制台将该选项显示为**即将推出**，通过 API 保存 `signature_level: "qes"` 将返回 `400` 及 `qes_not_available`。系统绝不会以 AES 静默替代。 |高级（AES）仅支持 PAdES 格式签署。对于 AES，`signature_format` 取值 `xades` 和 `cades` 会被拒绝并返回 `signature_format_not_supported`。在保存 AES 步骤之前，请检查工作流上的 `signature_availability`：当 `aes` 为 `false` 时，保存新步骤将返回 `400` 及 `aes_not_available`。## 工作原理**1. 对于高级（AES），工作流会先验证签署人**在高级（AES）等级下，签名步骤将在确立签署人身份的步骤之后运行：包括身份证件验证，以及对用于接收验证码的邮箱或电话号码进行邮箱验证或电话验证。请参阅[准备工作](#开始之前)。简单等级不需要任何前置步骤。**2. Didit 准备文件**当签署人进入该步骤时，Didit 会将文件及其字段复制到会话中，并记录每份文件的 SHA-256。之后对工作流的更改不会影响当前签署人所看到的内容。**3. 签署人逐一查看文件**对于包含字段的文件，签署人将被引导按顺序填写各个字段。他们只需设置一次签名，该签名就会应用到所有签名和姓名缩写字段，同时他们需要填写文本和复选框字段。Didit 从已验证的身份、会话或您的系统中获取的字段值已预先填入页面。对于没有字段的文件，他们阅读并同意即可。**4. 对于高级（AES），签署人使用验证码进行确认**当任何文件包含字段时，签署人首先需要同意以电子方式签署文件。在高级（AES）等级下，Didit 随后会向他们在会话前期验证过的邮箱或电话发送一个六位数验证码，输入该验证码即可授权签署该步骤中的所有文件。在简单等级下则没有验证码：同意即授权签名。**5. Didit 进行签署和盖章**Didit 会填入签署日期，将所有字段值盖印到每份 PDF 中，并附加证据页。在高级（AES）等级下，随后会应用 PAdES 签名和时间戳，使签名覆盖页面上的所有内容。在简单等级下，生成的文件是带有证据页的 PDF，不包含数字签名、印章或时间戳。**6. 您获取结果**决策和会话 Webhook 会携带包含签署人、确认信息、证书、时间戳、每份文件哈希值及每个字段值的 `signatures[]`。您可以下载已签署的 PDF 和证据 PDF，Didit 也可以向签署人发送电子邮件副本。## 开始之前在高级（AES）级别下，签名人必须在签署前完成验证。Didit 会从会话自身的已验证记录中提取其姓名和联系方式，绝不使用您或签名人输入的任何内容。简单级别无需这些：它不包含身份证件验证、邮箱验证、电话验证或验证码功能，且不适用于 KYB 签名人。**对于用户验证（KYC）**，请在工作流中的电子签名之前添加以下步骤：- **身份证件验证**，状态为已通过，且包含可读姓名。若未完成该验证，电子签名步骤将记录 `SIGNATURE_IDENTITY_NOT_VERIFIED`。
- 当验证码通过电子邮件发送（默认方式）时需要**邮箱验证**；当通过短信发送时需要**电话验证**。验证码仅会发送至在同一会话中验证过的联系方式。
- 如果工作流中还包含**活体检测**，则其状态必须为已通过。若要通过电子邮件向签名人发送已签署文件的副本，会话同样需要经过验证的邮箱，即使验证码是通过短信发送的也是如此。**对于企业验证（KYB）**，签名人为企业的关键人员，每位人员均须拥有自身已通过的 KYC：| `signature_signer` | 签名人 |
| - | - |
| `legal_representative` | 每位拥有 `representative` 或 `authorized_signatory` 角色的关键人员 |
| `key_people` | 拥有 KYC 会话的每位个人关键人员 |KYB 步骤包含 1 到 20 位签名人，每位签名人在签署时都必须拥有已通过的 KYC。每位签名人签署属于自己的文件副本，并通过发送至其本人 KYC 会话中已验证联系方式的验证码进行确认。为关键人员申报的姓名必须与其已验证姓名一致（忽略大小写和空格），否则该步骤将记录 `SIGNATURE_NAME_MISMATCH`。一旦所有签名人均已签署或已拒绝，该步骤即告完成。## 文档### 文档来源`signature_documents_source` 设置步骤获取文档的来源：| 值 | 文档 |
| - | - |
| `workflow`（默认） | 您在控制台中上传到工作流的文档。每个会话签署相同的文档。 |
| `session` | 您在[创建会话](https://docs.didit.me/zh/sessions-api/create-session.md#电子签名文档)时在 `sign.documents` 中发送的文档。每个会话签署各自的文档。 |
| `both` | 先签署工作流文档，然后签署会话文档。 |按会话指定的文档适用于让用户签署已由您的系统预填好其姓名、金额或条款的合同。### 支持的文件| | 限制 |
| - | - |
| PDF | 每个文件不超过 20 MB 且不超过 100 页。不能包含密码、脚本或附件文件。 |
| Word（`.docx`） | 不超过 20 MB。在您上传或创建会话时转换为 PDF，转换后的 PDF 具有与 PDF 相同的限制。`.doc`、`.docm`、`.odt` 和 `.rtf` 文件将被拒绝并返回 `unsupported_type`。 |
| 每个签署人 | 总计不超过 20 个文档且不超过 50 MB。 |当您上传 Word 文档时，Didit 会在上传过程中将其转换为 PDF，最多耗时 60 秒。转换后的页面即为签署人查看和签署的内容，因此在放置字段之前请先进行检查：换行可能与 Word 中略有不同。Word 文件及其 PDF 属于同一文档，并会随文档一同删除。证据 PDF 会记录此次转换以及两个文件的 SHA-256 哈希值。当待签署内容存在歧义时，Didit 会拒绝 Word 文件并返回 `signature_document_not_supported` 及对应的 `reason`：包含宏（`macros`）、未接受的修订（`tracked_changes`）、外部内容链接（`external_links`）或嵌入对象（`embedded_objects`）。请在上传前接受或拒绝所有修订，以确保 PDF 显示的是您确认一致的文本。无法转换的文件将被拒绝并返回 `signature_document_conversion_failed` 以及以下原因之一：| `reason` | 问题原因 |
| - | - |
| `docx_password_protected` | 文件设有密码。请移除密码后重新上传。 |
| `docx_unreadable` | 文件不是可读的 Word 文档。 |
| `docx_too_many_pages` | 转换后的 PDF 超过 100 页。 |
| `docx_too_large` | 文件过大，无法转换。 |
| `conversion_timeout` | 转换超时。请重试，或直接以 PDF 格式上传文档。 |### 文档上的字段字段将文档转换为签署人需要填写的模板，类似于在桌面端签署工具中准备签署信封的方式。没有字段的文档保持更简单的流程：签署人只需阅读并同意即可。| 类型 | 签署人的操作 | 值 |
| - | - | - |
| `signature` | 点击以应用其采用的签名。第一个签名或姓名首字母缩写字段会打开采用签名的步骤。 | 应用后为 `true` |
| `initials` | 点击以应用其采用的姓名首字母缩写。 | 应用后为 `true` |
| `text` | 输入值，根据字段的[验证](#验证)规则进行校验。可预填。 | 字符串 |
| `checkbox` | 勾选或取消勾选。必填的复选框必须勾选。 | 布尔值 |
| `email` | 若会话中包含已验证的邮箱，则以只读方式自动填充，无需操作；否则手动输入。 | 字符串 |
| `full_name` | 无需操作：Didit 会以只读方式填入已验证的姓名。 | 字符串 |
| `date_signed` | 无需操作：Didit 会填入文档签署日期。 | 字符串 |
| `data` | 无需操作：Didit 会以只读方式填入来自已验证身份、会话或您系统的值。在 `prefill` 中设置其来源。 | 字符串 |此版本暂无日期选择器。对于签署人输入的日期，请使用 `text` 字段。字段具有以下属性：| 属性 | 规则 |
| - | - |
| `id` | 由 Didit 设置。 |
| `key` | 在结果和 `sign.field_values` 中标识字段名称。由小写字母、数字和下划线组成，以字母开头，最多 64 个字符（`^[a-z][a-z0-9_]{0,63}$`），且在文档内必须唯一。 |
| `type` | 上述类型之一。 |
| `role` | 填写人，取值为 `signature_signer` 的值：`verified_person`、`legal_representative` 或 `key_people`。对于会话文档，默认为该步骤的签署人。 |
| `page` | 从 1 到文档的总页数。对于 Word 文档，为转换后 PDF 的页码。 |
| `x`、`y`、`width`、`height` | 相对于页面显示尺寸的比例（从 `0` 到 `1`），从左上角起算并四舍五入至 4 位小数。字段必须完全位于页面内。宽度至少为 `0.02`，高度至少为 `0.012`，签名至少为 `0.12` 宽乘以 `0.035` 高。 |
| `required` | `signature` 和 `initials` 默认为必填，除非设置为 `false`。`full_name`、`date_signed` 和 `data` 始终为必填。 |
| `label` | 1 到 80 个字符，向签署人展示并在结果中显示。 |
| `placeholder` | 仅适用于 `text` 和 `email`。最多 80 个字符。 |
| `position` | 引导签署人操作的顺序，从 `0` 开始。Didit 根据字段所在位置确定：先按页码，再从上到下，最后从左到右。 |
| `validation` | 仅适用于 `text`。请参阅[验证](#验证)。 |
| `prefill` | 值的来源。请参阅[预填值](#预填值)。 |
| `editable_when_prefilled` | 仅适用于 `text` 和 `email`：签署人可以修改预填值。默认为 `false`。 |
| `checked_by_default` | 仅适用于 `checkbox`：复选框初始状态为勾选。 |
| `date_format` | 仅适用于 `date_signed`：`DD/MM/YYYY`（默认）、`MM/DD/YYYY`、`YYYY-MM-DD` 或 `D MMMM YYYY`。 |```json theme={null}
{
  "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
}
```一个文档最多支持 200 个字段，一名签署人的所有文档合计最多包含 500 个字段。每个步骤仅填充并盖印其自身签署人的字段。仅当工作流中的多个签名步骤使用同一文档时，该文档才能包含多个角色的字段：每个步骤在其副本上填充属于自身角色的字段，并将其他角色的字段留空。若某个字段所属的角色未被工作流中的任何签名步骤使用，则会被拒绝并返回 `role_not_used`。在文档上拥有字段的每个角色都必须在该文档上至少包含一个 `signature` 或 `initials` 字段，否则工作流版本无法发布（`signature_field_missing`）。#### 验证`validation` 适用于 `text` 字段：```json theme={null}
{ "kind": "any", "min_length": 0, "max_length": 80, "pattern": null, "message": null }
```- `kind`：`any`；`letters`（任何文字系统中的字母、空格、连字符和撇号）；`number`（带有可选小数分隔符的数字）；`email`；或 `pattern`。
- `min_length`：从 `0` 到 `max_length`。
- `max_length`：从 `1` 到 `500`。默认值为 `120`。
- `pattern`：当 `kind: "pattern"` 时为必填项。最多 200 个字符的正则表达式，整个值必须与该表达式匹配。不支持环视和反向引用。
- `message`：最多 120 个字符，用于替代默认错误消息。控制台预览、签署流程和 API 均适用相同的规则。#### 预填值`prefill` 指定字段值的来源：| `prefill` | 值 |
| - | - |
| `identity.full_name`, `identity.first_name`, `identity.last_name` | 签署人已验证身份证件上的姓名。 |
| `identity.date_of_birth` | 来自已验证的身份证件，格式为 `DD/MM/YYYY`。 |
| `identity.nationality`, `identity.document_number`, `identity.document_type`, `identity.issuing_country` | 来自已验证的身份证件。 |
| `identity.address` | 来自已验证身份证件的格式化地址，或来自同一会话中的地址证明。 |
| `contact.email`, `contact.phone` | 签署人已验证的邮箱或电话。 |
| `company.name`, `company.registration_number`, `company.address`, `company.country` | 已验证的企业（用于 KYB）。 |
| `session.vendor_data` | 会话的 `vendor_data`。 |
| `metadata.<key>` | 会话 `metadata` 中 `<key>` 的值（字符串形式）。 |
| `api.<key>` | 在您[创建会话](https://docs.didit.me/zh/sessions-api/create-session.md#字段值)时发送的 `sign.field_values` 中 `<key>` 的值。 |`data` 字段必须包含 `prefill`。`full_name` 字段始终使用 `identity.full_name`，`email` 字段使用 `contact.email`，而 `text` 字段也可以设置一个。`data`、`full_name` 和已验证的 `email` 字段的值在签署人开始签署时即已固定：会话后续发生的更改不会改变这些值。除非您设置了 `editable_when_prefilled`，否则预填的 `text` 或 `email` 字段为只读状态。当必填字段的来源在当时没有值（例如会话中没有地址）时，该字段将保持为空，签署人仍可继续签署。系统不会触发警告，[报告](https://docs.didit.me/zh/core-technology/electronic-signature/report-electronic-signature.md)中的 `value_unavailable_reason` 会说明原因。## 在控制台中进行设置1) 前往**工作流**，打开一个工作流，并在验证签署人的步骤之后添加**电子签名**步骤。
2) 在**文件**中，选择**上传**以添加 PDF 或 Word 文件，并拖动文件以调整签署人看到的顺序。Word 文件会转换为 PDF：在放置字段之前，请先检查转换后的页面。**替换**会替换文档文件并保留其字段，但新文件中已不存在的页面上的字段除外。
3) 在**在文件上放置字段**下，选择**打开编辑器**。从面板中将字段拖动到页面上，或选中字段后点击要放置的位置，然后移动并调整其大小。针对每个字段，设置**填写人**、其标签、是否为**必填**、接受的内容、其值的来源以及其 **API 密钥**（字段的 `key`）。**以签署人身份预览**可以展示签署人在手机或桌面上看到的文件效果。编辑器会在操作过程中自动保存（**已保存到草稿**），并在您选择**完成**之前列出需要修复的内容。
4) 仍是在**文件**中，选择文件的来源：**此工作流**、**每次会话**或**两者**。对于没有字段的文件，选择签署人是否必须**签署前阅读至末尾**并**每份文件单独同意**。
5) 在**签名**中，选择**签署人**、**级别**（**简单**为默认值，或**高级（AES）**；**合格（QES）**显示为**即将推出**）、**格式**以及验证码发送方式（**一次性验证码发送方式**）。
6) 在**规则**中，设置每个[警告](https://docs.didit.me/zh/core-technology/electronic-signature/warnings-electronic-signature.md)对结论的影响。
7) 在**高级**中，选择是否**通过电子邮件发送已签署副本**以及**添加证据页**，并设置签署链接的有效天数。您还可以添加自定义状态规则。
8) 保存工作流。如需通过 API 配置相同的步骤，请参阅[工作流功能配置](https://docs.didit.me/zh/management-api/workflows/feature-configs.md#电子签名)。工作流文件及其字段在控制台中进行管理；通过 API 时，请在每次会话中发送文件和字段。## 签署体验签署步骤可在托管验证页面、[Web SDK](https://docs.didit.me/zh/integration/web-sdks/overview.md) 和[原生 SDK](https://docs.didit.me/zh/integration/native-sdks/overview.md) 中运行，支持桌面端和手机端。您无需构建任何签署界面。1) **简介**。签署人会看到他们即将签署的文件。
2) **按顺序查看每份文件**。对于包含字段的文件，签署人将按 `position` 顺序填写各个字段。第一个签名或姓名缩写字段会打开一个面板，供其[采用签名](#采用签名)。可选字段标记为 **可选**。Didit 预填的值在页面上显示带有锁定图标，不作为填写步骤。点击页面上的字段可直接跳转至该字段。在手机上，一次在保持于键盘上方的面板中显示一个字段。在宽度至少为 1200 px 的屏幕上，文件页面与字段列表并排显示。如果必填字段仍为空便尝试完成文件，系统会提示剩余未填数量并跳转至第一个未填字段。不含字段的文件只需按您的配置进行阅读并同意。
3) **审核**。签署人再次查看文件，当其中任何文件包含字段时，同意以电子方式签署。
4) **验证码（仅限高级电子签名 (AES)）**。签署人请求接收验证码。验证码有效期为 5 分钟，60 秒后可重新发送，签署人最多可获取 5 次验证码并允许 3 次错误尝试。次数耗尽将记录为 `SIGNATURE_OTP_FAILED`。在初级电子签名级别下无需验证码：签署人直接从审核进入签署。
5) **已签署**。签署完成后，签署人可以下载已签署的文件。如果您启用了该功能，Didit 还会通过电子邮件向其发送一份副本。
6) **拒绝**。签署人可以选择拒绝而非签署。这将记录为 `SIGNATURE_DECLINED`。在签署链接有效期间，被拒绝的会话可以重新打开，以便签署人在改变主意时仍能完成签署。流程会在验证码过期、文件发生变更、签署失败或签署链接过期时提示签署人。签署链接在 `signature_link_validity_days` 天内有效（1 到 30 天，默认为 7 天），自会话创建时起算。会话保持开放的时间至少与此相同。> [!NOTE]
>
> 原生 SDK 从添加该功能的版本开始显示签署步骤，该版本在发布时会列在[原生 SDK 概述](https://docs.didit.me/zh/integration/native-sdks/overview.md)中。包含字段的文件需要支持字段的版本：旧版本无法显示这些字段，并且该步骤会显示错误。不含字段的文件在支持签署步骤的所有版本中均可使用。在您的应用运行支持工作流所用功能的版本之前，请引导用户访问托管页面或 Web SDK。### 采用签名签署人只需在文件首次要求提供签名或姓名缩写时，在一个面板中采用一次自己的签名和姓名缩写：- **键入**：以其选择的手写风格显示经过核验的姓名，标记为 **来自您的证件**。签署人无法键入其他姓名。键入的缩写取自该姓名的首字母。
- **手写**：用手指或鼠标绘制，包括签名和姓名缩写。后续的每个签名或姓名缩写字段只需点击一下即可应用，再次点击已应用的字段可将其取消。## 结果每位签署人的结果是[会话决策](https://docs.didit.me/zh/sessions-api/retrieve-session.md)以及[会话 Webhook](https://docs.didit.me/zh/integration/webhooks.md) 的 `decision` 中 `signatures[]` 的一个元素。没有单独的签名 Webhook：会话的 `status.updated` 事件会通知您何时获取决策。您将获得每份文件的已签署 PDF、每位签署人的证据 PDF，以及每份原始文件和已签署文件的 SHA-256 哈希值，以便您日后证明文件未被篡改。对于包含字段的文件，您还可以获取每个字段的值、其来源和填写时间，以及采用的签名和签署人同意进行电子签名的时间。有关每个字段、下载方式以及如何重新验证签名，请参阅[电子签名报告](https://docs.didit.me/zh/core-technology/electronic-signature/report-electronic-signature.md)。在控制台中，会话的 **签名** 标签页会显示文件，随后是包含每页预览的 **字段** 区块、采用的签名和姓名缩写，以及每个字段的值、时间和来源。[PDF 报告](https://docs.didit.me/zh/sessions-api/generate-pdf.md)包含签名部分，当文件含有字段时，还包含 **电子签名 · 字段** 页面。## 定价电子签名每完成一次已签署会话费用为 \$0.10，计入您的免费额度中，无论单次签署包含多少份文件，也无论级别是初级还是高级电子签名 (AES)。拒绝、失败或过期的签名不收费。合格电子签名 (QES) 为暂未推出的附加功能，目前尚无定价。## 删除签名数据当您[删除会话](https://docs.didit.me/zh/sessions-api/delete-session.md)时，其签名数据会随之一并删除：随会话发送的文件及其原始 Word 文件、为每位签署人准备的副本、已签署的 PDF、证据 PDF、采用的签名和姓名缩写图像，以及每个字段的值。其下载链接将失效。当会话在数据保留期结束时被删除，情况亦相同。删除操作不可逆，因此请先下载需要保留的所有内容。- 企业验证的已签署文件属于该企业的会话。删除该会话将一并删除这些文件。
- 从工作流中移除文件会将其彻底删除，连同其字段和原始 Word 文件。已经开始签署的签署人仍会保留其看到的副本（作为其会话的一部分），直到您删除该会话为止。请仅在没有等待签署的会话时从工作流中移除文件。
- Didit 已经通过电子邮件发送给签署人的副本保留在他们的邮箱中，不受影响。## 相关内容- [电子签名报告](https://docs.didit.me/zh/core-technology/electronic-signature/report-electronic-signature.md)：`signatures[]`、已签署 PDF、证据 PDF 和下载。
- [电子签名警告](https://docs.didit.me/zh/core-technology/electronic-signature/warnings-electronic-signature.md)：各项警告及控制该警告的规则。
- [创建会话](https://docs.didit.me/zh/sessions-api/create-session.md#电子签名文档)：按每次会话发送文件、字段和字段值。
- [工作流功能配置](https://docs.didit.me/zh/management-api/workflows/feature-configs.md#电子签名)：该步骤的各项设置。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.