Langsung ke konten utama

Gambaran umum

Laporan verifikasi identitas mencakup semua hal yang diekstraksi dan divalidasi Didit dari dokumen identitas resmi yang diterbitkan pemerintah — paspor, kartu identitas, SIM, dan izin tinggal. Laporan ini menggabungkan kolom dokumen dan data biografis hasil OCR, URL bertanda tangan ke media yang diambil, data alamat yang diurai dan diberi geolokasi, skor kualitas gambar per sisi, konten MRZ, rincian multi-aksara (Latin / non-Latin), serta kecocokan dokumen lintas sesi. Laporan ini dibuat setelah pengguna menyelesaikan langkah pengambilan dokumen dalam alur kerja (atau memanggil endpoint OCR mandiri). Didit mengidentifikasi jenis dokumen, menjalankan OCR, memvalidasi MRZ / kode batang / kode QR, mengurai alamat, memeriksa manipulasi (tangkapan layar, salinan cetak, manipulasi potret), dan membandingkan dokumen tersebut dengan setiap dokumen lain yang diambil dalam aplikasi Anda. Setiap laporan memiliki status-nya sendiri — terlepas dari status sesi secara keseluruhan — yang mencerminkan hasil penyelesaian langkah ID saja:
  • Disetujui — dokumen dikenali, semua kolom yang diperlukan diekstraksi, tidak ada peringatan yang memicu tindakan penolakan.
  • Dalam Peninjauan — satu atau lebih peringatan terpicu dan alur kerja Anda mengarahkannya ke peninjauan.
  • Ditolak — kondisi penolakan otomatis terpicu (dokumen tidak didukung, dokumen kedaluwarsa, potret tidak ada, terdeteksi dalam daftar blokir, kegagalan usia adaptif) atau peringatan yang tindakan terkonfigurasinya adalah penolakan terpicu (usia minimum/maksimum secara default adalah Penolakan).
  • Kedaluwarsa — expiration_date dokumen telah terlewati setelah verifikasi. Pemantauan kedaluwarsa berkelanjutan Didit mengubah laporan dari Approved menjadi Expired, menambahkan peringatan DOCUMENT_EXPIRED, dan memindahkan sesi yang disetujui ke status sesi Kyc Expired.
  • Belum Selesai — pengguna tidak pernah menyelesaikan langkah pengambilan.

Lokasi kemunculan dalam respons API

Laporan ID disertakan di dalam array id_verifications[] — selalu berupa array JSON, tidak pernah berupa objek id_verification tunggal. Beberapa entri muncul ketika alur kerja menjalankan lebih dari satu langkah dokumen (misalnya ID utama ditambah verifikasi lanjutan).
  • API keputusan sesi — GET /v3/session/{sessionId}/decision/ mengembalikan id_verifications[] di tingkat atas. Lihat Ambil keputusan sesi.
  • Webhook — payload session.status.updated menyertakan array id_verifications[] yang sama setelah langkah tersebut menghasilkan data. Lihat Webhook.
  • API OCR mandiri — pengiriman dokumen langsung mengembalikan objek id_verification tunggal dengan kolom yang sama. Lihat API OCR mandiri.
Baca response.id_verifications[0] dan lakukan iterasi pada array tersebut. Bentuk id_verification tunggal hanya ada pada API OCR mandiri — bentuk ini tidak ada pada endpoint keputusan v3.

Schema

Skema kanonis kolom-demi-kolom tersedia di halaman referensi Data models. Kolom-kolom di bawah ini diambil langsung dari IDVerificationV3Serializer, yang memperluas IDVerificationV2Serializer dan menambahkan node_id, array lintas-sesi matches[], serta array Silent Capture document_selfie_face_matches[].

Kolom tingkat atas

