Cancelamento de pedido de API quando o cliente enviou um link incorreto

Primeiro verifique se o pedido foi enviado ao fornecedor

Um link incorreto nem sempre significa que a promoção já foi iniciada. No seu sistema interno, o pedido pode ter sido criado, mas ainda não enviado via API. Nesse caso, o cancelamento depende apenas da sua lógica de processamento: basta marcar o pedido como cancelado, interromper o pagamento automático e não iniciar o envio.

Verifique o identificador do pedido, a data de criação, o link, o tipo de serviço e o log de requisições da API. Se a requisição ao fornecedor não foi enviada, não crie um novo pedido sobre o antigo. Primeiro registre o cancelamento da solicitação original, caso contrário o cliente pode receber duas execuções em links diferentes.

Determine o status do pedido no fornecedor

Se a requisição de API já foi enviada, solicite o status atualizado ao fornecedor. Os nomes dos status variam, mas geralmente podem ser divididos em alguns grupos: aguardando, processando, execução parcial, concluído e cancelado. Para a decisão, o que importa não é o status no seu painel, mas a resposta de quem executa o serviço.

• Aguardando: o pedido ainda pode permitir cancelamento.
• Processando: a interrupção às vezes é possível, mas parte do volume já pode ter sido iniciada.
• Execução parcial: só é possível cancelar o restante, se o fornecedor oferecer suporte a essa operação.
• Concluído: não é mais possível corrigir o link por cancelamento.

A desvantagem de verificar apenas o status interno é que ele pode ser atualizado com atraso. Baseie-se na última resposta da API e no horário em que ela foi recebida.

Cancele o pedido antes do início do serviço

Para um pedido na fila, use o método de cancelamento, se ele estiver previsto na documentação do fornecedor. Envie o identificador recebido na criação do pedido, e não o seu número interno, se forem valores diferentes. Salve a resposta completa: código da operação, status, texto do erro e horário da requisição.

Não considere o pedido cancelado enquanto a API não confirmar o cancelamento. A resposta de aceite da solicitação e a interrupção efetiva do serviço podem ser eventos diferentes. Em algumas integrações, primeiro chega a confirmação de recebimento, e o status final muda depois.

A desvantagem dessa opção é que o fornecedor pode não conseguir retirar o pedido do processamento a tempo. Nesse caso, o cancelamento retornará uma recusa ou funcionará apenas para a parte não executada.

Não altere o link em um pedido já criado sem confirmação

Em muitas APIs, o link é fixado no momento da criação do pedido. A tentativa de enviar um novo link com o mesmo identificador pode ser ignorada, tratada como erro ou criar um estado imprevisível. Não conte com o reenvio da requisição para substituir o endereço automaticamente.

Se a documentação oferecer suporte explícito à edição do link, primeiro confirme que o serviço ainda não começou a ser executado. Depois, salve o valor antigo, o novo valor e a resposta da API. Isso será útil em uma disputa com o cliente ou com o fornecedor.

A desvantagem da edição é que, mesmo com o método disponível, parte das ações pode ter sido direcionada à página antiga antes da atualização. O link corrigido não transfere o resultado já obtido.

O que fazer em caso de execução parcial

Quando a promoção já começou no link incorreto, solicite o cancelamento do restante. Na solicitação ao fornecedor, informe o identificador do pedido, o link incorreto, o link correto, o status atual e o horário em que o erro foi detectado. Não altere os detalhes da solicitação várias vezes: isso dificulta a verificação do histórico.

Se o cancelamento do restante for confirmado, registre o volume que já foi executado. O reembolso, se estiver previsto nas regras do fornecedor, geralmente se aplica apenas à parte não executada. O volume executado não pode ser transferido tecnicamente de um canal, vídeo ou perfil para outro.

A desvantagem do cancelamento parcial é evidente: o cliente já pode ter recebido resultado na página incorreta, e o orçamento dessa parte do pedido nem sempre é devolvido.

Se o pedido estiver concluído, formalize a correção em uma solicitação separada

