Alamat dompet bukanlah satu sistem pembayaran. Ia hanyalah sebuah destinasi, tidak lebih daripada itu. Sesiapa sahaja yang mempunyai rentetan tersebut boleh menghantar apa-apa sahaja kepadanya pada bila-bila masa. Untuk urusan sekali sekala antara dua orang yang saling mempercayai, itu mungkin mencukupi. Tetapi jika anda mengendalikan produk SaaS, pasaran (marketplace), atau kedai dalam talian, menampal alamat statik pada halaman pembayaran adalah resipi kepada huru-hara operasi. Anda akan menghabiskan hari-hari anda memadankan transaksi misteri dengan pelanggan sebenar, meneka siapa yang membayar apa, dan membersihkan kekacauan apabila seseorang menghantar token yang salah melalui rangkaian yang salah.

Untuk membina sesuatu yang boleh berkembang (scale), anda perlu berhenti berfikir seperti sebuah tabung derma dan mula berfikir seperti satu sistem pembayaran yang berstruktur.

Mengapa Alamat Dompet Gagal pada Skala Besar

Masalahnya adalah konteks, atau ketiadaan konteks tersebut. Apabila pelanggan menyalin alamat dompet anda dan menghantar kripto daripada bursa (exchange) atau dompet simpanan kendiri (self-custody wallet), rantaian blok (blockchain) hanya merekodkan apa yang berpindah: jumlah, cap masa, dan dua alamat awam. Ia tidak merekodkan nombor invois anda. Ia tidak menyertakan ID pelanggan. Ia tidak menyatakan sama ada pemindahan itu adalah pembaharuan langganan, naik taraf pro-rata, atau pembelian yang benar-benar baharu.

Bayangkan sebuah syarikat SaaS yang mengebil lima ratus pelanggan dalam stablecoin setiap bulan. Jika setiap pelanggan menghantar USDT ke alamat statik yang sama, pasukan perakaunan anda akan menghadapi mimpi ngeri hamparan (spreadsheet). Satu pemindahan kelihatan serupa dengan yang lain. Anda tidak dapat membezakan sama ada dua puluh dolar yang tiba pada jam 2 pagi itu adalah Pelanggan A yang memperbaharui pelan mereka atau Pelanggan B yang menaik taraf di tengah-tengah kitaran. Rantaian blok melihat angka. Perniagaan anda memerlukan sebuah cerita.

Pasaran (Marketplaces) merasai kesakitan ini di kedua-dua belah transaksi. Anda perlu tahu pembeli telah mendepositkan dana, pegang dana tersebut sementara penjual menghantar barang, dan lepaskan dana tersebut hanya selepas pengesahan penghantaran. Alamat mentah tidak memberikan anda cara pengaturcaraan untuk memisahkan deposit pembeli daripada pemindahan masuk rawak atau dana penjual itu sendiri. E-dagang juga sama kucar-kacirnya. Tanpa menghubungkan transaksi kepada pesanan tertentu, anda tidak dapat mencetuskan pemenuhan (fulfillment). Seseorang mesti mengimbas rantaian secara manual, mencari pemindahan tersebut, dan mengemas kini pangkalan data anda. Lakukan perkara itu sepuluh kali sehari dan anda akan terlepas padanan. Lakukan seribu kali dan anda akan kerugian wang.

Peralihan ini mudah tetapi kritikal. Berhenti bertanya sama ada dana telah sampai ke sesuatu alamat. Mula bertanya sama ada permintaan pembayaran tertentu telah mencapai status yang betul.

Bina Berasaskan Permintaan Pembayaran

Aliran pembayaran kripto yang boleh dipercayai menganggap permintaan pembayaran sebagai objek pusat. Alamat dompet menjadi bekas sementara yang wujud untuk berkhidmat kepada permintaan tersebut. Permintaan itu membawa metadata yang menukarkan pemindahan rantaian blok kepada acara perniagaan yang boleh dikenali.