issuing_state selalu pada tingkat negara, tidak pernah sub-nasional. Untuk setiap jenis dokumen, termasuk surat izin mengemudi yang diterbitkan oleh negara bagian atau provinsi (Australia, Amerika Serikat, Kanada), issuing_state dan issuing_state_name melaporkan negara (misalnya AUS / Australia), bukan negara bagian. Nilai sub-nasional, jika dokumen memuatnya, tersedia secara terpisah di parsed_address.region (beralih ke extra_fields.state pada beberapa jenis dokumen). Ringkasan sesi Business Console menampilkan ini sebagai baris Wilayah di bawah Negara penerbit jika ada.
Surat izin mengemudi yang memuat dua nomor (Australia). Surat izin mengemudi Australia mencetak nomor lisensi, yang mengidentifikasi hak mengemudi pemegang dan tetap sama saat kartu diganti, serta nomor kartu, yang mengidentifikasi kartu fisik dan berubah pada setiap penerbitan ulang. Untuk lisensi ini Didit selalu memetakan nomor-nomor tersebut dengan cara yang sama:
  • personal_number — nomor lisensi
  • document_number — nomor kartu
Ini berlaku untuk setiap negara bagian dan wilayah Australia (NSW, VIC, QLD, WA, SA, TAS, ACT, NT). Pada beberapa varian, nomor kartu hanya dicetak di bagian belakang, sehingga hanya terbaca saat bagian belakang lisensi diambil. Jika tidak ada nomor kartu yang dapat dibaca, nomor lisensi dilaporkan sebagai keduanya, document_number dan personal_number, sehingga document_number selalu memuat sebuah pengidentifikasi setelah verifikasi selesai. personal_number tetap merupakan nomor lisensi dalam kedua kasus tersebut. Pada jenis dokumen lain, document_number tetap menjadi nomor utama hasil OCR dan dapat berupa pengidentifikasi tingkat pemegang itu sendiri.
CUIL Argentina adalah extra_fields.tax_number, bukan personal_number. Dokumen Argentina mencantumkan CUIL — pengenal 11 digit yang digunakan sebagai kunci oleh AFIP, ANSES, dan biro kredit — di tempat yang berbeda pada setiap dokumen, dan DNI mencantumkan nomor 11 digit kedua di sampingnya:
  • pada surat izin mengemudi (SIM), CUIL adalah nilai yang dibawa oleh personal_number;
  • pada DNI, personal_number membawa número de trámite, yang mengidentifikasi pengajuan kartu dan bukan merupakan pengenal bagi pemegangnya. CUIL DNI dibaca dari kolom cetaknya sendiri.
Oleh karena itu, personal_number bukanlah CUIL yang andal untuk Argentina: pada DNI, ini adalah nomor 11 digit yang secara senyap tidak akan mengembalikan hasil apa pun dari registri mana pun. Gunakan extra_fields.tax_number sebagai gantinya. Didit hanya melaporkannya jika nilainya tervalidasi sebagai CUIL nyata (awalan individu ditambah digit pemeriksaan modulo-11), dalam digit kanonik tanpa pemisah (27111111117), terlepas dari dokumen Argentina mana pun yang ditunjukkan oleh pemegang. Ketika CUIL kartu tidak dapat dibaca, kunci tersebut tidak ada, alih-alih diisi dengan nomor yang bukan CUIL — ambil surat izin mengemudi sebagai dokumen kedua, atau kumpulkan CUIL melalui jawaban Kuesioner atau metadata sesi, agar pengguna tersebut tercakup.

Skor kualitas gambar

front_image_quality_score dan back_image_quality_score masing-masing mengembalikan:
Gunakan overall_score sebagai pemeriksaan kelayakan cepat — skor di atas 70 umumnya menunjukkan tangkapan yang cukup baik untuk verifikasi yang andal.

Skor liveness dokumen

document_liveness melaporkan apa yang diukur oleh pemeriksaan liveness dokumen, terlepas dari apakah pemeriksaan tersebut memicu peringatan atau tidak. Peringatan hanya muncul ketika skor berada di bawah salah satu ambang batas alur kerja, sehingga sebelum adanya kolom ini dokumen yang disetujui tidak memuat bukti liveness sama sekali - kolom ini adalah cara Anda mengaudit sesi yang lolos. Kolom ini bernilai null jika pemeriksaan tidak dijalankan (misalnya metode non-dokumen, atau gangguan model yang tercatat dalam log sesi). Kolom ini memuat satu objek per jenis penipuan - portrait_replace, printed_copy, dan screen_replay - masing-masing dengan:
Untuk dokumen yang lebih lama tanpa bukti evaluasi yang tersimpan, skor yang tersimpan tetap terlihat tetapi ambang batas dan bucket bernilai null. Pengaturan alur kerja saat ini tidak pernah digunakan untuk merekonstruksi hasil historis. Hal yang sama berlaku untuk tangkapan yang evaluasi dokumennya belum selesai. Business Console menampilkan tiga baris yang sama di blok Liveness dokumen pada bagian Verifikasi Identitas sesi.

