Na hora de criar um pagamento o Body que é enviado ao back End é o PagamentoDto dto que contém o "STATUS", bom o usuário enviando um pagamento a URL e depois colocando como confirmado... isso poderia ser uma porta prejudicial?
Óbvio que poderia ser contornado pedindo como comprovante, ou alguma informação adicional vindo do Banco que processou o pagamento, mas caso seja apenas um PIX e um site que não tem essa segunda verificação, poderia dar problema, não?
Boa tarde/noite.
Quando o backend permite que o usuário envie ou altere o status do pagamento diretamente pelo body da requisição, ele está confiando em uma informação que não deveria vir do cliente. Em um cenário real, isso abre espaço para abuso: alguém poderia simplesmente criar um pagamento e marcá-lo como CONFIRMADO sem que nenhuma transação de fato tenha acontecido.
Mesmo no exemplo do PIX que você citou, em que não há uma segunda verificação automática, a responsabilidade de confirmar o pagamento ainda deveria ser do sistema, não do usuário. No máximo, o usuário informa que “pagou”, mas quem decide se o status muda ou não é o backend, com base em alguma regra, validação ou processo interno.
No curso, isso aparece dessa forma por simplicidade e fins didáticos, para facilitar os testes doCRUD. Mas em um sistema mais próximo da realidade, o fluxo seria diferente: o pagamento nasce sempre como CRIADO, e o status só muda por ações controladas, como uma confirmação vinda de outro serviço, um webhook, ou até um endpoint específico para confirmar pagamentos, que tenha validações claras.
Esse ponto que você levantou também explica por que, em muitos sistemas, não se usa um PUT genérico para alterar tudo. Às vezes faz mais sentido ter ações bem definidas, como “confirmar” ou “cancelar”, justamente para evitar que campos sensíveis fiquem livres para qualquer alteração.
Então, respondendo de forma direta: sim, do jeito que está, poderia dar problema. E perceber isso mostra que você já está pensando além do código funcionar, está pensando em regra de negócio, fluxo e segurança. É exatamente esse tipo de questionamento que aparece quando a aplicação começa a amadurecer.
Abç;