Memberi akses ke orang lain tanpa membagi kata sandi

Begitu ada orang kedua yang perlu melihat pembayaran masuk, cara paling cepat selalu terasa paling mudah: kirimkan saja email dan kata sandinya. Cara itu tidak bisa dirapikan belakangan. Kata sandi bersama tidak bisa dicabut dari satu orang saja, tidak meninggalkan jejak siapa melakukan apa, dan menghalangi verifikasi dua langkah karena kodenya hanya muncul di satu ponsel.

Jalur yang benar tersedia dan tidak rumit: Pengaturan → Tim untuk mengundang anggota dengan role-nya sendiri, dan Pengaturan → Keamanan untuk verifikasi dua langkah. Panduan ini menjelaskan apa yang sebenarnya dilihat setiap role, dan beberapa perilaku yang mengejutkan kalau baru ditemukan saat sedang buru-buru.

Tiga role, dan batas yang sebenarnya

Role ada tiga, yaitu Pemilik, Developer, dan Staf. Pembagiannya tegas dan mudah diingat kalau dibaca dari apa yang dipegang masing-masing.

• Staf memegang satu hal saja: pembayaran, termasuk membuat permintaan pembayaran, melihat daftar transaksi, dan membuka dashboard.
• Developer memegang pembayaran juga, ditambah API key dan konfigurasi webhook, di mode Live maupun mode tes. Pembayaran ikut dibuka bukan karena kemurahan hati: webhook yang mengirim payload keliru ditelusuri lewat pembayaran yang memicunya, dan integrator yang tidak bisa membuka transaksinya bekerja dalam gelap.
• Pemilik memegang semuanya, termasuk yang tidak dipegang kedua role lain.

Yang hanya ada di tangan Pemilik:

• profil usaha dan pengajuan verifikasi identitas;
• rekening tujuan pencairan;
• keanggotaan tim dan undangan;
• pengaturan halaman pembayaran publik;
• metode pembayaran yang diterima usaha, yang dipisahkan sendiri justru karena staf dan Developer memegang pembayaran: mematikan QRIS akan menghentikan seluruh penjualan, dan itu keputusan pemilik.

Perlu diketahui sejak awal supaya tidak salah paham saat melihat layar orang lain: kontrol yang tidak boleh dipakai staf tetap ditampilkan, dalam keadaan nonaktif, disertai keterangan bahwa hanya pemilik yang dapat mengelola tim. Tampilan itu bukan tanda ada yang rusak atau ada izin yang belum turun.

Cara memutuskannya pendek. Orang yang menagih dan memantau pembayaran, misalnya admin toko atau bendahara harian, diundang sebagai Staf. Orang yang memasang integrasi, misalnya developer lepas atau agensi, diundang sebagai Developer, sehingga pekerjaannya selesai tanpa seorang pun membuka akun pemilik. Role pemilik tidak diberikan kepada siapa pun, karena memang tidak bisa: role itu melekat pada orang yang membuat akun dan menyelesaikan verifikasinya, dan bagian berikutnya menjelaskan kenapa.

Mengundang: setiap undangan menunggu diterima

Undangan dikirim ke alamat email, bukan ke nama pengguna, dan tidak ada undangan yang langsung menjadi keanggotaan. Setiap undangan diparkir sebagai undangan tertunda, apa pun keadaan alamat yang diundang, dan baru menjadi akses setelah penerimanya menerimanya sendiri. Selama masih tertunda, undangan itu tidak memberi izin apa pun.

Penerima mengurusnya di halaman Undangan tim. Di sana tercantum merchant yang mengundang dan role yang ditawarkan, dengan dua tindakan: Terima atau Tolak. Menerima memunculkan merchant itu di akunnya; menolak menutup undangannya tanpa memberi akses. Orang yang sudah punya akun diarahkan ke halaman itu saat masuk kalau ada undangan yang menunggu, jadi undangan tidak terlewat begitu saja.

Sebelumnya, mengundang alamat yang sudah punya akun langsung mengaktifkan keanggotaannya tanpa persetujuan siapa pun. Itu sudah tidak berlaku, dan perubahannya disengaja: tidak seorang pun menjadi anggota sebuah usaha tanpa mengetahuinya. Konsekuensi praktisnya untuk pemilik, keanggotaan baru tidak muncul di daftar anggota pada detik undangan dikirim. Sampai undangannya diterima, namanya berada di daftar undangan tertunda dengan penanda Menunggu diterima.

Mendaftar tetap harus memakai alamat email yang persis sama dengan yang diundang. Mendaftar dengan alamat lain menghasilkan akun yang sah tetapi kosong, sementara undangannya tetap tertunda dan tampak seperti tidak pernah sampai.

