Kami menerima pembayaran dalam bitcoin: Bagian keempat, lebih dekat ke intinya!

Kami menerima pembayaran dalam bitcoin: Bagian keempat, lebih dekat ke intinya!

Dalam artikel sebelumnya, kami melihat prinsip-prinsip umum pengorganisasian gateway pembayaran bitcoin, menemukan alat dan perangkat lunak yang diperlukan, dan bahkan merakit jaringan bitcoin saku kami sendiri.

Untuk memahami langkah selanjutnya, disarankan untuk memiliki setidaknya pemahaman dasar tentang apa itu JSON dan cara kerja protokol http. 

Singkatnya, JSON (JavaScript Object Notation) adalah format sederhana yang memungkinkan Anda mengirimkan data heterogen dalam bentuk teks biasa. Penting bahwa JSON memungkinkan Anda tidak hanya mentransfer data, tetapi juga memulihkan strukturnya. Awalnya (seperti yang mudah Anda tebak dari namanya) ini diusulkan untuk bahasa JavaScript, namun karena kesederhanaannya, bahasa ini menjadi cukup luas. Hal ini menarik bagi kami terutama karena ini adalah bentuk data yang digunakan saat bertukar informasi antara kode kami dan bitcoind.

Saya tidak akan memberikan contoh kode yang sudah jadi. Bahasa pemrograman yang berbeda sekarang digunakan untuk pengembangan web, dan penjelasan contoh masing-masing bahasa tersebut berada di luar cakupan dan cakupan rangkaian artikel kami. Sebagai gantinya, saya akan menunjukkan hasil eksekusi menggunakan curl - utilitas baris perintah unix/linux. Jika tidak mungkin dilakukan tanpa contoh, saya akan menggunakan kodesemu.

Hal terpenting yang perlu kita pahami sekarang adalah bagaimana kita dapat berinteraksi dengan server bitcoind dan bagaimana kita dapat melakukan tugas-tugas penting dan paling kritis untuk mendapatkan gateway pembayaran yang berfungsi.

Pertama, mari kita coba mendapatkan informasi tentang status node, tetapi tidak dengan perintah bitcoin-cli getwalletinfo, seperti yang kita lakukan sebelumnya, tetapi menggunakan permintaan RPC. Mari kita jalankan perintah berikut:

curl --data-binary '{"jsonrpc":"1.0","method":"getwalletinfo","params":[]}' http://namapengguna:kata sandipengguna@localhost:18332

Dalam perintah ini kita meneruskan permintaan JSON yang dihasilkan. Sebenarnya panggilan itu sendiri: "method":"getwalletinfo". Permintaan ini dikirim sebagai permintaan http biasa ke alamat localhost:18332 - yaitu, mesin lokal kami, dan port RPC yang kami tentukan saat mengonfigurasi jaringan pengujian. Dan namapengguna:kata sandi pengguna - sesuai dengan parameter rpcuser dan rpcpassword yang kami tentukan dalam file konfigurasi yang sama. Hasilnya, kita akan mendapatkan sesuatu seperti ini:

{ "hasil": { "nama dompet": "dompet.dat", "versi dompet": 159900, "keseimbangan": 14717.18723440, "saldo_belum dikonfirmasi": 0,00000000, "keseimbangan_belum matang": 78.12526560, "jumlah tx": 1002, "keypool tertua": 1528970690, "ukuran kumpulan kunci": 999, "keypoolsize_hd_internal": 1000, "biaya pembayaran": 0..00000000, "hdmasterkeyid": "be875fb1dc27d408a5c032d8714cf21cbc3b9af0" }, "kesalahan": batal, "id": batal }

Langkah pertama untuk menerima pembayaran menggunakan bitcoin (seperti kebanyakan mata uang kripto) adalah mendapatkan alamat unik baru, yang juga akan berfungsi sebagai pengidentifikasi pembayaran. Hal inilah yang kami lakukan saat menjalankan perintah bitcoin-cli getnewaddress. Sebenarnya, perintah ini memiliki parameter tambahan, tetapi kami tidak tertarik padanya sekarang. Mari kita coba lakukan ini lagi (diasumsikan Anda telah menginstal bitcoind dan pengujian telah dikonfigurasi, seperti yang dijelaskan dalam artikel sebelumnya dalam seri ini)