Kecocokan lintas sesi

matches[] mencantumkan hingga 5 dokumen lain di aplikasi Anda yang cocok dengan dokumen ini — tanggal lahir yang sama, negara penerbit yang sama, dan nama lengkap yang sangat mirip. Dokumen yang dimasukkan ke daftar blokir juga memerlukan kecocokan nomor dokumen yang persis. Sesi milik pengguna yang sama (vendor_data yang sama) dikecualikan. Setiap entri mencakup session_id, session_number, vendor_data, verification_date, user_details (name, document_type, document_number), status, is_blocklisted (true jika dokumen ditambahkan ke daftar blokir Anda), api_service, dan front_image_url yang ditandatangani.

Nilai status

Dokumen multi-aksara (Latin / non-Latin)

Beberapa dokumen — Kirgizstan, Kazakh, Rusia, Jepang, Korea, Tiongkok, Arab, Thailand, dan lainnya — mencetak nama, alamat, atau tempat lahir pemegang dokumen baik dalam transliterasi Latin maupun aksara lokal. Anda memilih aksara mana yang mengisi respons level teratas menggunakan pengaturan alur kerja (atau API mandiri) preferred_characters: Nilai aksara alternatif berada di dalam extra_fields di bawah kunci berakhiran: first_name_non_latin, last_name_non_latin, middle_name_non_latin, full_name_non_latin, address_non_latin, place_of_birth_non_latin (atau varian _latin yang cocok).

Kapan kolom aksara alternatif muncul

  • Hanya jika kedua aksara benar-benar ada pada dokumen. Jika kolom OCR yang secara nominal diberi label “Surname-Kyrgyz (Cyrillic)” diekstraksi sebagai teks beraksara Latin (homoglif atau transliterasi Latin), kolom tersebut tidak memenuhi syarat sebagai alternatif non-Latin dan kunci tersebut dihilangkan.
  • full_name_non_latin (dan full_name_latin) selalu direkonstruksi dari komponen nama depan, nama tengah, dan nama belakang individual jika keduanya tersedia — kolom mentah “Full Name” dari OCR diabaikan demi konsistensi.
  • Ketika preferred_characters=latin tetapi dokumen hanya memuat teks non-Latin (sehingga kolom level teratas menjadi non-Latin), Didit menjalankan tahap transliterasi dan mengekspos first_name_latin, last_name_latin, middle_name_latin, full_name_latin, place_of_birth_latin, dan address_latin sebagai fallback Latin.
last_name_non_latin tidak ada karena kolom “Surname (Cyrillic)” pada dokumen terbaca sebagai karakter Latin pada sampel ini — tidak ada nama belakang non-Latin asli yang dapat diekstraksi.

Contoh

Approved — kartu identitas Spanyol yang bersih (semua kolom)

In Review — QR tidak terdeteksi pada dokumen yang seharusnya memilikinya

Diringkas — respons sebenarnya selalu memuat rangkaian kolom lengkap seperti yang ditunjukkan di atas.

Catatan keamanan

URL yang ditandatangani yang dikembalikan untuk gambar dan video dokumen bersifat sementara — URL tersebut kedaluwarsa setelah jendela validitas terbatas. Perlakukan URL tersebut sebagai berumur pendek: segera unduh apa yang Anda perlukan dan jangan simpan dalam cache atau tampilkan secara publik. Biasanya aplikasi Anda hanya membutuhkan status, beberapa kolom data biografi, dan peringatan — simpan seminimal mungkin untuk memperkecil celah terhadap potensi pelanggaran keamanan di masa mendatang.

Terkait

Terakhir diubah pada 7 November 2026