Bitcoin Payment Processor membuat permintaan pembayaran, mencocokkan pembayaran masuk dengan pesanan, dan mendukung pencatatan. Sistem ini dapat dikelola sendiri atau tersedia sebagai layanan. Ini bukan aturan konsensus Bitcoin, dan sebutan pemroses tidak menunjukkan siapa yang mengendalikan dana.
Toko membuat pesanan dan servernya meminta faktur dengan jumlah serta mata uang kepada pemroses. Server menyimpan hubungan nomor pesanan internal dengan pengenal faktur. Pelanggan menerima halaman pembayaran atau kode QR, dan pemroses memantau penerimaan. Tanpa hubungan ini, pembayaran tidak dapat dipastikan memenuhi pesanan yang mana; kembali ke peramban saja bukan bukti pembayaran. [BTCPay Server — eCommerce integration]
BTCPay Server dapat menurunkan alamat penerimaan dari data publik dompet yang sudah ada tanpa kunci privatnya. Ini berbeda dari dompet panas yang disimpan di server maupun akses ke dana node Lightning. Penyedia dapat menahan dana sampai pencairan. Nilai kepemilikan kunci yang sebenarnya, izin, dan kemampuan penarikan, bukan hanya nama produk atau kata non-custodial. [BTCPay Server — General FAQ] [BitPay — Configuring settlements]
Faktur BTCPay Server biasa mengunci kurs untuk waktu terbatas. Kedaluwarsa tidak berarti transfer berikutnya tidak dapat tiba. Pembayaran kurang, berlebih, dan terlambat memiliki status berbeda serta memerlukan prosedur lanjutan. Simpan jumlah asli dan kurs yang digunakan; jika harga berubah, permintaan baru mungkin meminta jumlah satoshi yang berbeda. [BTCPay Server — Invoice lifecycle]
BTCPay Server membedakan Processing, yang menunggu konfirmasi sesuai pengaturan, dari Settled; pembayaran Lightning yang berhasil menjadi Settled tanpa menunggu blok. Nama status penyedia lain tidak dapat langsung disamakan: BitPay secara tegas memperingatkan bahwa paid bukan jaminan pembayaran. Toko perlu aturan penyerahan barang untuk status dan metode pembayaran tertentu. Mengubah status secara manual tidak menciptakan konfirmasi jaringan. [BTCPay Server — Invoice lifecycle] [BitPay — Invoice webhooks]
BTCPay memverifikasi webhook menggunakan HMAC-SHA256 atas byte asli badan pesan dan rahasia bersama. BitPay menjelaskan IPN tanpa tanda tangan: notifikasi memicu permintaan status faktur melalui API, bukan menjadi bukti tepercaya dengan sendirinya. Notifikasi dapat berulang. Karena itu, integrasi harus mengenali peristiwa yang dikirim ulang secara andal dan mencegah pengiriman barang kedua untuk pesanan yang sama; setelah gangguan, status tersimpan harus dicocokkan dengan pemroses. [BTCPay Server — Webhook validation example] [BitPay — Invoice webhooks]
Konfirmasi pembayaran pelanggan belum tentu bersamaan dengan pencairan dari penyedia. BitPay memungkinkan pengaturan mata uang penyelesaian dan rekening bank atau alamat mata uang kripto; perubahan mungkin perlu persetujuan. Periksa mata uang yang tersedia, batas, jadwal, biaya, dan kendali dana sebelum pencairan. Penerimaan langsung ke dompet sendiri tidak otomatis menggunakan model pencairan oleh penyedia ini. [BitPay — Configuring settlements] [BTCPay Server — General FAQ]
Pengembalian dana memerlukan pembayaran lain serta verifikasi penerima; hal itu tidak mengubah transaksi bitcoin semula. Pisahkan keluhan pesanan, keputusan jumlah pengembalian, dan pengiriman uang yang sebenarnya. Simpan hubungan pesanan–faktur–pembayaran, kurs, biaya, dan pengembalian dana. Ekspor laporan membantu pencatatan, tetapi tidak dengan sendirinya menyelesaikan seluruh kewajiban akuntansi setempat atau sengketa pengiriman barang. Transfer yang telah dikonfirmasi pun tidak dengan sendirinya menentukan finalitas hukum transaksi: periksa sengketa, mekanisme chargeback yang mungkin ada, dan kewajiban menurut jalur pembayaran, kontrak, serta yurisdiksi. [BTCPay Server — Refunds] [BTCPay Server — Reporting] [BitPay — Merchant and shopper terms]
Uji pembayaran berhasil, tidak lengkap, terlambat, dan yang diberitahukan berulang kali, serta pemulihan setelah gangguan. Beri kunci API hanya izin yang diperlukan dan batasi ke toko terkait. Jangan masukkan data pelanggan yang tidak diperlukan ke metadata. Perhitungkan hosting, pembaruan, likuiditas, dan dukungan; perangkat lunak gratis bukan berarti biaya operasional nol. Ketersediaan layanan, penyimpanan kunci, dan ketepatan integrasi merupakan persyaratan terpisah. [BTCPay Server — eCommerce integration] [BTCPay Server — Lightning operations]
Notifikasi yang sama bukan pembelian baru
Dalam integrasi hipotetis, pesanan OBJ-101 menyimpan pengenal faktur. Setelah penyelesaiannya diverifikasi, sistem membuat pengiriman satu kali. Ketika notifikasi berulang untuk peristiwa yang sama tiba kemudian, sistem menghubungkannya ke pesanan yang sudah dipenuhi dan tidak membuat pengiriman baru. Menampilkan halaman terima kasih saja tidak boleh memicu peralihan ini.
Untuk gambaran yang lebih utuh, baca entri ini bersama BTCPay Server, Bitcoin Point of Sale, Merchant Adoption, Lightning Network, Bitcoin. Entri ini juga dirujuk dari Alza Bitcoin payments, Merchant Adoption, BTCPay Server, Bitcoin Point of Sale.
01Apakah setiap pemroses pembayaran menyimpan bitcoin saya?+
Tidak. Sebagian solusi hanya membuat permintaan dan memantau penerimaan ke dompet Anda, sedangkan yang lain mengelola dana sampai pencairan. Perangkat lunak yang sama pun bisa menggunakan model dompet berbeda. Penentunya adalah kunci, izin, dan aliran dana sebenarnya, bukan hanya sebutan pemroses.
02Bolehkah toko mengirim barang setelah pelanggan kembali dari halaman pembayaran?+
Kembali saja tidak cukup. Toko harus memverifikasi faktur yang sesuai dan statusnya dengan prosedur pemroses tersebut. Notifikasi diverifikasi menurut dokumentasi, dan pengiriman ulang tidak boleh memicu pemenuhan lain. Penyerahan barang mengikuti syarat konfirmasi pembayaran yang dipilih.