Um pedido concluído geralmente não pode ser cancelado via API. Nessa situação, não exclua o registro nem altere o link no histórico: os dados originais são necessários para conferência. Verifique se o serviço realmente foi prestado no endereço errado, e não se ele apenas aparece com atraso.

Depois, há dois caminhos: negociar uma compensação com o fornecedor conforme as regras dele ou criar um novo pedido para o link correto após alinhar com o cliente. O novo pedido deve ter um identificador separado, um valor e uma observação clara sobre o motivo da criação.

A desvantagem de uma nova execução é que ela exige orçamento adicional, e a compensação por um serviço concluído pode não estar disponível.

Informe o cliente sobre a situação antes de uma nova execução

Não inicie a substituição por conta própria se o link pertence ao cliente e o erro partiu dele. Envie a ele o link original, o status do pedido, a possibilidade de cancelamento e as consequências de cada opção. Isso é especialmente importante se parte do serviço já foi executada.

• Se o pedido não foi enviado, solicite o link correto e confirme o cancelamento da solicitação antiga.
• Se o pedido está na fila, informe que o cancelamento foi enviado, mas que se aguarda a resposta do fornecedor.
• Se houver execução parcial, indique que só é possível interromper o restante.
• Se o pedido estiver concluído, alinhe uma nova execução ou outra forma de solução.

A desvantagem de uma negociação longa é que, nesse meio-tempo, o pedido na fila pode passar para processamento. Por isso, primeiro envie a solicitação técnica de cancelamento, se houver essa possibilidade, e depois esclareça os próximos passos.

Salve os logs e as evidências da operação

Para cada pedido em disputa, salve o link original enviado pelo cliente, a data de recebimento, o número interno, o identificador no fornecedor, as requisições e respostas da API. Se o cliente enviou o link em uma conversa, não substitua a mensagem pela versão editada no cadastro do pedido sem preservar o original.

Registre separadamente quem detectou o erro e quando. Isso ajuda a distinguir dados enviados incorretamente de um erro do gerente, do formulário de pedido ou de um preenchimento automático. Em contatos repetidos com o fornecedor, use uma única cadeia de dados para evitar contradições.

A desvantagem de manter logs manualmente é o tempo gasto. Mas, sem histórico, fica mais difícil confirmar o status do cancelamento e explicar ao cliente por que o valor não pode ser reembolsado integralmente.

Verifique o tratamento de erros na integração

Depois de um caso como esse, verifique como o sistema envia os links para a API. O erro pode surgir não apenas por causa do cliente: às vezes o formulário corta parâmetros, insere um valor antigo do cache, aceita um link de perfil em vez de um link de publicação ou deixa passar um link com caracteres extras.

Adicione uma validação de formato antes de criar o pedido: compatibilidade com a plataforma, o tipo de serviço e o objeto esperado. Para serviços em vídeo, o sistema deve distinguir o link do vídeo do link do canal, e, para redes sociais, o perfil de uma publicação individual. A validação não garante que o link esteja correto, mas elimina parte dos erros evidentes.

É melhor separar o envio do pedido da sua criação com uma breve verificação de dados. A desvantagem da etapa adicional é que o pedido não entrará em execução instantaneamente, mas você terá tempo para perceber o endereço incorreto.

Defina um fluxo de cancelamento claro para a equipe

Descreva uma ordem única de ações: interromper o envio automático, verificar o status no fornecedor, enviar o cancelamento, salvar a resposta, informar o cliente e só então alinhar uma nova execução. Esse fluxo não é uma formalidade: ele evita que funcionários diferentes executem ações mutuamente excludentes.

Não conceda acesso ao cancelamento sem restrição de permissões e registro de ações. Se vários gerentes trabalharem no mesmo pedido ao mesmo tempo, um pode solicitar o cancelamento enquanto outro cria a substituição antes de receber a resposta. Isso gera custos extras e confusão nos cálculos.

A desvantagem de um fluxo rígido é a menor flexibilidade em casos urgentes. Mas, para pedidos de API, mais importante do que a velocidade de uma ação isolada é controlar qual link efetivamente entrou em execução.