Cancelamento

Cancelar pelo ERP

POST /v1/Orders/{orderNumber}/cancel


curl -X POST $GROCERS_API/v1/Orders/104821/cancel \
  -H "Authorization: Basic $BASIC" \
  -H "x-contractAccountId: $TENANT"

Resposta:


{
  "operationId": "7f3a1b2c-4d5e-4f60-8a71-9b0c1d2e3f40",
  "message": "Pedido enviado para cancelamento"
}

O cancelamento é assíncrono. O 200 confirma que a chamada foi aceita e enfileirada, não que o pedido já está cancelado.

Cancelar não leva direto a ORDER_CANCELLED (800). Quando a forma de pagamento exige estorno prévio, o pedido para em ORDER_CANCELLATION_ANALYSIS (750) e só depois avança. O estorno passa por REFUND_IN_PROGRESS e termina em REFUND_COMPLETED. Trate 750 como cancelamento em andamento, não como falha — e não retente. O prazo de crédito na fatura do cliente é do emissor do cartão, não da plataforma.

Quando o cliente pede cancelamento

Não existe fila de “cancelamento solicitado” para o ERP decidir. O cancelamento pelo app é auto-serviço e a plataforma o executa sozinha, sem consultar você — mas só dentro de uma janela estreita. Fora dela, o app recusa a solicitação e o cliente é direcionado ao atendimento.

As três condições precisam valer ao mesmo tempo para o cliente conseguir cancelar pelo app:

Condição	Regra
Status	`ORDER_CREATED` (100) ou `PAYMENT_PENDING` (200) — ou seja, antes de `PAYMENT_APPROVED`
Modalidade	apenas entrega agendada; expressa e retirada não permitem
Prazo	até 15 minutos após a criação do registro do pedido — que nasce como carrinho, não no checkout

Falhas

O evento Order_CancelFailed (132) chega quando o cancelamento não pôde ser processado. Causas típicas:

Causa	O que fazer
Pedido já cancelado	nada — confira o status antes de retentar
Pedido já entregue	cancelamento não se aplica; o caminho é devolução