Data pembeli yang diminta halaman pembayaran, kenapa daftarnya berbeda tiap pesanan, dan satu field yang terlihat benar tetapi tidak dihitung

Halaman pembayaran Kasera Pay kadang meminta nama pembeli, kadang meminta email, dan kadang langsung menampilkan QR tanpa bertanya apa pun. Daftarnya berbeda dari pesanan ke pesanan, dan itu bukan kebetulan. Daftar itu dihitung dari satu rumus yang selalu sama.

Yang ditanyakan ke pembeli
  = (yang dibutuhkan metode yang ditawarkan)
  + (yang penjual minta lewat setelan)
  - (yang penjual sudah isi sendiri)

Dua sumber permintaan, dijumlahkan, lalu dikurangi apa yang penjual sudah isi sendiri. Memahami rumus itu cukup untuk mengatur persis berapa banyak yang harus diketik pembeli sebelum bisa membayar, dan setiap kolom yang bisa dihapus adalah satu alasan lebih sedikit untuk menutup halaman.

Tulisan ini membahas datanya. Urutan layar yang dilihat pembeli dari tautan dibuka sampai lunas dibahas terpisah di yang dilihat pembeli dari awal sampai selesai.

Hanya ada tiga field, dan tidak pernah lebih

Yang bisa diminta halaman pembayaran kepada pembeli hanya nama lengkap, email, dan nomor telepon. Tidak ada kolom alamat, tidak ada kolom catatan, tidak ada kolom yang bisa ditambahkan penjual. Batas panjangnya pun tetap: nama 120 karakter, email 254, nomor telepon 32.

Sisi negatif dari kenyataan itu justru yang paling berguna untuk dikirim ke pembeli yang ragu. Karena hanya tiga field itu yang pernah ada, permintaan apa pun di luar ketiganya bukan berasal dari halaman pembayaran. PIN, kata sandi mobile banking, kode sekali pakai, nomor kartu, dan foto identitas tidak pernah diminta, dan permintaan semacam itu selalu penipuan terlepas dari tautannya asli atau tidak. Pembahasan lengkap dari sisi pembeli ada di aman tidak membayar lewat tautan.

Sumber pertama: yang dibutuhkan metodenya

Tiap metode pembayaran punya syarat datanya sendiri, dan syarat itu bukan pilihan melainkan kebutuhan teknis jalurnya.

QRIS              tidak membutuhkan apa pun
Virtual Account   membutuhkan nama
Kartu             membutuhkan email

QRIS tidak membutuhkan apa pun, karena data pembayar sudah ada di aplikasi yang memindai. Virtual Account membutuhkan nama karena nama itulah yang menempel pada nomor yang diterbitkan, dan nomornya memang baru bisa dicetak setelah namanya diketahui. Kartu membutuhkan email karena jalur kartu berpindah ke halaman penyedia jasa pembayaran berlisensi, dan email itu yang dipakai di sana.

Bagian yang paling sering mengejutkan penjual: yang dihitung adalah gabungan seluruh metode yang ditawarkan, bukan metode yang akhirnya dipilih pembeli. Selama pembeli belum memilih jalurnya, semua jalur masih mungkin, jadi datanya harus sudah tersedia untuk jalur mana pun.

# Ditawarkan QRIS saja, tidak ada setelan tambahan
payment_methods: ["qris"]              -> pembeli tidak ditanya apa pun

# Ditawarkan QRIS dan BCA Virtual Account
payment_methods: ["qris", "va_bca"]    -> pembeli ditanya nama
                                          (walau akhirnya membayar lewat QRIS)

# Sama, tetapi nama sudah diisi penjual saat membuat tagihan
payment_methods: ["qris", "va_bca"]
customer: { "name": "Sari" }           -> pembeli tidak ditanya apa pun

Menambahkan satu bank Virtual Account ke tagihan yang sebelumnya hanya QRIS berarti menambah satu kolom yang harus diisi pembeli, termasuk pembeli yang pada akhirnya membayar lewat QRIS. Itu bukan alasan untuk tidak menawarkannya, tetapi pertukaran yang layak disadari, terutama pada nominal kecil tempat QRIS hampir selalu lebih murah. Hitungannya ada di memilih antara QRIS dan Virtual Account.

Sumber kedua: yang penjual minta sendiri

Di luar kebutuhan metode, penjual bisa meminta nama, email, atau nomor telepon lewat setelan metode pembayaran di dashboard. Ketiganya berdiri sendiri dan berlaku untuk semua pembayaran berikutnya.

