Checklist pengujian formulir pembayaran adalah hal yang biasanya baru dibuat setelah ada insiden pertama. Padahal sebagian besar masalah pembayaran bukan berasal dari perhitungan yang rumit, melainkan dari alur yang jarang dicoba: penolakan, percobaan ulang, dan pengguna yang menekan tombol kirim lebih dari sekali. Halaman ini menyusun pemeriksaan itu menjadi daftar yang bisa langsung dipakai tim Anda sebelum peluncuran.
Apa saja yang perlu diuji sebelum peluncuran
Pembayaran yang berhasil adalah jalur yang paling jarang bermasalah, karena itulah jalur yang paling sering dicoba selama pengembangan. Sebaliknya, jalur kegagalan hampir tidak pernah disentuh, padahal di situlah pelanggan paling mudah hilang.
Karena itu, bagi pengujian menjadi empat kelompok: masukan yang salah, penolakan dari penyedia, gangguan teknis seperti koneksi terputus, dan tindakan setelah transaksi seperti pengembalian dana. Setiap kelompok memerlukan data uji dan harapan yang berbeda.
Yang juga sering terlewat adalah keadaan perangkat. Formulir yang berjalan mulus di komputer meja bisa berperilaku lain di telepon genggam dengan jaringan lambat, terutama ketika pengguna berpindah aplikasi untuk membaca kode verifikasi lalu kembali ke peramban. Menguji perpindahan itu sekali saja biasanya sudah cukup untuk menemukan dua atau tiga masalah nyata.
Matriks skenario yang sebaiknya lengkap
| Kelompok | Skenario | Hasil yang diharapkan |
|---|---|---|
| Masukan | Nomor salah ketik | Pesan jelas, tanpa permintaan ke jaringan |
| Masukan | Kolom kosong atau terisi sebagian | Tidak ada permintaan yang dikirim |
| Penolakan | Kartu ditolak penerbit | Pesan sopan, pengguna bisa mencoba kartu lain |
| Teknis | Koneksi terputus di tengah proses | Tidak ada transaksi yang menggantung |
| Perulangan | Tombol kirim ditekan dua kali | Hanya satu transaksi terbentuk |
| Setelah transaksi | Permintaan pengembalian dana | Status berubah dan tercatat dengan benar |
Matriks ini bukan daftar lengkap, melainkan kerangka yang bisa Anda tambahi sesuai produk. Yang penting, setiap baris punya nomor uji dan harapan yang tertulis, bukan sekadar diingat.
Matriks yang tidak pernah dijalankan ulang cepat berubah menjadi hiasan. Tentukan siapa yang memperbaruinya dan kapan, misalnya setiap kali alur pembayaran atau konfigurasi penyedia berubah. Satu baris yang ditambahkan hari ini jauh lebih berguna daripada sepuluh baris yang baru direncanakan bulan depan.
Bagaimana menangani penolakan dan percobaan ulang?
Penolakan perlu dibedakan menjadi dua jenis. Penolakan permanen, misalnya karena kartu sudah tidak berlaku, sebaiknya disampaikan dengan tegas agar pengguna tidak mencoba berulang kali dengan kartu yang sama. Penolakan sementara, misalnya karena batas transaksi sesaat, sebaiknya disertai saran untuk mencoba lagi nanti.
Yang sering terlewat adalah menjaga isi formulir saat percobaan ulang. Meminta pengguna mengetik ulang seluruh data setelah penolakan adalah cara tercepat kehilangan penjualan. Simpan masukan yang masih aman disimpan, dan hanya minta bagian yang perlu diganti.
Bedakan juga penolakan yang datang dari penyedia dengan kegagalan yang berasal dari sistem Anda sendiri. Ketika peladen Anda yang bermasalah, menampilkan pesan bahwa kartu ditolak akan menyesatkan pengguna dan membuat mereka mengganti kartu tanpa alasan. Pesan yang menyalahkan kartu hanya pantas muncul ketika jawabannya memang datang dari pihak penerbit.
Apakah pengembalian dana perlu diuji juga?
Ya, dan justru di sinilah banyak sistem menyimpan kejutan. Pastikan permintaan pengembalian dana hanya bisa dilakukan sekali untuk satu transaksi, dan bahwa statusnya tercermin di semua tempat yang menampilkannya, termasuk halaman riwayat pesanan dan surel pemberitahuan.
Uji juga kasus pengembalian sebagian serta pengembalian dana untuk transaksi yang sudah lama. Perbedaan zona waktu sering membuat tanggal pengembalian tampak mundur satu hari, dan hal-hal seperti itu paling cepat terlihat ketika diuji dengan data tetap, sebagaimana dibahas di catatan konsistensi data uji.
Bagaimana mencegah transaksi ganda?
Kunci utamanya adalah sifat idempoten pada titik akhir pembuatan transaksi. Artinya, permintaan yang sama yang dikirim dua kali hanya menghasilkan satu transaksi, dan permintaan kedua mengembalikan hasil yang sama seperti yang pertama.
Untuk menerapkannya, sertakan penanda unik pada setiap percobaan pembayaran, lalu perlakukan penanda itu sebagai kunci. Matikan tombol kirim setelah ditekan sebagai lapis pertama, tetapi jangan bergantung pada itu saja, karena pengguna bisa menyegarkan halaman atau jaringan bisa mengirim ulang permintaan secara otomatis.
Uji dengan sengaja mengirim permintaan yang sama dua kali secara berurutan, lalu memeriksa apakah hanya ada satu transaksi di sistem Anda dan di sisi penyedia. Skenario ini murah dibuat dan hasilnya menentukan apakah Anda perlu menangani pengembalian dana yang tidak seharusnya.
Melengkapi data uji di generator kartu virtual
Sebagian besar skenario di atas bisa dijalankan dengan data yang tidak nyata. Generator kartu virtual di situs ini menyediakan nomor, masa berlaku, dan kode keamanan contoh yang sah secara struktur tetapi tidak pernah diterbitkan, sehingga aman dipakai berulang kali di lingkungan uji.
Karena tanggal pada kartu contoh bisa dipilih, Anda juga bisa menyiapkan satu kartu yang sudah lewat masa berlaku untuk menguji pesan penolakannya. Perilaku batas bulan berjalan dijelaskan di halaman masa berlaku kartu, sedangkan perilaku gateway terhadap kartu yang memang disiapkan untuk gagal dijelaskan di halaman kartu uji Stripe.
Catatan untuk pengembang: matriks status dan idempotensi
Catat setiap transaksi dengan satu status yang jelas dan satu jalur perpindahan status yang tidak bercabang ganda. Status yang menggantung, misalnya transaksi yang tercatat sebagai menunggu selamanya, biasanya muncul karena kegagalan jaringan tidak ditangani sebagai kasus tersendiri.
Untuk idempotensi, uji tiga hal: permintaan yang sama dikirim berurutan, permintaan yang sama dikirim hampir bersamaan, dan permintaan yang sama dikirim setelah penyedia sempat memberi jawaban tetapi jawaban itu tidak sampai ke sistem Anda. Kasus ketiga adalah yang paling sering terlewat, dan cara menanganinya adalah menanyakan status transaksi ke penyedia sebelum membuat transaksi baru.
Terakhir, pastikan pesan galat yang muncul diuji seperti bagian produk lain. Pesan yang menyebut istilah internal tidak menolong siapa pun; pola penulisan pesan yang lebih baik dibahas di panduan validasi nomor kartu.
Langkah berikutnya
Ambil matriks di atas, isi kolom data ujinya hari ini, lalu jalankan seluruh baris sekali sebelum peluncuran berikutnya. Bila ada baris yang belum bisa Anda uji karena datanya belum ada, siapkan datanya lebih dulu lalu simpan bersama berkas pengujian, supaya pemeriksaan yang sama bisa diulang oleh siapa pun di tim.