Undangan tertunda tidak punya masa berlaku. Undangan itu menunggu tanpa batas waktu sampai diterima, ditolak, atau dibatalkan pemilik. Berguna karena tidak ada undangan yang basi diam-diam, tetapi juga berarti daftar itu perlu dibersihkan sendiri: alamat yang salah ketik akan duduk di sana selamanya, dan siapa pun yang suatu hari memegang alamat tersebut dapat menerimanya. Membatalkan undangan yang keliru adalah pekerjaan hari itu juga, bukan nanti.

Role ditetapkan saat mengundang, bukan setelahnya

Role dipilih di formulir undangan, dan pilihannya dua: Staf atau Developer. Setelah undangan diterima, tidak ada kontrol ubah role di daftar anggota. Mengubah role seorang anggota berarti mengeluarkannya dari daftar lalu mengundangnya kembali dengan role yang baru, dan karena undangan selalu menunggu diterima, orang itu perlu menerimanya sekali lagi.

Salah pilih role lebih murah diperbaiki sebelum undangannya diterima: mengundang ulang alamat yang undangannya masih tertunda memperbarui role yang ditawarkan, tanpa menghasilkan undangan kedua. Setelah diterima, mengundang alamat yang sama ditolak dengan keterangan bahwa alamat itu sudah ada di tim, dan jalur keluar-lalu-undang-ulang di atas yang berlaku.

Kepemilikan tidak berpindah

Pemilik sebuah merchant adalah orang yang membuatnya dan menyelesaikan verifikasinya. Role itu tetap di sana. Tidak ada kontrol untuk mengalihkan kepemilikan, tidak ada cara menaikkan anggota menjadi pemilik, dan undangan tidak pernah menawarkan role pemilik.

Alasannya ada pada uangnya. Rekening tujuan pencairan adalah rekening milik orang yang terverifikasi, dan namanya harus cocok dengan nama pada identitas yang diperiksa. Sebuah tombol yang memindahkan role pemilik akan memindahkan kendali atas rekening itu ke orang yang identitasnya tidak pernah diperiksa untuk akun tersebut. Satu sesi yang dicuri akan cukup untuk melakukannya.

Konsekuensinya perlu diketahui sebelum dibutuhkan, bukan sesudah. Menyerahkan usaha kepada orang lain berarti orang itu membuat akun sendiri dan menyelesaikan verifikasinya sendiri; riwayat transaksi, tautan pembayaran yang sudah disebar, dan API key tidak ikut pindah. Yang bisa dibagikan adalah kursi Staf dan kursi Developer, sehingga susunan yang tahan lama memisahkan siapa yang menagih dari siapa yang memegang rekening.

Kalau satu-satunya pemilik kehilangan akses ke akunnya, tidak ada anggota lain yang bisa mengambil alih. Jalurnya adalah menghubungi dukungan di halo@kasera.id dari alamat yang terkait dengan akun tersebut. Karena itu email pemilik dan kode pemulihan 2FA-nya, yang dibahas di bawah, perlu dijaga sebaik rekening banknya.

Mengeluarkan anggota, dan satu pagar yang tidak bisa ditembus

Pemilik dapat mengeluarkan anggota lain, tetapi tidak dapat mengeluarkan dirinya sendiri dari daftar anggota. Untuk keluar dari sebuah merchant, tindakannya adalah keluar sendiri, bukan menghapus diri dari daftar.

Di atas semua itu ada satu pagar yang berlaku mutlak: sebuah merchant tidak pernah boleh kehilangan pemilik terakhirnya. Pemilik tidak bisa dikeluarkan dan tidak bisa keluar sendiri, dan penolakannya menyebutkan bahwa merchant harus memiliki minimal satu pemilik. Karena kepemilikan tidak berpindah, pagar itu berlaku selamanya, bukan hanya sampai ada pemilik kedua. Staf dan Developer bebas keluar sendiri kapan saja.

Verifikasi dua langkah dan kode pemulihan

2FA diaktifkan di Pengaturan → Keamanan dengan aplikasi authenticator seperti Google Authenticator, Aegis, atau 1Password. Alurnya: pindai kode QR atau masukkan kuncinya secara manual, konfirmasi dengan satu kode enam digit, lalu kode pemulihan ditampilkan. Jumlah kode dan batas percobaannya ada di dokumentasi keamanan akun.

Kode pemulihan itu ditampilkan tepat satu kali. Setiap kode berlaku untuk sekali masuk kalau authenticator tidak bisa diakses. Tempat menyimpannya bukan di ponsel yang sama dengan authenticator, karena kehilangan ponsel adalah persis keadaan yang membuat kode itu dibutuhkan. Mengaktifkan ulang 2FA menerbitkan kode baru dan membuat kode lama berhenti berlaku, jadi catatan lama perlu dibuang agar tidak dipercaya saat panik.

