Pemberitahuan dashboard melawan webhook untuk penjual yang tidak menulis kode: apa yang benar-benar dijamin masing-masing, satu surel yang tidak pernah sampai ke kasir, dan garis yang menentukan siapa sebenarnya butuh webhook

Jawaban paling singkatnya lebih dulu: penjual yang tidak menulis kode hampir tidak pernah membutuhkan webhook. Webhook adalah cara memberi tahu sebuah sistem, bukan cara memberi tahu orang, dan penjual tanpa sistem sendiri sudah dilayani tiga permukaan yang bekerja tanpa satu baris kode pun.

Yang layak dibaca terus adalah bagian sesudahnya, karena ketiga permukaan itu menjamin hal yang berbeda-beda, dan satu di antaranya menyimpan kejutan yang rutin menyakiti usaha berpegawai: surel pembayaran tidak pernah sampai ke kasir. Membandingkan keduanya dari kecanggihannya menghasilkan kesimpulan yang salah. Membandingkannya dari apa yang benar-benar dijamin masing-masing menghasilkan garis yang jelas.

Tiga permukaan yang sudah ada sebelum kode apa pun ditulis

Yang berjalan otomatis pada setiap akun ada tiga, dan ketiganya tidak berbagi jaminan yang sama: daftar transaksi di dashboard, surel saat sebuah pembayaran berhasil, dan notifikasi peramban. Jalur keempat, webhook, menuntut satu alamat https yang siap menerima kiriman, dan alamat itulah yang biasanya belum ada.

Yang benar-benar dijamin daftar transaksi

Daftar transaksi adalah satu-satunya permukaan yang selalu lengkap. Setiap permintaan pembayaran ada di sana beserta statusnya, tanpa bergantung pada surel yang sampai, perangkat yang menyala, atau izin peramban yang diberikan. Untuk penutupan hari, inilah sumber yang dipakai.

Satu hal yang perlu diketahui agar tidak salah membaca: tampilan bawaannya menyaring. Hanya status pending dan succeeded yang ditampilkan, sementara yang kedaluwarsa, dibatalkan, dan gagal disembunyikan sampai statusnya ikut dipilih. Itu pilihan yang benar untuk pekerjaan harian, dan menyesatkan pada saat mencari satu tagihan yang tidak jadi dibayar.

Yang benar-benar dijamin surel, termasuk siapa yang tidak menerimanya

Setiap pembayaran berhasil memicu satu surel berjudul “Pembayaran diterima” diikuti nominalnya. Isinya nominal, keterangan pembayaran kalau ada, waktu dalam WIB, dan satu tautan ke halaman detail pembayaran. Yang tidak ada di dalamnya sama pentingnya: tidak ada nomor pesanan dari sistem penjual, dan tidak ada data pembeli. Surel itu kabar, bukan data.

Bagian yang paling sering mengejutkan adalah penerimanya. Surel pembayaran hanya dikirim ke pemilik akun. Anggota tim dengan peran staf tidak menerimanya, dan itu disengaja, bukan pengaturan yang terlewat dinyalakan. Untuk usaha yang kasirnya bukan pemiliknya, akibatnya langsung terasa: orang yang berdiri di depan pembeli adalah orang yang tidak mendapat surel. Pembagian peran dan apa yang menempel pada masing-masing dibahas di panduan keamanan akun dan akses tim.

Jaminan pengirimannya juga lebih pendek daripada yang diduga. Surel yang gagal dikirim dicoba ulang beberapa kali dalam hitungan jam, lalu berhenti. Cukup untuk melewati gangguan sesaat, tidak dirancang untuk mengejar alamat yang bermasalah selama berhari-hari seperti webhook. Pemberitahuannya juga bisa dimatikan sendiri per pengguna di pengaturan notifikasi, dan mematikannya berarti tidak ada surel sama sekali.

Yang benar-benar dijamin notifikasi peramban

Notifikasi peramban melengkapi persis lubang yang ditinggalkan surel: notifikasi ini dikirim ke setiap anggota aktif, pemilik maupun staf. Untuk toko dengan kasir, inilah jalur yang benar, dan menyiapkannya adalah satu tombol di pengaturan notifikasi pada perangkat yang dipakai.

Harganya adalah empat cara jalur ini padam tanpa pemberitahuan. Pertama, izinnya melekat pada satu peramban di satu perangkat, jadi menyalakannya di laptop tidak menyalakannya di ponsel kasir. Kedua, izin yang sudah ditolak tidak bisa diminta ulang dari halamannya dan hanya bisa dikembalikan lewat pengaturan situs di peramban itu sendiri. Ketiga, Safari di iPhone tidak mendukungnya kecuali dashboard-nya dipasang sebagai aplikasi di layar utama. Keempat, keluar dari akun ikut mematikan langganan notifikasi di perangkat tersebut, yang justru perilaku yang benar pada ponsel toko yang dipakai bergantian: tanpa itu, angka penjualan shift berikutnya akan muncul di layar kunci orang sebelumnya.

Dan tidak ada pengiriman ulang. Notifikasi yang tidak sampai karena perangkatnya mati tidak dikirim lagi setelah menyala. Itulah alasan penutupan hari tetap dilakukan di daftar transaksi.

Yang benar-benar dijamin webhook

Webhook adalah kiriman bertanda tangan ke satu alamat https milik penjual, setiap kali sebuah pembayaran terkonfirmasi. Tiga hal yang dijaminnya tidak bisa ditiru surel maupun notifikasi peramban.

