Bitcoin Point of Sale adalah antarmuka kasir untuk penjualan tatap muka: menghitung harga pembelian, membuat permintaan pembayaran, mencocokkan pembayaran yang diterima dan menyimpan catatan. Sistem ini dapat berjalan di ponsel, tablet atau terminal; tampilan perangkat tidak menentukan siapa yang mengendalikan koin.
Petugas memilih barang atau memasukkan jumlah, lalu memeriksa mata uang, tip dan total akhir. BTCPay Server menyediakan katalog, keranjang dan papan tombol angka. Setiap pembelian harus dapat ditelusuri melalui pesanan dan faktur; membuka ulang layar tidak boleh menghasilkan catatan penjualan kedua. [BTCPay Server — Point of Sale app] [BTCPay Server — Invoice lifecycle]
Harga dalam mata uang lokal dikonversi memakai sumber kurs yang dikonfigurasi; kasir harus menampilkan jumlah bitcoin yang diharapkan dan masa berlaku penawaran. BOLT 11 memuat data faktur Lightning, termasuk hash pembayaran dan kedaluwarsa; jumlahnya dapat bersifat opsional. Untuk pembelian tertentu, jumlah sebenarnya, jaringan dan penerima harus diperiksa. Menghitung harga bukan berarti menjual bitcoin menjadi uang fiat. [BTCPay Server — Store rates and policies] [Lightning BOLTs — Invoice protocol]
Kode QR hanya menyampaikan rincian pembayaran. Tangkapan layar pelanggan bukan pengganti status dalam sistem pedagang. Pada BTCPay Server, Processing menunggu konfirmasi on-chain yang dipilih; Settled berarti kebijakan terpenuhi, tetapi dapat pula diatur manual. Pembayaran Lightning yang berhasil tidak menunggu konfirmasi blok. Karena itu, penyerahan barang didasarkan pada pembayaran terverifikasi, bukan sekadar warna layar. [BTCPay Server — Invoice lifecycle]
Tablet yang sama dapat mengarahkan penerimaan ke dompet sendiri atau memakai penyedia kustodial. Penentunya adalah kunci, izin dan ketentuan pencairan, bukan logo Bitcoin. Penerimaan melalui kunci publik sekalipun tidak meniadakan penggantian alamat mendatang oleh kasir atau server yang diretas. Pisahkan izin petugas dari perubahan penerima, pengelolaan dompet dan persetujuan pengembalian dana. [BTCPay Server — Wallet setup] [BTCPay Server — Third-party hosting risks] [BTCPay Server — Lightning setup]
Node Lightning sendiri memerlukan operasi, kanal dan likuiditas masuk. Penyedia dapat mengambil alih sebagian pekerjaan, tetapi mengubah biaya dan kepercayaan. Kegagalan perutean atau kekurangan likuiditas bukan pembayaran berhasil. Sebelum mengganti metode pembayaran, petugas memeriksa hasil upaya awal agar satu pembelian tidak dibayar dua kali. [BTCPay Server — Lightning setup] [Lightning BOLTs — Invoice protocol]
Internet, backend atau sumber kurs yang tidak tersedia dapat menghalangi permintaan baru atau verifikasi penerimaan. Kode yang ditampilkan atau dicetak dapat tetap terbaca tanpa status terkini. Prosedur operasi harus menentukan koneksi cadangan, penundaan penjualan dan penelusuran pembayaran kemudian. Nilai pembayaran kurang, berlebih dan setelah kedaluwarsa secara terpisah; perubahan status manual tidak mengubah riwayat jaringan. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies]
Pengembalian memerlukan kaitan dengan pembelian awal, jumlah dan mata uang yang disepakati, tujuan terverifikasi serta persetujuan pihak berwenang. BTCPay Server memisahkan pembuatan permintaan pengembalian dari pengiriman pembayaran keluar. Transfer awal tidak dihapus. Petugas harus membedakan permintaan yang dibuat, pembayaran keluar yang tertunda dan pengembalian yang benar-benar selesai. [BTCPay Server — Refund workflow]
Pada akhir sif, cocokkan pesanan, pembayaran diterima, biaya, pengembalian dana dan kemungkinan pencairan dari penyedia. BTCPay Server mengekspor laporan pembayaran, produk terjual dan dompet on-chain; ekspor saja tidak menjamin pemenuhan ketentuan akuntansi dan pajak setempat. Uji prosedur petugas, gangguan dan pemulihan, batasi akses data pelanggan dan perhitungkan biaya perangkat, koneksi serta operasi. [BTCPay Server — Reporting] [BTCPay Server — Point of Sale app] [BTCPay Server — Third-party hosting risks]
Dua layar, satu pembelian
Dalam pesanan hipotetis POS-497, pelanggan menunjukkan pembayaran berhasil, tetapi tablet petugas kehilangan koneksi. Petugas tidak otomatis menandai pembelian sebagai belum dibayar dan langsung membuat permintaan kedua. Ia memulihkan koneksi, menemukan faktur awal dan memeriksa jumlah serta status penerimaan sebenarnya. Baru kemudian ia memutuskan menyerahkan barang atau mencoba lagi dan mencatat hasilnya pada pesanan yang sama.
Untuk gambaran yang lebih utuh, baca entri ini bersama Merchant Adoption, BTCPay Server, Bitcoin Payment Processor, BOLT 11, Konfirmasi, Bitcoin. Entri ini juga dirujuk dari Merchant Adoption, Bitcoin Payment Processor, BTCPay Server, BTC Map.
01Apakah kode QR saja cukup di kasir?+
Kode menyampaikan rincian pembayaran, tetapi tidak memverifikasi penerimaan atau mencocokkan pembayaran dengan pembelian secara mandiri. Kasir memerlukan status pembayaran tepercaya dan prosedur untuk jumlah salah, kedaluwarsa serta koneksi terputus.
02Apakah pembayaran Lightning selalu berarti kustodi mandiri bagi pedagang?+
Tidak. Kasir dapat memakai node sendiri, model layanan lain atau penyedia kustodial. Periksa siapa yang mengendalikan kunci dan saldo, siapa yang menangani penerimaan serta syarat penarikan dana.