Lewat agregator atau membangun integrasi sendiri ke bank: biaya yang tidak pernah muncul di tabel tarif

Pertanyaannya hampir selalu muncul dalam bentuk yang sama. Kalau uangnya toh berakhir di bank, kenapa harus ada pihak di tengah yang menagih persentase pada tiap transaksi, dan bukankah menghubungkan sistem sendiri langsung ke bank akan menghapus biaya itu. Bagian pertama dari pertanyaan itu benar. Bagian keduanya mengandaikan bahwa yang dibeli dari sebuah agregator adalah koneksi teknis, padahal koneksi teknis justru bagian termurah dari yang dibayar.

Kami membangun Kasera Pay, jadi kepentingannya jelas ada di satu sisi. Justru karena itu halaman ini disusun sebagai daftar biaya, bukan sebagai bujukan: ada keadaan yang membuat integrasi langsung benar-benar pilihan yang tepat, dan keadaan itu bisa dikenali dari angka, bukan dari selera.

Yang sebenarnya dibeli dari sebuah agregator

Sebuah agregator menjual paket yang isinya empat, dan tabel tarif hanya menyebut harganya, tidak pernah isinya.

• Izin. Menerima uang milik orang lain lalu meneruskannya adalah kegiatan yang diatur, dan mengakses rail pembayaran mensyaratkan status sebagai penyelenggara jasa pembayaran berlisensi. Ini tembok yang berdiri sebelum baris kode pertama, dan tidak bisa dilewati dengan kemampuan teknis.
• Kontrak, satu untuk tiap rail. Bukan satu kontrak untuk semua metode pembayaran, melainkan satu hubungan komersial dan teknis untuk tiap bank dan tiap skema.
• Rekonsiliasi. Uang yang masuk lewat banyak rail harus dicocokkan dengan pesanan, per rail, dengan jadwal dan format yang berbeda-beda.
• Operasi yang berjalan terus. Ada orang yang menerima telepon ketika sebuah rail berhenti merespons pada malam hari, dan biaya itu tidak berhenti pada bulan yang sepi.

Jumlah integrasi bukan satu, melainkan sebanyak rail-nya

Ini bagian yang paling sering salah diperkirakan. “Integrasi langsung ke bank” terdengar seperti satu pekerjaan, padahal jumlahnya mengikuti jumlah metode pembayaran yang ingin ditawarkan. Bentuknya bisa dilihat pada produk ini sendiri: daftar di dokumentasi metode pembayaran menampilkan QRIS dan Virtual Account dari delapan bank, dan di belakang satu antarmuka yang seragam itu tidak ada satu hubungan, melainkan sembilan.

Tiap rail membawa perbedaannya sendiri, dan perbedaan itulah yang menjadi pekerjaan: bentuk identitas pembayaran berbeda, nomor Virtual Account per transaksi tidak sama persoalannya dengan kode QR yang dipindai, jadwal penyelesaian dana berbeda antar lembaga, dan cara tiap pihak memberi tahu bahwa uang sudah masuk juga berbeda. Menambah satu bank berarti menambah satu integrasi penuh beserta satu rekonsiliasi baru, bukan menambah satu baris konfigurasi.

Pekerjaan yang tetap ada setelah integrasinya jadi

Perkiraan biaya integrasi langsung hampir selalu berhenti pada “menyambungkan API”, padahal bagian itu selesai dalam hitungan minggu dan tidak pernah menjadi bagian yang mahal. Yang mahal adalah yang berulang setiap hari sesudahnya, dan daftarnya sama untuk siapa pun yang membangunnya sendiri:

• Menjaga satu permintaan yang terkirim dua kali tidak menjadi dua tagihan, persoalan yang bentuknya diuraikan di tulisan tentang idempotency.
• Memverifikasi keaslian tiap pemberitahuan yang masuk, lalu tetap memeriksa bahwa nominalnya cocok dengan pesanan, karena tanda tangan yang sah hanya membuktikan asal dan bukan kebenaran isinya. Uraiannya ada di tulisan tentang webhook yang aman.
• Mengulang pengiriman yang gagal, mengarantina nominal yang tidak cocok alih-alih menerimanya, dan menjaga status sebuah pembayaran tidak pernah berpindah ke tempat yang tidak masuk akal.
• Memutar kunci dan sertifikat sebelum kedaluwarsa, pada tiap rail, selamanya.

Perbandingannya berdampingan

Kekalahan yang jujur dari sisi agregator

Biaya per transaksi tidak pernah berhenti, dan itu bukan hal sepele. Pada volume yang besar, persentase yang sama terus menerus menjadi angka yang jauh lebih besar daripada gaji beberapa orang. Selain itu ada tiga hal lain yang benar-benar hilang: kendali atas jadwal penyelesaian dana, kemampuan menawarkan metode pembayaran yang tidak dimiliki agregatornya, dan kepastian bahwa syarat layanannya tidak berubah. Tarif Kasera Pay ada di syarat layanan, termasuk kalimat bahwa perubahan biaya diberitahukan 30 hari sebelumnya, dan kalimat semacam itu adalah pengakuan bahwa tarif memang bisa berubah.

Kapan integrasi langsung benar-benar masuk akal

Ada tiga keadaan, dan ketiganya bisa diperiksa tanpa berdebat. Pertama, ketika total biaya per transaksi setahun sudah melampaui biaya sebuah tim pembayaran setahun ditambah kewajiban perizinan, bukan melampaui perkiraan biaya membangunnya. Kedua, ketika metode pembayaran yang dibutuhkan memang tidak tersedia di agregator mana pun yang bisa dipakai. Ketiga, ketika pembayaran itu sendiri yang menjadi produknya, sehingga menjadi penyelenggara berlisensi bukan biaya tambahan melainkan rencana usahanya.

Di luar ketiganya, yang biasanya dicari bukan integrasi langsung melainkan agregator yang biayanya lebih masuk akal, atau integrasi yang lebih rapi. Urutan langkah integrasi dari kunci API sampai webhook ada di panduan integrasi QRIS di website.

Jalan tengah yang menjaga pilihan tetap terbuka

Keputusan ini tidak perlu dikunci hari ini, asalkan satu aturan dipegang sejak awal: catatan pesanan tinggal di basis data sendiri, dan pemberitahuan dari pihak mana pun diperlakukan sebagai kabar, bukan sebagai buku besar. Artinya id pesanan lahir di sistem sendiri, id pembayaran dari luar disimpan sebagai kolom pendamping, dan tiap pemberitahuan yang masuk dipakai untuk mencari pesanan lalu memeriksa nominalnya, bukan untuk membuat pesanan baru.

Susunan itu tidak menambah pekerjaan hari ini dan menghapus sebagian besar biaya perpindahan nanti. Yang benar-benar mengunci sebuah usaha pada penyedia pembayarannya bukan tarif, melainkan riwayat pesanan yang hanya ada di tempat lain.

Pertanyaan yang sering muncul

Bentuk integrasinya sendiri, dari membuat permintaan pembayaran sampai verifikasi otomatis lewat webhook, dirangkum di API QRIS Kasera Pay.