Pedir um reembolso, obter aceitação e concluir o movimento de dinheiro são estados diferentes.
Pedir um reembolso, obter aceitação e concluir o movimento de dinheiro são estados diferentes. Uma contestação tem ainda o seu próprio ciclo. Reduzir ambos a um pagamento negativo pode criar mensagens erradas, efeitos duplicados e movimentos difíceis de explicar.
Separar estados e permissões
Mantenha pagamento original, valor já devolvido, pedidos abertos e estado do prestador. Defina quem pede e quem aprova. Reembolsos parciais simultâneos precisam de um limite comum. Um tempo de espera excedido significa incerteza: consulte a operação existente antes de criar outro pedido.
Ligar finanças e produto
Decida quando acesso, entrega ou subscrição mudam de acordo com a política aceite. O resultado técnico não estabelece automaticamente essa política. Separe contestações de devoluções voluntárias e confirme restrições do prestador quando coincidirem. Proteja documentos do caso e limite o histórico aos papéis que realmente precisam dele.
Ensaiar sequências problemáticas
Teste duplo clique, notificação tardia, vários valores parciais e interrupção entre resultado externo e atualização interna. O apoio deve distinguir pendente, falhado e concluído. Reconcilie movimentos com o ledger e atribua casos incertos. A reparação deve preservar provas e acrescentar um teste de regressão. Alterar manualmente a etiqueta de estado pode deixar o problema financeiro intacto.
Um exemplo para validar
Um cliente recebe uma devolução parcial enquanto outra permanece aberta. Uma nova ação não pode ultrapassar o limite conjunto. Faça chegar tarde a resposta original e confirme associação ao caso existente. A aceitação inclui total realmente devolvido, valor pendente e consequência no produto. Apoio e finanças devem explicar o mesmo histórico através da referência. Um total correto por acaso não chega se o ecrã apresenta estados contraditórios ou permite repetir uma operação já concluída. Guarde esse exemplo como verificação da correção entregue.
- Serviço relacionado
- Auditar pagamentos: cobranças duplicadas e operações em falta
- Idempotência de webhooks: impedir efeitos de pagamento duplicados
Perguntas frequentes
Um pedido aceite já terminou?
Não. O prestador pode ainda executar processamento assíncrono.
Um timeout permite criar outro pedido?
Não sem verificar o estado da tentativa original.
Contestação e reembolso são equivalentes?
Não. Regras, estados e consequências financeiras diferem.
O acesso deve terminar imediatamente?
Aplique a política acordada através de uma transição explícita e testada.
O que precisa o apoio?
Referência, valor, estado, atualização recente, ações permitidas e escalamento.
Da ideia a um âmbito que se consegue executar
Partilhe o percurso do utilizador, integrações e condições de lançamento. Podemos preparar uma estimativa com pressupostos e exclusões.
Leitura complementar
Auditar pagamentos: cobranças duplicadas e operações em falta
Uma página de confirmação não prova que o pagamento foi tratado de ponta a ponta.
Idempotência de webhooks: impedir efeitos de pagamento duplicados
A idempotência garante o efeito pretendido de uma operação lógica mesmo quando a entrega ou execução se repete.
Reconciliação de pagamentos: explicar cada diferença
A reconciliação compara registos da mesma atividade económica e explica as diferenças.