bitcoin-cli dapatkan alamat baru

2N49FdQ7Ppb1W8BXfNYUPT4BcnWu5B4zFVt

Sekarang kita perlu melakukan hal yang sama, tetapi menggunakan JSON-RPC. Permintaan itu sendiri akan memiliki bentuk yang sama seperti pada contoh sebelumnya, hanya saja alih-alih "method":"getwalletinfo" kita akan menentukan "method":"getnewaddress":

ikal --data-biner \ '{"jsonrpc":"1.0","method":"getnewaddress","params":[]}' \ http://nama pengguna:kata sandipengguna@localhost:18332

Dan hasilnya akan sesuai:

{ "hasil": "2NBqem3SZijakVD4Cy6ZQTMTZzCPRjNMeKF", "kesalahan": batal, "id": batal }

Jika kita mencermati struktur respons, kita akan melihat elemen umum dalam kedua kasus:

{ "hasil": ... , "kesalahan": batal, "id": batal }

Bidang hasil berisi hasil permintaan, dan kesalahan - dengan demikian, deskripsi kesalahan jika permintaan tidak dapat diselesaikan. Karena kami telah melakukan semuanya dengan benar sejauh ini, kami tidak pernah mengamati bahwa bidang ini selain kosong (null). Namun kenyataannya tidak begitu cerah, jadi ketika mengurai respons dari server, bidang ini harus selalu diperiksa kesalahannya, dan baru kemudian melanjutkan untuk memproses hasilnya.

Mari kita kembali ke alamat baru kita.

Jadi, kita tahu cara mendapatkan alamat baru, dan ini bisa dilakukan dalam jumlah yang tidak terbatas (yah, dalam kerangka kehidupan manusia, itu sudah pasti). Apa sebenarnya yang harus kita lakukan selanjutnya? Saat membuat formulir pembayaran untuk klien, Anda memberinya alamat ini, yang menunjukkan jumlah yang perlu ditransfer kepadanya. Anda menyimpan alamat itu sendiri di tempat yang aman, menunjukkan pesanan mana yang berlaku dan pengguna mana yang berlaku. Sekarang mari kita kesampingkan masalah implementasi antarmuka - seperti kode QR, tombol ajaib seperti "Bayar melalui dompet Bitcoin", sekarang penting bagi kita untuk menguasai prinsip itu sendiri..

Setelah menerima alamat, kami perlu memahami kapan klien melakukan pembayaran. Salah satu cara yang paling sederhana dan jelas adalah dengan mengecek secara berkala apakah dana sudah diterima atau belum. Tentu saja, kita dapat melakukan ini melalui getwalletinfo - namun perintah ini akan menunjukkan keadaan umum dompet kita dan tidak akan menunjukkan dengan cara apa pun siapa sebenarnya yang melakukan pembayaran. Jika toko Anda beroperasi setengah secara manual, dan Anda menerima pesanan beberapa kali sehari, dan pelanggan Anda lebih membutuhkan Anda daripada Anda membutuhkannya, Anda dapat meminta nomor transaksi bitcoin kepada klien setelah pembayaran. 

Namun hal ini, pertama, merepotkan, dan kedua, tidak menyelesaikan masalah sepenuhnya. Tapi anggaplah Anda memilih opsi ini. Pengguna mengaku telah membayar dan memberi Anda nomor transaksi:

ce397d610c0066f1f4f38d532bc527daac3bd6aac25081618be63620d9078c7b

Anda dapat menggunakan penjelajah blok publik seperti blockchain.info, tapi jelas bukan itu yang kami lakukan di sini. Hanya bitcoind, hanya hardcore. Mari kita coba cek sendiri transaksinya menggunakan baris perintah:

bitcoin-cli gettransaksi ce397d610c0066f1f4f38d532bc527daac3bd6aac25081618be63620d9078c7b

Sebagai tanggapan, kami akan menerima sesuatu seperti ini (jika transaksi tersebut, tentu saja, benar-benar ada dan terjadi melalui jaringan):