Sebelum membentangkan pilihan pembayaran (checkout), takrifkan titik data yang menjadikan pembayaran tersebut boleh dikenal pasti:

  • ID pembelian atau langganan, supaya anda tahu dengan tepat mengapa wang tersebut berpindah.
  • Jumlah yang dijangkakan, dinyatakan sehingga ke angka perpuluhan.
  • Aset dan jenis rangkaian yang tepat, kerana menghantar USDT di Ethereum tidak boleh ditukar ganti dengan menghantarnya di Tron atau Polygon.
  • Rujukan kepada pelanggan atau akaun dalaman.
  • Masa tamat tempoh, supaya sebut harga yang dibayar separuh pada bulan Mac tidak menutup pesanan secara tidak sengaja pada bulan Jun.

Apabila pelanggan klik bayar, sistem anda menjana permintaan yang mengandungi medan-medan ini. Pelanggan kemudian membayar berdasarkan permintaan khusus tersebut, bukan sekadar alamat. Transaksi pada rantaian kini mempunyai identiti luar rantaian (off-chain). Sistem anda tahu untuk apa pembayaran itu sebelum ia sempat membuat pertanyaan kepada peneroka blok (block explorer).

Modelkan Status Secara Jujur

Wang di dalam rantaian blok bergerak dalam beberapa peringkat. Sistem dalaman anda memerlukan kosa kata yang sepadan dengan peringkat tersebut, atau pasukan kejuruteraan, sokongan, dan operasi anda akan gagal berkomunikasi dengan berkesan.

Kekalkan model ini secara mendatar dan deskriptif. Ejen sokongan bukan teknikal sepatutnya boleh membaca status dan tahu apa yang perlu diberitahu kepada pelanggan.

  • Created: Permintaan wujud, tetapi rantaian blok belum menunjukkan apa-apa lagi. Pelanggan belum menyiarkan transaksi.
  • Detected: Pemantauan anda mengesan transaksi yang berkaitan dalam mempool atau blok terbaru, tetapi ia belum mencapai tahap muktamad. Jangan hantar produk.
  • Confirming: Transaksi berada di dalam rantaian dan sedang mengumpul pengesahan. Rantaian bergerak pada kelajuan yang berbeza. Bitcoin mungkin memerlukan enam blok. Ethereum mungkin memerlukan dua belas atau lebih bergantung pada selera risiko anda. Sistem anda harus menghormati tingkah laku rangkaian itu sendiri.
  • Completed: Pembayaran sepadan dengan jumlah, aset, rangkaian, dan konteks yang dijangkakan. Setiap peraturan yang anda tetapkan telah dipenuhi. Kini anda boleh memenuhi pesanan, mengaktifkan langganan, atau melepaskan escrow.
  • Expired: Pelanggan terlepas tempoh pembayaran. Permintaan tersebut tidak sepatutnya menerima pembayaran masa hadapan melainkan anda mengaktifkannya semula secara eksplisit.
  • Mismatch: Pelanggan telah menghantar dana, tetapi terdapat sesuatu yang tidak kena. Jumlahnya tidak mencukupi, rangkaian berbeza, atau aset tidak sepadan. Salurkan ini kepada bahagian sokongan. Jangan biarkan sistem pemenuhan anda membuat tekaan.

Saluran (pipeline) ini menukarkan aliran data rantaian yang kucar-kacir kepada satu proses yang boleh difahami oleh seluruh syarikat anda.

Berhenti Melakukan Polling. Mula Mendengar.

Salah satu cara terpantas untuk membazirkan bajet infrastruktur adalah dengan membiarkan backend anda bertanya kepada penyedia anda setiap beberapa saat sama ada wang telah sampai atau belum. Ia membazirkan sumber di kedua-dua belah pihak dan menambah kependaman (latency) yang tidak perlu.

Seni bina yang lebih baik menggunakan model pemberitahuan status. Penyedia pembayaran atau infrastruktur nod anda harus menolak (push) acara (event) ke sistem anda sebaik sahaja status berubah. Anda menerima webhook apabila transaksi dikesan, satu lagi apabila ia sedang disahkan, dan yang terakhir apabila ia selesai atau gagal.

Ini memastikan sistem anda responsif tanpa menggunakan kitaran CPU yang tidak perlu.