Menempelkan tanda tangan elektronik ke aplikasi sendiri sering dibayangkan sebagai pekerjaan sehari: panggil endpoint, terima balasan, selesai. Kenyataannya bagian yang paling menyita waktu justru setelah dokumen dikirim — memastikan statusnya tidak nyangkut, memastikan yang meneken benar orang yang dimaksud, dan memastikan buktinya masih utuh saat suatu hari dipersoalkan.
Kalau kamu sedang menyiapkan integrasi e-signature untuk aplikasi web, tiga hal itu yang sebaiknya dibereskan lebih dulu, bukan warna tombol di halaman tanda tangan.
Rancang alurnya dulu, endpoint-nya belakangan
Sebelum membuka dokumentasi penyedia, tulis dulu di kertas: siapa yang mengirim dokumen, siapa saja yang harus menandatangani, urutannya bagaimana, berapa lama tautan tanda tangan berlaku, dan apa yang terjadi kalau salah satu pihak membatalkan di tengah jalan. Pertanyaan-pertanyaan ini menentukan bentuk API-mu, bukan sebaliknya.
Urutan penandatangan mengubah bentuk data
Kalau dua pihak boleh meneken kapan saja, kamu hanya perlu daftar penerima. Tapi begitu urutannya berjenjang — direktur dulu, baru mitra — kamu butuh konsep giliran. Siapa yang sedang giliran, siapa yang menunggu, dan apa yang terjadi kalau orang pertama menolak.
Simpan status dokumen sebagai satu rangkaian yang jelas: draf, terkirim, sebagian ditandatangani, selesai, kedaluwarsa, dibatalkan. Jangan pakai kolom boolean is_signed yang cuma punya dua nilai. Dokumen yang punya empat penandatangan akan membuat kolom itu bohong.
Endpoint yang perlu kamu siapkan
Untuk kebutuhan umum, daftarnya tidak panjang. Buat amplop dokumen, unggah berkas PDF, daftarkan penandatangan, kirim untuk ditandatangani, cek status, unduh dokumen final, dan batalkan. Tujuh endpoint itu sudah cukup untuk sebagian besar alur.
Dua hal kecil yang sering dilewatkan dan kemudian merepotkan:
- Hash dokumen sebelum dikirim. Hitung sidik digital berkas asli, simpan nilainya. Setelah dokumen selesai, hitung ulang dan bandingkan. Kalau berbeda, ada sesuatu yang berubah di tengah jalan dan kamu tahu sebelum klien yang menemukannya.
- Idempotency key untuk permintaan kirim. Jaringan putus lalu pengguna menekan tombol dua kali, dan tiba-tiba ada dua permintaan tanda tangan untuk dokumen yang sama. Kunci idempotensi menutup celah itu tanpa perlu debat internal.
Webhook yang tidak bikin status nyangkut
Mengandalkan polling untuk memantau status itu jalan pintas yang mahal dan rapuh. Webhook jauh lebih masuk akal, tapi hanya kalau kamu memperlakukannya sebagai sistem yang bisa gagal, bukan sebagai panggilan fungsi yang selalu berhasil.
Verifikasi asal webhook
Endpoint webhook-mu terbuka ke internet, jadi siapa pun bisa mengirim payload palsu yang mengaku dokumen sudah selesai. Verifikasi tanda tangan permintaan dari penyedia — biasanya berupa nilai HMAC dari isi payload dengan rahasia bersama. Kalau tidak ada mekanisme itu, jangan pernah percaya isinya; ambil status langsung dari API penyedia.
Event bisa datang dua kali dan tidak berurutan
Ini bukan kasus langka, ini kasus normal. Simpan ID setiap event dan tolak yang sudah pernah diproses. Lalu jangan mengambil keputusan berdasarkan urutan kedatangan. Kalau event "selesai" tiba sebelum "dikirim", percaya saja yang terbaru dan jangan menurunkan status dokumen yang sudah tinggi.
Sediakan juga jalur rekonsiliasi harian. Kalau webhook gagal berkali-kali, penyedia biasanya berhenti mencoba. Tanpa pengecekan berkala, kamu baru sadar ada dokumen yang macet saat klien menelepon.
Validasi identitas penandatangan jangan berhenti di OTP
Mengirim kode sekali pakai ke email hanya membuktikan satu hal: orang itu bisa membuka kotak masuk. Itu bukan identitas. Untuk dokumen bernilai kecil, mungkin cukup. Untuk perjanjian yang mengikat uang, tidak.
Secara praktis ada tiga tingkat yang biasa dipakai, dan kamu bisa memilih per jenis dokumen, bukan satu tingkat untuk semuanya:
- Tingkat dasar — tautan unik plus kode ke email atau nomor telepon. Murah, cepat, cocok untuk persetujuan internal.
- Tingkat menengah — pencocokan data kependudukan ditambah foto diri atau deteksi gerak untuk memastikan yang meneken benar-benar orangnya, bukan yang memegang fotonya.
- Tingkat tersertifikasi — tanda tangan memakai sertifikat elektronik dari penyelenggara yang diakui, dengan passphrase atau perangkat kriptografi yang dipegang penandatangan.
Catat metode verifikasi yang dipakai di jejak audit. Saat dokumen dipersoalkan, pertanyaan pertama biasanya bukan "apakah tanda tangannya asli", melainkan "bagaimana kamu tahu orang itu benar-benar dia". Jawaban yang bisa ditunjukkan lebih berguna daripada keyakinan.
Menempelkan meterai elektronik di alur yang sama
Di Indonesia, banyak dokumen perjanjian juga wajib dibubuhi bea meterai. Meterai elektronik dan tanda tangan elektronik adalah dua hal berbeda yang sering dianggap sama. Meterai soal pemenuhan kewajiban pajak atas dokumen, tanda tangan soal persetujuan dan keabsahan. Keduanya bisa hidup di satu berkas, tapi urutannya perlu dipikirkan.
Yang penting: isi dokumen tidak boleh berubah setelah meterai dibubuhkan. Kalau ada revisi, meterai lama tidak lagi menempel pada dokumen yang sah dan harus dibubuhkan ulang. Karena itu, kunci alurnya di tahap penyuntingan — pastikan dokumen benar-benar final sebelum masuk ke tahap pembubuhan dan penandatanganan.
Satu lagi yang sering terlewat: kode atau token meterai bersifat sekali pakai. Jangan pernah menyimpannya di log aplikasi atau menampilkannya kembali di halaman riwayat. Itu sama saja menempelkan materai di papan pengumuman.
Jejak audit dan penyimpanan setelah selesai
Setelah dokumen selesai, yang perlu kamu simpan bukan cuma PDF hasilnya. Simpan juga sertifikat penandatanganan, log waktu setiap kejadian, alamat IP dan perangkat yang dipakai, serta nilai hash dokumen. Semua ini yang nanti menjadi bahan kalau ada sengketa atau audit.
Tempatkan berkas di penyimpanan yang tidak bisa diakses publik, dan atur masa simpannya sesuai kebutuhan bisnis serta aturan yang berlaku di industrimu. Beri satu jalur ekspor bukti, supaya kamu tidak perlu merakit manual saat ada permintaan mendadak dari tim legal.
Jebakan yang paling sering kejadian
- Menganggap webhook selalu berhasil, lalu tidak punya cara memeriksa dokumen yang macet.
- Menyimpan status dalam satu kolom teks bebas yang isinya berbeda-beda antar programmer.
- Menaruh token API penyedia di kode frontend karena "biar cepat".
- Tidak mencatat metode verifikasi identitas, sehingga tidak bisa menjelaskan apa pun saat ditanya.
- Mengubah isi dokumen setelah meterai atau tanda tangan terpasang.
Integrasi tanda tangan elektronik pada akhirnya bukan soal berhasil memanggil API. Itu bagian yang paling mudah. Yang menentukan apakah sistem ini layak dipercaya adalah seberapa rapi kamu mengelola status, seberapa tahan webhook-mu saat gagal, dan seberapa jelas kamu bisa membuktikan siapa yang meneken apa. Uji ketiganya dengan dokumen sungguhan dan skenario gagal yang disengaja, sebelum memakainya untuk perjanjian yang benar-benar penting.
