Virtual Account dan transfer biasa: kenapa yang satu bisa cocok otomatis

Perbedaan antara Virtual Account dan transfer ke rekening biasa bukan soal kecepatan dana masuk. Keduanya sama-sama transfer bank, dan uangnya berjalan di rel yang sama. Yang berbeda adalah nomor yang dituju. Transfer biasa menuju satu nomor rekening yang sama untuk semua pembayar, sedangkan Virtual Account menerbitkan nomor yang berbeda untuk setiap tagihan. Karena nomornya berbeda, catatan yang masuk sudah membawa jawaban atas pertanyaan yang paling mahal dalam menerima pembayaran: transfer ini untuk pesanan yang mana.

Kenapa transfer biasa tidak pernah cocok dengan pasti

Pada transfer ke rekening biasa, satu-satunya petunjuk yang tersedia adalah nominal, nama pengirim, dan waktu. Ketiganya tampak cukup sampai transaksinya lebih dari beberapa per hari, lalu keempat masalah ini muncul bergantian.

• Nominal yang sama. Dua pesanan seharga Rp 150.000 pada sore yang sama menghasilkan dua catatan yang identik. Tidak ada cara memutuskan mana milik siapa selain bertanya.
• Nama yang tidak cocok. Pembayaran dikirim dari rekening pasangan, orang tua, atau rekan kantor. Nama pengirim tidak pernah sama dengan nama pemesan, dan itu hal yang normal, bukan pengecualian.
• Nominal yang meleset. Pembeli mengetik Rp 15.000 alih-alih Rp 150.000, atau membulatkan menjadi Rp 155.000. Catatannya masuk, tapi tidak cocok dengan tagihan mana pun.
• Bukti yang datang dari pihak yang membayar. Selama konfirmasi bersandar pada tangkapan layar, yang diperiksa adalah gambar, bukan dana. Enam bentuk pemalsuan yang benar-benar dipakai dibahas di bukti transfer palsu, dan tiga di antaranya memakai struk yang asli.

Trik kode unik, yaitu meminta pembeli menambah tiga digit di belakang nominal, adalah versi rakyat dari Virtual Account: memaksa identitas masuk ke satu-satunya kolom yang bisa dikendalikan, yaitu nominalnya. Trik ini bekerja pada volume kecil dan mulai gagal persis saat mulai berguna. Kodenya habis dan bertabrakan ketika banyak tagihan hidup bersamaan, pembeli sering membulatkan angka yang aneh itu, dan pembukuan jadi penuh nominal yang tidak sama dengan harga barangnya.

Yang sebenarnya terjadi pada Virtual Account

Nomor Virtual Account diterbitkan untuk satu tagihan, lalu diberikan ke pembeli untuk dituju dari aplikasi banknya. Ketika transfer masuk ke nomor itu, tidak ada yang perlu ditebak: nomornya sendiri sudah menyatakan tagihan mana yang dibayar. Pencocokan berhenti menjadi pekerjaan manusia dan menjadi konsekuensi dari cara nomornya dibuat.

Di Kasera Pay, tagihan Virtual Account dibuat lewat API dengan menyebut kode banknya pada payment_methods, misalnya va_mandiri. Responsnya membawa payment.payment_code berisi nomor yang harus dituju, nama banknya, blok instructions berisi langkah pembayaran untuk ditampilkan apa adanya, dan expires_at. Tujuh bank tersedia hari ini: BRI, BNI, Mandiri, Permata, CIMB Niaga, Danamon, dan Maybank. Daftar yang berlaku untuk satu akun sebaiknya dibaca dari GET /v1/payment_methods alih-alih ditulis permanen di kode, karena sebuah bank bisa diaktifkan atau dihentikan tanpa rilis di sisi mana pun. Rinciannya ada di dokumentasi Virtual Account, dan ringkasan produknya beserta tarif per transaksi ada di Virtual Account di Kasera Pay.

