Pelajari cara merancang halaman pengecek saldo kartu hadiah dengan pencarian kode untuk pelanggan, serta alat staf untuk menyesuaikan saldo dengan aman setelah pembelian.
Halaman pengecek saldo kartu hadiah punya satu tugas: memberi tahu seseorang berapa banyak uang yang tersisa pada kartu hadiah, dengan cepat dan tanpa kebingungan. Orang menggunakannya tepat sebelum membeli sesuatu, setelah menerima kartu, atau setelah pembelian baru-baru ini.
Halaman ini biasanya melayani dua audiens:
Jelaskan dengan spesifik apa yang dimaksud "kode" di toko Anda. Bisa berupa angka tercetak di balik kartu fisik, kode dari email, atau sesuatu yang ditampilkan dalam aplikasi. Beberapa program juga mengharuskan PIN atau bagian gosok. Jika sistem Anda memerlukan nomor kartu dan PIN, katakan itu segera agar orang tidak membuang waktu.
Pengalaman yang baik terasa dapat diprediksi: tempat jelas untuk memasukkan kode, satu aksi "Check balance" yang mencolok, dan hasil yang mudah dibaca (mata uang plus waktu "last updated"). Ketika sesuatu salah, halaman harus menjelaskan cara pemulihan tanpa membuat orang merasa terjebak.
Akurasi adalah inti dari semua ini. Jika halaman menampilkan jumlah yang salah, muncul konflik saat checkout, lebih banyak panggilan dukungan, dan kepercayaan yang hilang.
Halaman pengecek saldo kartu hadiah punya dua tugas: membantu pelanggan mengonfirmasi sisa saldo, dan memberi staf cara aman untuk memperbarui saldo saat sesuatu berubah di kasir. Penataan terbaik menjaga tampilan pelanggan tetap sederhana dan menaruh aksi kuat di layar khusus staf.
Di sisi pelanggan, alurnya harus terasa seperti pengecekan struk. Masukkan kode, ketuk periksa, dapatkan jawaban jelas. Tampilkan sisa saldo dalam mata uang toko dan sertakan cap waktu "last updated" agar orang tahu hasilnya terkini.
Di sisi staf, alurnya adalah cari, verifikasi, lalu sesuaikan. Staf harus dapat menemukan kartu berdasarkan kode (dan kelak, jika Anda memilih, dengan pemindaian), meninjau saldo saat ini dan aktivitas terbaru, lalu menambah nilai (top-up) atau mengurangi nilai (penebusan manual atau koreksi). Setiap penyesuaian harus membutuhkan alasan singkat dan, jika memungkinkan, referensi seperti nomor struk.
Kebanyakan tim merilis versi pertama dengan:
Contoh: sebuah kafe menjual kartu hadiah $25. Seorang pelanggan memasukkan kode dan melihat “$13.40 remaining, updated 2 minutes ago.” Nanti, seorang staf menyadari kasir melewatkan penebusan, menemukan kode yang sama, mengurangi $4.60, dan menyimpan catatan “latte, receipt 887.”
Kasus tepi menghasilkan tiket dukungan, jadi tangani dengan tenang:
Halaman pengecek saldo kartu hadiah harus cepat, tenang, dan sulit salah digunakan. Banyak pelanggan menggunakan ponsel, berdiri di kasir, dan berusaha tidak menghambat antrean.
Jaga input sederhana. Gunakan satu field untuk kode, dengan label terlihat (bukan hanya placeholder). Tambahkan contoh format singkat seperti "Contoh: ABCD-EFGH-IJKL," dan buatnya mudah ditempel. Hindari pemformatan yang mengejutkan yang mengubah apa yang diketik pengguna.
Buat aksi jelas. "Check balance" lebih jelas daripada "Submit." Setelah diketuk, tunjukkan status pemuatan ("Checking…") dan nonaktifkan tombol agar permintaan tidak terkirim dua kali.
Pesan kesalahan harus membantu pelanggan jujur pulih, sambil mengungkapkan sesedikit mungkin kepada orang yang menebak-nebak kode. Pada halaman publik, biarkan kegagalan bersifat generik. Simpan alasan rinci (kedaluwarsa, diblokir, tidak ditemukan) untuk layar staf setelah seseorang terverifikasi.
Daftar centang UX singkat yang mencegah sebagian besar kebingungan:
Aksesibilitas penting bahkan di halaman kecil. Pastikan label terkait dengan input, pengguna keyboard dapat mencapai tombol, outline fokus terlihat, dan kontras cukup kuat untuk pencahayaan toko yang terang.
Layar admin staf yang baik terasa membosankan dalam arti terbaik. Itu membantu karyawan memperbaiki masalah kartu hadiah dalam hitungan detik, sambil meninggalkan jejak yang jelas untuk pemeriksaan kemudian.
Mulai dengan login staf dan peran sederhana. Kebanyakan staf hanya boleh mencari kartu dan melihat riwayat, sementara hanya manajer (atau grup kecil tepercaya) yang bisa mengubah saldo. Jika Anda menjalankan banyak lokasi, tandai perubahan dengan toko/lokasi.
Buat pencarian cepat dan toleran. Spasi dan tanda hubung sebaiknya tidak mengganggu pencarian. Untuk kasus nyata di mana kode rusak atau sulit dibaca, Anda bisa menawarkan opsi pencarian sekunder hanya untuk staf (dan hanya jika aman), seperti ID struk/pesanan, atau email/telepon pelanggan jika Anda memang mengumpulkannya.
Setelah kartu ditemukan, tampilkan saldo saat ini dan aktivitas terbaru sebelum kontrol edit muncul. Ini mengurangi kesalahan klasik: menyesuaikan kartu yang salah karena banyak tab terbuka.
Buat formulir penyesuaian terstruktur daripada bebas:
Setelah memasukkan jumlah, pratinjau hasil dengan jelas: "Current balance: $40.00. New balance: $15.00." Tambahkan langkah konfirmasi untuk perubahan besar (misalnya, perubahan di atas $100 atau lebih dari 25% dari saldo saat ini). Untuk perubahan berisiko tinggi, minta PIN manajer atau memasukkan ulang jumlah.
Halaman pengecek saldo kartu hadiah terdengar sederhana, tetapi menarik penebakan, penyalahgunaan, dan kesalahan jujur. Tujuannya bukan keamanan sempurna, melainkan menghilangkan serangan mudah dan membuat masalah mudah terlihat dan diperbaiki.
Perlakukan kode kartu hadiah seperti kata sandi. Jika seseorang mendapat daftar kode, mereka bisa menguras nilai dengan cepat.
Dua hal dasar sudah sangat membantu: simpan kode dengan aman, dan buat sulit untuk menguji banyak kode dengan cepat. Banyak sistem menghindari menyimpan kode mentah dalam teks jelas. Sebagai gantinya, simpan versi terlindungi (mis. hash satu arah), sehingga kebocoran database tidak memberikan penyerang kode yang bisa digunakan.
Di layar pelanggan, hindari menampilkan seluruh kode kembali setelah pencarian. Tampilkan versi ter-mask (mis. hanya 4 karakter terakhir) sehingga screenshot dan shoulder-surfing lebih sedikit bahayanya.
Batasan laju juga penting. Tanpa itu, bot bisa mencoba ribuan kombinasi. Jaga sederhana:
Sebagian besar kerugian nyata berasal dari penyesuaian staf tanpa kontrol cukup, bukan dari peretasan ala film. Setiap perubahan saldo harus menghasilkan jejak audit: siapa yang melakukannya, kapan, berapa banyak, dan mengapa.
Pertahankan akses staf ketat. Tidak semua orang perlu memiliki kekuatan untuk mengubah saldo. Hindari login bersama, karena itu membuat jejak audit tidak berguna.
Putuskan bagaimana refund dan chargeback memengaruhi kartu hadiah dan tuliskan sebagai aturan internal yang sederhana. Contoh: refund mengembalikan nilai ke kartu hadiah asal bila memungkinkan; jika kartu sudah digunakan, kasus itu ditandai untuk peninjauan.
Halaman terasa sederhana, tetapi data di baliknya harus dapat dibuktikan. Pendekatan aman: jangan mengandalkan satu angka "saldo" yang dapat diubah tanpa jejak transaksi yang menjelaskannya.
Struktur umum menggunakan tiga tabel:
Perlakukan tabel transaksi sebagai sumber kebenaran. Jenis transaksi tipikal meliputi issuance (pengisian awal), redemption (pembelian), adjustment (koreksi staf), dan refund (membatalkan redemption). Anda bisa menghitung saldo saat ini sebagai jumlah dari transaksi, atau menyimpan saldo cache pada catatan kartu yang Anda perbarui dengan hati-hati.
Untuk mencegah pengisian ganda ketika seseorang mengetuk dua kali pada perangkat lambat, gunakan kunci idempotensi untuk setiap penulisan. Itu memberi setiap checkout atau penyesuaian ID operasi unik, dan submit berulang diabaikan.
Untuk audit dan dukungan, beberapa field terbukti sangat berguna:
Tentukan apa yang dilihat pelanggan sebelum Anda membangun apa pun. Halaman harus menjelaskan di mana menemukan kode, apa arti "saldo" di toko Anda, dan apa yang harus dilakukan jika pencarian gagal. Pada layar hasil, tampilkan saldo, mata uang, dan waktu "last updated" yang jelas.
Tentukan aturan kode dan lakukan validasi sedini mungkin. Pilih panjang tetap dan izinkan hanya karakter yang benar-benar Anda cetak. Validasi saat pengguna mengetik dan lagi saat submit, sehingga Anda menangkap typo dengan cepat tanpa mengungkapkan detail ekstra.
Bangun alur pencarian pelanggan secara bertahap: buat layar input, panggil backend saat submit, lalu tangani tiga hasil - ditemukan, tidak ditemukan/invalid, dan sementara tidak tersedia.
Kemudian tambahkan sisi staf. Staf harus masuk sebelum bisa mengubah apa pun, dan setiap perubahan harus meminta alasan eksplisit. Tambahkan langkah konfirmasi yang mengulang kode dan jumlah.
Setelah penyesuaian berfungsi, tambahkan riwayat. Setiap kartu hadiah harus menampilkan daftar transaksi dan log audit yang merekam siapa mengubah apa dan kapan.
Akhirnya, uji skenario nyata sebelum diluncurkan: salah ketik, saldo nol, penebusan parsial, refund yang mengembalikan nilai, dan dua staf yang menyesuaikan kartu yang sama dalam beberapa menit.
Sebagian besar tiket dukungan muncul dari dua hal: umpan balik yang tidak jelas untuk pelanggan jujur, dan catatan yang hilang untuk aksi staf.
Satu jebakan umum adalah terlalu spesifik dengan pesan kesalahan publik. Detail seperti "kode ada tetapi tidak aktif" bisa membantu penyerang menebak kode valid. Biarkan pesan kepada pelanggan bersifat netral, dan tampilkan spesifik hanya di alat staf setelah verifikasi.
Magnet tiket lain adalah membiarkan staf mengubah saldo tanpa konteks. Ketika seseorang mengatakan, "Kartu saya $50 kemarin," Anda butuh jawaban cepat. Pengeditan tanpa jejak menciptakan situasi he-said-she-said.
Kesalahan yang biasanya paling merugikan:
Contoh: kasir menebus $25, tablet lambat, dan mereka mengetuk "Confirm" lagi. Tanpa proteksi, sistem mencatat dua penebusan. Perbaiki ini dengan memperlakukan setiap perubahan sebagai event tunggal yang tercatat, dan membuat tombol "Confirm" aman ditekan dua kali.
Sebelum publikasi halaman pengecek saldo, lakukan percobaan "seolah-olah Anda pelanggan", lalu "seolah-olah Anda staf."
Pemeriksaan pelanggan yang harus dilakukan:
Pemeriksaan staf yang harus dilakukan:
Juga periksa kata-kata Anda. Jangan mencampur "gift card balance" dengan "store credit" kecuali keduanya benar-benar berarti sama di toko Anda. Jika ada batasan (tanggal kedaluwarsa, hanya di toko), katakan dalam satu kalimat pendek.
Bayangkan sebuah toko kecil yang menjual kartu fisik di kasir. Pelanggan bisa mengecek saldo di rumah sebelum berkunjung, dan staf bisa menebus kartu secara langsung.
Pada Minggu malam, Maya menemukan kartu hadiah di laci. Dia membuka halaman pengecek saldo toko, mengetik kode dari balik kartu, dan melihat hasil sederhana: saldo saat ini, waktu pembaruan terakhir, dan pengingat singkat untuk menjaga kerahasiaan kode. Tidak perlu akun.
Pada Senin, Maya membeli barang senilai $38.50 dan membayar dengan kartu hadiah. Saat checkout, staf membuka layar admin, mencari kode yang sama, dan menebus jumlah parsial. Staf melihat detail lebih banyak daripada Maya, termasuk riwayat dan tempat menambahkan catatan.
Nanti hari itu, Maya mengembalikan satu barang seharga $12.00. Staf mencatat refund dengan referensi jelas. Ketika seseorang bertanya mengapa saldo berubah, jawabannya ada dalam satu baris riwayat alih-alih harus direkonstruksi dari ingatan.
Pilih rilis kecil pertama yang bisa Anda percayai. Untuk kebanyakan toko, minimum adalah pengecek saldo pelanggan plus alat staf yang bisa menyesuaikan saldo dengan alasan dan log riwayat.
V1 praktis mencakup pencarian pelanggan berdasarkan kode, staf sign-in, penyesuaian dengan alasan wajib, log transaksi untuk setiap perubahan, dan batas dasar (ditambah konfirmasi kedua untuk perubahan besar).
Sebelum menambah fitur, tuliskan aturan internal singkat untuk situasi berantakan seperti refund dan sengketa, lalu latih staf dengan dua atau tiga contoh nyata. Setelah peluncuran, tinjau pesan dukungan mingguan dan perbaiki poin sakit teratas terlebih dahulu.
Jika Anda sudah menggunakan Koder.ai (koder.ai) untuk membangun alat internal, menjaga pencarian pelanggan dan pengeditan staf sebagai layar terpisah dengan izin berbeda sejak hari pertama membuat proyek lebih mudah dipelihara seiring pertumbuhan.
Fokuskan pada satu tugas: masukkan kode kartu hadiah dan lihat jumlah tersisa. Tampilkan saldo dalam mata uang toko dan sertakan waktu "last updated" yang jelas sehingga hasil terasa dapat dipercaya.
Minta apa pun yang benar-benar diperlukan oleh program Anda, dan beri tahu sejak awal. Jika Anda membutuhkan nomor kartu dan PIN (atau bagian yang digosok), tampilkan kedua field tersebut segera agar orang tidak membuang waktu.
Buat sederhana dan ramah-tempel: satu input berlabel, contoh format singkat, dan satu tombol "Check balance". Setelah submit, tampilkan status pemuatan singkat dan nonaktifkan tombol untuk mencegah pemeriksaan ganda.
Tampilkan saldo, mata uang, dan timestamp "last updated". Sembunyikan sebagian kode (misalnya hanya 4 karakter terakhir) sehingga screenshot atau orang di dekat tidak melihat seluruh kode.
Gunakan pesan generik di halaman publik, misalnya "Kami tidak dapat memverifikasi kode tersebut. Silakan cek dan coba lagi." Simpan detail seperti "kedaluwarsa" atau "terblokir" untuk layar staf setelah verifikasi pelanggan.
Jangan perlakukan sebagai kesalahan. Tampilkan "$0.00 remaining" (dengan waktu pembaruan) sehingga pelanggan mengerti kartu valid namun kosong.
Pisahkan dari halaman pelanggan dan wajibkan staf masuk. Sebagian besar staf hanya boleh melihat, sedangkan grup kecil (mis. manajer) yang boleh mengubah saldo, dan setiap perubahan dicatat dalam jejak audit.
Wajibkan alasan dan referensi bila memungkinkan (mis. nomor struk atau ID pesanan), serta rekam siapa yang melakukan perubahan dan kapan. Tampilkan preview "Current balance" dan "New balance" sebelum konfirmasi akhir untuk mengurangi kesalahan.
Catat setiap perubahan sebagai riwayat transaksi, bukan hanya menyimpan angka saldo yang bisa diubah. Issuance, redemption, refund, dan penyesuaian manual harus membuat record baru agar Anda bisa menjelaskan saldo di kemudian hari.
Tambahkan batasan laju dan jeda singkat setelah kegagalan berulang agar bot tidak bisa mencoba banyak kode dengan cepat. Simpan kode kartu hadiah dengan aman (mis. dalam bentuk terlindungi) dan hindari menampilkan seluruh kode kembali ke pengguna.
