Kartu uji Stripe adalah nomor khusus yang hanya berfungsi di lingkungan percobaan penyedia tersebut, dan menjadi cara paling praktis untuk mencoba seluruh alur checkout tanpa memindahkan uang sungguhan. Dengan nomor ini, tim bisa memaksa transaksi berhasil, memaksa transaksi ditolak, atau memicu permintaan autentikasi tambahan, semuanya secara berulang dan dapat diprediksi. Bagi tim yang baru membangun integrasi pembayaran, mempelajari perilaku ini jauh lebih murah daripada menemukannya sendiri di produksi.
Mengapa penyedia pembayaran menerbitkan kartu uji
Setiap alur pembayaran punya cabang yang tidak bisa dipicu dengan kartu biasa: apa yang terjadi saat penerbit menolak, bagaimana tampilan halaman ketika autentikasi tambahan diminta, dan bagaimana sistem bereaksi ketika permintaan diulang. Cabang-cabang itu justru yang paling sering menyembunyikan bug.
Kartu uji memberi kendali atas cabang tersebut. Alih-alih menunggu kejadian langka, pengembang bisa memicunya kapan saja di sandbox, lalu memastikan aplikasinya menampilkan pesan yang benar dan mencatat status yang benar. Karena nomor ini hanya berlaku di lingkungan uji, tidak ada risiko uang berpindah atau data pelanggan nyata ikut terbawa.
Ada keuntungan lain yang jarang disebut: kartu uji membuat hasil pengujian bisa diulang. Tim yang mencoba alur pembayaran dengan kartu sungguhan tidak pernah tahu apakah kegagalan yang muncul berasal dari kodenya atau dari kondisi rekening saat itu. Dengan kartu uji, penyebabnya jauh lebih sempit dan pengujian ulang sesudah perbaikan jadi masuk akal untuk dilakukan.
Kartu uji yang paling banyak dipakai
Salah satu nomor yang paling sering dikutip dalam dokumentasi penyedia dibentuk dari pola empat dua empat dua yang diulang empat kali, sehingga panjangnya enam belas digit dan diawali angka empat. Nomor ini diterima di mode uji dengan masa berlaku apa pun yang belum lewat dan kode keamanan tiga digit apa pun. Karena sangat sederhana, nomor ini biasanya menjadi pilihan pertama saat seseorang baru mencoba integrasi.
Perlu ditegaskan bahwa nomor tersebut sah secara struktur tetapi tidak pernah diterbitkan sebagai kartu nyata. Ia hanya berfungsi di lingkungan sandbox penyedianya, dan tidak akan menyelesaikan pembayaran di sistem mana pun yang berjalan di mode langsung.
Bagaimana cara mensimulasikan kegagalan?
Penyedia menyediakan nomor lain yang dirancang untuk selalu ditolak, biasanya dibedakan lewat prefiks atau digit tertentu, dan sebagian di antaranya memetakan penolakan ke kode alasan yang berbeda seperti dana tidak cukup, kartu kedaluwarsa, atau kartu diblokir. Karena daftarnya berubah dari waktu ke waktu, cara paling aman adalah membaca dokumentasi resmi penyedia alih-alih menyalin daftar dari artikel lama.
Rujukan yang tepat untuk daftar terbaru adalah halaman pengujian resmi Stripe. Buka halaman itu, pilih nomor sesuai skenario yang ingin Anda uji, lalu catat tanggal aksesnya di dalam catatan tim. Kebiasaan mencatat sumber dan tanggal membuat pengujian Anda tetap bisa dipertanggungjawabkan ketika daftarnya berubah.
Apakah kartu uji bisa dipakai di mode langsung?
Tidak. Nomor uji hanya dikenali di mode uji milik penyedia, dan percobaan di mode langsung akan berakhir dengan penolakan atau galat konfigurasi. Batas ini bukan kelemahan, melainkan pengaman: ia memastikan kegiatan pengujian tidak pernah menyentuh jaringan pembayaran sungguhan.
Karena itu, simpan kredensial uji dan kredensial langsung di berkas lingkungan yang terpisah, dan periksa ulang variabel lingkungan setiap kali menerapkan perubahan. Sebagian besar insiden kecil di tim pengembangan berasal dari kunci uji yang tertinggal di konfigurasi produksi atau sebaliknya.
Skenario autentikasi tambahan yang perlu disiapkan
Selain sukses dan gagal, penyedia biasanya menyediakan kartu untuk memicu autentikasi tambahan. Skenario berikut layak disiapkan sebagai kasus tetap:
| Skenario | Yang diamati |
|---|---|
| Autentikasi berhasil | Pengguna kembali ke halaman Anda dengan status sukses |
| Autentikasi gagal | Pesan yang jelas, tanpa status transaksi yang menggantung |
| Pengguna menutup jendela autentikasi | Transaksi tidak dianggap selesai |
| Koneksi terputus di tengah proses | Tidak ada transaksi ganda saat pengguna mencoba lagi |
Baris terakhir adalah yang paling sering diabaikan, padahal justru di situlah bug paling mahal bersembunyi.
Perlu diingat juga bahwa autentikasi tambahan bukan hanya soal berhasil atau gagal. Ada kalanya penyedia meminta pengguna membuktikan identitasnya, ada kalanya bank penerbit yang mengambil alih, dan ada kalanya permintaan itu dibatalkan oleh pengguna sendiri. Ketiga jalur itu berakhir pada pesan yang berbeda di aplikasi Anda, dan ketiganya perlu diperiksa satu per satu, bukan diasumsikan berperilaku sama.
Melengkapi data uji lokal di generator kartu virtual
Kartu uji dari penyedia sangat berguna untuk menguji respons gateway, tetapi tidak selalu cocok untuk menguji formulir Anda sendiri, misalnya ketika Anda perlu banyak nomor dari jaringan tertentu sekaligus. Untuk kebutuhan itu, generator kartu virtual di situs ini bisa membuat sekumpulan nomor dengan jaringan dan jumlah yang Anda tentukan. Semua hasilnya benar secara struktur dan tidak pernah diterbitkan, jadi hanya cocok untuk formulir, fixture, dan demo.
Membedakan dua kebutuhan ini akan menghemat banyak waktu: pakai kartu dari penyedia ketika yang diuji adalah respons jaringan, dan gunakan nomor buatan sendiri ketika yang diuji adalah perilaku antarmuka. Perbandingan per jaringan bisa dilihat di halaman kartu uji per jaringan, sedangkan pola penamaan data ujinya dibahas di halaman nomor kartu untuk pengujian.
Catatan untuk pengembang: menyiapkan skenario tanpa bergantung satu penyedia
Susun berkas konfigurasi pengujian yang memisahkan tiga hal: nomor untuk jalur sukses, nomor untuk tiap jenis penolakan, dan nomor untuk autentikasi tambahan. Pisahkan juga berdasarkan penyedia, karena nomor satu penyedia tidak selalu berperilaku sama di penyedia lain. Ketika nanti Anda berpindah penyedia, hanya satu berkas yang perlu diperbarui.
Simpan juga catatan tentang apa yang diharapkan dari setiap nomor, termasuk kode alasan yang seharusnya muncul. Tanpa catatan itu, pengujian akan berubah menjadi sekadar menekan tombol sampai hijau, dan tidak ada yang tahu apakah penolakan yang muncul memang penolakan yang dimaksud. Rangkaian pemeriksaan menyeluruh sebelum peluncuran bisa dilihat di checklist pengujian formulir pembayaran.
Langkah berikutnya
Buka dokumentasi penyedia yang Anda pakai, ambil tiga nomor untuk tiga skenario berbeda, dan tuliskan harapan Anda untuk masing-masing. Setelah alur gateway teruji, lanjutkan dengan menguji formulir itu sendiri memakai nomor dari halaman generator agar kolom-kolom antarmuka juga ikut teruji.