Ringkasnya
- Integrasi pembayaran bukan soal tombol bayar, melainkan soal apa yang terjadi ketika ada yang gagal di tengah jalan.
- Lima hal yang dijaga: permintaan yang terulang, pemberitahuan yang datang dua kali atau tidak datang, keaslian pemberitahuan, pesanan yang tersangkut, dan pencocokan dengan saldo.
- Uji jalur gagalnya, bukan hanya jalur mulusnya.
- Tanyakan kepada pembuat sistem Anda: apa yang terjadi bila tombol bayar ditekan dua kali, dan bila pemberitahuan pembayaran tidak pernah datang?
Cara kerja pembayaran online, singkatnya
Payment gateway adalah perantara antara website Anda dan bank atau dompet digital pembeli. Alurnya tiga langkah. Website membuat tagihan di payment gateway. Pembeli membayar di halaman milik payment gateway. Lalu payment gateway memberi tahu website bahwa tagihan itu sudah dibayar. Pemberitahuan terakhir itu disebut webhook.
Ketiganya terjadi di tiga tempat berbeda, lewat jaringan yang bisa putus kapan saja. Hampir semua masalah integrasi pembayaran lahir dari satu pertanyaan: apa yang terjadi bila salah satu langkah itu terulang, terlambat, atau tidak sampai?
Contoh di tulisan ini berasal dari toko online Yoora Sarah, yang pembayarannya memakai Xendit.
1. Tombol bayar ditekan dua kali
Pembeli menekan “Bayar”, layar terasa lambat, lalu ia menekan lagi. Tanpa penjagaan, website membuat dua pesanan dan dua tagihan. Pembeli membayar salah satunya, dan tim Anda harus mencari mana yang asli.
Penjagaannya disebut kunci idempotensi: setiap percobaan checkout membawa satu kunci unik, dan permintaan dengan kunci yang sama hanya diproses sekali. Di toko online Yoora Sarah, menekan tombol bayar berkali-kali tidak pernah membuat pesanan ganda.
2. Pemberitahuan datang dua kali, atau tidak datang
Payment gateway umumnya mengirim ulang webhook bila website tidak menjawab tepat waktu. Artinya pemberitahuan yang sama bisa tiba dua kali. Bila setiap pemberitahuan langsung diproses, stok bisa berkurang dua kali untuk satu pesanan.
Kebalikannya juga terjadi: pembayaran berhasil, tetapi webhook-nya tidak pernah sampai, misalnya karena jaringan terputus. Pembeli sudah membayar, sementara pesanannya tetap berstatus menunggu pembayaran.
Keduanya dijaga dengan sikap yang sama: webhook diperlakukan sebagai petunjuk, bukan satu-satunya sumber kebenaran. Pemberitahuan yang terulang tidak boleh diproses dua kali, dan untuk yang tidak pernah datang harus ada jalan kedua — pembayaran dicocokkan ulang dengan catatan di payment gateway.
3. Pemberitahuan palsu
Alamat webhook adalah pintu yang terbuka ke internet. Siapa pun yang mengetahuinya bisa mencoba mengirim pesan “tagihan ini sudah lunas”. Karena itu setiap webhook harus diperiksa keasliannya sebelum dipercaya. Di backend Yoora Sarah, tanda tangan webhook diverifikasi, dan pembatasan laju permintaan berlaku lintas instance server.
4. Pesanan yang tersangkut di tengah
Tidak semua pembeli menyelesaikan pembayaran saat itu juga. Ada yang menutup tab, ada yang kehabisan waktu di halaman bank. Pesanan seperti itu butuh dua hal: batas waktu yang jelas, dan jalan kembali.
Di toko online Yoora Sarah, pesanan yang belum dibayar punya hitung mundur dan jalan kembali ke halaman pembayaran. Untuk kasus sebaliknya — sudah dibayar tetapi tersangkut — tersedia alat pemulihan.
5. Uang di sistem harus sama dengan uang di saldo
Di akhir hari pertanyaannya sederhana: apakah jumlah pesanan lunas di sistem sama dengan uang yang benar-benar masuk? Mencocokkan keduanya disebut rekonsiliasi. Tanpa itu, selisih kecil bisa menumpuk lama sebelum ada yang menyadarinya.
Di Yoora Sarah, pembayaran direkonsiliasi dengan Xendit dan saldonya punya buku besar sendiri. Pengembalian dana berjalan berantai — CS mengajukan, gudang memeriksa, finance mengeksekusi — sampai dananya dicairkan lewat Xendit.
Uji jalur gagalnya, bukan hanya jalur mulusnya
Semua integrasi tampak berhasil ketika diuji dengan satu pembayaran yang lancar. Yang membedakan adalah skenario gagal: jaringan putus setelah pembeli membayar, webhook ganda, dua admin menekan tombol yang sama, pembayaran yang tertunda.
Di backend Yoora Sarah, jalur yang menyangkut uang dan stok memakai transaksi database dan penguncian baris. Uji integrasinya berjalan terhadap PostgreSQL dan Redis sungguhan, bagian dari 2.404 fungsi test otomatis. Perubahan dirilis bertahap — 10%, lalu 50%, lalu 100% — dan ditarik kembali otomatis bila tingkat galat naik.
Lima pertanyaan untuk pembuat sistem Anda
- Apa yang terjadi bila pembeli menekan tombol bayar dua kali?
- Apa yang terjadi bila pemberitahuan pembayaran datang dua kali?
- Apa yang terjadi bila pemberitahuan itu tidak pernah datang?
- Bagaimana sistem memastikan pemberitahuan benar-benar berasal dari payment gateway?
- Bagaimana uang di sistem dicocokkan dengan uang di saldo, dan siapa yang mengerjakannya?
Bila jawabannya “itu jarang terjadi”, berarti belum dijaga. Hal yang jarang terjadi pada sepuluh pesanan akan rutin terjadi pada sepuluh ribu pesanan.
Pembayaran hanya satu dari banyak sambungan
Prinsip yang sama berlaku untuk kurir, marketplace, dan WhatsApp: setiap sambungan bisa terlambat, terulang, atau gagal. Di Yoora Sarah, pembayaran, pengiriman, percakapan pelanggan, iklan, dan marketplace masuk ke backend yang sama, sehingga satu pesanan punya satu riwayat.
Menyambungkan layanan-layanan itu supaya uang dan stok tetap benar adalah pekerjaan integrasi sistem yang saya kerjakan. Bila yang Anda butuhkan adalah tokonya sekaligus, lihat jasa pembuatan toko online.