Blog
Cara Kerja QRIS: Dari Scan Sampai Dana Masuk

Pernah bertanya-tanya apa yang sebenarnya terjadi antara pembeli menempelkan kamera ke kode dan notifikasi "pembayaran diterima" muncul? Memahami cara kerja QRIS dari scan sampai dana masuk membantu Anda—baik sebagai pemilik UMKM maupun developer—menyiapkan alur pembayaran yang benar, memasang notifikasi otomatis, dan tahu kapan uang benar-benar bisa ditarik. Artikel ini mengurai seluruh perjalanan transaksi: interkoneksi antar bank dan dompet, peran issuer dan acquirer, notifikasi, sampai penyelesaian dana (settlement) dan penarikan ke rekening.
Apa Itu QRIS Secara Singkat
QRIS (Quick Response Code Indonesian Standard) adalah standar kode QR pembayaran nasional. Sebelum QRIS, setiap dompet digital dan bank punya kode QR sendiri, sehingga pembeli harus punya aplikasi yang sama dengan yang dipasang penjual. QRIS menyatukan semuanya: satu kode QR bisa dibayar dari aplikasi bank atau e-wallet apa pun yang mendukung QRIS. Bagi merchant, ini berarti cukup memajang satu kode untuk menjangkau hampir semua pembeli.
Ada dua bentuk QRIS yang perlu Anda kenali: statis (satu kode dipakai berulang, nominal diisi pembeli) dan dinamis (kode dibuat per transaksi dengan nominal terkunci). Untuk pembayaran online lewat website atau aplikasi, yang dipakai umumnya QRIS dinamis karena nominalnya sudah pasti dan lebih mudah direkonsiliasi otomatis.
Cara Kerja QRIS: Alur End-to-End
Inti dari cara kerja QRIS adalah rantai pesan yang berjalan sangat cepat di belakang layar. Mari kita telusuri langkah demi langkah.
1. Kode dibuat
Saat pembeli hendak membayar, sistem penjual meminta pembuatan kode QRIS untuk nominal tertentu. Di BorderPay, permintaan ini bisa dibuat lewat dashboard, payment link, Embed Checkout (tempel satu snippet), atau REST API—kode QR yang dihasilkan berlaku 60 menit. Setelah lewat batas itu, kode otomatis kedaluwarsa dan tidak ada mekanisme bayar-telat, sehingga tidak ada risiko pembayaran nyasar ke transaksi lama.
2. Pembeli scan dan konfirmasi
Pembeli membuka aplikasi bank atau e-wallet, memindai kode, lalu melihat nama penjual dan nominal. Aplikasi pembeli ini berperan sebagai issuer—pihak yang menerbitkan instrumen pembayaran (saldo dompet atau rekening) milik pembeli. Ketika pembeli menekan "Bayar" dan memasukkan PIN, issuer memeriksa saldo dan mengunci dana.
3. Perjalanan lewat switching (interkoneksi)
Pesan pembayaran tidak langsung loncat dari aplikasi pembeli ke penjual. Ia melewati lembaga switching (penyelenggara jasa pemrosesan) yang menjembatani issuer dan acquirer. Lembaga switching inilah yang membuat interkoneksi bekerja: dana dari e-wallet A bisa sampai ke penjual yang memakai acquirer bank B, karena semua tersambung dalam jaringan yang sama. Proses routing, otorisasi, dan pencatatan awal terjadi di lapisan ini dalam hitungan detik.
4. Peran acquirer
Acquirer adalah pihak berlisensi yang "menerima" transaksi atas nama penjual—biasanya bank atau lembaga pembayaran. Acquirer mencatat bahwa penjual berhak menerima dana dari transaksi tersebut, lalu meneruskan status berhasil kembali melalui jaringan sampai ke aplikasi pembeli (yang menampilkan "Pembayaran berhasil").
Di sinilah posisi BorderPay perlu dijelaskan dengan jujur. BorderPay adalah lapisan teknologi (software) yang berjalan di atas mitra Payment Gateway berlisensi Bank Indonesia. Pemrosesan dan penyimpanan dana dilakukan oleh mitra berlisensi tersebut—BorderPay bukan payment gateway dan bukan penyelenggara jasa pembayaran sendiri. Yang BorderPay lakukan adalah menyederhanakan cara Anda membuat kode, menerima notifikasi, dan memantau saldo, sementara peran issuer, switching, dan acquirer tetap dijalankan pihak berlisensi.
5. Notifikasi ke sistem penjual
Setelah dana terkonfirmasi, sistem penjual perlu tahu—dan inilah bagian yang sering terlewat. Notifikasi berbasis "penjual rajin cek dashboard" tidak cukup andal untuk otomasi. Karena itu BorderPay mengirim webhook: pesan otomatis ke URL yang Anda daftarkan, berisi event seperti payment.paid, payment.expired, atau payment.failed.
Setiap webhook ditandatangani dengan HMAC sehingga sistem Anda bisa memverifikasi bahwa pesan itu benar dari BorderPay dan tidak dipalsukan. Ada log pengiriman dan opsi kirim ulang bila endpoint Anda sempat tidak aktif. Dua praktik yang kami sarankan untuk developer:
- Verifikasi tanda tangan setiap notifikasi sebelum memprosesnya.
- Terapkan idempotensi—pastikan menerima event yang sama dua kali tidak menggandakan efek (misalnya mengirim barang dua kali).
Detail teknis pemasangan ada di dokumentasi kami. Sebelum go-live, Anda bisa menguji seluruh alur di mode test/sandbox tanpa uang sungguhan.
Penyelesaian Dana (Settlement): Kapan Uang Jadi "Milik" Anda
Banyak yang mengira dana langsung masuk ke saldo begitu notifikasi "paid" muncul. Kenyataannya ada tahap settlement—proses penyelesaian dana antar lembaga yang berjalan mengikuti jadwal, bukan seketika.
Di BorderPay, setelah pembayaran berhasil, dana tertahan sebentar lalu tersedia sesuai jadwal per metode pembayaran. Perhitungan jadwal mengikuti hari kerja: akhir pekan dan libur nasional dilewati. Status dan tanggal ketersediaan dana ini tampil di dashboard, jadi Anda tidak perlu menebak. Alur penyelesaian dana secara umum kami bahas di settlement pembayaran.
Membedakan tiga status ini penting:
| Status | Artinya |
|---|---|
| Paid | Pembayaran pembeli berhasil, dana masuk ke sistem |
| Available / Settled | Dana sudah tersedia dan bisa ditarik |
| Withdrawn | Dana sudah dikirim ke rekening bank Anda |
Jangan menganggap "paid" sama dengan "bisa ditarik". Selalu lihat kolom status dan tanggal di dashboard untuk kepastian.
Dari Saldo ke Rekening: Penarikan
Tahap terakhir adalah memindahkan saldo yang sudah tersedia ke rekening bank Anda. Penarikan di BorderPay berjalan otomatis ke rekening bank di Indonesia. Ada biaya per penarikan, dan bila penarikan gagal, saldo dikembalikan penuh sehingga tidak ada dana yang hilang di tengah jalan.
Soal biaya, kami sengaja tidak mencantumkan angka di artikel ini karena bisa berubah—rincian transparannya ada di halaman pricing. Yang pasti: tidak ada biaya pendaftaran maupun langganan; biaya hanya muncul saat ada transaksi. Bagi UMKM, ini berarti Anda tidak menanggung biaya tetap saat sedang sepi.
Ringkasan Alur dalam Satu Tabel
| Tahap | Yang terjadi | Pihak utama |
|---|---|---|
| Buat kode | Sistem penjual minta QRIS (berlaku 60 menit) | Merchant + BorderPay + mitra berlisensi |
| Scan & bayar | Pembeli konfirmasi, dana dikunci | Issuer (aplikasi pembeli) |
| Routing | Otorisasi lewat interkoneksi | Switching |
| Terima | Transaksi dicatat untuk penjual | Acquirer |
| Notifikasi | Webhook ber-HMAC ke sistem penjual | BorderPay |
| Settlement | Dana tersedia sesuai jadwal | Mitra berlisensi |
| Penarikan | Saldo dikirim ke rekening bank | Merchant |
Catatan untuk Merchant dan Developer
Beberapa hal praktis yang memengaruhi pengalaman Anda:
- Limit transaksi QRIS mengikuti ketentuan yang berlaku dari regulator dan penerbit. Selalu cek ketentuan terkini karena angkanya dapat berubah sewaktu-waktu.
- Kedaluwarsa itu fitur, bukan bug. Kode yang tidak dibayar dalam 60 menit otomatis gugur, sehingga rekonsiliasi Anda tetap bersih.
- Uji dulu, baru live. Mode test/sandbox bisa dipakai sejak hari pertama untuk memastikan integrasi berjalan. Untuk menerima uang sungguhan, Anda perlu menyelesaikan proses KYC terlebih dahulu—ini bagian dari kepatuhan pembayaran di Indonesia.
Penutup
Memahami cara kerja QRIS membuat Anda lebih tenang saat membangun alur pembayaran: Anda tahu perjalanan uang melewati issuer, switching, dan acquirer; tahu bahwa notifikasi andal datang lewat webhook ber-HMAC; dan tahu bahwa "paid" belum berarti "bisa ditarik" karena ada tahap settlement berjadwal. BorderPay bertugas menyederhanakan semua itu sebagai lapisan software di atas mitra berlisensi Bank Indonesia—Anda cukup fokus berjualan. Siap mencoba? Mulai di mode test sekarang, dan buka FAQ bila ada pertanyaan.