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 perannya sendiri, dan Pengaturan → Keamanan untuk verifikasi dua langkah. Panduan ini menjelaskan apa yang sebenarnya dilihat setiap peran, dan beberapa perilaku yang mengejutkan kalau baru ditemukan saat sedang buru-buru.

Dua peran, dan batas yang sebenarnya

Peran hanya ada dua, yaitu Pemilik dan Staf, dan pembagiannya tegas. Staf memegang satu hal saja: pembayaran, termasuk membuat permintaan pembayaran, melihat daftar transaksi, dan membuka dashboard. Semua sisanya milik Pemilik:

• profil usaha dan pengajuan verifikasi identitas;
• rekening tujuan pencairan;
• keanggotaan tim dan undangan;
• API key dan konfigurasi webhook;
• pengaturan halaman pembayaran publik;
• metode pembayaran yang diterima usaha, yang dipisahkan sendiri justru karena staf 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.

Peran staf cocok untuk orang yang menagih dan memantau pembayaran, misalnya admin toko atau bendahara harian. Peran pemilik hanya untuk orang yang memang boleh memindahkan uang keluar, karena rekening pencairan ada di sisi pemilik. Cara paling sederhana untuk memutuskan: kalau orang itu tidak seharusnya bisa mengganti rekening tujuan pencairan, orang itu bukan pemilik.

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 peran 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.

Mengubah peran anggota lain

Setiap baris di daftar anggota punya kontrol Ubah peran. Staf dinaikkan menjadi pemilik, dan pemilik diturunkan menjadi staf, langsung dari daftar itu. Tidak perlu mengeluarkan siapa pun lebih dulu, dan anggota yang perannya berubah menerima pemberitahuan lewat email.

Satu batas berlaku pada kontrol ini: peran pemilik terakhir tidak dapat diturunkan. Penolakannya menyebutkan bahwa merchant harus memiliki minimal satu pemilik, dan itu pagar yang sama yang menjaga daftar anggota saat seseorang dikeluarkan.

Baris sendiri sengaja ditampilkan dalam keadaan nonaktif, disertai keterangan untuk memakai Alihkan kepemilikan. Menyerahkan peran sendiri adalah tindakan yang berbeda, dan bagian berikutnya menjelaskan kenapa.

Mengundang ulang orang yang sudah menjadi anggota tetap ditolak dengan keterangan bahwa alamat itu sudah ada di tim; perannya diubah lewat kontrol di atas, bukan lewat undangan baru. Untuk undangan yang masih tertunda, mengundang ulang alamat yang sama memperbarui peran yang ditawarkan, jadi salah pilih peran saat mengundang cukup diperbaiki begitu.

Mengalihkan kepemilikan

Menyerahkan usaha kepada orang lain punya jalurnya sendiri, yaitu Alihkan kepemilikan di daftar anggota. Satu tindakan menaikkan anggota yang dipilih menjadi pemilik dan menurunkan peran sendiri menjadi staf, keduanya sekaligus, sehingga tidak ada satu momen pun ketika usaha berada tanpa pemilik atau dengan dua orang yang sama-sama mengira sudah menyerahkannya.

Tindakan itu dikonfirmasi dengan kode sekali pakai yang dikirim ke email pemilik yang sedang masuk, gerbang yang sama yang menjaga pencairan dana. Alasannya langsung: sesi yang berhasil dicuri saja tidak cukup untuk memindahkan kepemilikan sebuah usaha ke alamat lain.

Setelah pengalihan selesai, peran lama tidak kembali sendiri. Pemilik baru yang mengembalikannya, lewat kontrol Ubah peran. Karena itu pengalihan dilakukan kepada orang yang memang dipercaya memegang rekening pencairan, bukan sebagai langkah sementara.

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 terakhir tidak bisa dikeluarkan dan tidak bisa keluar sendiri, dan penolakannya menyebutkan bahwa merchant harus memiliki minimal satu pemilik. Detail yang penting untuk perencanaan suksesi: undangan pemilik yang belum diklaim tidak dihitung sebagai pemilik. Mengundang rekan sebagai pemilik lalu langsung keluar tidak akan berhasil selama undangan itu belum diterima, dan memang seharusnya begitu, karena kalau berhasil akun tersebut akan berakhir tanpa satu pun orang yang dapat bertindak untuknya.

Untuk benar-benar menyerahkan usaha, jalurnya adalah Alihkan kepemilikan di bagian sebelumnya, bukan mengundang pemilik baru lalu keluar. Keluar tetap tersedia setelah pengalihan selesai, karena saat itu merchant sudah punya pemilik aktif yang lain.

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 delapan kode pemulihan ditampilkan.

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 delapan 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 delapan kode pemulihan di luar ponsel.
2. Nyalakan kebijakan wajib 2FA sebelum anggota pertama diundang.
3. Undang anggota dengan peran staf sebagai bawaan. Peran pemilik hanya untuk orang yang boleh mengubah rekening pencairan.
4. Periksa daftar Undangan tertunda, batalkan alamat yang salah ketik hari itu juga, dan ingatkan penerima bahwa undangannya baru berlaku setelah diterima.
5. Pastikan selalu ada lebih dari satu pemilik aktif kalau usaha tidak boleh berhenti saat satu orang tidak bisa dihubungi. Undangan yang belum diterima tidak dihitung.
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