BTCPay Server adalah perangkat lunak bebas pemrosesan pembayaran berlisensi MIT, yang dapat dijalankan pada instans sendiri atau melalui host pihak ketiga. Proyek ini menyediakan perangkat lunak, bukan rekening kustodian universal atau arbitrase sengketa pedagang. Kepercayaan bergantung pada hubungan nyata antara server, dompet, dan layanan pembayaran.
Pedagang menghubungkan kasir atau toko online dengan faktur dan metode penerimaan pilihan. BTCPay Server membuat alamat on-chain dan permintaan Lightning, memantau pembayaran serta menampilkan faktur. Tersedia pula aplikasi kasir, donasi, dan antarmuka integrasi. Sumber terbuka memungkinkan pemeriksaan dan modifikasi, tetapi tidak dengan sendirinya membuktikan keamanan instalasi tertentu. [BTCPay Server — Source repository]
Dompet on-chain yang ada dapat dihubungkan memakai kunci publik diperluas: server menurunkan alamat penerimaan tanpa membutuhkan kunci privatnya. Dompet panas yang dibuat di server memiliki model risiko berbeda. Izin node Lightning juga dapat memungkinkan penggunaan dananya. Bedakan kunci penerimaan, penandatanganan, dan administrasi; kata self-hosted saja tidak menentukan siapa yang bisa membelanjakan uang. [BTCPay Server — Wallet setup] [BTCPay Server — General FAQ]
Pihak ketiga mengoperasikan server sementara pengguna dapat menerima langsung ke dompet sendiri. Ini tidak menghapus kepercayaan: server jahat atau yang dibobol dapat mengganti kunci publik dan mengalihkan pembayaran mendatang. Koin yang sudah diterima di dompet dan rincian pembayaran baru yang ditampilkan adalah hal berbeda. Periksa penerimaan juga secara independen dari kasir. Serangan yang sama dapat menimpa instans sendiri yang dibobol; host juga memengaruhi ketersediaan dan privasi. [BTCPay Server — Third-party hosting risks]
Toko mengatur mata uang, sumber kurs, masa berlaku, dan konfirmasi yang diperlukan. Processing untuk pembayaran on-chain menunggu kondisi yang ditetapkan; Settled menandakan kondisi terpenuhi. Pembayaran Lightning yang berhasil tidak perlu menunggu blok. Tangani kekurangan, kelebihan, penerimaan terlambat, dan perubahan status manual yang tidak menciptakan konfirmasi jaringan. Menghitung harga dalam bitcoin bukan menjualnya ke fiat: plugin atau penyedia konversi menambahkan biaya dan persyaratan kepercayaannya sendiri. [BTCPay Server — Invoice lifecycle] [BTCPay Server — Store rates and policies] [BTCPay Server — General FAQ]
Toko online harus menyimpan hubungan pesanan dengan pengenal faktur. Greenfield API dapat membatasi izin pada toko tertentu; jangan beri kunci akses melebihi kebutuhan integrasi. Verifikasi webhook sesuai dokumentasi dan proses peristiwa berulang tanpa pengiriman kedua. Kembalinya pelanggan ke halaman terima kasih tidak membuktikan pembayaran dengan sendirinya. Setelah gangguan, cocokkan catatan lokal dengan status faktur dan pembayaran sebenarnya. [BTCPay Server — eCommerce integration]
Node sendiri membutuhkan ketersediaan, pengelolaan kanal, dan likuiditas masuk. Layanan likuiditas, swap, atau dompet kustodian menyelesaikan bagian masalah yang berbeda dan bukan model yang sama. Pada layanan kustodian, penyedia tetap mengendalikan dana; untuk pilihan lain, periksa izin dan risiko konkretnya. Logo BTCPay Server tidak menjamin setiap pembayaran berhasil atau biaya nol. [BTCPay Server — Lightning options]
Cadangkan data toko, faktur, konfigurasi, dan data dompet yang diperlukan sesuai penerapan; seed tidak menggantikan basis data pesanan. Dokumentasi Docker mengharuskan pengujian pemulihan cadangan. Status kanal Lightning lama dapat menyebabkan kehilangan dana jika dipulihkan secara keliru. Migrasi terencana dengan node awal dimatikan dengan benar berbeda dari pemulihan bencana; setelah pengganti berjalan, jangan hidupkan salinan awal node yang sama. Prosedur harus sesuai backend yang dipakai. [BTCPay Server — Backup and restore]
Rencanakan pembaruan, perlindungan akses administrator, paparan jaringan, pemantauan ketersediaan, dan cadangan terverifikasi. Hosting, perangkat keras, biaya jaringan, likuiditas, dan dukungan dapat memerlukan biaya meski perangkat lunak tidak mengambil persentase dari setiap pembayaran. Batasi data pelanggan yang disimpan. Pedagang menangani pengembalian dana dan sengketa pengiriman, bukan pengembang proyek; ekspor faktur tidak menjamin pemenuhan semua kewajiban akuntansi. [BTCPay Server — Maintenance] [BTCPay Server — General FAQ] [BTCPay Server — eCommerce integration]
Kasir mati bukan berarti koin yang sudah diterima hilang
Dalam toko hipotetis, server hanya mengetahui data publik dompet eksternal. Saat hosting gagal, koin on-chain yang sudah diterima tetap dikendalikan kunci dompet tersebut, tetapi kasir mungkin tidak dapat membuat faktur atau melaporkan pembayaran. Operator memulihkan layanan, memeriksa pengaturan penerimaan, dan mencocokkan pesanan dengan dompet. Contoh ini tidak berlaku untuk dompet panas pada server yang hilang atau status kanal Lightning yang sudah usang.
Untuk gambaran yang lebih utuh, baca entri ini bersama Bitcoin Payment Processor, Bitcoin Point of Sale, Kustodi mandiri, Lightning Network, Merchant Adoption, Bitcoin. Entri ini juga dirujuk dari Bitcoin Coffee, Bitcoin Payment Processor, Bitcoin Point of Sale, Bitcoin Donations.
01Apakah BTCPay Server otomatis berarti penyimpanan mandiri?+
Tidak. Penentunya adalah dompet yang terhubung, layanan Lightning, dan izin nyata. Menerima ke dompet eksternal hanya dengan kunci publik berbeda dari dompet panas pada server orang lain atau backend kustodian. Anda juga harus memercayai ketepatan rincian pembayaran yang ditampilkan.
02Apakah cadangan seed cukup untuk pemulihan?+
Seed dapat memulihkan dompet on-chain yang sesuai, tetapi tidak otomatis faktur, pengaturan toko, dan status kanal Lightning. Bagian itu memiliki cadangan serta prosedur sendiri. Pemulihan harus diuji; salinan usang node Lightning aktif tidak dapat diperlakukan dengan aman seperti cadangan berkas biasa.