> ## 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 через госреестры

> API проверки по госреестрам Didit: от $0.05/check с оплатой за запрос. 60+ стран, биометрическое сравнение лиц при наличии фото.

**Проверка по базам данных** Didit сверяет идентификационные данные человека с официальным источником в соответствующей стране — национальным реестром актов гражданского состояния, налоговой службой, списком избирателей, кредитным бюро или биометрическим реестром, который изначально выдал документ. Каждая проверка возвращает результат сопоставления по каждому полю (`identification_number`, `first_name`, `last_name`, `date_of_birth` и поля адреса, если сервис их использует), а также агрегированный результат и исходные данные записи, если они доступны.Это самая надёжная защита от мошенничества с синтетическими личностями: украденный реальный DNI или CPF не пройдёт проверку в реестре, а сфабрикованного номера в официальной базе данных просто не окажется. Проверка по базам данных работает в связке с нашей биометрической функцией сравнения лиц в странах, где реестр хранит официальную фотографию (Аргентина через RENAPER, Панама через Tribunal Electoral SIB / SIB Plus). Благодаря этому вы можете убедиться не только в подлинности номера, но и в том, что **человек перед камерой действительно является его владельцем**.

Промпт для интеграции проверки по базам данных



      
      

\<pre>

\````# Goal
Integrate Didit Database Validation (verify identity data against authoritative national registries) into your app. Pick ONE mode.

\# Mode A — Session-based
Use this when Database Validation runs as a step in a hosted Didit flow. Fields are auto-fed into the registry lookup from the steps in front of it — ID Verification, NFC, Liveness, Phone/Email Verification, Proof of Address, Document AI or a Questionnaire. An ID Verification step is not required.

1\. Add the DATABASE_VALIDATION feature to the workflow (Business Console or POST /v3/workflows/). Optionally pin specific services per country.
2\. Create a session — POST /v3/session/ with { workflow_id, vendor_data, callback }. See /sessions-api/create-session.
3\. Open session.url for the user (or mount the Web/Mobile SDK).
4\. Fetch the decision — GET /v3/session/{sessionId}/decision/ or subscribe to session.status.updated.

Decision surface: `database_validations[]` array on the decision payload.

\# Mode B — Standalone API (server-to-server)
Use when you already have the identity data and want a one-shot registry check.

POST https://verification.didit.me/v3/database-validation/
multipart/form-data — x-api-key: YOUR_API_KEY