Nomor telepon adalah satu-satunya dari ketiganya yang tidak pernah dibutuhkan metode mana pun, jadi nomor telepon selalu berasal dari sumber kedua ini. Kalau nomor itu memang dipakai untuk mengabari pengiriman, meminta lewat setelan masuk akal. Kalau tidak dipakai, mematikannya menghapus satu kolom tanpa kehilangan apa pun.

Satu hal yang perlu diketahui bagi yang membuat tagihan lewat API: setelan akun itu diwarisi hanya kalau objek checkout tidak dikirim sama sekali. Mengirim objek itu mengganti ketiga permintaan sekaligus, jadi objek checkout yang hanya berisi steps justru mematikan ketiga setelan akun untuk pembayaran tersebut. Ini bukan galat, dan tidak ada peringatan yang muncul.

Yang ditanya berarti wajib

Tidak ada kolom opsional di formulir itu. Kolom yang muncul harus diisi, dan tombol lanjut baru aktif setelah semua kolom yang tampil terisi. Pilihannya bukan antara wajib dan opsional, melainkan antara ditanyakan dan tidak ditanyakan sama sekali.

Karena itu cara memperpendek formulirnya bukan melunakkan kolomnya, melainkan menghapus penyebabnya: isi datanya sendiri saat membuat tagihan, jangan tawarkan metode yang membutuhkannya, atau matikan permintaan tambahan di setelan.

Yang sudah diisi penjual tidak pernah ditanyakan lagi

Bagian pengurangan dalam rumus di awal berlaku mutlak. Data yang sudah dikirim penjual saat membuat tagihan dihapus dari daftar yang perlu ditanyakan, jadi pembeli tidak pernah diminta mengetik ulang sesuatu yang penjual sudah tahu.

Untuk penjual yang pesanannya datang dari chat, ini berarti formulirnya bisa hilang seluruhnya. Nama pembeli biasanya sudah ada di percakapan, dan mengisikannya saat membuat tagihan menghapus satu langkah dari sisi pembeli. Tagihan yang dibuat lengkap dengan nama pembeli dan satu metode pembayaran saja langsung membuka layar pembayarannya. Latar belakang penagihan lewat chat ada di jualan lewat WhatsApp dan Instagram.

Satu field yang terlihat benar tetapi tidak dihitung

Bagi yang membuat tagihan lewat API, ini jebakan yang paling mahal di halaman ini. Ada dua tempat yang sama-sama menerima nama, email, dan nomor telepon: customer dan payer. Keduanya sama-sama disimpan dan dikembalikan, jadi nama yang dikirim di payer memang akan terlihat kembali dan tidak ada yang tampak salah.

# Tidak memenuhi syarat Virtual Account: ditolak 422 customer_required
payer:    { "name": "Sari" }

# Memenuhi syarat
customer: { "name": "Sari" }

Tetapi hanya customer yang memenuhi syarat sebuah metode pembayaran. Nama yang dikirim di payer tidak akan mengisi Virtual Account, dan pada pembuatan tagihan tanpa halaman checkout, keadaan itu ditolak 422 customer_required seolah-olah namanya tidak pernah dikirim. payer ada lebih dulu daripada customer dan dipertahankan karena tetap disimpan; pada API ini, kirim customer.

Penolakan itu sendiri hanya terjadi kalau tidak ada halaman yang bisa bertanya. Tagihan yang dibuat dengan halaman checkout tidak pernah ditolak karena data pembeli kurang, karena formulirnya yang akan mengumpulkan kekurangannya. Rinciannya ada di daftar kode galat.

Yang diterima penjual setelahnya

Data yang diisi pembeli kembali ke penjual: ikut di respons pembacaan transaksi dan ikut di event payment.paid yang dikirim ke webhook. Jadi nama yang diketik pembeli di halaman pembayaran tidak perlu ditanyakan ulang lewat chat, dan bisa langsung masuk ke catatan pesanan di sistem penjual.

Bagi yang menyimpannya di basis data sendiri, kolom mana yang layak disimpan dan mana yang sebaiknya tidak dibahas terpisah di yang perlu disimpan dari sebuah pembayaran di basis data sendiri.

Ringkasnya

Formulir terpendek yang mungkin dicapai adalah tidak ada formulir sama sekali, dan itu bukan hal yang jarang. Tagihan QRIS tanpa permintaan tambahan di setelan tidak menanyakan apa pun kepada pembeli. Begitu sebuah Virtual Account ikut ditawarkan, nama menjadi wajib; begitu kartu ikut ditawarkan, email menjadi wajib. Sisanya berasal dari setelan sendiri dan bisa dimatikan kapan saja.

Pertanyaan yang sering muncul