Cara menangani invoice kripto yang kurang atau lebih bayar

Invoice yang kurang bayar tidak boleh memicu fulfillment otomatis; invoice lebih bayar juga tidak boleh memicu refund otomatis. Pertama, konfirmasi jaringan, contract asli, penerima, status, dan jumlah. Lalu terapkan kebijakan tertulis yang mencatat selisih dan menghasilkan satu keputusan jelas.

Di GramPayBot, jumlah yang diharapkan bersifat tepat. Transfer lebih rendah diklasifikasikan partial; transfer lebih tinggi menjadi overpaid. Keduanya tidak diam-diam menjadi invoice paid normal.

Tabel keputusan

Hasil verifikasi	Keputusan invoice	Langkah berikutnya
Jumlah sama persis	Dapat cocok setelah konfirmasi	Penuhi saat paid
Jumlah lebih rendah	Pembayaran sebagian	Catat kekurangan dan beri instruksi
Jumlah lebih tinggi	Kelebihan pembayaran	Putuskan menerima, kredit, atau refund
Beberapa transfer terkait	Kasus ambigu	Verifikasi setiap hash manual
Jaringan, token, atau penerima salah	Bukan pembayaran invoice ini	Ikuti alur rute salah

Jika jaringannya salah, ikuti panduan investigasi dan recovery jaringan salah. Jika selisih melibatkan invoice kedaluwarsa atau pengganti, gunakan alur invoice belum dibayar, terlambat, dan kedaluwarsa sebelum meminta pembayaran lain.

BTCPay Server memisahkan status partial dan overpaid dari invoice yang settle normal. Stripe juga mencatat sisa dan kelebihan secara terpisah. Referensi ini tidak menentukan kebijakan bisnis Anda, tetapi menunjukkan mengapa pengecualian jumlah memerlukan status sendiri.

Penyebab umum kurang bayar

• membulatkan angka alih-alih menyalin semua digit;
• salah memahami biaya wallet atau exchange;
• mengirim tes dan menganggapnya otomatis dijumlahkan;
• memakai instruksi lama atau invoice kedaluwarsa;
• integrasi salah menangani desimal token;
• beberapa orang mencoba membayar pesanan yang sama;
• sengaja menahan sebagian karena sengketa.

Biaya withdrawal berbeda antar penyedia dan dapat berubah. Binance, misalnya, menyatakan biaya withdrawal kripto bersifat dinamis dan tampil di halaman withdrawal. Tidak ada aturan universal bahwa biaya jaringan selalu mengurangi jumlah penerima. Pembeli harus memeriksa preview akhir.

Penyebab umum lebih bayar

Pembeli dapat menyalin harga fiat sebagai jumlah token, menambahkan fee yang sebenarnya ditagih terpisah, membayar dua kali, mengirim total setelah tes, atau salah dalam unit/desimal.

Meski UI menampilkan desimal, blockchain merepresentasikan jumlah sebagai unit dasar integer. Contoh resmi Circle menunjukkan USDC dengan enam angka desimal. Integrasi harus mengonversi atomic unit secara deterministik, bukan membandingkan perkiraan floating-point.

Verifikasi transfer sebelum menyelesaikan

1. Buka hash di explorer jaringan invoice.
2. Pastikan sukses dan cukup terkonfirmasi.
3. Periksa contract atau mint, bukan hanya simbol.
4. Bandingkan alamat penerima lengkap.
5. Baca jumlah pada event transfer atau balance change.
6. Bandingkan dengan semua digit checkout.
7. Periksa apakah transaksi lain sudah dipakai untuk pesanan.
8. Bandingkan waktu blok dengan tenggat.

Jika contract salah, masalahnya bukan sekadar selisih jumlah; asetnya berbeda. Gunakan panduan verifikasi contract USDT dan USDC.

Setelah verifikasi, kaitkan setiap hash yang diterima dengan tepat satu invoice dan pesanan. Panduan mencocokkan pembayaran kripto dengan pesanan menjelaskan cara menjaga hubungan itu tanpa bergantung pada screenshot atau username chat.

Matching jumlah tepat di GramPayBot

GramPayBot menetapkan jaringan, token, penerima, dan jumlah sebelum pembayaran. Jumlah checkout saat ini memakai paling banyak empat digit setelah desimal dan dapat memuat suffix identifikasi. Jika tertulis 180.0134 USDT, kirim seluruh angka, bukan 180 USDT yang dibulatkan. USDT atau USDC dapat memakai enam desimal unit dasar on-chain; itu tidak berarti GramPayBot menampilkan suffix invoice enam digit.

Transfer terkonfirmasi yang tepat dapat membayar invoice; yang lebih rendah menjadi partial; yang lebih tinggi overpaid; beberapa kandidat atau transaksi yang sudah dipakai bukan kecocokan bersih. Matcher normal tidak menjumlahkan transaksi kedua sembarang sebagai “top-up”. Minta pembeli tidak mengirim lagi sebelum ada solusi eksplisit.

