PDV embarcado na maquininha para um foodtruck
Um app de vendas que roda dentro da própria maquininha de cartão: cardápio, cobrança, nota impressa, estorno protegido e preço de evento.
- Papel
- Solo
- Período
- set. de 2026 – em andamento
- Kotlin
- Jetpack Compose
- Room
- Hilt
- Coroutines
- DataStore
- PagBank PlugPag SDK



- toques numa venda simples
- 4
- aparelho para pedido, cobrança e nota
- 1
- testes automatizados
- +400
Neste case
#O balcão de um foodtruck não espera
Fila na janela, uma pessoa só atendendo, mãos ocupadas, cliente com pressa. Cada pedido de espetinho tem detalhes: qual carne, qual acompanhamento, sem vinagrete, mais um refrigerante.
O jeito comum de resolver isso é um caderno, uma calculadora e a maquininha de cartão do lado. O operador anota, soma de cabeça, digita o valor na maquininha e torce para não ter errado. Os problemas aparecem rápido:
- O valor digitado à mão erra. Um zero a mais ou a menos e o caixa do dia não fecha.
- O detalhe do pedido se perde entre o caderno e a chapa.
- Desfazer uma venda é um sufoco. O cliente desiste depois de pagar, ou a cobrança saiu na forma errada, e o estorno vira uma caça a menus dentro da maquininha.
- No fim da noite, ninguém sabe ao certo quanto vendeu, nem em quê.
#O que eu construí
Um ponto de venda que roda dentro da própria maquininha (uma PagBank Moderninha Smart, que é um Android com leitor de cartão e impressora térmica). Não há tablet, nem celular, nem cabo: o mesmo aparelho monta o pedido, cobra o cliente e imprime a nota.

O cardápio é a tela inicial. Cada categoria tem uma cor.

Escolhas um passo de cada vez: espeto 1 de 2.

Tirar o vinagrete é um toque, e o preço já vem atualizado.

O carrinho mostra cada detalhe que vai para a nota.

Total grande e uma forma de pagamento por botão.

Valor avulso sem sair da tela de vendas.
#Uma venda em quatro toques
Uma venda simples fecha em quatro toques: o produto, COBRAR, a forma de pagamento e a confirmação do cliente no cartão. Produtos com escolhas (carne, acompanhamentos, o que tirar) abrem uma escolha por vez e voltam direto para a venda.
O valor nunca é digitado à mão: o app soma o pedido, aplica o desconto se houver, e manda o total exato para a cobrança no débito, no crédito, no PIX ou no voucher. Um pedido com desconto total é registrado como cortesia, sem passar pela maquininha.
#Feito para o balcão, não para a vitrine
A interface não tenta ser bonita, tenta ser impossível de errar com pressa. Cada decisão visual vem da operação:
- Botões grandes, do tamanho de um dedo apressado. O operador trabalha em pé, muitas vezes com uma mão ocupada. Nada de ícone pequeno, menu escondido ou gesto que precisa de precisão.
- Uma cor por categoria. Espetos, churraspães, hambúrgueres e bebidas têm cores diferentes, para o olho achar o produto antes de ler o nome.
- O mais vendido ocupa a linha inteira. O espeto é o item que mais sai, então tem o maior alvo da tela.
- O que importa aparece grande. O total a cobrar é o maior texto da tela de pagamento, e cada forma de pagamento é um botão da largura da tela.
- Sem confirmações desnecessárias. Produto sem escolhas vai direto para o carrinho com um toque. A única pergunta que o app faz é a que evita um erro de verdade, como confirmar um estorno.
- Um toque, um som. Cada botão responde com um clique, para o operador saber que o toque pegou sem precisar olhar de novo.
#A nota sai da própria maquininha
Depois do pagamento, o app imprime a sua própria nota: nome do foodtruck, data e hora, cada item com os adicionais e o que foi retirado, desconto, total e forma de pagamento. Logo e número do pedido em letras grandes também podem sair.
O dono escolhe o que vai na nota, o tamanho de cada parte do texto e se ela é impressa sempre ou só quando o cliente pede. Uma prévia mostra exatamente como vai sair no papel, na largura real da bobina.
#O cardápio é do dono, não do programador
Produtos, preços, ordem na tela e variações são editados no próprio aparelho, com setas para reordenar e um interruptor para tirar da tela o item que acabou, sem apagar o histórico. As escolhas são grupos reutilizáveis: o mesmo grupo de espetos serve a um lanche que pede um e a outro que pede dois.

Ordem na tela e produtos ativos, sem programador.

Preço, categoria e quantas escolhas cada grupo exige.

Prévia da nota na largura real da bobina.

Fechamento do dia, por forma de pagamento.

Modo evento ligado: o aviso fica na tela de vendas.

