Mengapa perlu ada integrasi pembayaran dengan Bank, khususnya untuk pembayaran SPP atau pembayaran mahasiswa secara umum? Tidak cukup kah dengan meminta teller Bank untuk datang ke Kampus dan menerima pembayaran mahasiswa dalam rentang periode pembayaran mahasiswa? Atau cukup transfer saja ke rekening Rektor, tidak perlu datang juga bisa kan?

Setidaknya ada 2 hal, yang menjadi pertimbangan Anda (Kampus) untuk meminta dukungan integrasi dari Bank Mitra Anda :

1. Akses Perbankan Semakin Mudah

Saat ini akses perbankan sudah semakin mudah, dan pilihan integrasi juga makin beragam. Tidak perlu lagi mahasiswa berbondong-bondong datang ke kampus hanya untuk mengantri membayar SPP kuliah. Antrian ini juga akan berdampak pada konsekuensi tenaga operator yang harus didedikasikan guna memberikan pelayanan ini.

2. Pembayaran Biaya Kuliah adalah Titik Penting untuk Mengaktifkan Layanan Mahasiswa

Seperti layanan rencana studi (KRS), keanggotaan perpustakaan, dan lainnya. Ketika Bank sudah mampu diminta untuk terintegrasi dengan sistem yang ada di Kampus, otomatis pelayanan berikutnya akan menjadi lebih cepat dinikmati oleh mahasiswa.

Momen Pertama Layanan Integrasi Pembayaran dengan Bank

eCampuz memulai perjalanan pertamanya dengan melayani Universitas Andalas (UNAND) dengan misi mengintegrasikan aplikasi Pembayaran Mahasiswa (ePembayaran) dengan Bank Nagari. Di misi pertama ini, eCampuz menggunakan protokol ISO 8583 untuk mengintegrasikan sistem pembayaran mahasiswa di kampus dengan layanan kemahasiswaan (rencana studi, kepustakaan, dan fasilitas kampus). Kami menyelesaikan pengembangan integrasi pembayaran mahasiswa UNAND dalam waktu 1,5 bulan.

Apa saja yang diintegrasikan?  Seperti proses bisnis integrasi pada umumnya, perihal pembayaran mahasiswa, integrator ini menangani proses penanganan permintaan tagihan (Inquiry), sinkronisasi status pembayaran, reversal, dan rekonsiliasi. Mekanisme ini lazim disebut sebagai Host to Host (H2H). Apa itu H2H? Maknanya kurang lebih, host (server) Kampus berkomunikasi langsung dengan host (server) bank dengan messaging protocol yang ditentukan. Selain H2H, sebenarnya bank juga menyediakan layanan Point to Host (P2H). P2H mengandalkan pertukaran berkas (bisa via jasa hantaran flashdisk, atau email).

 

Sekilas, H2H lebih maju dibandingkan dengan P2H ya, benar kah?

Jawabannya adalah benar, jika dan hanya jika pertanyaan ini muncul di tahun 2006. Untuk saat ini, di tahun 2019, kami mendapati pelayanan dan perkembangan teknologi non H2H terus berkembang. Kita bahas itu di akhir tulisan ini. Tapi sebelumnya, kami menilai berikut adalah kelebihan dan kekurangan yang memang tampak mencolok kala itu :

Kelebihan Integrasi H2H Pembayaran Mahasiswa

  1. Toleransi yang tinggi atas perubahan tagihan secara mendadak (baca: dinamika tagihan yang tinggi), karena untuk setiap inquiry tagihan, host bank menghubungi (inquiry) langsung ke host Kampus. Selama tagihan untuk mahasiswa bersangkutan belum dibayar, perubahan tagihan di sisi sistem Kampus diperbolehkan.
  2. Sinkronisasi status pembayaran yang sangat cepat (real time). Ketika mahasiswa membayar di kanal Bank, statusnya diteruskan (oleh host Bank) ke host Kampus seketika itu juga. Sistem kampus membaca data ini dan melakukan aksi turunan yang telah ditentukan (sinkronisasi status aktif mahasiswa ke sistem-sistem internal yang membutuhkannya).

Kekurangan H2H?

  1. Biaya pengembangan di sisi Kampus/Biller (biaya, dan waktu untuk belajar). Tidak mudah membangun komunikasi dengan preferred-messaging-protocol dari Bank Mitra.
  2. Ongkos layanan H2H nya sendiri, yang tidak sedikit dan dibebankan ke pihak kampus. Ada Bank yang mensyaratkan minimal harus memiliki 5 ribu transaksi per-bulan, ada juga Bank yang mensyaratkan biaya administrasi tertentu. Bervariasi. Bisa saja juga tidak ada biaya, dengan pendekatan-pendekatan pimpinan Kampus kepada pimpinan Bank.