{ "jumlah": 0,00000000, "biaya": -0,00007880, "konfirmasi": 0, "tepercaya": benar, "txid": "ce397d610c0066f1f4f38d532bc527daac3bd6aac25081618be63620d9078c7b", "konflik dompet": [ ], "waktu": 1529143485, "waktu diterima": 1529143485, "bip125-replaceable": "tidak", "detail": [ { "akun": "", "alamat": "2NBqem3SZijakVD4Cy6ZQTMTZzCPRjNMeKF", "kategori": "kirim", "jumlah": -10.00000000, "label": "", "muntah": 0, "biaya": -0,00007880, "ditinggalkan": salah }, { "akun": "", "alamat": "2NBqem3SZijakVD4Cy6ZQTMTZzCPRjNMeKF", "kategori": "menerima", "jumlah": 10.00000000, "label": "", "vout": 0 } ], "hex": "02000000.....12bf2ed000e9030000" }

Saya telah menghapus beberapa informasi agar lebih mudah dibaca, namun secara keseluruhan inilah yang akan kami dapatkan sebagai tanggapan. Pertama, Anda harus selalu memperhatikan parameter konfirmasi; ini menunjukkan apakah transaksi tersebut termasuk dalam blok, yaitu apakah sudah dikonfirmasi. Dalam Bitcoin, secara umum diterima bahwa suatu transaksi dikonfirmasi setelah 6 konfirmasi, namun belakangan ini sering kali dibatasi hingga 3 atau bahkan satu konfirmasi. Hal kedua yang perlu kita perhatikan adalah daftar details, yang menunjukkan semua input dan output transaksi. Kami tertarik pada blok yang berisi category": "receive . Ini logis, kami mengharapkan pembayaran.. Dan di blok tersebut kita harus sudah menemukan alamat yang kita berikan kepada klien dan membandingkan jumlah yang dia kirim. Kami memiliki lebih banyak informasi, namun informasi inilah yang paling menarik bagi kami.

Mari kita lakukan hal yang sama, tetapi menggunakan permintaan RPC:

ikal --data-biner \ '{"jsonrpc":"1.0","method":"gettransaction","params":["ce397d610c0066f1f4f38d532bc527daac3bd6aac25081618be63620d9078c7b"]}' \ http://nama pengguna:kata sandipengguna@localhost:18332

Saya tidak akan menduplikasi jawabannya, jawabannya sepenuhnya identik dengan yang diterima menggunakan baris perintah. Namun dalam permintaan itu sendiri kami memiliki sesuatu yang baru. Perhatikan blok "params". Itu tidak lagi kosong. Sebaliknya, kami memiliki nomor transaksi di dalamnya. Saat membuat permintaan RPC, ingatlah bahwa urutan parameter penting karena tidak diberi nama. Kita akan membutuhkannya pada contoh berikutnya.

Tentu saja, menanyakan nomor transaksi kepada pengguna bukanlah hal yang modis, merepotkan, dan secara umum. Dan kami harus menangani sendiri fakta pembayarannya. Kami tidak tahu apakah ada pembayaran dan jika ya, kapan. Yang harus kita lakukan, seperti yang saya katakan di atas, adalah memeriksa status alamat satu menit sekali.

bitcoin-cli dapatkan diterima berdasarkan alamat 2NBqem3SZijakVD4Cy6ZQTMTZzCPRjNMeKF

Catatan untuk pemilik: saat meminta, secara default di respon kami hanya akan melihat dana yang sudah dikonfirmasi. Jika kita ingin melihat fakta pembayaran yang belum dikonfirmasi, maka kita perlu menambahkan 0 di akhir perintah.

Jika kita ingin melihat berapa jumlahnya, misalnya minimal 6 konfirmasi, maka kita perlu menambahkan 6. Artinya, kita menunjukkan jumlah minimum konfirmasi yang kita minati. Mari kita coba mengeksekusi permintaan yang sama, namun dalam bentuk permintaan RPC.

ikal --data-biner \ '{"jsonrpc":"1.0","method":"getreceivedbyaddress","params":["2NBqem3SZijakVD4Cy6ZQTMTZzCPRjNMeKF", 0]}' \ http://nama pengguna:kata sandipengguna@localhost:18332

