Página de comprobación de saldo de tarjetas de regalo: búsqueda para clientes y ediciones del personal

Qué debe hacer esta página (en lenguaje sencillo)

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:

• Clientes, que quieren una búsqueda rápida y fiable.
• Personal de la tienda, que necesita una herramienta privada para actualizar saldos cuando se vende, usa, reembolsa o corrige una tarjeta.

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.

Funciones principales: comprobación por cliente y ajustes por personal

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:

• Entrada de código por parte del cliente y visualización del saldo (con hora de última actualización)
• Pantalla de búsqueda para el personal que muestra estado de la tarjeta, saldo y cambios recientes
• Acciones para el personal para sumar o restar valor con un motivo obligatorio
• Manejo de estados simple (activa, caducada, bloqueada)

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:

• Código inválido o mal tecleado: ofrece una ruta clara para reintentar
• Tarjeta caducada: explica qué significa “caducada” y qué hacer a continuación
• Saldo cero: muestra $0.00 con la hora de última actualización (no lo trates como un error)

Experiencia del cliente que evita confusiones

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:

• Un campo de código con una etiqueta real y un ejemplo simple
• Un botón claro “Check balance” y un estado de carga visible
• Un estado de éxito claro: saldo, moneda y “Última actualización”
• El código tecleado permanece en la caja tras un error
• Objetivos táctiles grandes y texto legible en móvil

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.

Pantalla de administración para el personal: cambios de saldo seguros y rápidos

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:

• Importe (+ para añadir, - para restar)
• Motivo (desplegable como reembolso, corrección manual, promoción, transferencia por tarjeta perdida)
• Referencia (ID de pedido o número de recibo)
• Notas opcionales
• Miembro del personal capturado automáticamente

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.

Seguridad y conceptos básicos contra fraude (versión no técnica)

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.

Proteger los códigos y limitar intentos de adivinanza

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:

• Limita comprobaciones por minuto por IP y por dispositivo
• Añade un enfriamiento corto tras varios intentos fallidos
• Usa un mensaje de fallo genérico en la página pública

Hacer trazables las acciones del personal

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.

Modelo de datos: saldos, transacciones e historial de auditoría

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:

• gift_cards: una fila por tarjeta (almacena el código de forma segura), más estado, moneda y marcas de tiempo
• gift_card_transactions: cada cambio es una fila nueva, nunca se sobrescribe
• staff_users: quién puede hacer acciones y qué hicieron

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:

• Importe (con signo), moneda, hora de creación
• Motivo y referencia (ID de pedido o número de recibo)
• Realizado por (usuario del personal)
• Saldo antes y saldo después

Paso a paso: construir el comprobador de saldo y las herramientas administrativas

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.

Errores comunes que generan tickets de soporte

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:

• El personal puede cambiar un saldo sin motivo (y de forma ideal una referencia)
• Solo se almacena el saldo actual y no un historial de transacciones
• No hay rastro de auditoría mostrando quién cambió qué y cuándo
• La comprobación de saldo escribe en el saldo (en vez de leer) o sobrescribe el historial
• La página se puede enviar dos veces en redes lentas, causando redenciones duplicadas

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.

Lista rápida antes de publicar

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:

• Introducir un código válido, redimir algo pequeño y volver a comprobar
• Meter un código inválido y confirmar que la página no revela pistas
• Probar una tarjeta caducada o desactivada y verificar que el mensaje se mantiene genérico
• Introducir un código válido con saldo cero y confirmar que se muestra como resultado normal
• Probar un saldo muy alto y confirmar el formato y la moneda

Comprobaciones para el personal:

• Confirmar que un ajuste crea una entrada de historial inmediatamente
• Verificar permisos con dos cuentas (solo ver vs ajustar)
• Confirmar que nadie puede borrar o editar el historial pasado
• Abrir una entrada de registro y confirmar que muestra quién cambió qué y por qué

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.

Ejemplo real: una tienda pequeña con redenciones en tienda

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.

Próximos pasos: lanzar una primera versión y mejorar con seguridad

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.