curl example (Brazil CPF):
\```bash
curl -X POST 'https://verification.didit.me/v3/database-validation/' \
-H "x-api-key: $DIDIT_API_KEY" \
-F "issuing_state=BRA" \
-F "identification_number=00000000191" \
-F "first_name=Jane" \
-F "last_name=Doe" \
-F "date_of_birth=1990-01-15" \
-F "vendor_data=user-1234"
\```
Returns: { request_id, database_validation: { match_type: "full_match"|"partial_match"|"no_match", validation_type, services_used, match_score, validations: [{ service, status, matched_fields, record_details }], warnings: [...] } }.

\# Important behaviour
\- Use `identification_number` (universal field) — Didit maps it to CPF/RUT/CURP/DNI/etc. by issuing_state.
\- Omit `services` to run the country's default service only. Pass `services=["bra_cpf"]` (etc.) to choose which services run — list several to run more than one.
\- Argentina (`arg_renaper`) and Panama (`pan_sib`) take an extra `selfie` (JPG/PNG/WebP up to 2 MB) and `gender` for biometric face-match against the registry photo.
\- Services flagged `requires_consent=true` in the catalog require `consent=true` (HTTP 400 otherwise).
\- Billing is **per successful service hit** — multi-service requests can produce multiple usage events.

\# Status / match_type
status: "Approved" | "In Review" | "Declined" (per the partial-match / no-match actions configured on the workflow)
match_type: "full_match" | "partial_match" | "no_match"

\# Warnings (LogWarningChoices.DATABASE_VALIDATION)
warnings[] risk codes include:
DATABASE_VALIDATION_NO_MATCH, DATABASE_VALIDATION_PARTIAL_MATCH, COULD_NOT_PERFORM_DATABASE_VALIDATION (biometric outcomes surface via per-service outcome_code, e.g. BIOMETRIC_NO_MATCH).
Full catalogue: /core-technology/database-validation/database-validation-warnings.

\# Failure modes to handle
\- HTTP 400 — service id not eligible for issuing_state, missing required field, missing consent for PAYGO services.
\- HTTP 502 with validation_errors[] — every selected upstream service failed; request is **not billed** and a COULD_NOT_PERFORM_DATABASE_VALIDATION log is written. Retry later or fall back to OCR-only.
\- match_type="no_match" — record not in registry; treat as synthetic identity per policy.
\- match_type="partial_match" — some fields match, others don't (e.g. DOB matches, name doesn't); route to review.

\# See also
\- Canonical schema: /reference/data-models#database-validation
\- Per-feature report: /core-technology/database-validation/database-validation-report
\- Risk catalogue: /core-technology/database-validation/database-validation-warnings
\- Outcome codes: /core-technology/database-validation/database-validation-outcome-codes
\- Full integration playbook: /integration/integration-prompt````

\</pre>

## Почему Didit- **Самые низкие цены с оплатой за запрос.** От **\$0.05** за проверку (Доминиканская Республика) до **\$7.00** для самых дорогих специализированных источников. Цена устанавливается за сервис, а не за страну — если реестр взимает высокую оптовую ставку, цена формируется соответственно (национальное удостоверение Финляндии стоит **\$2.10**). Актуальный тариф для конкретного сервиса всегда можно посмотреть в [таблице цен по сервисам](https://docs.didit.me/ru/getting-started/database-validation-pricing.md). Никаких ежемесячных минимумов, плат за платформу или тарификации за места — оплачиваются только успешные запросы.
- **Самая быстрая интеграция.** [Зарегистрируйтесь](https://business.didit.me/), получите API-ключ в консоли и вызывайте `POST /v3/database-validation/` уже через несколько минут. Никаких звонков в отдел продаж, циклов закупки и документов для проверки концепции — Didit полностью работает в режиме самообслуживания.
- **Прямые запросы к официальным источникам.** RENAPER, Receita Federal (SERPRO), Tribunal Electoral, RENAPO, RENAP, RNP, RNPN, Junta Central Electoral, Registraduría Nacional, SEGIP, Servicio de Registro Civil, Tribunal Supremo de Elecciones, Dirección General de la Policía — никаких данных, собранных парсингом агрегаторов.
- **Биометрическое сравнение лиц, если в реестре есть официальное фото.** Уверенность выше, чем при OCR, без дополнительных работ по интеграции.
- **Задержка, соответствующая требованиям продакшн-среды.** Сквозная задержка p95 обычно составляет менее 1.5 с, квартальная доступность 99.9%.Урок Didit Academy по чтению результатов верификации доходит до проверки по базам данных на отметке 11:05 и демонстрирует полное и частичное совпадение, а также отсутствие совпадения.[Проверка по базам данных: полное, частичное совпадение и отсутствие совпадений — Didit Academy](https://www.youtube.com/embed/7htTWCWsl60?start=665\&rel=0\&playsinline=1)## Глобальное покрытиеНаведите курсор на любую подсвеченную страну, чтобы увидеть все доступные в ней сервисы проверки по базам данных, категорию данных (идентификационные данные, финансовые данные, биометрические данные, адресные данные, телекоммуникационные данные, …) и цену за запрос. Страны, доступные в продакшне, готовы к использованию уже сегодня; остальные подключаются по запросу клиента.Live Database Validation coverageProduction-ready countries and the cheapest live service available in each.LIVE<details><summary>Show on-demand catalog countries ()</summary></details>> [!TIP]
>
> **Не нашли нужную страну?** Свяжитесь с нами — наш каталог насчитывает 60+ стран с сотнями сервисов, которые мы активируем по запросу клиентов. Подключение новых интеграций обычно занимает 2–3 недели.## Как проходит Проверка по базам данныхПроверка по базам данных никогда не запускается наугад. Она выполняется только тогда, когда соблюдены **все** следующие условия:1) В сессии определена страна для запроса — из поля `issuing_state` шага [Верификация личности](https://docs.didit.me/ru/core-technology/id-verification/overview.md) либо, если в сценарии нет шага Верификации личности, из единственной страны, настроенной для шага Проверки по базам данных.
2) Для этой страны в сценарии включен хотя бы один сервис Проверки по базам данных.
3) Шаги, предшествующие шагу Проверки по базам данных, предоставили **все обязательные поля**, необходимые выбранному сервису.Если сервис включен, но обязательные поля так и не поступили (например, CPF не удалось извлечь из размытого бразильского RG), сервис пропускается, **с вас не взимается плата**, а для сессии формируется предупреждение: `DATABASE_VALIDATION_NOT_APPLICABLE`, если в документе попросту нет идентификатора, по которому этот сервис делает запрос, или `COULD_NOT_PERFORM_DATABASE_VALIDATION`, если он должен был присутствовать, но отсутствовал. Оба предупреждения перечислены в [каталоге предупреждений](https://docs.didit.me/ru/core-technology/database-validation/database-validation-warnings.md).Сотрудник вашей команды с правами на проверку сессии может вручную заполнить недостающее поле на странице сведений о сессии в Console, и сохранение изменений автоматически перезапустит проверку. Это действие проверяющего, а не то, что может сделать конечный пользователь. Чтобы позволить **пользователю** предоставить поле, которого нет в его документе, запросите его в Анкетах (либо через извлечение в Document AI, либо в виде значения, передаваемого при создании сессии) и сопоставьте его на шаге Проверки по базам данных, как описано ниже.### Проверка по базам данных не требует Верификации личностиРаньше шаг Проверки по базам данных предполагал обязательное наличие предшествующего шага Верификации личности, поскольку OCR документа, удостоверяющего личность, было единственным встроенным способом получить данные конечного пользователя. Теперь это не так: **для каждого обязательного поля указывается, какие шаги могут его предоставить**, и сервис становится доступным, как только ваш сценарий начинает содержать шаг, предоставляющий все необходимые ему поля.| Источник входных данных | Предоставляет |
| - | - |
| Верификация личности | Имена, дату рождения, адрес, номер документа/персональный номер и специфичные для страны идентификаторы, указанные на документе (налоговый номер, национальный ID, номер паспорта, номер водительского удостоверения, …) |
| NFC | Считанный с чипа набор тех же данных с более высоким уровнем доверия |
| Проверка живости | Селфи в реальном времени для сервисов реестров с распознаванием лиц по биометрии |
| Проверка телефона | Подтверждённый номер телефона |
| Проверка электронной почты | Подтверждённый адрес электронной почты |
| Подтверждение адреса | Подтверждённый адрес проживания и его компоненты |
| Document AI | Любое поле, сопоставленное с одним из ваших ключей извлечения |
| Анкеты | Любое поле, сопоставленное с одним из ваших вопросов |
| Входные данные API | Любые данные в автономном API — вызывающая сторона передаёт значения напрямую |Это означает, что **сервис биометрической идентификации по лицу может работать только на основе шага Проверки живости**, без какого-либо документа, удостоверяющего личность, в сценарии, а сервис, использующий налоговый номер, номер телефона или адрес электронной почты, может получить соответствующее значение из ответа на вопрос анкеты, шага Проверки телефона или Проверки электронной почты или извлечения через Document AI.Безопасность обеспечивается двумя правилами:- **Сценарий без Верификации личности должен содержать ровно одну настроенную страну** на шаге Проверки по базам данных. Без поля `issuing_state` из документа это единственный однозначный сигнал о том, к какому национальному реестру обращаться, поэтому конфигурация для нескольких стран без Верификации личности ничего не запустит, чтобы избежать догадок.
- **Проверка обязательных полей остаётся неизменной.** Сервис, для которого на момент выполнения предоставлены не все поля, пропускается до отправки запроса какому-либо провайдеру, поэтому с вас никогда не списываются средства за обращение к базе данных, к которой фактически не обращались.#### Сопоставление полей Document AI и анкетПоля извлечения Document AI и вопросы анкет используют *ваши* имена ключей, а не имена Didit. Ключ, точно совпадающий с именем входного поля Проверки по базам данных (`tax_number`, `date_of_birth`, `phone`, …), сопоставляется автоматически и не требует настройки. Для всех остальных редактор сценариев отображает на шаге Проверки по базам данных список ещё не заполненных полей, где вы указываете для каждого из них соответствующий ключ поля Document AI или ответ из анкеты.В Console сервис, который ваш сценарий пока не может выполнить, отображается отключённым с указанием причины — какие поля отсутствуют и какой шаг мог бы их предоставить — а редактор предлагает добавить этот шаг. Его добавление сразу же активирует все сервисы, которые он разблокирует.> [!TIP]
>
> **Практический пример — идентификатор, отсутствующий в документе.** Сервис национальных ID Нигерии выполняет запрос по 11-значному NIN, который часто не напечатан на загружаемых пользователями документах. Поэтому опора исключительно на документ приводит к тому, что проверка пропускается как неприменимая для значительной доли пользователей. Добавьте шаг **Анкеты** перед шагом Проверки по базам данных с запросом NIN, а затем сопоставьте `national_id` с этим вопросом на шаге Проверки по базам данных. Такое же сопоставление позволяет использовать внутри сценария идентификаторы, которых вообще никогда не бывает на документах — например, банковский верификационный номер или регистрационный номер компании.Для сервисов, работающих на основе адреса, Didit автоматически разбивает единый `address` из документа на структурированные адресные элементы:| Поле Didit | Значение |
| - | - |
| `address_element_1` | Адрес улицы, включая номер и тип улицы |
| `address_element_2` | Номер квартиры/офиса, корпус, этаж или дополнительная строка адреса (необязательно) |
| `address_element_3` | Пригород, район, населённый пункт или микрорайон |
| `address_element_4` | Город, населённый пункт, штат, провинция или регион |
| `address_element_5` | Почтовый индекс |При вызове автономного API вы можете передавать как единую строку `address`, так и эти структурированные поля напрямую. При наличии обоих вариантов приоритет имеют структурированные поля. Сервисам, требующим поиска по адресу, необходим `address_element_1` плюс хотя бы один дополнительный элемент адреса; если Didit не сможет извлечь их из документа, удостоверяющего личность, или Подтверждения адреса в сценарии, сервис пропускается и плата не взимается.Если определённая страна не включена вовсе, шаг пропускается без уведомлений, без предупреждений и без списания средств.![Didit database validation flow checking user data against government identity registries](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/database-validation-how-it-works.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=3d5bb0df058265af0d8728cd60a78416)## Результат сопоставленияКаждый включённый сервис возвращает результат проверки для каждого поля:| Поле | Результаты |
| - | - |
| `identification_number` | `full_match` · `partial_match` · `no_match` |
| `first_name` | `full_match` · `partial_match` · `no_match` |
| `last_name` | `full_match` · `partial_match` · `no_match` |
| `date_of_birth` | `full_match` · `no_match` |
| `address` | `full_match` · `partial_match` · `no_match` |Агрегированный `match_type` сводится к следующим значениям:- **`full_match`** — каждое запрошенное поле совпадает как минимум с одним источником.
- **`partial_match`** — частичное совпадение; кейс направляется в очередь на проверку согласно правилам вашего сценария.
- **`no_match`** — ни один источник не подтвердил данные; обычно следует отклонить.## Как определяется сопоставление (1×1 / 2×2)Мы больше не требуем заранее выбирать «1×1» или «2×2» — они определяются тем, сколько отдельных сервисов вернули полное совпадение с входными данными:- **Результат 1×1** — один сервис вернул полное совпадение (данные подтвердил один авторитетный источник).
- **Результат 2×2** — два или более сервисов вернули полное совпадение (независимое подтверждение; максимальный уровень уверенности).В сценарии можно включить любое количество сервисов для каждой страны; оплата взимается за каждый сервис, который фактически вернул результат. Сервисы, для которых не удалось извлечь обязательные поля, пропускаются без взимания платы.➡️ Полную логику принятия решений и то, как она взаимодействует с `partialMatchAction` / `noMatchAction`, см. в разделе **[Методы сопоставления](https://docs.didit.me/ru/core-technology/database-validation/database-validation-matching-methods.md)**.## Биометрическая проверка по базам данныхРеестры актов гражданского состояния некоторых стран содержат биометрический шаблон (портрет или отпечаток пальца). Если он доступен, мы совмещаем поиск по реестру с биометрическим **сравнением лиц** с селфи пользователя:- **Аргентина (`arg_renaper`)** — биометрическое сравнение лиц с официальной фотографией из базы RENAPER. Охват населения 100%; каждый гражданин Аргентины с DNI внесён в базу данных.
- **Панама (`pan_cedula_sib`, `pan_cedula_sib_plus`)** — биометрическое сравнение лиц через сервис SIB избирательного трибунала (Tribunal Electoral). SIB Plus представляет собой вариант повышенного уровня с более строгими биометрическими порогами и более подробными метаданными сопоставления.Для этих сервисов поле `selfie` является **обязательным**. В рамках сессии повторно используется селфи из проверки живости (наивысшее качество), а в качестве запасного варианта используется портрет из документа. Вне сессии, при вызове автономного API (`POST /v3/database-validation/`, режим B выше), вы передаёте JPEG/PNG самостоятельно.## Глобальное обогащение данных о личности`glb_identity_enrichment` представляет собой **глобальный сервис Проверки по базам данных, доступный только через автономный API**. По адресу электронной почты и/или номеру телефона он определяет связанных физических лиц (имена, даты рождения, адреса, телефоны, адреса электронной почты и национальные идентификаторы) и возвращает оценку совпадения имени, сопоставленную со стандартными [кодами результатов](https://docs.didit.me/ru/core-technology/database-validation/database-validation-outcome-codes.md) `MATCH` / `PARTIAL_MATCH` / `NO_MATCH` / `DOCUMENT_NOT_FOUND` (с соответствующим `match_type`: `full_match` / `partial_match` / `no_match`).Поскольку это глобальный сервис (`GLB`), привязанный к электронной почте или телефону, а не к стране выдачи документа, он **недоступен в конструкторе сценариев**. Вызывайте его напрямую через автономный API с параметром `issuing_state`, установленным в `GLB`:```json theme={null}
POST /v3/database-validation/
{
  "issuing_state": "GLB",
  "services": ["glb_identity_enrichment"],
  "email": "john.doe@example.com",
  "phone": "+14155552671"
}
```Его стоимость составляет **\$0.20 за запрос** (плата взимается только в том случае, если провайдер возвращает результат).## НастройкаПроверка по базам данных настраивается индивидуально для каждого сценария в Console. Для каждой страны вы выбираете конкретные сервисы, которые хотите запускать; обязательные и необязательные входные поля определяются объединением требований этих сервисов. Действие, выполняемое при результатах `partial_match` и `no_match`, настраивается отдельно и может принимать значения `approve`, `review` или `decline`.![Настройки проверки по базам данных в Didit Console: выбор сервисов реестров для отдельных стран и правил для результатов](https://mintcdn.com/didit-0f962782/z6T2GHM4Zh-iSj-K/images/database-validation-console.png?fit=max\&auto=format\&n=z6T2GHM4Zh-iSj-K\&q=85\&s=2e1ac27f07fa9ca9c54108c6fd19a6b3)## Уведомления о доступностиГосударственные реестры и другие источники периодически выходят из строя. Пока база данных недоступна, проверки по ней не возвращают ответа и за них не взимается плата. Внутри сценария сервис переходит в статус [`REGISTRY_UNAVAILABLE`](https://docs.didit.me/ru/core-technology/database-validation/database-validation-outcome-codes). В отдельном API такой сбой может проявляться в одной из трёх форм, поэтому обязательно проверяйте результаты по каждому сервису **и** `database_validation.errors[]`, а не только HTTP-статус:- `200` с `outcome_code: "REGISTRY_UNAVAILABLE"` у этого сервиса в `validations`, если Didit сохранил результат, о котором можно сообщить.
- `200` с этим сервисом в `database_validation.errors[]` как `code: "empty_provider_response"`, `retryable: true`, когда сервис не вернул пригодного для использования ответа, но другой выбранный сервис ответил успешно. В этом случае сбойный сервис отсутствует в `validations` и в `services_used`, поэтому `errors[]` является единственным местом, где он отображается.
- `502` с `validation_errors[].code: "empty_provider_response"` и `retryable: true`, когда ни один из выбранных сервисов не вернул пригодного для использования результата (см. [отклонённые входные данные и недоступные результаты](https://docs.didit.me/ru/standalone-apis/database-validation.md#отклонённые-данные-и-недоступные-результаты)).Общий `status` определяется сервисами, которые вернули ответ, поэтому сам по себе он не является надёжным индикатором сбоя. Запрос, в котором не с чем было выполнить сравнение, переходит в статус `In Review`, но запрос, в котором было выбрано несколько сервисов, может получить статус `Approved` на основе совпадения из другого сервиса, даже если один из источников был недоступен. Повторите проверку только для сбойного сервиса, указанного в `errors[]`, а не весь запрос целиком.Ни один из этих вариантов ничего не говорит о проверяемом человеке.Didit отслеживает фактические результаты реальных проверок по каждой базе данных отдельно и отправляет вашей организации уведомление по электронной почте, если сбой затянулся, а не представляет собой единичный неудачный запрос:| Письмо | Когда отправляется | О чём сообщает |
| - | - | - |
| **Сбой в работе базы данных** | Проверки по базе данных завершаются сбоем не менее десяти минут, и почти все проверки за этот период остались без ответа. Кратковременный всплеск или единичный сбой никогда не вызывают отправку уведомления. | Какая база данных и страна затронуты, а также когда сбои были зафиксированы впервые. Проверки могут не возвращать результат до восстановления доступа; это не означает, что предоставленные данные о личности недействительны. |
| **Доступ к базе данных восстановлен** | Реальные проверки снова возвращают ответы без сбоев на протяжении не менее пяти минут. Периоды затишья никогда не считаются восстановлением, поэтому базе данных с низким объёмом трафика требуется больше времени для подтверждения обоих состояний. | Когда восстановление было подтверждено. Верификации, которые не удалось завершить во время сбоя, **не** обрабатываются повторно автоматически: проверьте их и повторите попытку. |Уведомления направляются участникам и контактам по биллингу каждой организации, которая выполняла проверку именно по этой базе данных за последние 48 часов. Ничего настраивать не требуется, и отдельно подписываться не нужно. Трафик в песочнице никогда не инициирует такие уведомления, как и сбои, вызванные отправленными вами данными (отклонённые или некорректно сформированные входные данные), либо сервисами, работающими с учётными данными, подключёнными вашей собственной организацией. Проверка, получившая ответ через резервный источник, считается доступной, как и окончательный результат об отсутствии совпадения.## Цены — платите только за то, что используетеПроверка по базам данных тарифицируется **за каждый успешный запрос к каждому сервису** по ставке, опубликованной для данного сервиса. Ставки варьируются от **\$0.05** за проверку (Доминиканская Республика через Junta Central Electoral) до **\$7.00** для самых дорогих специализированных источников. Запросы ко многим государственным реестрам находятся в диапазоне **от 0.20 до 0.30 USD**, однако целый ряд источников стоит значительно дороже, поскольку сам источник взимает более высокую плату — например, проверка удостоверения личности Финляндии (`fin_national_id`) стоит **\$2.10** за успешный запрос. Определяйте цену для страны по её собственной строке в [таблице цен](https://docs.didit.me/ru/getting-started/database-validation-pricing.md), а не по диапазону. Здесь нет ежемесячных минимальных платежей, обязательств или комиссий за использование платформы.Вы платите только тогда, когда сервис возвращает результат. Сервисы, пропущенные из-за отсутствия входных данных, не тарифицируются. Не тарифицируется и сервис, вызов источника которого завершился ошибкой: ошибка реестра или его недоступность (`REGISTRY_ERROR` / `REGISTRY_UNAVAILABLE`) означают, что запрос так и не получил ответа, поэтому такой результат не подлежит оплате.Каждый успешный запрос к реестру оплачивается начиная с самого первого, независимо от того, выполняется ли он в рамках сценария или через отдельный API `POST /v3/database-validation/`. Он списывается с кредита вашего тарифа или баланса пополнения, как и любая другая проверка, и скидка по вашему тарифу применяется ко всей его стоимости. См. [страницу с ценами](https://docs.didit.me/ru/getting-started/pricing.md#скидки).➡️ [Цены на Проверку по базам данных](https://docs.didit.me/ru/getting-started/database-validation-pricing.md) · [Зарегистрироваться и получить API-ключ](https://business.didit.me/)## Все сервисы

\<table><thead><tr><th>Страна</th>
            \<th>ISO3</th>
            \<th>Услуга</th>
            \<th>Описание</th>
            \<th>Цена (USD)</th></tr></thead>
        \<tbody /></table>

## Что читать дальше- [Методы сопоставления](https://docs.didit.me/ru/core-technology/database-validation/database-validation-matching-methods.md) — как формируются результаты 1×1 / 2×2 и как на них реагировать.
- [Коды результатов](https://docs.didit.me/ru/core-technology/database-validation/database-validation-outcome-codes.md) — полный список кодов ответов провайдеров (умерший, несовершеннолетний, документ не найден, биометрическое несовпадение, …) и их сопоставление с решениями по сессиям.
- [Предупреждения](https://docs.didit.me/ru/core-technology/database-validation/database-validation-warnings.md) — что отображается, когда сервис не может быть запущен из-за отсутствия данных.
- [Отчёты](https://docs.didit.me/ru/core-technology/database-validation/database-validation-report.md) — ежемесячные выгрузки биллинга по сервисам с указанием страны, идентификатора сервиса, объёма использования, цены за единицу и общей стоимости.
- [Поддерживаемые страны](https://docs.didit.me/ru/core-technology/database-validation/database-validation-supported-countries.md) — статическая таблица со всеми странами, которые поддерживаются на сегодняшний день.


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