Dua hal yang sering terlewat saat pertama kali memakainya. Pertama, Virtual Account membutuhkan customer.name, karena nama itulah yang tampil di aplikasi bank pembeli saat nomor tujuan diperiksa; tanpa nama itu, create lewat Direct API ditolak dengan 422 customer_required. Kedua, jeda antara pembuatan tagihan dan pembayaran terhitung dalam jam, bukan menit, jadi masa berlaku Virtual Account pantas diatur lebih panjang daripada QRIS lewat expires_in_minutes, dengan maksimum mengikuti konfigurasi akun. Nama itu bukan pemeriksaan identitas dan tidak pernah dibandingkan dengan pemilik rekening yang mentransfer, yang menjadi penting pada pesanan yang dibayari orang lain: pembeli yang membayar dari rekening orang lain membahas akibatnya beserta nama yang sebaiknya diisi.

Konfirmasinya datang lewat webhook payment.paid saat transfernya benar-benar masuk, bukan saat tagihannya dibuat, dan setiap webhook ditandatangani pada header Kasera-Signature-V1 sehingga keasliannya bisa diperiksa tanpa panggilan balik. Status transaksinya berubah menjadi succeeded. Karena jedanya panjang, memeriksa ulang lewat GET /v1/transactions/:id dengan jadwal jarang adalah pelengkap yang masuk akal khusus untuk Virtual Account. Untuk pembuatan tagihannya sendiri, header Idempotency-Key adalah satu-satunya yang mencegah satu pesanan menjadi dua tagihan; external_id dan merchant_ref hanya label yang disimpan dan dikembalikan.

Yang tidak diperbaiki Virtual Account

Virtual Account bukan jawaban untuk semua hal, dan tiga batas ini nyata. Transfer yang sudah masuk tidak bisa dibalik, sehingga pengembalian dana harus dilakukan sebagai transfer terpisah dengan konsekuensi biaya sendiri. Pembeli tetap harus membuka aplikasi bank dan menyalin nomor yang panjang, jadi tombol salin dan instruksi yang jelas mengurangi sebagian besar pertanyaan yang masuk. Dan struktur biayanya berbeda dari QRIS: Virtual Account dikenai biaya tetap Rp 5.000 per pembayaran berhasil, sementara QRIS dikenai biaya Kasera Rp 250 per transaksi ditambah tarif QRIS 0,7 persen. Keduanya diterbitkan terbuka di halaman biaya, dan tarif yang berlaku untuk satu akun tetap terbaca per metode lewat GET /v1/payment_methods.

Satu batas lagi yang sering ditanyakan lebih dulu: nomornya diterbitkan per tagihan dan tidak bisa dijadikan nomor tetap yang melekat pada satu pelanggan. Apa yang hilang karena itu dan cara menutupinya dibahas di perbandingan nomor Virtual Account tetap dengan nomor per pesanan.

Kapan QRIS tetap lebih tepat

QRIS unggul saat uangnya ada di ponsel yang sama dengan yang memesan: satu scan, selesai dalam hitungan detik, tanpa menyalin nomor. Virtual Account unggul saat nominalnya besar, saat pembayar lebih percaya memindahkan uang dari mobile banking daripada dari e-wallet, atau saat pembayarannya memang direncanakan untuk besok. Keduanya bisa ditawarkan sekaligus dalam satu tagihan dengan mengirim beberapa kode pada payment_methods, dan pembeli yang memilih.

Satu catatan yang berlaku hari ini dan pantas diketahui sebelum merencanakan alur: halaman checkout yang dihost Kasera Pay menuntaskan kedua metode, yaitu QRIS sebagai kode QR dan Virtual Account sebagai nomor pembayaran lengkap dengan petunjuknya, jadi Virtual Account tidak lagi menuntut halaman pembayaran milik sendiri. Status terbarunya selalu ada di dokumentasi metode pembayaran. Formulir pembuatan pembayaran di dashboard punya pemilih metode, sehingga penjual yang belum memakai integrasi sendiri bisa mulai dari sana; tiga jalur menerima pembayaran tanpa menulis kode dibahas di panduan menerima QRIS tanpa website.

Ringkasnya

Transfer ke rekening biasa memindahkan uang dengan benar dan memindahkan informasi dengan buruk. Setiap upaya memperbaikinya, mulai dari kode unik sampai meminta tangkapan layar, berusaha menempelkan identitas pada catatan yang memang tidak dirancang membawanya. Virtual Account menyelesaikan hal itu di tempat asalnya, yaitu pada nomor tujuannya, sehingga pertanyaan siapa membayar apa tidak pernah perlu diajukan.