Menerima pembayaran kartu kredit: biayanya, chargeback, dan kapan layak dinyalakan

Kartu kredit dan debit sudah aktif di Kasera Pay. Satu kode, card, mencakup Visa, Mastercard, JCB, dan Amex, dan status aktifnya bisa dicek sendiri di daftar metode pembayaran. Tetapi menyalakan kartu bukan keputusan yang otomatis benar hanya karena channelnya bertambah. Kartu adalah metode termahal di daftar, dan satu-satunya yang bisa menarik uang kembali berbulan-bulan setelah barang dikirim.

Artikel ini menghitung selisih biayanya terhadap QRIS dan Virtual Account, menjelaskan risiko yang tidak dimiliki dua metode lain itu, lalu menutup dengan kondisi konkret yang membuat kartu layak dinyalakan.

Berapa mahalnya, dibandingkan QRIS dan Virtual Account

Tarif tiap metode dikembalikan oleh GET /v1/payment_methods sebagai persen dalam basis poin plus rupiah tetap. Tarif default yang diterbitkan di dokumentasi adalah 0,7% + Rp 250 untuk QRIS, Rp 5.000 tetap untuk Virtual Account, dan 2,8% + Rp 2.500 untuk kartu. Ketiganya menerima nominal Rp 10.000 sampai Rp 10.000.000.

Dua hal yang perlu dibaca dari tabel itu. Pertama, kartu tidak pernah lebih murah daripada QRIS, pada nominal berapa pun. Komponen persennya empat kali lipat dan komponen tetapnya sepuluh kali lipat, jadi tidak ada titik impas yang bisa dikejar dengan menaikkan nominal. Kedua, terhadap Virtual Account ceritanya berbeda: karena VA berbiaya tetap Rp 5.000, kartu justru lebih murah di bawah sekitar Rp 89.000. Di atas angka itu VA yang lebih murah, dan selisihnya melebar terus.

Artinya kartu tidak pernah menjadi pilihan yang diambil karena biaya. Kartu diambil karena pembeli tertentu tidak punya cara lain untuk membayar, dan biaya tambahannya adalah harga untuk menjangkau pembeli itu. Pada margin yang tipis, selisih Rp 5.400 per transaksi Rp 150.000 terhadap QRIS bisa memakan seluruh keuntungan satu pesanan.

Yang lebih mahal daripada tarifnya: uang bisa ditarik kembali

QRIS dan Virtual Account bersifat final. Setelah statusnya succeeded, uangnya tidak bisa diambil kembali oleh pembayar. Kartu tidak begitu. Pemegang kartu bisa mengajukan sanggahan ke bank penerbitnya berbulan-bulan setelah transaksi, dan kalau sanggahan itu dimenangkan, nominalnya ditarik kembali dan dipotong dari pencairan berikutnya, sama seperti refund. Biaya pada pembayaran aslinya tidak ikut kembali.

Konsekuensinya bersifat operasional, bukan teknis: catatan pesanan harus disimpan. Data pembeli yang dikirim di objek customer, bukti pengiriman, dan riwayat percakapan adalah bahan yang menjawab sanggahan. Penjual yang menghapus riwayat pesanan setelah barang dikirim tidak punya apa pun untuk dilawankan. Untuk penjualan barang fisik bernominal besar ke pembeli baru, ini risiko yang perlu dihitung sebelum kartu dinyalakan, bukan setelah sanggahan pertama datang.

Kartu satu-satunya metode yang bisa direfund lewat API

Sisi baiknya ada juga, dan hanya ada di kartu. Pengembalian dana pada QRIS dan Virtual Account dilakukan manual, yaitu transfer terpisah dari rekening sendiri ke rekening pembeli. Pada kartu, POST /v1/refunds mengembalikan uang secara programatik ke kartu yang sama. Nominalnya boleh dikosongkan untuk seluruh pembayaran atau disebut untuk refund sebagian, dan refund sebagian boleh diulang sampai nominal yang dibayar habis. Permintaan refund pada metode selain kartu ditolak 422 refund_not_supported, dan prosedur manual untuk kedua metode itu ada di panduan mengembalikan uang pembeli pada QRIS dan Virtual Account.

Tiga hal yang sering baru disadari setelah refund pertama:

