Banyak tim menganggap integrasi e-Meterai selesai begitu satu dokumen berhasil dibubuhi meterai lewat API. Padahal pekerjaan yang menentukan justru muncul setelahnya: memastikan kuota tidak habis di tengah proses, menyimpan jejak siapa membubuhkan apa dan kapan, serta menjaga arsip tetap bisa dibuka ketika suatu hari dokumen itu diminta ulang. Tiga hal ini jarang masuk dokumen perencanaan, dan biasanya baru terasa merepotkan saat audit atau sengketa datang.
Integrasi e-Meterai bukan proyek sekali jadi
Menyambungkan e-Meterai ke aplikasi internal biasanya dimulai dari kebutuhan sederhana: pengguna tidak perlu keluar dari sistem untuk membubuhkan meterai. Tim developer menyiapkan pemanggilan endpoint, menyimpan kunci API di server, lalu menguji satu dokumen. Berhasil. Lalu apa lagi?
Di sinilah banyak proyek berhenti. Padahal dokumen bermeterai punya sifat yang tidak dimiliki file biasa. Meterai menempel pada satu dokumen tertentu, tidak bisa dipindah ke dokumen lain, dan jumlahnya terbatas sesuai kuota yang dibeli. Begitu volume naik dari sepuluh dokumen sehari menjadi ratusan, tiga hal yang tadi terlihat sepele berubah jadi sumber masalah.
Anggap saja integrasi ini punya dua lapisan. Lapisan pertama mengurus pembubuhan meterai. Lapisan kedua mengurus tata kelolanya: pencatatan, pembatasan, dan penyimpanan. Lapisan kedua inilah yang jarang digarap serius, padahal justru itu yang diminta ketika ada pemeriksaan.
Validasi kuota sebelum dokumen masuk antrean
Kesalahan paling umum adalah mengecek kuota setelah dokumen dikirim. Kalau saldo habis, dokumen gagal, dan pengguna melihat pesan error dari penyedia yang sama sekali tidak berhubungan dengan pekerjaan mereka. Mereka menyalahkan aplikasi Anda, bukan penyedianya.
Cek saldo di awal alur, bukan di akhir
Sediakan satu titik pemeriksaan sebelum dokumen masuk ke antrean pembubuhan. Kalau saldo di bawah ambang tertentu, sistem sebaiknya menolak lebih awal dengan pesan yang jelas, misalnya kuota meterai sedang habis dan dokumen belum bisa diproses. Jauh lebih baik menahan satu dokumen daripada menggagalkan seratus dokumen di tengah proses batch.
Kalau penyedia menyediakan endpoint untuk membaca sisa kuota, panggil secara berkala dan simpan hasilnya. Jangan memanggil di setiap permintaan pengguna, karena itu hanya menambah beban dan titik gagal.
Rancang perilaku saat kuota habis
- Untuk pembubuhan satuan, tampilkan peringatan di halaman pengguna sebelum tombol kirim ditekan.
- Untuk proses batch, hentikan antrean, tandai dokumen yang belum diproses, dan simpan posisinya agar bisa dilanjutkan setelah kuota diisi.
- Untuk alur otomatis, kirim notifikasi ke admin, jangan diam-diam menggagalkan dokumen tanpa jejak.
Yang penting: jangan pernah menandai dokumen sebagai selesai kalau meterainya belum benar-benar terpasang. Status setengah jadi lebih berbahaya daripada status gagal yang jujur.
Audit trail yang berguna saat dokumen dipertanyakan
Audit trail bukan sekadar log server yang penuh teks. Ia harus bisa menjawab pertanyaan sederhana: siapa yang membubuhkan meterai pada dokumen ini, kapan, dari perangkat atau akun mana, dan apa respons penyedia saat itu.
Data yang layak disimpan
- Identitas pengguna atau sistem yang memicu pembubuhan.
- Waktu permintaan dan waktu respons, bukan hanya waktu pencatatan di database Anda.
- Nomor referensi atau ID transaksi dari penyedia e-Meterai.
- Nilai hash dokumen sebelum dan sesudah dibubuhi meterai.
- Status akhir beserta kode atau pesan kesalahan bila gagal.
Jangan cuma menyimpan status sukses
Respons mentah dari API sebaiknya disimpan apa adanya, bukan hanya kesimpulan sukses atau gagal. Ketika suatu hari ada dokumen yang dipermasalahkan, respons mentah inilah yang menjelaskan apa yang sebenarnya terjadi. Simpan juga identitas versi dokumen, karena dokumen bisa saja direvisi setelah meterai terpasang, dan revisi itu harus terpisah jelas dari versi yang sudah bermeterai.
Satu hal yang sering luput: catat juga siapa yang membatalkan atau menarik dokumen. Pembatalan adalah bagian dari riwayat, bukan sesuatu yang bisa dihapus begitu saja.
Arsip dokumen bermeterai agar tetap terbaca bertahun-tahun
Dokumen bermeterai punya masa pakai panjang. Perjanjian kerja sama, kontrak, atau dokumen transaksi bisa diminta ulang lima sampai sepuluh tahun kemudian. Kalau arsipnya hanya berupa tautan yang masa berlakunya terbatas, Anda sedang menabung masalah.
Simpan berkas finalnya, bukan tautannya
Setelah proses pembubuhan selesai, unduh berkas final dan simpan di penyimpanan milik Anda sendiri. Tautan dari penyedia bisa saja kedaluwarsa, berubah, atau tidak lagi tersedia. Berkas yang Anda simpan sendiri adalah salinan yang bisa Anda pertanggungjawabkan.
Beri nama dan metadata yang bisa dicari
Arsip yang tidak bisa dicari sama saja dengan arsip yang hilang. Simpan setidaknya nomor dokumen, jenis dokumen, pihak yang terlibat, tanggal pembubuhan, dan nomor referensi meterai. Dengan begitu, ketika ada permintaan mendadak, Anda tidak perlu membuka folder satu per satu.
Perhatikan juga format penyimpanannya. Pilih format yang stabil dan umum dibuka, serta pisahkan berkas asli dari hasil pemindaian atau konversi. Kalau perlu salinan cadangan, taruh di lokasi berbeda dari penyimpanan utama.
Lima kebiasaan yang membedakan integrasi rapi dan berantakan
Kalau Anda ingin menilai apakah integrasi e-Meterai di tim Anda sudah sehat, cek lima hal berikut.
- Kuota diperiksa sebelum dokumen diproses, bukan setelah gagal.
- Setiap pembubuhan punya jejak lengkap yang bisa ditelusuri per dokumen.
- Berkas final disimpan di sistem sendiri, bukan hanya mengandalkan tautan pihak lain.
- Kegagalan di tengah batch tidak menghilangkan dokumen, hanya menahannya di antrean.
- Ada satu orang atau satu tim yang bertanggung jawab mengisi kuota dan mengecek arsip secara berkala.
Poin terakhir sering diremehkan. Secara teknis sistemnya jalan, tapi tidak ada yang merasa bertanggung jawab saat kuota menipis atau arsip mulai menumpuk tanpa struktur.
Yang perlu disiapkan sebelum sistem dipakai penuh
Sebelum integrasi dipakai untuk dokumen sungguhan, pastikan Anda sudah punya jalur pengujian yang terpisah, penanganan kegagalan yang jelas, dan prosedur pengisian kuota yang tidak bergantung pada ingatan seseorang. Uji juga skenario paling tidak menyenangkan: kuota habis tepat saat batch berjalan, koneksi ke penyedia terputus, dan respons API tidak kembali dalam waktu wajar.
Integrasi e-Meterai lewat API memang terlihat seperti pekerjaan teknis murni. Kenyataannya, separuh pekerjaannya adalah soal tata kelola dokumen. Tim yang menyadari itu sejak awal akan jauh lebih tenang ketika dokumennya diminta ulang bertahun-tahun kemudian.