Menonaktifkan 2FA memerlukan satu kode yang valid, baik kode dari authenticator maupun kode pemulihan. Artinya sesi yang berhasil dicuri saja tidak cukup untuk melepas perlindungan itu, dan itu memang tujuannya. Konsekuensinya juga jelas: authenticator hilang dan kode pemulihan hilang bersamaan berarti tidak ada jalur mandiri di dashboard. Yang tersisa adalah menghubungi dukungan di halo@kasera.id.

Mewajibkan 2FA untuk seluruh anggota

Ada satu saklar kebijakan tingkat merchant yang mewajibkan 2FA untuk semua anggota merchant tersebut. Saklar itu milik pemilik; staf melihatnya dalam keadaan nonaktif disertai keterangan bahwa pengaturannya hanya untuk pemilik. Anggota yang belum mengaktifkan 2FA akan diarahkan ke halaman Keamanan saat masuk, dengan keterangan bahwa pemilik merchant mewajibkannya.

Waktu yang tepat menyalakannya adalah sebelum orang kedua diundang, bukan setelah tim membesar. Menyalakan kebijakan pada tim yang sudah berisi banyak orang berarti mengganggu banyak orang sekaligus pada hari yang sama.

Sesi aktif: memeriksa perangkat mana yang sedang masuk

Kartu Sesi aktif di Pengaturan → Akun memuat daftar perangkat yang sedang masuk ke akun sendiri, lengkap dengan kapan masuk dan kapan terakhir aktif. Perangkat yang tidak dikenali muncul di sana, jadi pemeriksaan setelah kejadian sudah tersedia dan tidak perlu lagi mengandalkan pencegahan saja.

Setiap baris punya tombol Keluar untuk mencabut satu perangkat, dan ada Keluar dari semua perangkat lain untuk mencabut semuanya sekaligus tanpa mengeluarkan diri sendiri. Baris sesi yang sedang dipakai ditampilkan dalam keadaan nonaktif, disertai keterangan untuk memakai tombol Keluar biasa. Daftar ini per akun, jadi setiap anggota memeriksa perangkatnya sendiri.

Kebiasaan yang tetap dipegang tidak berubah, hanya bertambah satu: meninjau daftar anggota dan daftar undangan tertunda secara berkala, misalnya setiap awal bulan, mencabut akses pada hari seseorang berhenti, dan memeriksa sesi aktif sendiri setelah masuk dari komputer bersama atau ponsel yang kemudian dijual.

Kalau ada satu tindakan yang layak dilakukan setelah menduga kata sandi bocor, tindakannya adalah Keluar dari semua perangkat lain, lalu mengganti kata sandi, lalu memastikan 2FA aktif.

Ada satu jalur akses yang sering terlewat justru karena terasa sudah beres. Mengeluarkan seseorang dari tim tidak mencabut API key yang sempat disalinnya. API key berlaku atas nama merchant dan bukan atas nama orang yang membuatnya, sehingga developer yang sudah keluar tetap dapat membuat pembayaran dengan key lama sampai key itu dirotasi. Rotasi juga bukan tindakan yang bisa dilakukan sambil lalu, karena hanya ada satu key aktif per mode dan key lama mati seketika. Urutan dan waktu yang tepat untuk melakukannya dibahas di panduan menyimpan dan merotasi kunci API. Aturan singkatnya: setiap kali seseorang yang pernah memegang key live berhenti, rotasi key masuk ke daftar tugas hari itu.

Urutan yang disarankan

1. Aktifkan 2FA di akun pemilik, dan simpan kode pemulihannya di luar ponsel.
2. Nyalakan kebijakan wajib 2FA sebelum anggota pertama diundang.
3. Undang anggota dengan role Staf sebagai bawaan, dan pakai role Developer hanya untuk orang yang memang memasang integrasinya.
4. Periksa daftar Undangan tertunda, batalkan alamat yang salah ketik hari itu juga, dan ingatkan penerima bahwa undangannya baru berlaku setelah diterima.
5. Jaga akses ke email pemilik dan kode pemulihan 2FA-nya, karena role itu tidak bisa dipindahkan ke anggota lain kalau pemegangnya tidak bisa dihubungi.
6. Tinjau daftar anggota secara berkala, dan cabut akses pada hari seseorang berhenti.
7. Periksa Sesi aktif sendiri sesekali, dan cabut perangkat yang sudah tidak dipakai.
8. Rotasi API key setiap kali pemegang key live berhenti.

Langkah-langkah ini juga muncul sebagai satu langkah tunggal dalam checklist sebelum menerima pembayaran sungguhan yang pertama, dan alasan kenapa rekening pencairan pantas dijaga seketat ini dijelaskan di panduan pencairan dana. Bagi yang selama ini menerima pembayaran usaha ke rekening pribadi, akses bersama adalah salah satu hal yang paling cepat rusak, dan hal itu dibahas terpisah di tulisan tentang jualan pakai rekening pribadi.

Pertanyaan yang sering diajukan