• Biaya tidak ikut kembali. Biaya pada pembayaran aslinya tetap berlaku apa pun yang direfund. Pada refund penuh, biaya itu menjadi tanggungan penjual.
• Nominalnya dipotong dari pencairan berikutnya, tercantum sebagai refund_withheld. Alurnya sama dengan potongan lain yang dijelaskan di panduan pencairan dana.
• Header Idempotency-Key tetap wajib dipakai. Refund yang diulang dengan kunci yang sama mengembalikan refund yang asli, bukan memindahkan uang dua kali. Tanpa kunci itu, setiap percobaan ulang adalah refund baru.

Satu jawaban yang perlu ditangani terpisah adalah 502 refund_unresolved: pemroses tidak bisa dihubungi dan nominalnya ditahan berstatus pending. Jangan diulang, karena pengulangan berisiko mengembalikan uang dua kali. Yang benar adalah menghubungi dukungan. Bandingkan dengan 502 refund_refused, yang berarti tidak ada uang yang bergerak sama sekali sehingga aman dicoba lagi.

Yang tidak perlu dibangun: kepatuhan kartu

Menangani nomor kartu mentah menuntut sertifikasi PCI DSS, dan itu proyek tersendiri yang jauh lebih besar daripada integrasi pembayaran. Kartu di Kasera Pay tidak menuntut itu. Bentuknya redirect: respons create memuat payment.redirect_url, pembeli diarahkan ke sana, nomor kartu diketik di halaman pemroses, dan 3-D Secure berjalan di sana juga. Tidak ada endpoint yang menerima nomor kartu, jadi tidak ada nomor kartu yang pernah melewati server penjual.

Arahkan dengan navigasi tingkat atas, bukan iframe. Langkah 3-D Secure dari bank penerbit memang keluar dari frame apa pun, jadi iframe hanya menghasilkan halaman yang tampak rusak. Langkah lengkapnya ada di dokumentasi kartu kredit.

Dua kesalahan integrasi yang paling sering terjadi

Pertama, lupa mengirim customer.email. Kartu adalah satu-satunya metode yang mewajibkannya, karena pemroses membutuhkan identitas untuk menjalankan 3-D Secure dan mengirim struk. Create yang menyebut card tanpa email ditolak 422 customer_required. Pada halaman checkout bawaan, langkah customer yang menanyakannya ke pembeli, jadi masalah ini hanya muncul pada integrasi Direct API atau ketika langkah itu sengaja dihilangkan.

Kedua, memenuhi pesanan berdasarkan kembalinya pembeli. Setelah membayar, pembeli diarahkan kembali ke return_url dengan ?id=payreq_…&status=succeeded. URL itu bisa diketik siapa saja, jadi bukan bukti pembayaran. Yang menjadi dasar pemenuhan adalah webhook payment.paid yang bertanda tangan, dan pada kartu webhook itu menyala saat otorisasi sehingga biasanya sudah tiba ketika pembeli masih dalam perjalanan kembali. Cara memverifikasinya dengan benar dibahas di artikel webhook pembayaran yang aman.

Kapan kartu layak dinyalakan

Kartu masuk akal ketika pembeli berada di luar Indonesia dan tidak punya aplikasi yang mendukung QRIS, ketika nominalnya besar sehingga selisih 2,1 persen terhadap QRIS masih tertutup margin, ketika pembeli korporat membayar dengan kartu perusahaan karena alasan pembukuan, dan ketika kolom kartu memang diharapkan ada sehingga ketiadaannya membuat pesanan batal.

Kartu tidak masuk akal ketika seluruh pembeli ada di Indonesia dan sudah terbiasa memindai QRIS, ketika nominal rata-rata kecil sehingga komponen tetap Rp 2.500 memakan porsi besar, dan ketika barangnya dikirim jauh setelah pembayaran sehingga jendela sanggahan terbuka lebar. Untuk mayoritas penjual online di Indonesia, QRIS dan Virtual Account sudah menutup hampir seluruh pembayaran, dan kartu adalah pelengkap, bukan pengganti.

Menyalakannya dilakukan dari pengaturan metode pembayaran di dashboard, lalu kirim "payment_methods": ["card"] untuk mengarahkan satu pembayaran langsung ke kartu, atau kosongkan isian itu agar pembeli memilih sendiri dari semua metode yang aktif. Jangan menulis daftar metode secara permanen di kode: baca GET /v1/payment_methods, karena sebuah metode bisa diaktifkan, dihentikan, atau diubah tarifnya tanpa rilis di sisi integrasi.