Aprende a diseñar una página de comprobación de saldo de tarjetas de regalo con búsqueda por código para clientes y herramientas para que el personal ajuste saldos de forma segura.
Una página de comprobación de saldo de tarjeta de regalo tiene un trabajo: decir a alguien cuánto dinero queda en una tarjeta, rápido y sin confusiones. La gente la usa justo antes de comprar algo, nada más recibir una tarjeta o después de una compra reciente.
Esta página suele atender a dos públicos:
Sé específico sobre qué significa “código” en tu tienda. Puede ser un número impreso en el reverso de una tarjeta física, un código de un correo electrónico o algo que se muestra dentro de una app. Algunos programas también requieren un PIN o una franja para raspar. Si tu sistema necesita tanto número de tarjeta como PIN, dilo de inmediato para que la gente no pierda tiempo.
Una buena experiencia se siente predecible: un lugar claro para introducir el código, una única acción obvia “Check balance” y un resultado fácil de leer (moneda más hora de “última actualización”). Cuando algo va mal, la página debería explicar cómo recuperarse sin que la persona se quede atascada.
La precisión es el objetivo. Si la página muestra una cantidad incorrecta, hay conflictos en caja, más llamadas a soporte y pérdida de confianza.
Una página de comprobación de saldo tiene dos trabajos: ayudar a los clientes a confirmar lo que queda y dar al personal una forma segura de actualizar saldos cuando algo cambia en el mostrador. Las mejores soluciones mantienen la vista de cliente simple y ponen las acciones potentes detrás de una pantalla solo para personal.
En el lado del cliente, el flujo debe sentirse como una consulta de recibo. Introduce el código, pulsa comprobar y recibe una respuesta clara. Muestra el saldo restante en la moneda de la tienda e incluye una marca de tiempo de “última actualización” para que la gente sepa que el resultado está al día.
En el lado del personal, el flujo es buscar, verificar y luego ajustar. El personal debe poder encontrar una tarjeta por código (y más adelante, si lo eliges, por escaneo), revisar el saldo actual y la actividad reciente, y luego añadir valor (recarga) o restar valor (redención manual o corrección). Cada ajuste debe requerir una razón corta y, cuando sea posible, una referencia como el número de recibo.
La mayoría de los equipos lanza una primera versión con:
Ejemplo: una cafetería vende tarjetas de $25. Un cliente introduce un código y ve “$13.40 restantes, actualizado hace 2 minutos.” Más tarde, un empleado nota que la caja pasó por alto una redención, busca el mismo código, resta $4.60 y guarda la nota “latte, recibo 887.”
Los casos límite generan tickets de soporte, así que trátalos con calma:
La página debe ser rápida, calmada y difícil de estropear. Muchos clientes usan el móvil, están en el mostrador y no quieren retrasar la fila.
Mantén la entrada simple. Usa un solo campo para el código, con una etiqueta visible (no solo texto de ejemplo). Añade un formato de ejemplo corto como “Ejemplo: ABCD-EFGH-IJKL” y haz que sea fácil pegar. Evita formatos que cambien de forma sorprendente lo que el usuario escribió.
Haz la acción obvia. “Check balance” es más claro que “Enviar”. Tras pulsar, muestra un estado de carga (“Comprobando…”) y desactiva el botón para que la petición no se envíe dos veces.
Los mensajes de error deben ayudar a clientes honestos a recuperarse, sin revelar demasiado a quien está intentando adivinar códigos. En la página pública del cliente, mantén los fallos genéricos. Guarda las razones detalladas (caducado, bloqueado, no encontrado) para la pantalla del personal después de que alguien se verifique.
Una lista de control corta de UX que previene la mayoría de confusiones:
La accesibilidad importa incluso en una página pequeña. Asegúrate de que la etiqueta esté asociada al campo, que los usuarios de teclado puedan acceder al botón, que los contornos de enfoque sean visibles y que el contraste sea fuerte para luz brillante en la tienda.
Una buena pantalla para el personal es aburrida en el mejor sentido: ayuda a los empleados a arreglar un problema en segundos y deja un rastro claro para más tarde.
Empieza con inicio de sesión del personal y roles simples. La mayoría del personal debería poder buscar una tarjeta y ver el historial, mientras que solo los managers (o un grupo reducido de confianza) pueden cambiar saldos. Si tienes varias ubicaciones, etiqueta los cambios por tienda/ubicación.
Haz las búsquedas rápidas y tolerantes. Espacios y guiones no deberían romper las búsquedas. Para casos del mundo real en que un código está dañado o ilegible, puedes ofrecer opciones secundarias de búsqueda solo si puedes hacerlo de forma segura (y solo para personal), como ID de recibo/pedido o email/teléfono del cliente si ya lo recoges.
Una vez encontrada la tarjeta, muestra el saldo actual y la actividad reciente antes de cualquier control de edición. Esto reduce el error clásico: ajustar la tarjeta equivocada porque hay varias pestañas abiertas.
Mantén el formulario de ajuste estructurado en lugar de libre:
Tras introducir un importe, muestra una vista previa clara: “Saldo actual: $40.00. Nuevo saldo: $15.00.” Añade un paso de confirmación para cambios grandes (por ejemplo, cualquier cambio superior a $100 o más del 25% del saldo actual). Para cambios de alto riesgo, requiere un PIN de manager o reingresar el importe.
Una página de comprobación de saldo parece simple, pero atrae intentos de adivinanza, abuso y errores honestos. El objetivo no es seguridad perfecta, sino eliminar ataques triviales y hacer los problemas fáciles de detectar y arreglar.
Trata los códigos como contraseñas. Si alguien obtiene una lista de códigos, puede vaciar saldo rápidamente.
Dos medidas básicas ayudan mucho: almacena los códigos de forma segura y dificulta probar muchos códigos rápido. Muchos sistemas evitan guardar el código en texto plano; en su lugar almacenan una versión protegida (por ejemplo, un hash unidireccional), así una fuga de base de datos no entrega códigos utilizables.
En la pantalla de cliente, evita mostrar el código completo tras la búsqueda. Muestra una versión enmascarada (por ejemplo, solo los últimos 4 caracteres) para que capturas de pantalla y miradas por encima del hombro hagan menos daño.
Los límites de velocidad también importan. Sin ellos, un bot puede intentar miles de combinaciones. Manténlo simple:
La mayoría de las pérdidas reales vienen de ajustes del personal sin suficientes controles, no de hackeos cinematográficos. Cada cambio de saldo debe crear un rastro de auditoría: quién lo hizo, cuándo, cuánto y por qué.
Mantén el acceso del personal ceñido. No todo el mundo necesita el poder de editar saldos. Evita inicios de sesión compartidos, porque convierten el rastro de auditoría en inútil.
Decide cómo afectan reembolsos y contracargos a las tarjetas regalo y escríbelo como una regla interna simple. Por ejemplo: los reembolsos devuelven valor a la tarjeta original cuando es posible; si la tarjeta ya se gastó, el caso se marca para revisión.
La página parece simple, pero los datos detrás deben ser demostrables. Un enfoque seguro es: no confiar en un único número de “saldo” editable sin un historial de transacciones que lo explique.
Una estructura común usa tres tablas:
Trata la tabla de transacciones como la fuente de la verdad. Tipos de transacción típicos incluyen emisión (carga inicial), redención (compra), ajuste (corrección por personal) y reembolso (anular una redención). Puedes calcular el saldo actual como la suma de transacciones o mantener un saldo en caché en la fila de la tarjeta que actualices con cuidado.
Para evitar cargos duplicados cuando alguien pulsa dos veces en un dispositivo lento, usa una clave de idempotencia para cada escritura. Eso da a cada checkout o ajuste un ID de operación único y las repeticiones se ignoran.
Para auditorías y soporte, algunos campos valen su coste:
Decide lo que el cliente ve antes de empezar. La página debe explicar dónde encontrar el código, qué significa “saldo” en tu tienda y qué hacer si la búsqueda falla. En la pantalla de resultado, muestra el saldo, la moneda y una clara hora de “última actualización”.
Define las reglas del código y valida pronto. Elige una longitud fija y permite solo los caracteres que realmente imprimes. Valida mientras el usuario escribe y otra vez al enviar, para atrapar errores sin revelar detalles extra.
Construye el flujo de búsqueda del cliente en pasos pequeños: crea la pantalla de entrada, llama al backend al enviar y luego maneja tres resultados: encontrado, no encontrado/inválido y temporalmente no disponible.
Luego añade el lado del personal. El personal debe iniciar sesión antes de poder cambiar nada, y cada ajuste debe requerir una razón explícita. Añade un paso de confirmación que repita el código y el importe.
Cuando los ajustes funcionen, añade historial. Cada tarjeta debe mostrar una lista de transacciones y un registro de auditoría que indique quién cambió qué y cuándo.
Finalmente, prueba escenarios reales antes del lanzamiento: un error tipográfico, un saldo cero, una redención parcial, un reembolso que restaura valor y dos miembros del personal ajustando la misma tarjeta con minutos de diferencia.
La mayoría de tickets vienen de dos cosas: retroalimentación poco clara para clientes honestos y registros faltantes para acciones del personal.
Una trampa común es ser demasiado específico con los mensajes públicos de error. Detalles como “el código existe pero está inactivo” pueden ayudar a atacantes a confirmar códigos válidos. Mantén el mensaje de cara al cliente neutral y muestra específicos solo en la herramienta del personal tras la verificación.
Otro foco de tickets es permitir que el personal cambie saldos sin contexto. Cuando alguien dice “mi tarjeta tenía $50 ayer”, necesitas una respuesta rápida. Las ediciones silenciosas crean discusiones.
Los errores que más suelen doler:
Ejemplo: un cajero redime $25, la tablet se queda pillada y pulsa “Confirmar” otra vez. Sin protección, el sistema registra dos redenciones. Soluciona esto tratando cada cambio como un evento único registrado y haciendo que “Confirmar” sea seguro de pulsar dos veces.
Antes de publicar la página, haz una pasada «haz de cuenta que eres cliente» y luego una de «haz de cuenta que eres personal».
Comprobaciones para clientes:
Comprobaciones para el personal:
También revisa el wording. No mezcles “saldo de tarjeta regalo” con “crédito de tienda” a menos que signifiquen lo mismo en tu tienda. Si hay límites (fechas de caducidad, uso solo en tienda), dilo en una frase corta.
Imagina una pequeña tienda que vende tarjetas físicas en el mostrador. Los clientes pueden comprobar su saldo desde casa antes de venir, y el personal puede redimir tarjetas en persona.
El domingo por la noche, Maya encuentra una tarjeta en un cajón. Entra en la página de comprobación de saldo, escribe el código del reverso y ve un resultado simple: saldo actual, hora de la última actualización y un recordatorio corto para mantener el código privado. No hace falta cuenta.
El lunes, Maya compra artículos por $38.50 y paga con la tarjeta. En caja, el personal abre la pantalla administrativa, busca el mismo código y redime una cantidad parcial. El personal ve más detalle que Maya, incluido el historial y un lugar para añadir una nota.
Más tarde ese día, Maya devuelve un artículo por $12.00. El empleado registra un reembolso con una referencia clara. Cuando alguien pregunta por qué cambió el saldo, la respuesta está en una línea del historial en lugar de que alguien intente reconstruir la historia.
Elige una primera versión pequeña en la que puedas confiar. Para la mayoría de tiendas, lo mínimo es un comprobador de saldo para clientes y una herramienta de personal que pueda ajustar saldos con un motivo y un registro de transacciones.
Un v1 práctico incluye búsqueda por código del cliente, inicio de sesión del personal, ajustes con motivos obligatorios, un registro de transacciones por cada cambio y límites básicos (más una segunda confirmación para cambios grandes).
Antes de ampliar funciones, escribe una regla interna corta para situaciones complicadas como reembolsos y disputas, y entrena al personal con dos o tres ejemplos reales. Tras el lanzamiento, revisa los mensajes de soporte semanalmente y arregla los puntos de dolor principales primero.
Si ya usas Koder.ai (koder.ai) para construir herramientas internas, mantener la búsqueda del cliente y la edición por parte del personal como pantallas separadas con permisos distintos desde el primer día hace el proyecto más fácil de mantener a medida que crece.
Pon el foco en una tarea: introducir un código de tarjeta y ver la cantidad restante. Muestra el saldo en la moneda de la tienda e incluye un claro “última actualización” para que el resultado inspire confianza.
Pide lo que tu programa realmente requiera y dilo desde el principio. Si necesitas tanto el número de tarjeta como un PIN (o una franja para raspar), muestra ambos campos de inmediato para que la gente no pierda tiempo.
Manténlo simple y fácil de pegar: un único campo con etiqueta, un ejemplo de formato y un solo botón “Check balance”. Tras enviar, muestra un breve estado de carga y desactiva el botón para evitar dobles comprobaciones.
Muestra el saldo, la moneda y una marca de tiempo de “última actualización”. Enmascara el código en el resultado (por ejemplo, muestra solo los últimos 4 caracteres) para que capturas de pantalla o miradas por encima del hombro revelen menos.
Usa un mensaje genérico en la página pública, por ejemplo: “No pudimos verificar ese código. Por favor, comprueba y vuelve a intentarlo.” Guarda detalles como “caducado” o “bloqueado” para la herramienta del personal una vez que se verifique al cliente.
No lo trates como un error. Muestra “$0.00 restantes” (con la hora de última actualización) para que los clientes entiendan que la tarjeta es válida pero está vacía.
Sepárala de la página de cliente y exige inicio de sesión del personal. La mayoría del personal solo debería poder ver, mientras que un grupo más pequeño (por ejemplo, managers) puede ajustar saldos, y cada cambio debe quedar registrado en un rastro de auditoría.
Requiere un motivo y, cuando sea posible, una referencia (como un recibo o ID de pedido), y registra quién hizo el cambio y cuándo. Muestra una vista previa tipo “Saldo actual” y “Nuevo saldo” antes de la confirmación final para reducir errores.
Registra cada cambio como una entrada en el historial de transacciones, no solo como un número de saldo editable. Emisión, redención, reembolso y ajustes manuales deben crear un registro nuevo para poder explicar cualquier saldo más adelante.
Añade límites de velocidad y un periodo de enfriamiento tras varios fallos para que los bots no puedan probar miles de códigos rápidamente. También almacena los códigos de forma segura (por ejemplo, en forma protegida) y evita mostrar el código completo al usuario.