Baik, sekarang mari kita ulas tentang P2H-nya.

Kelebihan Integrasi Pembayaran Mahasiswa Model P2H Kala Itu

  1. It is a given service dari Bank, no additional charge required.
  2. Untuk tagihan-tagihan yang tidak perlu diantisipasi kedinamisannya, P2H adalah pilihan terbaik. Tagihan-tagihan yang cocok dengan karakter P2H contohnya listrik, telepon, atau tagihan internet.

Kekurangan P2H, dibandingkan dengan H2H?

  1. Aktitivas menyusun tagihan ke format excel, dan menginterpretasikan output rekaman status bayar per eod (end of day), bisa merepotkan dengan besarnya jumlah mahasiswa dan cacah tagihannya. Tidak selalu setiap kampus memiliki tenaga operator yang cukup waktu untuk memproduksi daftar ini dalam rentang waktu yang pendek.
  2. Mekanisme P2H tidak mentolerir dinamika tagihan (last minute change). Tidak semua kampus memiliki privilege untuk bisa mengunci tagihan semester-an nya, since kondisi 1 dan lain hal mahasiswa yang menyebabkan ada kebijaksanaan tagihan.
  3. Gak possible real-time. Kala itu di 2006, report pembayaran ya harus menunggu di eod. Gak mungkin bisa dipercepat. Ini membuat SOP pelayanan pembayaran juga menyesuaikan.

Baca juga : ePembayaran Aplikasi Tepat Permudah Segala Transaksi Mahasiswa

Nah, 2 tahun terakhir eCampuz sering mendapati preferensi kampus condong pada P2H. Demikian juga dengan Bank, simply karena alternatif integrasinya makin baik. Kesimpulan ini tentu saja subyektif ya, dan kami sandarkan berdasarkan pengalaman eCampuz membangun integrasi dengan banyak Bank Mitra Kampus seperti terlihat pada tabel berikut :

Integrasi Pembayaran Mahasiswa
Ragam Model Integrasi Bank

Jadi inilah ragam model integrasi pembayaran mahasiswa dengan Bank yang kami lakukan sepanjang 13 tahun terakhir. Kok jadi 7 ya? Ini kategorisasi kami sendiri, dan memang berbeda karena secara pembangunan integrasi maupun perilaku integrasinya, berbeda.

 

Wow, 13 tahun? Penasaran, ada berapa banyak Bank yang sudah bekerja sama?

eCampuz telah bekerja sama apik dengan 14 Bank, 1 switcher (Alto), dan MPN G2 (Modul Penerimaan Negara Generasi ke 2, Simponi Kemenkeu) sejauh ini. Dilihat dari tabel di atas, layanan pembayaran via Virtual Account (VA) menjadi basis baru Bank untuk pelayanan integrasi dan menjadi primadona. VA, adalah nomor rekening virtual untuk para mahasiswa yang dibuatkan oleh Bank, atas permintaan kampus (interpretasi untuk konteks kampus).

BNI misalnya, dengan merk eCollection mencoba memberikan nilai tambah berbasis layanan VA agar proses tek tok-an nya real time. BRI juga memiliki produk yang serupa, dengan brand BRIVA. Lately, BRI telah mengupgrade kapabilitas BRIVA (BRIAPI) yang sedang diimplementasikan di Poltekkes Kemenkes Malang. BCA dan Bank Mandiri juga memiliki mekanisme yang sama, namun sepanjang pengalaman kami, BNI dan BRI yang terdepan.

Dari tabel di atas, tergambar bahwa model deployment-nya juga bervariasi, dan beberapa bank membuka opsi lebih dari 1 model integrasi. Kami mencoba membuat kategorisasinya. Dikarenakan judul kolom pada tabel di atas tidak self-explained, berikut penjelasannya untuk masing-masing kolom tersebut.

1. H2H (Host to Host)

Kolom ini menunjukkan kekhususan mengenai protokol. Dalam pada ini, Bank mengikuti protokol yang eCampuz definisikan. Kami sangat apresiasi dengan bank yang berkenan untuk comply dengan protokol eCampuz (Gamatechno). Format messaging kami dapat di tengok di:  http://payment.gamatechno.com.

Pada skema delivery nya, eCampuz membuat host intermediary yang kami Cloud-kan. Kami tempatkan dedicated server di gedung Cyber untuk mengampu tugas ini. Setiap tagihan dan notifikasi payment, akan difasilitasi oleh host intermediary ini, agar aktivitas pembayaran di multi channel bank tidak terganggu, regardless koneksi internet dan listrik yang ada di biller.

2. H2H Lokal

