Payment system tidak jadi kompleks karena scale. Mereka jadi kompleks karena tidak ada yang benar-benar memutuskan lifecycle-nya harus seperti apa.
19 Juli 2026 · 3 menit baca
Payment system tidak jadi kompleks karena scale. Mereka jadi kompleks karena tidak ada yang benar-benar memutuskan lifecycle-nya harus seperti apa.
Saya pernah melihat sistem yang menangani banyak PSP sekaligus: QRIS, virtual account, e-wallet, transfer manual, dengan flow yang campur antara sync dan async. Di atas kertas ini terlihat kompleks. Tapi kompleksitas itu bukan yang bikin sistem-sistem ini akhirnya rusak.
Yang benar-benar merusak adalah setiap metode pembayaran mulai mendefinisikan aturan sendiri-sendiri. Satu provider menganggap "success" begitu callback masuk. Provider lain menganggap "pending" sampai rekonsiliasi selesai. Provider lain lagi retry diam-diam, tanpa memberitahu siapa pun.
Sistem lalu tumbuh mengelilingi ketidakkonsistenan itu: ada handling khusus per provider, ada special case tersebar di banyak tempat, ada logic rekonsiliasi yang berbeda untuk tiap flow. Kelihatannya seperti kompleksitas yang datang dari scale. Padahal bukan.
Itu adalah akibat dari absennya satu keputusan penting:
Apa sebenarnya lifecycle pembayaran di sistem ini?
Alih-alih memutuskan lifecycle di awal, tim membiarkan setiap integrasi baru memutuskannya sendiri-sendiri. Yang akhirnya dibangun bukan payment platform. Tapi kumpulan perilaku provider yang dijahit jadi satu, dan disebut sistem.
Trade-off yang sebenarnya ada di sini sederhana: memaksa satu lifecycle yang rigid dan penuh constraint, atau membiarkan tiap provider bebas dengan konsekuensi chaos yang maksimal.
Kebanyakan tim memilih opsi kedua. Bukan karena itu pilihan yang lebih baik, tapi karena memaksa satu lifecycle terasa tidak nyaman. Kamu harus menolak edge case yang terdengar masuk akal. Kamu harus menormalkan behavior yang tadinya berbeda-beda. Kamu harus berani bilang tidak ke product.
Sistem pembayaran yang kuat mendefinisikan satu lifecycle, misalnya INIT, AUTHORIZED, IN_PROGRESS, SUCCESS, FAILED, lalu memaksa semua provider masuk ke model itu. Deviasi diperlakukan sebagai exception yang harus dijelaskan, bukan sebagai flow baru yang otomatis sah.
Ini bukan berarti semua pembayaran harus diperlakukan sama. Kartu, QRIS, dan virtual account punya flow, timing, dan jaminan yang berbeda-beda. Tujuannya bukan menyamakan behavior. Tujuannya menyamakan cara sistem memahami state.
Jalan boleh beda. Sumber kebenaran harus satu.
Sebelum menambah metode pembayaran baru, ada pertanyaan yang harus dijawab dulu.
Bagaimana metode ini masuk ke lifecycle yang sudah ada?
State transition apa yang tidak bisa ditawar?
Mana yang kita standarkan, dan mana yang kita anggap exception?
Kalau metode baru ini merusak model yang ada, yang salah modelnya, atau integrasinya?
AI sekarang bisa bantu generate adapter untuk provider baru dalam hitungan menit. Bisa suggest mapping status. Bisa generate handler untuk tiap jenis callback. Tapi AI tidak bisa memutuskan lifecycle mana yang jadi standar sistem kamu.
Kalau lifecycle belum diputuskan, AI cuma mempercepat satu hal: kecepatan kamu menulis special case baru.
Kalau setiap provider punya lifecycle sendiri-sendiri, kamu tidak sedang punya sistem pembayaran. Kamu cuma punya kumpulan integrasi yang kebetulan belum kelihatan chaos-nya.
Suka konten Arya Nugroho?
Dukung kreator agar terus berkarya.
