{prompt.trim()}| Country | ISO3 | Service | Description | Price (USD) |
|---|---|---|---|---|
| {row.label} | ||||
| {row.country_name} | {row.country_iso3} |
{row.service_name}
{row.service_id}
|
{row.description} | ${row.default_price_usd.toFixed(2)} |
Hover any highlighted country to see its services and per-call pricing.
{false && active &&{s.service_id}
{s.price != null && · {formatPrice(s.price)}}
## The match outcome
Each enabled service returns a per-field validation:
| Field | Outcomes |
| ----------------------- | ------------------------------------------- |
| `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` |
The aggregated `match_type` rolls up to:
* **`full_match`** — every requested field agrees with at least one source.
* **`partial_match`** — some agreement; route to a review queue per your workflow rules.
* **`no_match`** — no source confirmed the data; usually decline.
## How matching is derived (1×1 / 2×2)
We do not ask you to pre-pick "1×1" or "2×2" anymore — those are derived from how many distinct services full-matched the input data:
* **1×1 outcome** — one service returned a full match (a single authoritative source confirmed the data).
* **2×2 outcome** — two or more services returned a full match (independent corroboration; the highest confidence we can express).
A workflow can enable any number of services per country; you are billed per service that actually returned a result. Services whose required fields couldn't be extracted are skipped with no charge.
➡️ See **[Matching Methods](./database-validation-matching-methods)** for the full decision logic and how it interacts with `partialMatchAction` / `noMatchAction`.
## Biometric Database Validation
Some countries' civil registries publish a biometric template (a portrait or a fingerprint). When that's available, we pair the registry lookup with a **biometric face-match** against the user's selfie:
* **Argentina (`arg_renaper`)** — biometric face-match against the official RENAPER photo on file. 100% population coverage; every Argentine citizen with a DNI is in the database.
* **Panama (`pan_cedula_sib`, `pan_cedula_sib_plus`)** — biometric face-match against the Tribunal Electoral SIB service. SIB Plus is the elevated-tier variant with stronger biometric thresholds and richer match metadata.
For these services the `selfie` field is **required**. Inside a session flow we re-use the liveness selfie (highest quality) and fall back to the document portrait. Outside a session, when calling the standalone API (`POST /v3/database-validation/`, Mode B above), you supply the JPEG/PNG yourself.
## Configuration
Database Validation is configured per-workflow from the Console. For each country you select the specific services you want to run; required and optional input fields are derived from the union of those services. The action taken on `partial_match` and `no_match` outcomes is configured separately and can be `approve`, `review`, or `decline`.
## Pricing — pay only for what you use
Database Validation is billed **per successful query, per service**. The lowest tier starts at **\$0.05** per check (Dominican Republic via Junta Central Electoral). Standard government-registry checks cost **\$0.20–\$0.30**, and biometric premium tiers (Panama SIB Plus) cost **\$1.50**. There are no monthly minimums, no commitments, no platform fees.
You only pay when a service returns a result. Services that skip because of missing input data are not billed.
➡️ [Database Validation Pricing](/getting-started/database-validation-pricing) · [Sign up and get an API key](https://business.didit.me/)
## All services