Dan kita akan melihat hasil seperti berikut:

{ "hasil": 10.00000000, "kesalahan": batal, "id": batal }

Kami melihat ada orang baik hati yang mentransfer 10 bitcoin kepada kami. Namun karena kami menentukan parameter kedua 0 dalam permintaan, kami tidak tahu apakah mereka memiliki konfirmasi. Anda dapat mengubah parameter ini, misalnya, menjadi 1 dan mengulangi permintaannya. Kami akan berasumsi bahwa ini adalah pekerjaan rumah, dan Anda dapat mengatasinya sendiri.

Kami belum menerima terlalu banyak informasi, dan ini mungkin menimbulkan pertanyaan. Misalnya, kita tidak tahu tahun pembayarannya. Pengguna dapat, misalnya, membayar bukan dengan satu pembayaran, tetapi dengan beberapa pembayaran.. Secara umum, saya ingin menerima informasi lebih lanjut. Oke, untuk ini, alih-alih getreceivedbyaddress kita bisa menggunakan listreceivedbyaddress.

curl --data-binary '{"jsonrpc":"1.0","method":"listreceivedbyaddress","params":[]}' http://namapengguna:kata sandipengguna@localhost:18332

Perintah ini akan mengembalikan semua pembayaran ke semua alamat yang kami keluarkan dengan nomor transaksi.

{ "hasil": [ { "alamat": "...", "akun": "", "jumlah": ..., "konfirmasi": 7, "label": "", "txids": [ "..." ] }, { "alamat": "2NBqem3SZijakVD4Cy6ZQTMTZzCPRjNMeKF", "akun": "", "jumlah": 10.00000000, "konfirmasi": 6, "label": "", "txids": [ "ce397d610c0066f1f4f38d532bc527daac3bd6aac25081618be63620d9078c7b" ] } ], "kesalahan": batal, "id": batal }

Dan di antara data ini kita perlu menemukan semua alamat kita dan mencari tahu siapa yang mengirim kita dan berapa banyak. Penting untuk diingat bahwa secara default, listreceivedbyaddress hanya akan mengembalikan transaksi yang dikonfirmasi kepada Anda. Jika Anda ingin mendapatkan daftar lengkapnya, Anda harus memasukkan 0 sebagai parameter - seperti dalam kasus getreceivedbyaddress

Penggunaan metode ini menjadi semakin sulit dan mahal seiring berjalannya waktu - karena Anda melihat semua transaksi dengan semua alamat yang Anda miliki.


Secara umum, kami memiliki segala yang dibutuhkan untuk menerima pembayaran menggunakan bitcoin. Tentu saja, metode yang dijelaskan ini bukan yang paling nyaman, namun metode ini sudah memungkinkan Anda mengatur gateway pembayaran sederhana.


Baca juga: KAMI MENERIMA PEMBAYARAN DALAM BITCOIN: BAGIAN SATU, TEORITIS

                         KAMI MENERIMA PEMBAYARAN DALAM BITCOIN: BAGIAN KEDUA. ALAT DAN PERSIAPAN

                         TERIMA PEMBAYARAN DALAM BITCOIN: BAGIAN KETIGA, TESTNET ANDA. DENGAN BLACKJACK

                            

Baca juga

02018-06-29

Kami menerima pembayaran dalam bitcoin: Bagian enam. Nuansa, sekali lagi nuansa

Di bagian terakhir, kami menunjukkan bahwa bukanlah ide yang buruk untuk mencari tahu fakta pembayaran dari bitcoind, daripada melalui semua alamat yang dikeluarkan.

Kepada pengembang
112026-02-07

Robot perdagangan DIY: lebih detail, lebih banyak nuansa

Pada bagian pertama, kita menguji ide dasarnya: penasihat perdagangan bukanlah “robot yang melakukan perdagangan untuk Anda”, namun sebuah sistem yang menerima data pasar, menghasilkan sinyal (dan penjelasan), dan menunjukkan hasilnya kepada seseorang.

Kepada pengembang, Teknologi, Pendidikan, Jual beli

Artikel terbaru dari bagian Kepada pengembang