Ketekunan. Endpoint harus menjawab 2xx; kalau tidak, kirimannya diulang dengan jeda menaik sampai tujuh percobaan dalam kurang lebih 33 jam. Pengirimannya bersifat at-least-once, artinya kiriman yang sama bisa datang lebih dari sekali dan penerimanya yang harus tahan terhadap pengulangan.

Isi yang lengkap. Kirimannya membawa data pembayaran, termasuk penanda milik penjual sendiri seperti external_id, sehingga sistem penerima bisa mencocokkan pembayaran dengan pesanannya tanpa bertanya lagi. Inilah yang tidak dibawa surel.

Keaslian yang bisa diperiksa. Setiap kiriman membawa tanda tangan bertimestamp di header Kasera-Signature-V1, sehingga penerima bisa memastikan kabar itu memang datang dari Kasera Pay dan bukan dari siapa pun yang menebak alamat endpoint-nya. Rinciannya, beserta contoh verifikasi, ada di dokumentasi webhook.

Satu batas yang perlu diketahui sebelum berharap terlalu banyak: yang dikirim adalah kabar bahwa sebuah pembayaran berhasil. Tagihan yang kedaluwarsa tidak mengirimkan apa pun, jadi sistem yang perlu melepas stok saat tagihan mati tetap harus menghitung sendiri dari waktu kedaluwarsanya.

Empat jaminan, berdampingan

Garis pemisahnya: empat pertanyaan

Yang menentukan bukan besarnya usaha dan bukan kemampuan teknis pemiliknya, melainkan apakah ada sesuatu yang harus terjadi tanpa manusia. Satu jawaban ya sudah cukup untuk menjadikan webhook pantas dipasang.

• Apakah ada yang harus terbuka sendiri saat pembayaran masuk? Tautan unduhan, akses kelas, nomor kursi, kode voucher. Semua yang tidak boleh menunggu seseorang membaca notifikasi.
• Apakah ada sistem kedua yang memegang pesanannya? Toko online, aplikasi pemesanan, atau basis data sendiri yang statusnya harus ikut berubah.
• Apakah pembayaran datang saat tidak ada yang berjaga? Penjualan yang ramai tengah malam dijawab jauh lebih baik oleh sesuatu yang tidak tidur.
• Apakah jumlah pembayaran per hari sudah melewati yang sanggup dibaca satu orang? Pada titik itu, membaca notifikasi berhenti menjadi cara bekerja dan mulai menjadi sumber kesalahan.

Empat jawaban tidak berarti penjual tetap tidak berhak tahu apa-apa. Artinya, jalur orang sudah cukup, dan energi yang tersisa lebih baik dipakai untuk membiasakan penutupan hari di daftar transaksi. Untuk yang sudah menulis kode dan sedang memilih antara webhook dan memeriksa status secara berkala, perbandingannya ada di perbandingan webhook dengan pemeriksaan status berkala.

Jalan tengah yang sering terlewat

Ada satu keadaan yang sering salah dibaca: toko yang jelas menjawab ya pada pertanyaan kedua, tetapi pemiliknya tidak menulis kode. Toko WooCommerce adalah bentuk paling umumnya. Di situ webhook tetap yang dibutuhkan, dan yang tidak dibutuhkan adalah menulis penanganannya sendiri: plugin resminya yang memasang endpoint, memverifikasi tanda tangannya, dan menandai pesanan lunas, sementara pemiliknya hanya mengisi dua kolom pengaturan. Langkahnya ada di dokumentasi plugin WooCommerce.

Untuk penjual yang belum sampai ke sana tetapi merasa pekerjaan tangannya mulai terlalu banyak, urutan pindah dari tautan manual ke integrasi dibahas di panduan dari tautan manual ke integrasi API.

Pertanyaan yang sering muncul

Apakah penjual yang tidak punya website tetap harus memasang webhook? Hampir tidak pernah. Webhook adalah cara memberi tahu sebuah sistem, bukan cara memberi tahu orang. Penjual yang mengirim barang atau membuka akses dengan tangan sudah mendapat kabarnya lewat surel pembayaran, notifikasi peramban, dan daftar transaksi di dashboard, dan ketiganya bekerja tanpa satu baris kode pun. Webhook baru diperlukan ketika ada sesuatu yang harus terjadi sendiri tanpa menunggu manusia membacanya.

Kenapa kasir tidak menerima surel pembayaran padahal akunnya aktif? Karena surel pembayaran hanya dikirim ke pemilik akun. Anggota tim dengan peran staf tidak menerimanya sama sekali, dan itu perilaku yang disengaja, bukan pengaturan yang belum dinyalakan. Jalur yang terbuka untuk staf adalah notifikasi peramban, yang berhak diterima setiap anggota aktif, dan daftar transaksi di dashboard yang bisa dibuka siapa pun yang punya akses.

Kalau notifikasi peramban sudah aktif, apakah masih perlu memeriksa daftar transaksi? Ya, dan itu bukan kehati-hatian berlebihan. Notifikasi peramban melekat pada satu peramban di satu perangkat, mati saat keluar dari akun, dan tidak pernah dikirim ulang kalau perangkatnya sedang mati. Daftar transaksi adalah satu-satunya permukaan yang selalu lengkap, jadi penutupan hari tetap dilakukan di sana.

Apakah webhook lebih bisa diandalkan daripada surel? Untuk mencapai sebuah sistem, ya, dan jaraknya jauh. Webhook di-retry sampai tujuh kali dalam kurang lebih 33 jam sampai endpoint menjawab 2xx, sementara surel dicoba beberapa kali dalam hitungan jam lalu berhenti. Tetapi keandalan itu hanya berarti kalau ada endpoint yang siap menerima; tanpa itu, webhook bukan jalur yang lebih andal melainkan jalur yang tidak ada.