O menu inteiro fica atrás da senha do dono.
#Dia de evento, preço de evento
Em festas e feiras, o mesmo cardápio é vendido mais caro, e os valores são decididos no dia. Um interruptor liga o modo evento: a tela de vendas e o editor passam a usar preços de evento, com um aviso visível para ninguém cobrar o preço errado sem perceber. Ao desligar, os preços do dia a dia estão exatamente onde ficaram. Vendas já feitas guardam o valor que foi cobrado e não mudam com o modo.
#Estorno pelo app, só com a senha do dono
Estorno devolve dinheiro, então fica atrás de uma senha do dono, que protege o menu inteiro: cardápio, preços, relatório e estorno. Vender, cobrar um valor avulso e reimprimir a última nota continuam livres para o operador.
A senha é guardada só como hash com sal, há bloqueio progressivo depois de erros seguidos e um código de recuperação para o dia em que ela for esquecida.
#O fechamento do dia em papel
O relatório lista cada venda com hora, valor e forma, filtra por forma de pagamento, navega entre os dias e é impresso na própria maquininha. Vendas estornadas aparecem marcadas e ficam fora do total.
#Onde um PDV não pode errar
Um app de vendas pode ser simples e ainda assim ser usado. O que ele não pode é cobrar duas vezes ou registrar uma coisa diferente do que aconteceu no cartão. Foi aí que eu concentrei as decisões mais cuidadosas:
- O app e a maquininha nunca discordam sobre um estorno. Antes de pedir o estorno, o app registra que ele está em andamento. Se a resposta for clara, grava o desfecho. Se a comunicação cair no meio, a venda fica como "estorno não confirmado" e só oferece tentar de novo, que resolve o caso dos dois lados.
- Cancelar é cancelar de verdade. O botão de cancelar e a seta de voltar pedem o cancelamento ao terminal e esperam a resposta dele. Sair da tela sem isso deixava a cobrança presa no serviço de pagamento, e a venda seguinte falhava.
- Erro desconhecido não vira "deu certo" nem "deu errado". Respostas que o app não reconhece são tratadas como incertas, nunca como estorno feito ou recusado.
- Uma falha de impressão não perde a venda. O pagamento aprovado é gravado antes da nota; se o papel acabar, a nota sai depois, sem cobrar de novo.
- Atualizar o app não apaga o histórico. Cada mudança no banco de dados vem com uma migração testada que preserva vendas e cardápio.
#Como uma venda acontece
- 1Operador toca nos produtos e escolhe as opções
- 2App soma o pedido e aplica o desconto
- 3Cobrança no cartão, PIX ou voucherMensagens do terminal na tela do app
- 4Venda gravada com o preço de cada item
- 5Nota impressa na hora
#As decisões por trás
Por que rodar dentro da maquininha, e não num tablet ao lado?
Porque no balcão de um foodtruck cada aparelho a mais é um cabo, uma bateria e uma chance de falhar. A Moderninha já tem tela, leitor de cartão, impressora e Android. Um app nativo nela resolve o pedido, a cobrança e a nota sem nenhuma integração entre aparelhos.
Por que uma interface tão simples?
Porque quem usa é um operador com fila na frente, não um visitante de site. Cada enfeite é um lugar a mais para o olho passar antes de achar o botão certo. Cores servem para separar categorias, tamanho serve para o total e os botões principais, e o resto sai do caminho.
Como desenvolver antes de ter acesso ao sistema de pagamento?
O código que conversa com o PagBank fica isolado atrás de uma interface, numa parte do projeto que só entra na versão final. Enquanto as chaves não chegavam, o app inteiro rodava num celular comum com pagamento e impressão simulados. Quando chegaram, bastou ligar a implementação real, sem reescrever telas.
E se um dia o foodtruck trocar de maquininha?
O app foi separado em variantes por adquirente. A do PagBank está em homologação, e a da Stone já existe como esqueleto, esperando o SDK. O cardápio, as vendas, a nota e o relatório são os mesmos; só muda a peça que fala com o terminal.
Como saber que o preço está certo sem testar na maquininha toda vez?
Toda a regra de preço, desconto, agrupamento de itens e modo evento é código puro, sem Android, testado em segundos no computador. O banco de dados e as telas têm testes num emulador. A maquininha fica para o que só ela faz: o cartão e o papel.
#Em números
- 4
- toques numa venda simples
- 4
- formas de pagamento, mais cortesia
- +400
- testes automatizados
- 1
- aparelho para pedido, cobrança e nota
#O que muda no balcão
O operador para de somar de cabeça e de digitar valores na maquininha: toca no que o cliente pediu e cobra. O dono muda um preço sem pedir a ninguém, liga o modo evento quando estaciona numa feira e fecha a noite com o relatório impresso na mão. E quando uma venda precisa ser desfeita, ela é desfeita pelo app, com senha, e o registro bate com o que aconteceu no cartão.
Quer um sistema assim na sua operação?
Diagnóstico gratuito de 30 min. Você sai com escopo, prazo e preço fechados.
Quero meu diagnósticoQuer um resultado assim no seu produto?
Me conte o problema em uma frase. Respondo em até 48h úteis com uma leitura honesta do que dá pra fazer.