Aprenda a criar uma página de verificação de saldo de cartão-presente com busca por código para clientes e uma área administrativa para a equipe ajustar saldos com segurança.
Uma página de verificação de saldo de cartão-presente tem um trabalho: informar rapidamente e sem confusão quanto dinheiro resta em um cartão. As pessoas a usam antes de comprar algo, logo após receber um cartão ou depois de uma compra recente.
Essa página normalmente serve dois públicos:
Seja específico sobre o que “código” significa na sua loja. Pode ser um número impresso no verso do cartão físico, um código enviado por e-mail ou algo mostrado dentro de um app. Alguns programas também exigem um PIN ou área para raspar. Se seu sistema precisa tanto do número do cartão quanto do PIN, diga isso imediatamente para que as pessoas não percam tempo.
Uma boa experiência é previsível: um campo claro para inserir o código, uma ação óbvia "Check balance" e um resultado fácil de ler (valor em moeda e um horário de "última atualização"). Quando algo dá errado, a página deve explicar como recuperar sem deixar a pessoa presa.
Precisão é o ponto principal. Se a página mostra o valor errado, você terá conflito no caixa, mais chamadas ao suporte e perda de confiança.
Uma página de verificação de saldo tem duas funções: ajudar clientes a confirmar o que resta e dar à equipe uma forma segura de atualizar saldos quando algo muda no balcão. Os melhores setups mantêm a visão do cliente simples e colocam ações poderosas atrás de uma tela só para a equipe.
Do lado do cliente, o fluxo deve parecer com a verificação de um recibo. Insira o código, toque em verificar, receba uma resposta clara. Mostre o saldo restante na moeda da loja e inclua um carimbo de "última atualização" para que as pessoas saibam que o resultado é atual.
Do lado da equipe, o fluxo é buscar, verificar e ajustar. A equipe deve encontrar um cartão pelo código (e, se quiser, futuramente por leitura), revisar o saldo atual e a atividade recente, então adicionar valor (recarga) ou subtrair valor (redenção manual ou correção). Cada ajuste deve exigir um motivo curto e, quando possível, uma referência como número de recibo.
A maioria das equipes entrega uma primeira versão com:
Exemplo: uma cafeteria vende cartões-presente de $25. Um cliente insere um código e vê “$13.40 restantes, atualizado há 2 minutos.” Mais tarde, um funcionário percebe que o caixa perdeu uma redenção, busca o mesmo código, subtrai $4.60 e salva a nota “latte, recibo 887.”
Casos de borda geram tickets de suporte, então trate-os com calma:
Uma página de verificação de saldo deve ser rápida, calma e difícil de confundir. Muitos clientes estão no celular, de pé no balcão, tentando não atrapalhar a fila.
Mantenha o input simples. Use um campo único para o código, com um rótulo visível (não apenas placeholder). Adicione um curto exemplo de formato como "Exemplo: ABCD-EFGH-IJKL" e facilite colar o código. Evite formatações surpresa que mudem o que o usuário digitou.
Torne a ação óbvia. "Check balance" é mais claro que "Enviar." Depois de tocar, mostre um estado de carregamento ("Checking…") e desative o botão para que a requisição não seja enviada duas vezes.
Mensagens de erro devem ajudar clientes honestos a se recuperar, revelando o mínimo possível para quem está tentando adivinhar códigos. Na página pública, mantenha falhas genéricas. Guarde os motivos detalhados (expirado, bloqueado, não encontrado) para a tela da equipe, após verificação.
Uma lista rápida de verificação de UX que previne a maioria das confusões:
Acessibilidade importa mesmo numa página pequena. Garanta que o rótulo esteja ligado ao input, que usuários de teclado alcancem o botão, que o foco seja visível e que o contraste suporte iluminação forte da loja.
Uma boa tela administrativa para a equipe é monótona da melhor forma: ajuda os funcionários a resolver um problema de cartão em segundos, enquanto deixa um rastro claro para depois.
Comece com login da equipe e papéis simples. A maioria deve poder buscar um cartão e ver o histórico, enquanto apenas gerentes (ou um pequeno grupo confiável) podem alterar saldos. Se você tiver múltiplas lojas, marque as mudanças por loja/local.
Faça buscas rápidas e tolerantes. Espaços e traços não devem quebrar a busca. Para casos reais em que um código está danificado ou ilegível, ofereça opções secundárias de busca apenas para a equipe (e apenas se for seguro), como ID do recibo/pedido ou e-mail/telefone do cliente se você já os coletar.
Quando um cartão for encontrado, mostre o saldo atual e a atividade recente antes de qualquer controle de edição. Isso reduz o erro clássico: ajustar o cartão errado porque várias abas estão abertas.
Mantenha o formulário de ajuste estruturado em vez de livre:
Após digitar um valor, mostre a prévia claramente: "Saldo atual: $40.00. Novo saldo: $15.00." Adicione uma etapa de confirmação para mudanças grandes (por exemplo, qualquer alteração acima de $100 ou mais de 25% do saldo atual). Para mudanças de alto risco, exija PIN de gerente ou redigitação do valor.
Uma página de verificação de saldo soa simples, mas atrai tentativas de adivinhação, abuso e erros honestos. O objetivo não é segurança perfeita, é eliminar ataques fáceis e tornar problemas fáceis de detectar e corrigir.
Trate códigos de cartão-presente como senhas. Se alguém obtiver uma lista de códigos, pode drenar o valor rapidamente.
Dois passos básicos já ajudam muito: armazene códigos com segurança e dificulte testar muitos códigos rapidamente. Muitos sistemas evitam armazenar o código bruto em texto simples. Em vez disso, armazenam uma versão protegida (como um hash unidirecional), para que um vazamento de banco de dados não entregue códigos funcionando aos atacantes.
Na tela do cliente, evite mostrar o código completo após a consulta. Mostre uma versão mascarada (por exemplo, apenas os últimos 4 caracteres) para que capturas de tela e observação por cima causem menos dano.
Limites de taxa também importam. Sem eles, um bot pode tentar milhares de combinações. Mantenha simples:
A maioria das perdas reais vem de ajustes da equipe feitos sem controles suficientes, não de invasões cinematográficas. Toda mudança de saldo deve criar uma trilha de auditoria: quem fez, quando, quanto e por quê.
Mantenha o acesso da equipe restrito. Nem todo mundo precisa do poder de editar saldos. Evite logins compartilhados, pois eles tornam a trilha de auditoria inútil.
Defina como reembolsos e estornos afetam cartões-presente e documente isso como uma regra interna simples. Por exemplo: reembolsos devolvem valor ao cartão original quando possível; se o cartão já foi gasto, o caso é sinalizado para revisão.
A página parece simples, mas os dados por trás devem ser comprováveis. Uma abordagem segura é: não confie apenas em um número de "saldo" editável sem um histórico de transações que o explique.
Uma estrutura comum usa três tabelas:
Trate a tabela de transações como fonte da verdade. Tipos típicos de transação incluem emissão (carga inicial), redenção (compra), ajuste (correção da equipe) e reembolso (desfazer uma redenção). Você pode calcular o saldo atual como soma das transações, ou manter um saldo em cache no registro do cartão que você atualiza com cuidado.
Para evitar cobranças duplicadas quando alguém toca duas vezes num dispositivo lento, use uma chave de idempotência para cada escrita. Isso dá a cada checkout ou ajuste um ID de operação único, e envios repetidos são ignorados.
Para auditoria e suporte, alguns campos pagam por si mesmos:
Decida o que o cliente vê antes de construir qualquer coisa. A página deve explicar onde encontrar o código, o que “saldo” significa na sua loja e o que fazer se a consulta falhar. Na tela de resultado, mostre o saldo, a moeda e um horário claro de "última atualização".
Defina as regras do código e valide cedo. Escolha um comprimento fixo e permita apenas os caracteres que você realmente imprime. Valide enquanto o usuário digita e novamente no envio, assim você pega erros rápido sem revelar detalhes extras.
Construa o fluxo de consulta do cliente em passos pequenos: crie a tela de entrada, chame o backend no envio e então trate três resultados - encontrado, não encontrado/inválido e temporariamente indisponível.
Depois adicione o lado da equipe. A equipe deve se autenticar antes de poder mudar qualquer coisa, e toda alteração deve exigir um motivo explícito. Adicione uma etapa de confirmação que repita o código e o valor.
Depois que ajustes funcionarem, adicione histórico. Cada cartão-presente deve mostrar uma lista de transações e um log de auditoria que registre quem mudou o quê e quando.
Finalmente, teste cenários reais antes do lançamento: um erro de digitação, um saldo zero, uma redenção parcial, um reembolso que restaura valor e dois funcionários ajustando o mesmo cartão com poucos minutos de diferença.
A maioria dos tickets vem de duas coisas: feedback pouco claro para clientes honestos e registros ausentes para ações da equipe.
Uma armadilha comum é ser muito específico com mensagens públicas de erro. Detalhes como "o código existe, mas está inativo" podem ajudar atacantes a descobrir códigos válidos. Mantenha a mensagem pública neutra e mostre especificidades só na ferramenta da equipe após verificação.
Outro gerador de tickets é permitir que a equipe mude saldos sem contexto. Quando alguém diz "Meu cartão tinha $50 ontem", você precisa de uma resposta rápida. Edições silenciosas criam uma situação de "ele disse/ela disse".
Os erros que costumam prejudicar mais:
Exemplo: um caixa resgata $25, o tablet fica lento e o funcionário toca em "Confirm" novamente. Sem proteção, o sistema registra duas redenções. Corrija isso tratando cada mudança como um evento único registrado e tornando o botão "Confirm" seguro para pressionar duas vezes.
Antes de publicar a página de verificação de saldo, faça uma checagem rápida como "finja que é cliente" e depois "finja que é equipe".
Checagens de cliente para rodar:
Checagens da equipe para rodar:
Também revise sua terminologia. Não misture "saldo do cartão-presente" com "crédito da loja" a menos que realmente signifiquem a mesma coisa na sua loja. Se houver limites (datas de expiração, uso apenas na loja), diga isso em uma frase curta.
Imagine uma pequena loja de presentes que vende cartões físicos no caixa. Clientes podem checar o saldo em casa antes de visitar, e a equipe pode resgatar cartões pessoalmente.
No domingo à noite, Maya encontra um cartão-presente numa gaveta. Ela abre a página de verificação de saldo da loja, digita o código do verso do cartão e vê um resultado simples: saldo atual, horário da última atualização e um lembrete curto para manter o código privado. Nenhuma conta necessária.
Na segunda, Maya compra itens totalizando $38.50 e paga com o cartão-presente. No caixa, a equipe abre a tela administrativa, busca o mesmo código e resgata um valor parcial. A equipe vê mais detalhes que Maya, incluindo histórico e um campo para adicionar nota.
Mais tarde, Maya devolve um item por $12.00. O funcionário registra um reembolso com referência clara. Quando alguém pergunta por que o saldo mudou, a resposta está em uma linha do histórico em vez de alguém tentar reconstruir a história.
Escolha um lançamento inicial pequeno e confiável. Para a maioria das lojas, o mínimo é um verificador de saldo para clientes mais uma ferramenta da equipe que possa ajustar saldos com motivo e registrar um histórico.
Um v1 prático inclui consulta de cliente por código, login da equipe, ajustes com motivos obrigatórios, um log de transações para cada mudança e limites básicos (além de uma segunda confirmação para mudanças grandes).
Antes de expandir recursos, escreva uma regra interna curta para situações complicadas como reembolsos e disputas, então treine a equipe com dois ou três exemplos reais. Após o lançamento, revise as mensagens de suporte semanalmente e corrija primeiro os pontos que mais incomodam.
Se você já usa Koder.ai (koder.ai) para construir ferramentas internas, manter a consulta do cliente e a edição pela equipe como telas separadas e com permissões distintas desde o dia 1 facilita a manutenção do projeto conforme ele cresce.
Coloque o foco em uma tarefa: inserir o código do cartão-presente e ver o valor restante. Mostre o saldo na moeda da loja e inclua um horário claro de "última atualização" para que o resultado pareça confiável.
Peça exatamente o que seu programa exige e diga isso desde o começo. Se precisar tanto do número do cartão quanto de um PIN (ou uma área para raspar), mostre ambos os campos imediatamente para que as pessoas não percam tempo.
Mantenha simples e amigável para colar: um campo rotulado, um exemplo de formato e um único botão "Check balance". Após o envio, mostre um estado de carregamento curto e desabilite o botão para evitar verificações duplicadas.
Mostre o saldo, a moeda e um carimbo de horário "última atualização". Masque o código no resultado (por exemplo, mostre apenas os últimos 4 caracteres) para que capturas de tela e olhares por cima revelem menos.
Use uma mensagem genérica na página pública, como "Não foi possível verificar esse código. Verifique e tente novamente." Guarde detalhes como "expirado" ou "bloqueado" para a tela da equipe, após a verificação do cliente.
Não trate como erro. Exiba "$0.00 restantes" (com o horário da última atualização) para que o cliente entenda que o cartão é válido, mas sem saldo.
Separe da página do cliente e exija autenticação da equipe. A maioria dos funcionários deve apenas visualizar; um grupo menor (por exemplo, gerentes) pode ajustar saldos, com cada mudança registrada em uma trilha de auditoria.
Exija um motivo e, quando possível, uma referência (como recibo ou ID do pedido), e capture quem fez a mudança e quando. Mostre uma prévia como "Saldo atual" e "Novo saldo" antes da confirmação final para reduzir erros.
Registre cada alteração como um histórico de transações, não apenas um número de saldo editável. Emissão, redenção, reembolso e ajustes manuais devem criar registros separados para que você possa explicar qualquer saldo posteriormente.
Adicione limites de taxa e um período de cooldown após falhas repetidas para que bots não consigam testar muitos códigos rapidamente. Também armazene os códigos de forma segura (por exemplo, em uma versão protegida) e evite mostrar o código completo de volta ao usuário.
