Setelah pelanggan menekan tombol bayar, aplikasi Anda menghadapi satu pertanyaan penting: bagaimana cara mengetahui pembayaran benar-benar berhasil? Ada dua pendekatan utama untuk menjawabnya, yaitu polling (aplikasi Anda menanyakan status berulang kali) dan webhook (penyedia yang memberi tahu Anda begitu status berubah). Keduanya bekerja, tetapi punya karakter yang sangat berbeda dalam hal keandalan, kecepatan, dan beban sistem. Memilih yang salah bisa membuat status pembayaran terlambat diketahui atau server Anda kelelahan tanpa perlu. Artikel ini membandingkan polling vs webhook secara jujur, lengkap dengan kapan memakai masing-masing dan mengapa kombinasi keduanya sering jadi jawaban terbaik.
Cara Kerja Polling dan Kapan Cocok Dipakai
Polling berarti aplikasi Anda secara berkala memanggil endpoint status penyedia untuk menanyakan, "Apakah transaksi ini sudah dibayar?" Anda mengulang pertanyaan itu, misalnya tiap beberapa detik, sampai mendapat jawaban akhir atau timeout.
Kelebihan polling:
- Sederhana dijalankan — Anda hanya perlu membuat request keluar, tanpa perlu endpoint publik yang bisa diakses penyedia.
- Mudah di lingkungan terbatas — cocok saat server Anda di balik firewall atau tidak bisa menerima koneksi masuk.
- Kontrol penuh di sisi Anda — Anda menentukan kapan dan seberapa sering menanyakan status.
Kekurangannya:
- Boros sumber daya — sebagian besar panggilan mengembalikan "belum berubah", jadi banyak request terbuang.
- Ada jeda — status baru diketahui pada polling berikutnya, bukan seketika.
- Rentan rate limit — polling terlalu agresif bisa menabrak batas API. Bila Anda memilih jalur ini, terapkan disiplin menangani timeout dan retry serta jarak antar-pengecekan yang wajar.
Polling paling masuk akal untuk kasus di mana Anda tidak bisa menerima koneksi masuk, untuk pengecekan sesekali, atau sebagai jaring pengaman yang dijalankan sesekali, bukan tiap detik. Kuncinya adalah menyesuaikan frekuensi dengan kebutuhan nyata, bukan mengecek sesering mungkin hanya karena bisa.
Cara Kerja Webhook dan Kelebihannya
Webhook membalik arah komunikasi. Alih-alih Anda bertanya terus, penyedia yang "menelepon" server Anda begitu ada perubahan status, dengan mengirim HTTP request ke URL yang sudah Anda daftarkan. Untuk pemahaman menyeluruh, baca webhook pembayaran.
Kelebihan webhook:
- Real-time — Anda tahu hasilnya nyaris seketika setelah pembayaran diproses.
- Efisien — tidak ada request sia-sia; server hanya bekerja saat benar-benar ada peristiwa.
- Skalabel — cocok untuk volume tinggi karena tidak menambah beban linear seperti polling.
Kekurangannya:
- Butuh endpoint publik — server Anda harus bisa menerima koneksi masuk dari penyedia.
- Perlu keamanan — endpoint webhook harus memverifikasi bahwa request benar-benar dari penyedia, bukan pemalsuan.
- Bisa gagal terkirim — jaringan bermasalah atau server Anda sempat down berarti sebuah notifikasi bisa tertunda atau hilang jika tidak ada mekanisme pengulangan.
Webhook adalah pilihan default yang tepat untuk sebagian besar integrasi pembayaran modern karena kecepatan dan efisiensinya.
Ada perbedaan mendasar dalam beban kerja antara keduanya. Pada polling, beban tumbuh seiring jumlah transaksi yang Anda pantau: makin banyak transaksi menunggu, makin banyak pengecekan berkala yang harus Anda lakukan, bahkan untuk transaksi yang belum berubah sama sekali. Pada webhook, beban tumbuh seiring jumlah peristiwa nyata: server hanya bekerja saat ada perubahan status yang benar-benar terjadi. Untuk bisnis yang memproses ribuan transaksi per hari, perbedaan pola ini menentukan apakah infrastruktur Anda tetap ramping atau membengkak hanya untuk menanyakan hal yang sama berulang-ulang.
Menjaga Webhook Tetap Aman dan Andal
Karena webhook adalah endpoint publik yang memicu perubahan status penting, keamanannya tidak bisa ditawar. Beberapa praktik wajib:
- Verifikasi tanda tangan — cek signature (biasanya HMAC) pada setiap request untuk memastikan asalnya sah. Jangan pernah memproses webhook tanpa verifikasi.
- Idempotensi — penyedia bisa mengirim notifikasi yang sama lebih dari sekali. Pastikan memproses dua kali tidak berdampak ganda, misalnya tidak menerbitkan dua tiket atau mengubah saldo dua kali.
- Balas cepat — kembalikan HTTP 200 secepatnya, lalu proses pekerjaan berat secara asinkron. Respons lambat bisa membuat penyedia menganggap gagal dan mengulang kirim.
- Simpan status sendiri — jadikan database Anda sebagai sumber kebenaran, sebagaimana dibahas pada menyimpan status pembayaran.
Karena webhook bisa gagal terkirim akibat masalah jaringan, Anda memerlukan cara memastikan tidak ada pembayaran yang terlewat. Inilah alasan polling tidak sepenuhnya usang.
Pola Hybrid: Yang Terbaik dari Keduanya
Dalam praktik, integrasi paling tangguh tidak memilih salah satu, melainkan menggabungkan webhook dan polling. Idenya:
- Webhook sebagai jalur utama — andalkan untuk pembaruan status yang cepat dan efisien.
- Polling sebagai jaring pengaman — jalankan pengecekan berkala (misalnya tiap beberapa menit) hanya untuk transaksi yang masih berstatus "menunggu", untuk menangkap kasus di mana webhook gagal terkirim.
Dengan pola ini, Anda mendapat kecepatan webhook sekaligus jaminan bahwa tidak ada pembayaran yang tertinggal jika ada notifikasi yang hilang. Untuk transaksi yang tak kunjung tuntas, Anda tetap butuh strategi menangani timeout dan retry yang jelas agar status akhir selalu terkonfirmasi, entah lewat webhook susulan atau polling penutup.
Beberapa prinsip agar pola hybrid tidak justru membebani sistem:
- Batasi polling hanya pada transaksi yang belum final, bukan semuanya.
- Beri jarak yang makin longgar seiring waktu (semakin lama menunggu, semakin jarang mengecek).
- Hentikan polling setelah transaksi mencapai status akhir atau melewati batas waktu wajar.
Ada satu prinsip penting yang menyatukan kedua pendekatan: apa pun jalur yang mengabari Anda, database Anda sendiri harus menjadi sumber kebenaran akhir. Baik webhook maupun polling hanyalah cara memperoleh informasi; keputusan bisnis, seperti menerbitkan tiket, mengaktifkan layanan, atau menandai tagihan lunas, sebaiknya bertumpu pada status yang Anda simpan dan verifikasi sendiri. Dengan begitu, jika suatu saat Anda mengganti penyedia atau menambah metode notifikasi, logika inti aplikasi Anda tetap stabil karena tidak terikat pada satu mekanisme pengabaran tertentu.
BorderPay adalah lapisan teknologi (software) di atas mitra Payment Gateway yang berlisensi Bank Indonesia; pemrosesan dan penyimpanan dana dilakukan oleh mitra berlisensi tersebut. Baik notifikasi status maupun endpoint pengecekan berdiri di atas mitra berlisensi tersebut, sementara BorderPay merapikan cara Anda menerima dan mencatatnya. Kami sampaikan pembagian peran ini secara jujur agar Anda paham dari mana sinyal status Anda berasal.
Pada akhirnya, polling dan webhook bukan musuh, melainkan alat dengan peran berbeda. Webhook memberi kecepatan dan efisiensi, polling memberi jaminan tidak ada yang terlewat, dan menggabungkan keduanya memberi Anda ketenangan bahwa status pembayaran selalu akurat. Jika Anda ingin integrasi yang sejak awal menyediakan webhook aman dan pola pengecekan yang rapi, lapisan software seperti BorderPay bisa membantu Anda memulai tanpa merancang semuanya dari nol.