Alur untuk kurang bayar

1. Hitung kekurangan terverifikasi

Hitung dalam unit token:

kekurangan = jumlah invoice tepat − jumlah diterima terverifikasi

2. Tahan fulfillment

Jangan tandai pesanan paid hanya karena sebagian besar jumlah sudah tiba. Ini mencegah keputusan berbeda untuk kasus yang setara.

3. Pilih satu resolusi tertulis

Pilih satu hasil:

• terima manual sebagai diskon atau write-off;
• buat invoice baru dan terpisah untuk sisa;
• batalkan fulfillment dan refund jumlah terverifikasi;
• eskalasi ke support atau compliance.

Jika menagih sisa, kaitkan invoice baru dengan pembayaran awal di catatan. Jangan menjanjikan invoice lama akan menjumlahkan dua transaksi otomatis.

4. Beri tahu hasil kepada pembeli

Beri tahu jumlah diterima, selisih, keputusan, dan referensi invoice baru atau refund.

Alur untuk lebih bayar

1. Singkirkan transfer ganda atau tidak terkait

Pastikan dulu bukan pembayaran ganda atau transaksi milik pesanan lain.

2. Pisahkan jumlah invoice dari kelebihan

Catat:

kelebihan = jumlah diterima terverifikasi − jumlah invoice tepat

Jangan mengubah jumlah invoice secara retroaktif.

3. Terapkan satu kebijakan

Sesuai ketentuan, refund kelebihan, jadikan kredit yang disepakati, terima sebagai tip/pembelian tambahan, atau refund semua dan buat invoice baru.

Dokumentasi pembayaran parsial Stripe memberi contoh non-kripto mengapa saldo dan kelebihan membutuhkan aturan formal.

4. Verifikasi alamat refund secara terpisah

Jangan otomatis refund ke pengirim on-chain. Exchange mungkin memakai wallet bersama. Autentikasi pelanggan melalui pesanan, konfirmasi alamat refund jaringan yang sama, jelaskan fee, dan simpan hash baru. Refund adalah transfer baru, bukan pembalikan.

Kebijakan yang perlu ditentukan sebelumnya

• apakah toleransi kurang bayar ada dan cara menghitungnya;
• apakah invoice sisa diizinkan;
• nilai minimum refund setelah biaya jaringan;
• apakah kredit pelanggan didukung;
• siapa yang menyetujui penerimaan manual dan refund;
• penanganan duplikat;
• lama penyimpanan catatan pengecualian.

Jika ada toleransi, terapkan konsisten dan jangan menyembunyikannya di matching tepat bila integrasi tidak mendukung aturan tersebut.

Instruksi pencegahan untuk pembeli

Buka invoice terbaru, pilih token dan jaringan tepat, salin semua digit desimal, periksa apakah exchange mengurangi jumlah penerima, kirim sekali, dan simpan hash. Jika sudah melakukan tes atau invoice kedaluwarsa, berhenti dan hubungi merchant.

Lihat cara membayar invoice dengan USDT atau USDC.

Template catatan pengecualian

Untuk setiap pembayaran kurang atau lebih, simpan:

• ID invoice dan pesanan;
• jaringan, token, penerima, dan jumlah tepat yang diharapkan;
• semua hash terkait;
• jumlah terverifikasi dan status konfirmasi per hash;
• kekurangan atau kelebihan dalam unit token;
• tenggat invoice dan waktu blok;
• metode autentikasi pelanggan;
• resolusi, penyetuju, dan timestamp;
• referensi invoice sisa, kredit, atau refund.

Catatan ini mencegah transfer dihitung dua kali dan memungkinkan staf lain mereproduksi keputusan.

Pertanyaan umum

Apakah pembayaran kedua otomatis melengkapi invoice partial?

Jangan menganggap demikian. Matcher normal mengharapkan satu transfer tepat dan tidak menjumlahkan pembayaran parsial sembarang. Tunggu invoice sisa atau instruksi jelas.

Bolehkah jumlah checkout dibulatkan?

Tidak. Kirim semua digit; suffix dapat dipakai untuk mengidentifikasi invoice.

Apakah invoice lebih bayar otomatis menjadi paid?

Tidak. Itu pengecualian yang memerlukan review manual.

Refund ke alamat pengirim?

Jangan otomatis. Konfirmasi pelanggan dan alamat refund, terutama bila dana berasal dari exchange.

Apakah transfer USDT asli membuktikan pesanan sudah dibayar?

Tidak dengan sendirinya. Jaringan, contract token, penerima, jumlah, jendela pembayaran, dan identitas transaksi harus cocok dengan invoice, dan transfer harus terkonfirmasi.