Evite Que Um Aviso de Pagamento Crie Dois Pedidos
Serviços de pagamento, reserva e entrega podem mandar o mesmo aviso mais de uma vez. Seu app deve lembrar o que concluiu para cada ação do cliente gerar um único resultado.
antes de começar
O mesmo aviso pode chegar duas vezes, mas o pagamento, envio, crédito ou acesso deve mudar uma única vez.
Entenda por que o mesmo aviso pode chegar duas vezes
em palavras simples
Outro serviço pode repetir um aviso automático quando não consegue confirmar que o app recebeu a primeira cópia.
Seu app pode estar ligado a uma empresa de pagamentos, agenda, formulário, assinatura ou entrega. Depois que o cliente paga, cancela, reserva ou altera a conta, essa empresa pode mandar um aviso automático diretamente ao app. O nome técnico desse tipo de aviso é webhook. Se o primeiro envio demora, a resposta se perde ou o app para de responder por alguns instantes, a empresa pode mandar o mesmo aviso novamente. Em geral, isso tenta garantir a entrega e não representa uma segunda ação do cliente.
O perigo começa quando o app trata cada chegada como um trabalho novo. Um pagamento pode criar dois pedidos, um estorno pode devolver dinheiro duas vezes e uma reserva pode ocupar duas vagas. Um aviso repetido sobre a conta também pode conceder ou retirar acesso mais de uma vez. Anote o resultado real provocado por cada tipo de aviso. Defina exatamente o que só pode acontecer uma vez, como cobrar, dar crédito, enviar um pacote, mudar o estoque, mandar um e-mail ou alterar o que o cliente pode abrir.
- ▸Inclua pagamentos, estornos, assinaturas, reservas, entregas e mudanças de conta.
- ▸Considere a repetição do envio algo esperado, não a prova de uma nova ação do cliente.
risco comum
O cliente paga uma vez. Como a empresa de pagamentos não recebe uma resposta rápida, ela manda outra confirmação, e o app cria dois envios.
o que fazer agora
Liste cada aviso automático recebido pelo app e o único resultado em dinheiro, estoque, pedido ou conta que ele pode gerar.
peça isto à sua IA
Examine este app e mostre todos os lugares que recebem avisos automáticos de serviços de pagamento, reserva, formulário, assinatura ou entrega. O nome técnico desse aviso é webhook. Para cada lugar, liste a ação posterior relacionada a cliente, dinheiro, estoque, e-mail, envio ou conta. Identifique quais ações devem acontecer uma única vez. Ainda não altere o app.
Faça o app lembrar o que já foi concluído
em palavras simples
O app precisa guardar um comprovante duradouro de que determinado aviso já produziu o único resultado permitido.
A maioria dos serviços inclui um número de referência estável em cada aviso. O nome técnico é ID do evento ou ID da entrega. Antes de mudar um pedido, saldo, reserva, envio ou conta, o app deve procurar essa referência nos registros salvos. Se ela já estiver marcada como concluída, o app deve confirmar o recebimento sem repetir a ação. Prefira a referência do serviço ao nome do cliente ou ao horário, pois uma pessoa pode realizar várias ações e duas cópias podem chegar quase juntas.
O comprovante precisa continuar existindo depois que o app reiniciar. O nome técnico da coleção estruturada e duradoura de registros é banco de dados. Salve nele o serviço de origem, a referência, o horário de chegada, o estado do processamento e a ligação com o pedido ou cliente. O app deve reservar a referência antes do trabalho importante, impedindo que duas cópias simultâneas avancem. A regra simples é: o mesmo aviso deve produzir o mesmo resultado final. O nome técnico dessa regra é idempotência. Visitantes não podem ler, criar nem alterar esses comprovantes.
Um aviso pode parar no meio do trabalho. Por isso, não registre apenas “recebido” ou “pronto”. Use estados claros, como aguardando, em andamento, concluído e falhou antes da ação importante. Registre também se dinheiro, estoque, e-mail, envio ou acesso realmente mudou. Quando uma tentativa incerta voltar, o app deve consultar o estado salvo em vez de começar novamente sem pensar. Assim, é possível investigar sem guardar senhas, chaves de pagamento, códigos de acesso ou dados desnecessários de clientes nesses registros.
- ▸Use a referência estável fornecida pelo serviço que enviou o aviso.
- ▸Reserve cada referência nova antes de começar a ação importante.
- ▸Registre o resultado final para analisar interrupções com segurança.
risco comum
O app lembra as referências apenas na memória temporária. Depois de reiniciar, uma cópia atrasada chega e adiciona o mesmo crédito novamente.
o que fazer agora
Crie comprovantes duradouros e consulte cada um antes de gerar pedido, estorno, crédito, mensagem, envio ou mudança de conta.
peça isto à sua IA
Adicione processamento de uma única vez para todos os avisos automáticos externos deste app. Use o ID estável do evento enviado pelo serviço como referência única. Em uma tabela protegida do banco de dados, reserve esse ID antes de qualquer ação ligada a cliente, dinheiro, estoque, e-mail, envio ou conta. Salve origem, horário, estado, registro relacionado e resultado final. Se um ID concluído chegar novamente, envie a resposta normal de sucesso sem repetir a ação. Trate também duas cópias simultâneas e impeça visitantes de acessar esses registros.
Recuse cópias que não devem mais ser aceitas
em palavras simples
Lembrar o trabalho concluído não basta; o app também deve confirmar quem enviou o aviso e se ele ainda é recente.
Uma pessoa não deve conseguir inventar um aviso de pagamento ou cancelamento. Normalmente, o serviço inclui uma prova matemática que somente ele consegue produzir. O nome técnico dessa prova é assinatura digital. O app precisa conferi-la exatamente da forma documentada pelo serviço. A conferência deve ocorrer na parte protegida do app que funciona longe do aparelho do visitante; o nome técnico desse processo protegido é servidor. Tudo isso precisa acontecer antes de mudar dinheiro, estoque, pedidos, dados de clientes ou acesso à conta.
Para conferir a prova, o processo protegido usa uma chave de assinatura entregue pelo serviço. Trate essa chave como uma chave de pagamento ou um código de acesso. Não a coloque em páginas, arquivos de instruções, configurações públicas ou qualquer arquivo enviado ao aparelho do visitante. Confira o conteúdo original do aviso, sem alterações, porque mudar sua formatação antes da verificação pode invalidar uma prova verdadeira. Recuse avisos sem prova ou com prova inválida. Registre apenas um motivo seguro, nunca a chave, senhas, dados de pagamento, códigos de acesso ou informações completas de clientes.
Mesmo um aviso verdadeiro pode ser perigoso quando alguém guarda uma cópia antiga e tenta usá-la novamente. Confira o horário de criação e aceite somente o período curto recomendado pelo serviço. O nome técnico da recusa de cópias antigas reutilizadas é proteção contra replay. Combine essa verificação com a referência salva: a prova confirma a origem, o horário recusa cópias velhas e o comprovante impede que uma repetição recente refaça o trabalho. As três verificações devem ocorrer antes de qualquer mudança importante.
- ▸Siga exatamente as instruções oficiais de conferência fornecidas pelo serviço.
- ▸Guarde a chave de assinatura no processo protegido, longe dos arquivos enviados aos visitantes.
- ▸Recuse avisos inválidos ou antigos demais antes de mudar algo importante.
risco comum
Um aviso verdadeiro de cancelamento, criado meses atrás, é enviado novamente e retira o acesso de um cliente que já renovou.
o que fazer agora
Confirme a origem, a idade e a referência salva antes de qualquer mudança em pagamento, pedido, estoque ou conta.
peça isto à sua IA
Revise todos os lugares que recebem avisos automáticos externos. Antes de qualquer ação importante, confira no servidor a assinatura digital do remetente pelo método oficial do provedor e usando o conteúdo original do aviso, sem alterações. Recuse assinaturas ausentes ou inválidas e avisos fora do período recomendado pelo provedor. Depois, consulte o ID do evento salvo antes de agir. Mantenha chaves de assinatura fora de todos os arquivos enviados aos visitantes e não inclua senhas, chaves de pagamento, códigos de acesso, dados de pagamento nem informações de clientes nos registros de recusa.
Teste as repetições e acompanhe as mudanças
em palavras simples
A proteção só funciona de verdade quando avisos repetidos ou interrompidos continuam produzindo um único resultado final.
Use o modo inofensivo de prática oferecido pelo serviço. O nome técnico costuma ser ambiente de teste. Envie o mesmo aviso duas vezes e confirme que existe apenas um pedido, estorno, crédito, e-mail, envio ou mudança de conta. Envie também duas cópias quase ao mesmo tempo. Depois, interrompa uma tentativa de prática após salvar o comprovante. O app deve mostrar se o trabalho não começou, foi concluído, falhou ou precisa de análise cuidadosa. Não repita manualmente uma ação com dinheiro enquanto o resultado ainda estiver incerto.
Mantenha um histórico protegido de chegadas, decisões, resultados e falhas. O nome técnico desses registros é log de processamento. Eles devem conter referências e estados úteis, mas não senhas, chaves de assinatura, chaves de pagamento, códigos de acesso, dados completos de pagamento ou informações desnecessárias de clientes. Crie um alerta para falhas repetidas, provas de origem inválidas, avisos antigos demais e aumento incomum nas repetições recusadas. Confira o pedido, saldo, envio ou conta real, em vez de confiar apenas em uma mensagem de sucesso.
Repita os testes sempre que conectar outro serviço ou alterar a lógica de pagamentos, pedidos, estoque, e-mails, envios ou contas. O VibeCodeWall confere o app público por fora e pode acompanhar mudanças importantes ao longo do tempo. Ele não vê código particular nem substitui os testes feitos no processo protegido. O acompanhamento contínuo pode indicar que o app público mudou, enquanto os testes de repetição, origem, horário, interrupção e registros confirmam que cada ação importante continua acontecendo uma única vez.
- ▸Teste o mesmo exemplo duas vezes e duas cópias chegando juntas.
- ▸Confira um comprovante salvo e um único resultado real.
- ▸Repita os testes após cada nova conexão ou mudança no processamento.
risco comum
Uma mudança posterior coloca a conferência de repetição depois do pedido de envio, e cada novo aviso pode despachar outro pacote.
o que fazer agora
Execute agora todos os testes de repetição e interrupção e repita-os após cada mudança relacionada.
peça isto à sua IA
Crie e execute um plano seguro de testes para todos os lugares que recebem avisos automáticos externos. No ambiente de teste do provedor, envie o mesmo evento duas vezes, mande duas cópias quase simultâneas, teste uma assinatura inválida, teste um horário vencido e simule uma interrupção depois de reservar o comprovante. Confirme exatamente um resultado final para o cliente e mostre o registro protegido correspondente. Adicione verificações automáticas de repetição quando possível e explique o que deve ser acompanhado após mudanças futuras. Não faça cobranças reais nem exponha senhas, chaves de assinatura, chaves de pagamento, códigos de acesso, dados de pagamento ou informações de clientes.
Checklist rápido
- 01Liste os serviços externos que enviam avisos automáticos ao app.
- 02Identifique o número de referência estável de cada aviso.
- 03Salve a referência antes de iniciar uma ação importante.
- 04Interrompa com segurança uma referência que já foi concluída.
- 05Confirme que o aviso veio realmente do serviço esperado.
- 06Recuse avisos mais antigos do que o serviço recomenda.
- 07Envie duas vezes o mesmo aviso inofensivo de teste e confirme um resultado.
- 08Continue acompanhando falhas repetidas e mudanças importantes.
FAQ
Por que um serviço manda o mesmo aviso duas vezes?
Talvez ele não tenha recebido a primeira resposta do app por causa de lentidão, interrupção temporária ou perda da resposta. A segunda cópia ajuda a evitar que a atualização seja perdida.
Posso usar o número do pedido como comprovante?
Às vezes, mas a referência do aviso costuma ser mais segura. Várias atualizações podem pertencer ao mesmo pedido, como pagamento, estorno, envio e cancelamento.
O app deve informar erro quando recebe uma repetição concluída?
Em geral, deve confirmar o recebimento depois de conferir a origem, o horário e a referência salva. A ação importante não pode ser repetida.
Conferir quem enviou o aviso é suficiente?
Não. Um serviço verdadeiro também pode mandar o mesmo aviso mais de uma vez. O app ainda precisa conferir a idade do aviso e manter um registro duradouro das referências concluídas.