Deteksi transaksi, konfirmasi chain, asosiasi order, dan pengiriman layanan adalah langkah-langkah yang terpisah. Verifikasi chain, aset, penerima, dan jumlah yang benar; terapkan kebijakan penerimaan yang terdokumentasi; dan buat rekonsiliasi bersifat idempoten. Referensi transaksi, tangkapan layar, atau tombol browser saja tidak dapat membuktikan bahwa order tertentu telah dibayar.
Pisahkan peristiwa rantai dari peristiwa pesanan
Wallet yang melaporkan bahwa transfer telah dikirim adalah bukti tentang tindakannya sendiri, bukan keputusan pembayaran yang lengkap. Backend penerima harus mengamati jaringan yang dimaksud, memverifikasi transfer yang sebenarnya, dan mengaitkannya dengan order. Hanya setelah itu order dapat menerapkan kebijakan penerimaannya. Pengiriman infrastruktur adalah langkah operasional lain setelah penerimaan pembayaran.
Jaga agar transisi ini tetap eksplisit baik dalam kode maupun bahasa pelanggan. Layar dapat menampilkan menunggu, terdeteksi, atau mengonfirmasi tanpa menyebut order telah dibayar. Jangan biarkan browser memasok jumlah yang diterima atau menimpa status otoritatif. Simpan kuotasi yang dibuat server beserta instruksinya agar rekonsiliasi selanjutnya dapat dinilai terhadap order asli, bukan keranjang yang berubah.
Gunakan aturan keyakinan khusus rantai
Jaringan yang berbeda menjelaskan keyakinan transaksi secara berbeda. Panduan pengembang Bitcoin menjelaskan bagaimana node memilih chain dengan akumulasi proof of work terbanyak dan bagaimana blok yang bersaing dapat terjadi. Transaksi yang baru terlihat karena itu memerlukan kebijakan untuk kedalaman konfirmasi dan kemungkinan perubahan chain. Tidak ada satu jumlah konfirmasi yang cocok untuk setiap aset dan risiko komersial.
Dokumentasi proof-of-stake Ethereum menjelaskan finalitas checkpoint, sementara Solana mendokumentasikan status komitmen processed, confirmed, dan finalized. Jangan menerjemahkan istilah-istilah tersebut secara sembarangan menjadi satu jumlah blok universal. Catat aturan spesifik jaringan, sumber informasi, dan perilaku selama ketidakpastian. Operator harus menentukan ambang penerimaan terhadap risiko pembayaran dan pengiriman, bukan menyalin angka dari checkout yang tidak terkait.
Verifikasi payload transfer yang sebenarnya
Identifikasi penerima, aset, dan jumlah pada chain yang benar. Pembayaran token memerlukan identitas token yang dimaksud, bukan sekadar transaksi yang berhasil ke suatu alamat. Verifikasi keberhasilan eksekusi yang relevan dan bukti transfer sesuai model chain tersebut. Uraikan jumlah integer pada presisi aset yang tepat alih-alih memercayai desimal terformat yang dipasok browser.
Instruksi pembayaran harus tetap terikat pada rute aslinya. Transfer di jaringan lain, token berbeda dengan simbol yang sama, atau referensi transaksi yang tidak terkait tidak boleh memenuhinya. Catatan verifikasi harus menjelaskan apa yang diperiksa dan menyimpan bukti yang diperlukan untuk meninjau keputusan tersebut. Panduan ini menjelaskan prinsip rekonsiliasi pembayaran secara umum, bukan implementasi layanan tertentu.
Buat keterkaitan pesanan tidak ambigu
Alamat penerima tetap dapat menerima beberapa order dengan jumlah serupa. Adanya transfer yang cocok tidak membuktikan pelanggan atau order mana yang harus dikreditkan. Tentukan metode asosiasi sebelum menerima pembayaran langsung dan sertakan penanganan untuk tabrakan. Referensi transaksi yang diberikan pengguna tetap memerlukan validasi bahwa transfer yang sama belum ditetapkan di tempat lain.
Bayangkan dua invoice dengan jumlah yang sama pada rute yang sama selama jendela yang tumpang tindih. Pengamat melihat satu transfer. Menandai keduanya sebagai dibayar secara otomatis adalah salah; memilih salah satu tanpa bukti yang cukup juga tidak aman. Biarkan transfer tidak dialokasikan atau dalam peninjauan sampai kebijakan operator dapat menetapkan asosiasi yang valid. Kecocokan yang ambigu adalah keadaan yang harus ditangani, bukan alasan untuk mengarang kepastian.
Tentukan status yang mentoleransi bukti yang terlambat dan berubah
Proses pembayaran diuntungkan oleh sekumpulan kecil status yang jelas, dengan bukti chain terpisah dari keputusan untuk menerima order. Tabel ilustratif ini menjelaskan tahapan yang mungkin, bukan menggambarkan nama status layanan tertentu. Setiap transisi harus memiliki alasan yang terverifikasi, dan penerimaan pembayaran harus tetap berbeda dari pengiriman infrastruktur.
Sertakan transfer yang terlambat, sebagian, dan berlebih, kedaluwarsa kuotasi, serta data chain yang sementara tidak tersedia. Kedaluwarsa tidak membuat transfer nyata menghilang. Pembayaran yang terlambat mungkin memerlukan peninjauan alih-alih penerimaan atau penolakan otomatis. Jika peristiwa chain yang sebelumnya teramati berubah, evaluasi ulang status berdasarkan kebijakan yang terdokumentasi alih-alih memperlakukan setiap notifikasi pengamat sebagai kebenaran yang tidak dapat dibatalkan.
| Status ilustratif | Arti | Keputusan berikutnya |
|---|---|---|
| Menunggu | Tidak ada transfer memenuhi syarat yang terverifikasi | Lanjutkan mengamati invoice yang valid |
| Terdeteksi | Transfer relevan teramati | Periksa keyakinan chain dan asosiasi |
| Mengonfirmasi | Aturan penerimaan belum terpenuhi | Amati sampai kebijakan memungkinkan keputusan |
| Tinjau | Bukti terlambat, sebagian, atau ambigu | Selesaikan berdasarkan kebijakan operator |
| Diterima | Pembayaran terverifikasi dan direkonsiliasi | Lanjut ke alur kerja pengiriman yang terpisah |
Buat percobaan ulang aman dan dapat diamati
Pengamat dan tugas rekonsiliasi akan mencoba lagi setelah koneksi terputus atau proses dimulai ulang. Gunakan identitas transfer yang stabil, seperti chain dan pengenal transaksi atau transfer yang sesuai, untuk mencegah kredit ganda. Simpan kemajuan dan keputusan secara persisten agar peristiwa yang sama dapat diproses lagi tanpa menyediakan layanan kedua atau mengubah kuotasi yang telah diterima.
Bedakan hasil yang tidak diketahui dari operasi yang gagal. Jika permintaan hilir habis waktu, periksa hasil otoritatifnya sebelum mengirim ulang. Simpan catatan tahan lama tentang tindakan yang diterima dan tidak pasti. Batasi akses ke token order dan bukti internal sambil menyimpan cukup informasi untuk menyelidiki pembayaran yang disengketakan. Keandalan di sini adalah tentang keputusan yang dapat diulang, bukan animasi yang mulus di checkout.
Ketahui apa yang masih dibutuhkan pesanan yang tertunda
Order dapat tetap tertunda karena transfer belum teramati, keyakinan chain yang diperlukan belum tercapai, atau asosiasinya dengan invoice perlu ditinjau. Simpan invoice dan referensi transaksi publik, periksa aturan penerimaan yang dinyatakan, dan gunakan proses bantuan yang dimaksudkan untuk order tersebut. Pembaruan status yang tertunda, dengan sendirinya, bukan alasan untuk mengirim pembayaran lain.
Ikuti instruksi dan status terverifikasi untuk order yang sebenarnya. Konfirmasi pembayaran harus mengidentifikasi penerimaan transfer yang direkonsiliasi, sementara pengiriman layanan memiliki status tersendiri. Jauhkan token akses privat dan rahasia wallet dari permintaan bantuan.
Daftar periksa praktis Anda.
- Simpan kuotasi yang dibuat server secara immutable.
- Verifikasi chain, penerima, aset, dan jumlah integer.
- Dokumentasikan aturan penerimaan spesifik chain.
- Tangani tabrakan alamat tetap tanpa menebak.
- Cegah kredit ganda dan pengiriman ulang yang tidak aman.
- Uji kasus keterlambatan, sebagian, rute salah, dan bukti yang berubah.
Detail yang penting.
Apakah hash transaksi cukup untuk mengonfirmasi pembayaran?+
Tidak. Verifikasi transfer pada chain yang dimaksud, payload dan keyakinannya, lalu pastikan bahwa transfer itu milik order tersebut dan belum pernah dikreditkan.
Dapatkah setiap jaringan menggunakan ambang konfirmasi yang sama?+
Tidak. Jaringan mengekspos model keyakinan dan finalitas yang berbeda. Operator harus menetapkan dan menguji kebijakan penerimaan yang sesuai untuk setiap rute.
Apakah pembayaran yang dikonfirmasi berarti server telah disediakan?+
Tidak. Penerimaan pembayaran dan pengiriman adalah peristiwa alur kerja yang terpisah. Komunikasikan status penyediaan dari proses otoritatifnya sendiri.
Kunjungi sumbernya.
Referensi ini mendukung konsep teknis dalam panduan ini. Ikuti dokumentasi terkini sebelum mengubah sistem produksi.
- Panduan pengembang Bitcoin: Perilaku blockchain developer.bitcoin.org
- Ethereum: Proof of stake dan finalitas ethereum.org
- Solana: Komitmen status RPC solana.com
Panduan editorial oleh SwissOctet. Contoh bersifat ilustratif. Spesifikasi layanan, opsi yang tersedia, dan ketentuan kontraktual harus diverifikasi secara terpisah.