H2H Lokal sama persis dengan point a (H2H) hanya saja posisi host intermediary nya berada di server biller/kampus. Mekanisme deployment ini memberikan kebebasan lebih pada kampus untuk mengelola host intermediary nya. Pada point H2H, eCampuz yang mengendalikan penuh maintenance-nya. Pada point H2H Lokal, kampus memiliki kewajiban untuk melakukan pemeliharaan.

Mekanisme H2H Lokal juga biasanya ditempuh bilamana masa pendampingan implementasi telah berakhir dan pelanggan eCampuz menginginkan untuk mengelola host intermediary-nya sendiri. Pertanyaannya, protokolnya bagaimana? Well, protokolnya menggunakan messaging eCampuz, sama dengan point a. Kasus khusus terjadi untuk Bank Mandiri di Universitas Widyagama Samarinda, since ini adalah kali pertama eCampuz mendapati ada peran switcher (Mitrakom) yang menjadi perpanjangan tangan Bank Mandiri.

3. H2H Soap

Mekanisme ini menggunakan protokol yang Bank tetapkan, dan eCampuz menyesuaikan integrator-nya agar comply dengan format messaging Bank. Mekanisme ini kami pernah terapkan untuk UNSRAT, bersama BNI waktu itu. For the record, mekanisme ini tidak preferred oleh BNI. Semua digiring menggunakan eCollection.

4. H2H DB Share

Mekanisme ini mirip dengan poin B. DB Share ini berarti, ada tabel yang kami siapkan, berisi tagihan dan kolom kosong (untuk diisi oleh Bank) perihal status pembayarannya.  Yang berbeda adalah : eCampuz menyerahkan kepada Bank perihal mekanisme mereka untuk mengakses tabel tersebut. eCampuz / Biller Simply bertanggung jawab untuk provide data tagihan dan mengakses data status pembayaran dari tabel bersama tersebut, dengan protokol H2H eCampuz sendiri.

5. VA (Virtual Account)

Virtual Account adalah nomor akun virtual yang dibuat untuk masing-masing mahasiswa, atas ijin dan data yang Kampus berikan. Bank menyediakan API untuk kampus dapat menyediakan/dapat mem-push data tagihan pembayaran. Dalam case ini, eCampuz harus comply dengan protokol yang Bank tetapkan. Berita baiknya, solusi ini mudah diintegrasikan, pelaporannya real-time, dan sependek yang kami tahu, it is free. Untuk solusi BNI, bisa Anda browse di sini. Untuk solusi BRIAPI, dokumentasi lengkap messaging dapat Anda lihat di sini

6. H2H Custome

Solusi ini kami kembangkan pada awal-awal masa pembangunan integrasi. Kala itu, eCampuz belum memiliki standar messaging seperti yang tadi kami sampaikan di awal (payment dot gamatechno dot com). Simply ini adalah queries yang kami berikan ke pihak Bank, untuk dapat mengakses view yang sudah disiapkan, regarding inquiry dan push tagihan.

Tentu saja, privilege bank ke data biller dibatasi pada level yang sepantasnya dan secukupnya. Mekanisme ini memiliki kelemahan pada proses reversal, dan sehingga mengandalkan proses rekonsiliasi H+1 untuk mempatenkan kecocokan transaksi.

7. P2H (Point to Host)

The oldest one, We suppose. Dalam hal ini, biller/kampus (petugas keuangan, misalnya) melakukan create tarif dari sistem eCampuz, dan ada menu untuk membentuk tagihan yang kemudian meng-eksport-kan nya dalam berkas terformat CSV atau XLS. Berkas ini diberikan kepada pihak Bank via email, untuk secara manual diimportkan ke sistem Bank. Syukurlah tidak harus menunggu datangnya senja untuk mendapati laporan, dikarenakan ada peningkatan frekuensi pelaporan ke Biller. In fact, Biller dapat mengunduhnya sendiri setiap saat. File unduhan tersebut tetap saja harus diimportkan kembali secara manual ke sistem eCampuz, untuk bisa di rekam di database kampus.

Baca juga : Kesiapan Kampus untuk Adopsi Teknologi

Selalu akan ada trade-offs yang perlu dianalisis dampaknya :

  1. Variasi teknologi integrasi yang bank sediakan,
  2. Ekspektasi pimpinan,
  3. Upaya adopsi teknologi (terkait dengan pengembangan),
  4. Serta kapasitas internal kampus (tim, biaya).

Setidaknya 4 (empat) aspek itu yang mewarnai setiap keputusan kecondongan kampus dalam memilih layanan  integrasi. Apabila masih penasaran lebih detil lagi, boleh sapa kami di sini ya, dengan senang hati untuk diskusi lebih dalam 🙂