Pada pertengahan Mei 2016, gw kebagian salah satu project yang cukup kritikal dalam kemajuan payment tiket untuk yang masa akan datang. Project ini disebut dengan project virtual account. Sebenarnya di tiket sendiri sudah lama menggunakan virtual account yakni dalam metode pembayaran ATM Transfer. Dibalik metode pembayaran tersebut, kami menggunakan virtual account permata sebagai jalur pembayaran yang menerima semua pembayaran dari berbagai bank. Hanya saja branding virtual account permata berbeda dengan virtual account yang lain karena jika pada beberapa virtual account (kita singkat VA saja), hanya bisa menerima pembayaran dari VA tersebut. Sebagai contoh VA BCA dan Mandiri yang hanya bisa menerima pembayaran dari sesama banknya.
Sebelum lanjut ke development, pada bulan April sebenarnya gw akhirnya kedatangan teman baru bernama Rahman Fad yang dipanggil dengan nama Rafa. Dengan kedatangan Rafa, gw berbagi tugas pekerjaan dengan dia, dimana dia mengerjakan bagian callbacknya, sedangkan gw bertugas untuk mengerjakan bagian end usernya. Bagian end user disini berarti yang bersinggungan langsung dengan customer dimana saat customer memilih pembayaran sampai proses checkoutnya sendiri. Sedangkan bagian callback itu merupakan bagian dimana sistem menerima sinyal pembayaran ketika customer telah melakukan pembayaran ke ATM, Mobile Banking atau Internet Banking. Setelah melakukan pembayaran, maka bank akan melakukan proses ke payment gateway (PG) lalu PG akan memberikan informasinya ke sisi merchant yakni tiket.com. Untuk metode yang digunakan sendiri yakni metode push payment (penjelasan mengenai metode push payment bisa dibaca di artikel yang ini). Untuk waktu pengerjaan project sendiri memakan waktu sekitar 2-3 minggu dengan jumlah man power 2 orang yakni gw dan Rafa.
Sebenarnya sebelum memutuskan menggunakan PG, kami ingin mencoba menggunakan teknologi host to host langsung ke bank terkait terlebih dahulu. Percobaan pertama waktu itu kami ingin menggunakan BCA sebagai eksperimen, jika berhasil maka kami akan mencoba ke bank-bank besar lain seperti BNI, BRI dan Mandiri. Sayangnya waktu itu tidak jadi karena kami terkendala dengan fase UAT dan akhirnya diputuskan untuk melakukan integrasi melalui PG. Untuk integrasi dengan PG pun sebenarnya ada plus dan minusnya. Berikut detailnya.
Positifnya:
- Integrasi lebih mudah.
Dengan menggunakan PG, semua integrasi jadi lebih mudah karena mereka sudah meng-enkapsulasi semua kerumitan yang kita hadapi ketika integrasi host to host (H2H) dengan bank. Biasanya PG yang bagus akan mengekspose 1 API yang bisa dipakai untuk multiple bank dan cara menggunakannya hanya tinggal mengganti-ganti parameternya saja. - Tidak ribet dengan UAT.
Hal yang paling bikin males ketika integrasi H2H dengan bank adalah fase UAT. Hal ini dikarenakan kerumitan dari sisi test case bank itu sendiri yang direquest ke merchant dan apabila tidak terpenuhi maka tidak bisa live. Kalau dengan PG, maka yang ngurusin UAT itu antara PG dan bank. Merchant tidak perlu ikut campur dan bisa langsung pakai. - Development environment.
Salah satu service yang bisa diandalkan dari PG adalah mereka memiliki sandbox yang dimaintain dengan benar. Hal ini mempermudah fase development. Yang ngeselin dari H2H adalah sandbox biasanya hanya dibuka ketika merchant sedang melakukan development, setelah development selesai, mereka akan mencabut semua credential sehingga mempersulit testing di env development/staging milik merchant (gak bisa end to end flow lagi). - SLA yang lebih baik.
Kalau ngobrol langsung sama bank, biasanya kirim email tanggal 1, baru dibales tanggal 15, itu juga kalau di-follow up. Kalau tidak, ya uda bye bye. Apakah semua bank seperti itu? engga kok, cuma developer bakal habis waktunya kalau ngurusin begituan. Nah dengan ada PG, maka tinggal suruh PG aja ngejarin uangnya, toh kita sudah bayar jasanya.
Negatifnya:
- Biaya lebih mahal.
Kalau ini ya jangan ditanya, kan kita pakai PG pasti ada biaya jasanya juga. Gampangnya misal biaya VA BCA kalau H2H adalah IDR 2,000 per transaksi maka kalau lewat PG bisa jadi IDR 3,000 per transaksi atau lebih. Keliatannya cuma beda IDR 1,000, tapi jika itu dikalikan 1,000,000 transaksi lumayan ya bos, bisa jadi bonus LOL. - Man in the middle.
Ini maksudnya bukan isu security (bisa juga sih), melainkan karena ada layer sebelum menyentuh merchant, maka kemungkinan tracing error jadi lebih panjang. Jika sebelumnya tracingnya hanya di sisi bank dan merchant, maka berikutnya akan ada bank, PG dan merchant. Jika PG nya error pun, bisa membuat masalah baru yakni jadi tidak bisa melakukan transaksi padahal banknya tidak mengalami masalah apa-apa. - Pelimpahan dana.
Ini biasanya yang diributin emak-emak di tim finance tiket. Biasanya pelimpahan dana itu akan dimasukin ke rekening PG terlebih dahulu sebelum dilimpahkan ke rekening merchant. Nah biasanya emak-emak ga demen nih begini, terutama kalau uang kita gede banget. Kebayang gak kalau nominal transaksi 10 M rupiah dikasi bunga ketika lewat tanggal 1. Pasti gede banget donk? Nah makanya ini jadi ribet banget kalau lewat PG. Kebetulan di tiket emak-emaknya pinter nego jadi semua duit harus realtime masuk ke rekening tiket LOL.
Balik lagi ke development VA, setelah selesai dengan semua development, akhirnya masuk juga ke fase testing. Fase testingnya sendiri juga sangat simple karena kami bisa melakukan test seperti pembayaran real melalui staging. Hal ini tidak mungkin bisa terjadi jika kami menggunakan H2H karena untuk bisa melakukan pembayaran real hanya boleh terjadi di environment production yang telah melalui fase UAT. Setelah testing berhasil dilakukan oleh QA, selanjutnya adalah naik ke production. Nah karena dulu belum ada product, jadi metode pembayarannya sendiri menjadi tidak jelas. Berikut gambarnya (kebetulan cuma ada BCA).
Apakah kalian bisa tebak yang mana VA BCA? Kalau kalian menjawab Transfer, maka jawabannya adalah tepat, namun kurang lengkap karena m-BCA juga menggunakan VA. Bingung kan? Karena pada jaman jahiliyah tidak ada tim product, jadi semua mengikuti insting aja LOL. Yang lebih unik lagi, pertimbangan untuk mengganti transfer BCA menjadi VA BCA dikarenakan pada masa itu banyak sekali masalah di metode pembayaran bank transfer (BCA). Oleh karena itu VA BCA disamarkan menjadi transfer BCA. Berhubung gw dulu ga punya power, akhirnya gw iya-iya aja mengikuti kemauan bos-bos.
Pada akhirnya saat tim product sudah ada dan melewati fase diskusi yang cukup panjang, bentuk pilihan metode pembayarannya menjadi seperti berikut.
Bisa dibilang pada masa itu, metode pembayaran VA masih kalah pamornya dengan kartu kredit, ATM dan transfer karena masih banyak orang yang belum terbiasa. Tetapi terjadi pergeseran yang cukup besar ketika Gojek dan Grab menggunakan VA sebagai sarana top up, sehingga customer banyak beralih menggunakan VA ketimbang transfer dan ATM. Memang perlu waktu untuk mengedukasi customer dalam menggunakan metode pembayaran yang baru.
Untuk kisah berikutnya, gw akan bercerita mengalami hackathon pertama gw dalam hidup LOL. Hackathonnya sendiri menurut gw cukup istimewa karena untuk pertama kalinya gw bisa melihat CTO gw langsung ngoding di sebelah gw. Tidak hanya itu, gw juga belajar bagaimana cara beliau pitching di depan investor (lebih bagaimana dia meyakinkan juri di hackathon).