Nesta seção, apresentaremos descrição detalhada das Entidades, Eventos, Payloads e da REST API utilizada no desenvolvimento desta integração. É importante que você tenha uma compreensão completa dos componentes fundamentais que compõem essa integração, possibilitando uma implementação bem-sucedida.A Plataforma de Negociação para Pedidos é uma ferramenta destinada a facilitar, gerenciar e agilizar negociações entre duas partes, com o propósito de resolver questões relacionadas a PEDIDOS. Ela atua como intermediária e possibilita uma comunicação eficaz entre as partes envolvidas, permitindo a troca de propostas e facilitando a busca por acordos de forma eficaz.
Cenários
Cancelamento de Pedidos
Durante o processo de cancelamento de um pedido, em vez de apenas cancelar o pedido, a plataforma inicia uma negociação entre o Cliente e o Parceiro.Nessa negociação, o Cliente expressa a sua intenção de cancelar o pedido e a Plataforma de Negociação envia um evento para o Parceiro.Em seguida, o Parceiro tem a oportunidade de avaliar a situação e se o cancelamento é justificado. Para isso, a Plataforma de Negociação disponibiliza endpoints específicos, nos quais o Parceiro pode aceitar o cancelamento, recusar o cancelamento ou oferecer uma contraproposta, tomando uma decisão com base na negociação realizada.Atores:
Parceiro
Cliente
Reenvio de Itens - Experimental para alguns clientes - Em breve
Após receber o pedido, caso o cliente perceba que um ou mais itens não foram enviados, ele dá início a um processo de solicitação de reenvio por meio da Plataforma de Negociação para pedidos, o que dá início a uma interação entre o Cliente e o Parceiro. Nessa interação, o Cliente comunica sua intenção de receber os itens faltantes, e a Plataforma de Negociação envia um evento ao Parceiro. O Parceiro, por sua vez, tem a oportunidade de avaliar a situação e decidir se reenviar os itens é a melhor solução. Para esse fim, a Plataforma de Negociação oferece endpoints de acesso específicos, nos quais o Parceiro pode aceitar o reenvio dos itens, rejeitar o reenvio dos itens ou oferecer uma contraproposta. Essa decisão é tomada com base na negociação conduzida.Atores:
Parceiro
Cliente
Guia rápido para integração
Nesta seção descrevemos os passos essenciais que devem ser seguidos para que a integração seja bem sucedida. Todos os componentes mencionados neste guia são detalhados no decorrer da documentação.Certifique-se de implementar a lógica adequada para lidar com esses eventos e suas respectivas ações, garantindo que a integração ocorra de forma correta e eficiente.
Passo 1 - Mapeando as entidadesMapeie as entidades HandshakeDispute, HandshakeSettlement, DisputeAlternative, SelectedDisputeAlternative, Media, Item, GarnishItem e Amount.Passo 2 - Consumindo os EventosAtravés do mecanismo de polling, implemente o consumo dos eventos HANDSHAKE_DISPUTE e HANDSHAKE_SETTLEMENT. Essa funcionalidade permitirá receber notificações sobre Disputes e decisões tomadas durante a negociação. As entidades previamente mapeadas são utilizadas nesses eventos.Passo 3 - Integrando com a RESTAPIDesenvolva a integração dos endpoints /accept, /reject e /alternative, que são responsáveis por responder as Disputas representadas pelo evento HANDSHAKE_DISPUTE. Esses endpoints serão fundamentais para o gerenciamento e tomada de decisões relacionadas às Disputes.Passo 4 - Processando o evento HANDSHAKE_DISPUTEPara cada evento HANDSHAKE_DISPUTE recebido é obrigatório que ele seja respondido por algum endpoint fornecido. Essa ação pode ser ACEITAR, REJEITAR ou (REALIZAR CONTRAPROPOSTA).O endpoint /alternative deve ser utilizado apenas para os fluxos que incluem a contraproposta. Essa situação é devidamente documentada ao longo deste documentoSe o evento HANDSHAKE_DISPUTE não for respondido dentro do tempo especificado, a Plataforma de Negociação responderá automaticamente. O mecanismo de Timeout está devidamente documentado ao longo desta documentação.Uma vez que o HANDSHAKE_DISPUTE tenha sido respondido por algum endpoint disponível, não é possível responder novamente.Recomenda-se fortemente evitar a automatização das decisões de aceitação ou recusa das negociações. A automatização desse processo pode acarretar em uma experiência negativa para o cliente e causar prejuízos financeiros.É crucial analisar cada negociação de forma individual, levando em consideração as circunstâncias específicas, e tomar uma decisão adequada com base nas políticas e diretrizes estabelecidas.Passo 5 - Processando o evento HANDSHAKE_SETTLEMENTPara cada evento HANDSHAKE_SETTLEMENT recebido, não é esperada nenhuma ação adicional. No entanto, esse evento sinaliza que o evento HANDSHAKE_DISPUTE foi devidamente respondido e processado pela plataforma.
Entidades e Atributos
A seguir, apresentamos detalhes sobre as entidades e constantes que são utilizadas nos payloads dos eventos e na REST API.Entidades
HandshakeDispute
HandshakeSettlement
DisputeAlternative
SelectedDisputeAlternative
Media
Item
GarnishItem
Amount
Constantes
handshakeType
handshakeGroup
action
timeoutAction
status
type
negotiationReasons
Iniciamos com a descrição das entidades principais:
HandshakeDispute
HandshakeSettlement
Em seguida, detalhamos as entidades que compõem as entidades principais:
DisputeAlternative
SelectedDisputeAlternative
Media
Item
GarnishItem
Amount
E finalmente, são detalhadas as constantes que serão empregadas durante o fluxo:HandshakeDispute
handshakeType
handshakeGroup
timeoutAction
action
HandshakeSettlement
status
DisputeAlternative
type
Cada atributo é acompanhado de uma breve explicação sobre seu propósito, o tipo de dado suportado e se o atributo é obrigatório ou opcional.Para as constantes, são listados os possíveis valores disponíveis e uma breve explicação sobre seu propósito.É fundamental ressaltar que a inclusão de campos não obrigatórios se justifica pelo fato de serem utilizados somente em fluxos específicos, os quais serão devidamente explorados ao longo deste documento.
Entidades
HandshakeDispute
A entidade HandshakeDispute é utilizada no evento HANDSHAKE_DISPUTE que contém informações essenciais sobre a negociação em execução, por exemplo, o tipo do handshake (handshakeType), agrupamento do handshake (handshakeGroup), o propósito da Dispute (action), as evidências (evidences) e comentários (message) enviados pelo consumidor, o tempo máximo para responder ao evento (expiresAt) e a ação a ser tomada em caso de expiração do tempo de resposta (timeoutAction).Quando a negociação em execução contemplar a funcionalidade de Proposta de Reembolso, também são fornecidos atributos adicionais, como o DisputeAlternative.Nas negociações relacionadas a Solicitação de Cancelamento Parcial, são enviados os atributos Items (Item) e/ou GarnishItems (GarnishItem) que detalham os produtos que fazem parte da solicitação.Campos ObrigatóriosOs campos que não são obrigatórios são utilizados apenas em fluxos específicos. No decorrer da documentação é possível visualizar através de exemplos quando e como esses atributos são recebidos.
Atributo
Descrição
Tipo
Valores
Obrigatório
id
Id da Dispute
uuid
-
sim
parentDisputeId
Id da Dispute que originou uma contraproposta Por exemplo, no fluxo de Proposta de Reembolso
uuid
-
não
action
Ação que a Dispute representa, qual o objetivo da negociação
String
CANCELLATION, PARTIAL_CANCELLATION, PROPOSED_AMOUNT_REFUND, PROPOSED_ADDITIONAL_TIME ou VOID
sim
message
Mensagem associada à razão da Dispute (negociação). Para os fluxos de cancelamento, representa a justificativa de cancelamento informada pelo consumidor
String
-
sim
alternatives
Respostas alternativas que estão disponíveis, além do aceite/rejeite da Dispute. Contém as informações que podem ser enviadas no fluxo de proposta de reembolso, por exemplo.
List of DisputeAlternative
-
não
expiresAt
Tempo máximo para que a negociação seja respondida antes que a ação automática seja disparada automaticamente.
DateTime
-
sim
createdAt
Data e Hora de criação da Dispute
DateTime
-
sim
handshakeType
Tipo da negociação que foi iniciada
String
AFTER_DELIVERY, DELAY, PREPARATION_TIME ou AFTER_DELIVERY_PARTIALLY
sim
handshakeGroup
Agrupamento do handshake.
String
CUSTOMER_ORDER_SUPPORT
sim
timeoutAction
Ação automática a ser executada caso o Handshake não seja respondido dentro do prazo determinado pelo expiresAt.
String
ACCEPT_CANCELLATION, REJECT_CANCELLATION ou VOID
sim
metadata.item
Contém a lista de itens que podem ser cancelados no fluxo de Cancelamento Parcial. Em Disputes com a action PARTIAL_CANCELLATION.
List of Item
-
não
metadata.garnishItems
Contém a lista de sub itens que podem ser cancelados no fluxo de Cancelamento Parcial. Em Disputes com a action PARTIAL_CANCELLATION.
List of GarnishItem
-
não
metadata.evidences
Mídias enviadas pelo consumidor no momento da abertura do cancelamento. Actions CANCELLATION e PARTIAL_CANCELLATION.
List of Media
-
não
metadata.acceptCancellationReasons
Lista de strings com possíveis motivos do porque a loja aceitou o cancelamento solicitado pelo cliente.
A entidade HandshakeSettlement é utilizada no evento HANDSHAKE_SETTLEMENT contém informações relevantes sobre a Dispute que foi respondida, com o ID da Dispute (id), o status de solução da Dispute (status) e a razão da rejeição da Dispute, caso aplicável (reason).Quando o fluxo inclui a funcionalidade de Proposta de Reembolso, também são fornecidos atributos adicionais, como o SelectedDisputeAlternative.Campos ObrigatóriosOs campos que não são obrigatórios são utilizados apenas em fluxos específicos. No decorrer da documentação é possível visualizar através de exemplos quando e como esses atributos são recebidos.
Atributo
Descrição
Tipo
Valores
Obrigatório
id
Id do Settlement gerado
uuid
-
sim
disputeId
Id da Dispute
uuid
-
sim
status
Representa o resultado final da negociação relacionada a uma Dispute (disputeId)
String
ACCEPTED, REJECTED, EXPIRED ou ALTERNATIVE_REPLIED
sim
reason
Representa a justificativa de rejeição ou aceite de uma determinada negociação. Em casos de Disputes relacionadas à solicitação de cancelamento, o campo é obrigatório quando o status for REJECTED.
String
-
não
selectedDisputeAlternative
Representa os dados enviados durante a resposta de uma Dispute com status ALTERNATIVE_REPLIED. Por exemplo durante a execução do fluxo de Proposta de Reembolso.
SelectedDisputeAlternative
-
não
DisputeAlternative
A entidade DisputeAlternative é utilizada em conjunto com a Entidade HandshakeDispute, sendo enviada quando a Dispute, por exemplo, está relacionada a uma negociação que possui a funcionalidade de Proposta de Reembolso.
Atributo
Descrição
Tipo
Valores
Obrigatório
id
Id da DisputeAlternative que deve ser utilizada para responder uma determinada Dispute Por exemplo durante a execução do fluxo de Proposta de Reembolso.
uuid
sim
type
Ação que pode ser executada após a finalização da negociação.
String
REFUND, BENEFIT ou ADDITIONAL_TIME
sim
metadata.maxAmount
Valor monetário máximo possível para ser enviado na resposta de uma determinada Dispute. Por exemplo durante a execução do fluxo de Proposta de Reembolso, quando o parceiro tem a opção de enviar um valor monetário de até 80% do valor do pedido para evitar o cancelamento
Amount
Obrigatório apenas quando o type for REFUND ou BENEFIT
metadata.allowedsAdditionalTimeInMinutes
Lista com valores numéricos que o parceiro possa escolher quanto tempo a mais ele precisa para entregar o pedido. Por exemplo durante a execução do fluxo de negociação de atraso, quando o parceiro tem a opção de pedir que o cliente espere por mais X minutos para o pedido ser entregue.
List of Int
Obrigatório apenas quando o type for ADDITIONAL_TIME
metadata.allowedsAdditionalTimeReasons
Lista de motivos do atraso na entrega do pedido que a loja deve informar quando quiser negociar um novo tempo de entrega.
Obrigatório apenas quando o type for ADDITIONAL_TIME
SelectedDisputeAlternative
A entidade SelectedDisputeAlternative é utilizada em conjunto com a entidade HandshakeSettlement send enviada quando a Dispute foi respondida com ALTERNATIVE_REPLIED. Representa o tipo e contém os metadados relevantes da contraproposta enviada.
Atributo
Descrição
Tipo
Valores
Obrigatório
id
Id da DisputeAlternative selecionada da Dispute com opções de contraproposta.
uuid
sim
type
Tipo da DisputeAlternative selecionada durante a resposta da Dispute.
String
REFUND ou BENEFIT
sim
metadata.amount
Valor monetário enviado na contraproposta. Por exemplo durante a execução do fluxo de Proposta de Reembolso, quando o parceiro envia um valor monetário de até 80%do valor do pedido para evitar o cancelamento.
Amount
Obrigatório apenas quando o type for REFUND ou BENEFIT
metadata.allowedsAdditionalTimeInMinutes
Lista com valores numéricos que o parceiro possa escolher quanto tempo a mais ele precisa para entregar o pedido. Por exemplo durante a execução do fluxo de negociação de atraso, quando o parceiro tem a opção de pedir que o cliente espere por mais X minutos para o pedido ser entregue.
List of Int
Obrigatório apenas quando o type for ADDITIONAL_TIME
metadata.allowedsAdditionalTimeReasons
Lista de motivos do atraso na entrega do pedido que a loja deve informar quando quiser negociar um novo tempo de entrega.
Obrigatório apenas quando o type for ADDITIONAL_TIME
Media
A entidade Media é utilizada em conjunto com a entidade HandshakeDispute e contém as mídias enviadas pelo consumidor.
Atributo
Descrição
Tipo
Obrigatório
url
url da mídia enviada enviada pelo consumidor
String
sim
contentType
Tipo da mídia enviada
String
sim
AtençãoPara efetuar a requisição na URL retornada na variável do objeto Media, é indispensável estar autenticado.
Item
A entidade Item é utilizada em conjunto com a entidade HandshakeDispute e contém informações dos Itens que estão sendo cancelados, por exemplo, durante a execução do fluxo de Solicitação de Cancelamento Parcial.
Atributo
Descrição
Tipo
Obrigatório
id
Id do catálogo
UUID
sim
uniqueId
Id único do item na order
UUID
sim
externalCode
Id do item na integradora
String
sim
quantity
Quantidade de itens
int
sim
index
Index na bag
int
sim
amount
Valor unitário do item
Amount
sim
reason
Justificativa do consumidor para cancelar o item em questão. Por exemplo: Produto chegou diferente do solicitado.
String
não
GarnishItem
A entidade GarnishItem entidade é utilizada em conjunto com a entidade HandshakeDispute e contém informações dos GarnishItems que estão sendo cancelados, por exemplo, durante a execução do fluxo de Solicitação de Cancelamento Parcial.
Atributo
Descrição
Tipo
Obrigatório
id
Id do catálogo
UUID
sim
parentUniqueId
Unique id do item pai
UUID
sim
externalCode
Id do garnish item na integradora
String
sim
quantity
Quantidade de garnishItems que estão sendo cancelados
int
sim
index
Index na bag
int
sim
amount
Valor unitário do garnish item
Amount
sim
reason
Justificativa do consumidor para cancelar o item em questão. Por exemplo: Não chegou o refrigerante do combo.
String
não
Amount
A entidade Amount é utilizada em conjunto com as entidades DisputeAlternative e SelectedDisputeAlternative, e contém o valor e a unidade monetária
Atributo
Descrição
Tipo
Obrigatório
value
Valor monetário inserido sem casas decimais baseado na currency. Por exemplo: R$ 0, 99 = 99 R$ 1, 00 = 100 R$ 13, 99 = 1399
String
sim
currency
Unidade monetária utilizada. Para pedidos realizados em Real o valor enviado é BRL
A seguir, apresentamos os valores possíveis para os atributos da entidade HandshakeDispute: handshakeType, handshakeGroup, action e timeoutAction. Além disso, também detalhamos os atributos status presente na entidade HandshakeSettlement e type presente nas entidades DisputeAlternative e DisputeSelectedAlternative.
handshakeType
Identifica qual é o tipo de do handshake. Presente na entidade HandshakeDispute.
Valor
Descrição
AFTER_DELIVERY
Representa uma Negociação para uma solicitação de cancelamento após entrega
DELAY
Representa uma Negociação para uma solicitação de cancelamento de um pedido em atraso na entrega
PREPARATION_TIME
Representa uma Negociação para uma solicitação de cancelamento de um pedido que está em preparo pelo parceiro
AFTER_DELIVERY_PARTIALLY
Representa uma Negociação para uma solicitação de cancelamento parcial após entrega
handshakeGroup
Classifica o handshake em um grupo. Presente na entidade HandshakeDispute.
Valor
Descrição
CUSTOMER_ORDER_SUPPORT
Sinaliza que que a negociação é devido a uma solicitação do cliente.
action
Identifica o tipo de ação que está sendo negociado na Dispute. Presente na entidade HandshakeDispute.
Valor
Descrição
CANCELLATION
Sinaliza que a negociação trata-se de uma Solicitação de Cancelamento Total
PARTIAL_CANCELLATION
Sinaliza que a negociação trata-se de uma Solicitação de Cancelamento Parcial
PROPOSED_AMOUNT_REFUND
Sinaliza que a negociação trata-se de uma Solicitação de Cancelamento com possibilidade de realizar uma Proposta de Reembolso.
timeoutAction
Identifica a ação automática que será executada em caso de expiração do tempo de resposta do handshake. O tempo de expiração é definido no atributo expiresAt e ambos estão na entidade HandshakeDispute.
Valor
Ação
ACCEPT_CANCELLATION
Irá efetivar o cancelamento do pedido
REJECT_CANCELLATION
Não irá efetivar o cancelamento do pedido
VOID
Não possui nenhuma ação automática
status
Identifica o status da negociação. Presente na entidade HandshakeSettlement.
Valor
Descrição
ACCEPTED
Indica que a Dispute foi aceita
REJECTED
Indica que a Dispute foi rejeitada
EXPIRED
Indica que a Dispute excedeu o tempo máximo para resposta e foi automaticamente respondida
ALTERNATIVE_REPLIED
Indica que a Dispute foi respondida com sucesso para um fluxo que contém contraproposta. Por exemplo, no fluxo de Proposta de Reembolso.
type
Identifica o tipo do artefato que poderá ser ofertado em uma contraproposta. Presente nas entidades DisputeAlternative e SelectedDisputeAlternative.
Valor
Descrição
REFUND
Indica que será enviado um valor monetário como proposta de reembolso.
BENEFIT
Trata-se de um benefício (voucher ou desconto) que será oferecido ao cliente, a ser utilizado em compras futuras.
negotiationReasons
Lista com motivos padronizados que a loja pode escolher com o intuito de informar o porquê aceitou, recusou ou enviou uma contraproposta ao cancelamento solicitado pelo cliente.
Valor
Descrição
HIGH_STORE_DEMAND
Alta demanda na loja.
STORE_SYSTEM_ISSUES
Problemas de sistema na loja.
LACK_OF_DRIVERS
Falta de entregadores.
OPERATIONAL_ISSUES
Problemas operacionais.
ORDER_OUT_FOR_DELIVERY
Pedido saiu para entrega.
DRIVER_IS_ALREADY_AT_THE_ADDRESS
Entregador já está no endereço.
OTHER_REASONS
Outros motivos.
Eventos - Payload
Nesta seção, fornecemos informações detalhadas sobre os eventos HANDSHAKE_DISPUTE e HANDSHAKE_SETTLEMENT, que fazem parte do processo de negociação.Os payloads apresentados nesta seção contém todos os atributos possíveis, garantindo uma visão completa da sua estrutura, incluindo aqueles que não são obrigatórios sendo aplicáveis apenas em fluxos específicos.Ao longo da documentação, cada fluxo será detalhado com o payload exato que será propagado. Essa abordagem possibilitará uma compreensão clara do funcionamento de cada evento durante o processo de negociação.Para obter mais informações sobre os atributos, consulte a seção Entidades e Atributos.
HANDSHAKE_DISPUTE
O evento HANDSHAKE_DISPUTE indica que uma proposta foi realizada e que obrigatoriamente deve ser respondida.Para responder ao evento HANDSHAKE_DISPUTE, é fundamental utilizar os endpoints accept, reject ou alternative para indicar a decisão sobre a proposta em negociação. Essas opções permitem expressar se a proposta será aceita, rejeitada ou se será apresentada uma contraproposta.Caso um evento HANDSHAKE_DISPUTE não seja respondido por interação humana num prazo previamente determinado, ele será automaticamente respondido pela Plataforma de Negociação. Para obter maiores detalhes sobre a resposta automática em caso de timeout, consulte a seção Timeout.Os endpoints mencionados anteriormente serão detalhados ao longo da documentação.
O evento HANDSHAKE_SETTLEMENT sinaliza e formaliza que uma proposta foi respondida anteriormente através dos endpoints accept, reject ou alternativeEste evento contém informações sobre o status da Dispute.
{"id":"8290e4ac-8814-46d9-bf38-42d500ce933d", "orderId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "code":"HSS", "fullcode":"HANDSHAKE_SETTLEMENT", "merchantId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "createdAt":"2023-06-23T13:09:06.287636Z", "receivedAt":"2023-06-23T13:09:06.287636Z", "metadata":{"disputeId":"5166ded9-bdee-4440-8c73-b5488e8b1f83", "status":"REJECTED", "reason":"Razão por não aceitar a proposta", "selectedDisputeAlternative":{"id":"2d35d0b9-67ae-46d2-8261-f0a40e5d07fd", "type":"REFUND", "metadata":{"amount":{"value":"1500", "currency":"BRL" } } }, "createdAt":"2023-06-23T13:06:50.448434Z" }}
REST API
Nesta seção, fornecemos informações detalhadas sobre a implementação da API REST da Plataforma de Negociação. Esta API segue os princípios da arquitetura REST, que permite a comunicação entre sistemas por meio de solicitações HTTP, seguindo uma abordagem baseada em recursos e utilizando os verbos HTTP (GET, POST) para realizar as operações.Os desenvolvedores podem acessar os endpoints através de URLs específicas, enviar solicitações e receber respostas no formato JSON.É importante seguir a documentação da API para montar as solicitações corretas e interpretar as respostas.
Aceitar proposta
Este endpoint permite ACEITAR uma Dispute recebida. Essa Dispute é representada pelo evento HANDSHAKE_DISPUTE.Ao enviar uma solicitação para este endpoint, o sistema processará a resposta e realizará as ações correspondentes relacionadas ao processo de handshake. É necessário fornecer o ID correto da Dispute para associar a resposta a negociação desejada.
URL
POST order/v1.0/disputes/{disputeId}/acceptBodySomente é necessário enviar este payload no body da requisição quando no evento HANDSHAKE_DISPUTE for recebido o metadado metadata.acceptCancellationReasons.
{"reason":"HIGH_STORE_DEMAND", "detailReason":"Apenas se quiser detalhar o motivo de aceitar o cancelamento"}
Descrição dos parâmetros
Atributo
Descrição
Tipo
disputeId
O parâmetro "disputeId" representa o identificador único da Dispute que está sendo respondida. É um valor exclusivo atribuído a cada Negociação no sistema
uuid
Descrição dos atributos do corpo da mensagem
Atributo
Descrição
Tipo
Tamanho
Obrigatório
reason
Este campo é utilizado para fornecer a razão pela qual o cancelamento do pedido foi aceito. Ele deve ser preenchido com uma constante que vem no metadado metadata.acceptCancellationReasons do evento HANDSHAKE_DISPUTE.
String
-
Apenas quando o metadado metadata.acceptCancellationReasons estiver presente no evento HANDSHAKE_DISPUTE
detailReason
Ele deve ser preenchido com uma explicação clara e específica sobre o motivo pelo qual o cancelamento foi aceito pela loja.
String
250 Caracteres
não
Código de Status
Quando é feita uma solicitação à API da Plataforma de Negociação, a resposta recebida incluirá códigos de status que indicam o que está acontecendo do lado do servidor. Nesta seção é possível visualizar os códigos de status que encontrará nas respostas, juntamente com o significado de cada um deles.
Response Success
1 - A requisição foi processada com sucesso
HTTP Status
Descrição
201 Created
É retornado quando o processamento foi realizado com sucesso.
É retornado quando cliente não está autenticado/autorizado
O cliente não está devidamente autenticado/autorizado
2 - Dispute não foi encontrada
HTTP Status
Descrição
Causa
404 Not Found
É retornada quando a Dispute não foi encontrada.
O ID da Dispute fornecido não corresponde a nenhuma Dispute existente no sistema
Body
{"code":"DISPUTE_NOT_FOUND", "message":"Dispute with ID {} was not found"}
3 - Dispute já foi processada
HTTP Status
Descrição
Causa
422 Unprocesssable Entity
É retornada quando a Dispute já foi respondida anteriormente.
Uma resposta já foi enviada para a Dispute e não é possível enviar outra resposta
Body
{"code":"DISPUTE_ALREADY_ANSWERED", "message":"Dispute with ID {} has already been answered"}
4 - Handshake já foi concluído
HTTP Status
Descrição
Causa
422 Unprocesssable Entity
É retornada quando o handshake já está concluído.
O Handshake do ID da Dispute informada já foi finalizado e não é possível repetir o processo
Body
{"code":"HANDSHAKE_ALREADY_CONCLUDED", "message":"Handshake with ID {} and _Dispute_ ID {} has already been concluded"}
5 - Motivo de cancelamento inexistente ou inválido
HTTP Status
Descrição
Causa
400 Bad Request
É retornada quando existe a necessidade de enviar o motivo que a loja está aceitando o cancelamento.
O valor reason deve ser enviado no body da request com o valor contido no metadado metadata.acceptCancellationReasons do evento HANDSHAKE_DISPUTE. Vale lembrar que esse campo somente é obrigatório se, somente se, o metadado metadata.acceptCancellationReasons estive no evento do evento HANDSHAKE_DISPUTE.
Body
{"code":"INVALID_CANCELLATION_REASON", "message":"_Dispute_ ID {} requires a valid reason to cancel the order"}
Rejeitar proposta
Este endpoint permite REJEITAR uma Dispute recebida. Essa Dispute é representada pelo evento HANDSHAKE_DISPUTE.Ao enviar uma solicitação para este endpoint com o motivo da rejeição, o sistema processará a resposta e realizará as ações correspondentes relacionadas ao processo de handshake.
URL
POST order/v1.0/disputes/{disputeId}/reject Body
{"reason":"Justificativa da Proposta ser rejeitada"}
É fundamental observar que o campo reason deve ser obrigatoriamente incluído ao fazer essa requisição. Caso esse campo seja omitido, a requisição resultará em uma exceção adequada, contendo uma mensagem de erro explicativa juntamente com o código correspondente.Descrição dos parâmetros
Atributo
Descrição
Tipo
disputeId
O parâmetro "disputeId" representa o identificador único da Dispute que está sendo respondida. É um valor exclusivo atribuído a cada Negociação no sistema
uuid
Descrição dos atributos do corpo da mensagem
Atributo
Descrição
Tipo
Tamanho
Obrigatório
reason
Este campo é utilizado para fornecer a razão pela qual o cancelamento do pedido não pode ser aceito. Ele deve ser preenchido com uma explicação clara e específica sobre os motivos pelos quais o cancelamento não pode ser realizado.
String
250 Caracteres
Sim
Códigos de Status
Quando é feita uma solicitação à API da Plataforma de Negociação, a resposta recebida incluirá códigos de status que indicam o que está acontecendo do lado do servidor. Nesta seção é possível visualizar os códigos de status que encontrará nas respostas da API da Plataforma de Negociação, juntamente com o significado de cada um deles.
Response Success
1 - A requisição foi processada com sucesso
HTTP Status
Descrição
201 Created
É retornado quando o processamento foi realizado com sucesso.
Body
{"id":"adee6f8d-7112-4d12-b2e8-5ddf01c11a37", "status":"REJECTED", "reason":"Justificativa para rejeitar a proposta", "disputeId":"63ddd317-90fd-43ad-830c-532f9848b7f8", "createdAt":"2023-06-23T13:29:49.218951237Z"}
Descrição dos atributos
Atributo
Descrição
Tipo
id
Identificador único do retorno do endpoint dispute/accept. É representado por uma sequência de caracteres alfanuméricos.
UUID
status
O status da Dispute após a solicitação feita ao endpoint dispute/accept será atualizado para "REJECTED", indicando que a Dispute foi aceita com sucesso. Esse valor "REJECTED" serve como confirmação de que a Dispute foi processada e aceita pelo sistema.
String
reason
Descrição do motivo da recusa do cancelamento
String
disputeId
Identificador único da Dispute associado ao retorno do endpoint dispute/accept. É uma sequência de caracteres alfanuméricos que identifica uma Dispute específica, por exemplo, "63ddd317-90fd-43ad-830c-532f9848b7f8".
UUID
createdAt
O campo "createdAt" indica a data e horário exatos em que a ação foi processada.
DateTime
Response Failure
1 - Não autorizado
HTTP Status
Descrição
Causa
401 Unauthorized
É retornado quando cliente não está autenticado/autorizado
O cliente não está devidamente autenticado/autorizado
2 - Campos obrigatórios não foram enviados
HTTP Status
Descrição
Causa
400 Bad Request
É retornada quando os campos obrigatórios não são enviados na solicitação da Dispute.
Campos obrigatórios não foram foram preenchidos.
Body
{"code":"DISPUTE_REQUIRED_FIELDS_WERE_NOT_SENT", "message":"The request is missing the required field, \"reason\" that needs to be included"}
3 - Campo reason possui mais caracteres que o permitido
HTTP Status
Descrição
Causa
400 Bad Request
É retornada quando a justificativa do parceiro na Dispute é muito longa e ultrapassa o limite definido.
A justificativa fornecida pelo parceiro excede o limite de caracteres definido
Body
{"code":"DISPUTE_FIELD_EXCEEDS_MAXIMUM_LENGTH", "message":"The \"reason\" field exceeds the maximum allowed length. Please ensure that the field does not exceed 250 characters"}
4 - Dispute não foi encontrada
HTTP Status
Descrição
Causa
404 Not Found
É retornada quando a Dispute não foi encontrada
O ID da Dispute fornecido não corresponde a nenhuma Dispute existente no sistema
Body
{"code":"DISPUTE_NOT_FOUND", "message":"Dispute with ID {} was not found"}
5 - Dispute já foi processada
HTTP Status
Descrição
Causa
422 Unprocesssable Entity
É retornada quando a Dispute já foi respondida anteriormente.
Uma resposta já foi enviada para a Dispute e não é possível enviar outra resposta
Body
{"code":"DISPUTE_ALREADY_ANSWERED", "message":"Dispute with ID {} has already been answered"}
6 - Handshake já foi concluído
HTTP Status
Descrição
Causa
422 Unprocesssable Entity
É retornada quando o handshake já está concluído.
O Handshake do ID da Dispute informada já foi finalizado e não é possível repetir o processo.
Body
{"code":"HANDSHAKE_ALREADY_CONCLUDED", "message":"Handshake with ID {} and _Dispute_ ID {} has already been concluded"}
Realizar Contraproposta
Este endpoint permite REALIZAR UMA CONTRAPROPOSTA para uma Dispute recebida. Essa Dispute é representada pelo evento HANDSHAKE_DISPUTE.Ao enviar uma solicitação para este endpoint, o sistema processará a resposta e realizará as ações correspondentes relacionadas ao processo.
URL
POST order/v1.0/disputes/{disputeId}/alternatives/{alternativeId}Body - REFUND
O parâmetro "disputeId" representa o identificador único da Negociação que está sendo respondida. É um valor exclusivo atribuído a cada Negociação no sistema
uuid
alternativeId
O campo "id" representa o identificador único da alternativa que está sendo respondida. É um valor exclusivo atribuído a cada DisputeAlternative no sistema. Ao utilizar este campo, você deve fornecer o ID correto em questão para garantir que sua resposta esteja associada à Dispute correta. Certifique-se de incluir o valor adequado para este campo ao enviar sua resposta para a API
uuid
Descrição dos atributos
Atributo
Descrição
Tipo
Valores
type
Descreve o tipo da Alternativa que está sendo respondida.
String
REFUND, BENEFIT ou ADDITIONAL_TIME
metadata.amount
Atributo responsável pelas informações do valor e da unidade monetária que serão enviados na contraproposta.
Amount
metadata.additionalTimeInMinutes
Atributo responsável por informar o tempo de atraso até a entrega que o restaurante deseja negociar junto ao cliente.
Quando é feita uma solicitação à API da Plataforma de Negociação, a resposta recebida incluirá códigos de status que indicam o que está acontecendo do lado do servidor. Nesta seção é possível visualizar os códigos de status que encontrará nas respostas da API da Plataforma de Negociação, juntamente com o significado de cada um deles.
Response Success
1 - A requisição foi processada com sucesso
HTTP Status
Descrição
201 Created
É retornado quando o processamento foi realizado com sucesso.
É retornado quando cliente não está autenticado/autorizado
O cliente não está devidamente autenticado/autorizado
2 - Dispute não foi encontrada
HTTP Status
Descrição
Causa
404 Not Found
É retornada quando a Dispute não foi encontrada.
O ID da Dispute fornecido não corresponde a nenhuma Dispute existente no sistema
Body
{"code":"DISPUTE_NOT_FOUND", "message":"Dispute with ID {} was not found"}
3 - Dispute já foi processada
HTTP Status
Descrição
Causa
422 Unprocesssable Entity
É retornada quando a Dispute já foi respondida anteriormente.
Uma resposta já foi enviada para a Dispute e não é possível enviar outra resposta
Body
{"code":"DISPUTE_ALREADY_ANSWERED", "message":"Dispute with ID {} has already been answered"}
4 - Alternativa não foi encontrada
HTTP Status
Descrição
Causa
404 Not Found
É retornada quando a Dispute não foi encontrada.
O ID da Alternativa fornecida não corresponde a nenhuma Alternativa existente no sistema
Body
{"code":"DISPUTE_NOT_FOUND", "message":"Dispute with ID {} was not found"}
5 - Id da alternativa está incorreto
HTTP Status
Descrição
Causa
400 Bad Request
É retornada quando a alternativa da Dispute não foi encontrada.
O ID da Alternativa fornecida não corresponde a nenhuma Alternativa existente no sistema
Body
{"code":"DISPUTE_ALTERNATIVE_INVALID", "message":"Alternative with ID {} from _Dispute_ with ID {} was invalid"}
6 - Tipo da alternativa é inválida
HTTP Status
Descrição
Causa
400 Bad Request
É retornada quando o tipo da alternativa está inválida
O tipo da alternativa informado não está inválida.
Body
{"code":"DISPUTE_ALTERNATIVE_TYPE_INVALID", "message":"Alternative Type {} with ID {} from _Dispute_ with ID {} was invalid. Must be one of the following available types {}"}
7 - Handshake já foi concluído
HTTP Status
Descrição
Causa
422 Unprocesssable Entity
É retornada quando o handshake já está concluído.
O Handshake do ID da Dispute informada já foi finalizado e não é possível repetir o processo
Body
{"code":"HANDSHAKE_ALREADY_CONCLUDED", "message":"Handshake with ID {} and _Dispute_ ID {} has already been concluded"}
8 - Motivo da negociação de atraso é inválido
HTTP Status
Descrição
Causa
400 Bad Request
É retornado quando o metadata additionalTimeReason não contém um dos valores esperado.
O valor metadata.additionalTimeReason deve ser enviado no body da request com o valor contido no metadado alternatives.metadata.allowedsAdditionalTimeReasons do evento HANDSHAKE_DISPUTE.
Body
{"code":"HANDSHAKE_NEGOTIATION_TIME_INVALID_REASON", "message":"Alternative ID {} was replied with invalid negotiation time reason"}
9 - Tempo adicional da negociação de atraso é inválido
HTTP Status
Descrição
Causa
400 Bad Request
É retornado quando o metadata additionalTimeInMinutes não contém um dos valores esperado.
O valor metadata.additionalTimeInMinutes deve ser enviado no body da request com o valor contido no metadado alternatives.metadata.allowedsAdditionalTimeMinutes do evento HANDSHAKE_DISPUTE.
Body
{"code":"HANDSHAKE_NEGOTIATION_TIME_INVALID_TIME_IN_MINUTES", "message":"Alternative ID {} was replied with invalid additional time in minutes"}
Timeout
Quando ocorre a publicação de um evento HANDSHAKE_DISPUTE e ele não é respondido dentro do prazo estabelecido, uma ação automática é acionada, resultando na geração de um evento HANDSHAKE_SETTLEMENT com o status de EXPIRED, informando a decisão que foi tomada e a negociação encerrada.O tempo máximo para responder a uma Dispute é definido pelo atributo expiresAt.A ação automática a ser executada é descrita pelo atributo timeoutAction e poderá ter os seguintes valores:
Valor
Ação
VOID
Não realiza nenhuma ação automática. É gerado apenas o HANDSHAKE_SETTLEMENT com o status "EXPIRED” formalizando a decisão tomada.
ACCEPT_CANCELLATION
Essa ação cancela o pedido, gerando os eventos HANDSHAKE_SETTLEMENT com o status "EXPIRED" e o evento "CANCELLED" para indicar que o pedido foi cancelado com sucesso.
REJECT_CANCELLATION
Essa operação rejeita o cancelamento do pedido. Serão gerados os eventos HANDSHAKE_SETTLEMENT com o status "EXPIRED" e o evento "CANCELLATION_REQUEST_FAILED" para indicar que o pedido não pôde ser cancelado.
Casos de Uso - Exemplos
Negociações Disponíveis
A seguir, serão explicadas as opções de negociação disponíveis ao longo do ciclo de vida do pedido. As negociações mencionadas logo abaixo se referem exclusivamente às Solicitações de Cancelamento feitas pelos consumidores.
Proposta de Solicitação de Cancelamento
O cliente tem a opção de solicitar o cancelamento de um pedido. Essa ação é permitida apenas em momentos específicos do ciclo de vida do pedido, como antes da confirmação, durante a preparação, quando o pedido está atrasado e após a conclusão.Por meio da política de cancelamento definida pelo IFood, é verificado se é permitido iniciar uma negociação através da Plataforma de Negociação para uma determinada Solicitação de Cancelamento antes de efetivar o cancelamento.
Como funciona?
Quando uma Negociação é iniciada, o pedido não é cancelado imediatamente, em vez disso, é dado ao parceiro a oportunidade de avaliar a solicitação do cancelamento.Passo 1: O cliente solicita o cancelamento do pedidoPasso 2: Através do motor de cancelamento é identificado a necessidade da abertura de uma Negociação com o Parceiro antes de efetivar o Cancelamento.Passe 3: O Fluxo de Negociação é iniciado.Passo 4: O parceiro recebe um evento HANDSHAKE_DISPUTE contendo informações relevantes, como comentários e fotos que evidenciam a razão da solicitação de cancelamento.Passo 5: Após avaliar a Negociação, o parceiro tem a opção de ACEITAR, REJEITAR e PROPOR REEMBOLSO por meio dos endpoints disponibilizados.
AtençãoÉ importante ressaltar, caso o parceiro não responda a Dispute dentro do prazo informado no evento HANDSHAKE_DISPUTE através do atributo expiresAt, a negociação será processada automaticamente, podendo ser aceito ou rejeitado, de acordo com a informação contida no atributo timeoutAction também disponibilizado no evento HANDSHAKE_DISPUTE.
Cancelamento Total
Para os cenários de Solicitação de Cancelamento (Após Conclusão, Durante o Preparo e Atraso na Entrega), antes do cancelamento ser efetivado será iniciado uma negociação na Plataforma de Negociação, oportunizando o Parceiro de Aceitar ou Rejeitar a requisição do cliente.Nesse cenário de negociação, quando um cliente expressa a intenção de cancelar um pedido, o parceiro, por meio do mecanismo de polling, receberá um evento de HANDSHAKE_DISPUTE que representa uma Dispute.Para responder a Dispute representada pelo evento HANDSHAKE_DISPUTE, o parceiro deve utilizar os seguintes endpoints:
/accept - Para ACEITAR a solicitação de cancelamento
/reject - Para REJEITAR a solicitação de cancelamento
Após a requisição bem-sucedida, a Plataforma de Negociação processará a solicitação de forma assíncrona. E, na próxima verificação de polling, o parceiro receberá os seguintes eventos:
HANDSHAKE_SETTLEMENT
CANCELLED ou CANCELLATION_REQUEST_FAILED
TimeoutCaso o evento HANDSHAKE_DISPUTE não seja respondido dentro do prazo estabelecido, uma ação automática é acionada. Isso resultará na geração de um evento HANDSHAKE_SETTLEMENT com o status EXPIREDe a negociação será encerrada.
O prazo máximo para responder a uma proposta é definido pelo atributo expiresAt.
Ação automática a ser executada é descrita pelo atributo timeoutAction.
Para obter maiores detalhes sobre a resposta automática em caso de timeout, consulte a seção Timeout.
Diagrama de SequênciaSequência de execução de uma Negociação referente a uma Solicitação de Cancelamento executada pela Plataforma de Negociação para os cenários de Durante o Preparo, Atraso na Entrega e Após Conclusão.
Após Conclusão
Na solicitação de cancelamento Após Conclusão antes do cancelamento ser efetivado será iniciado uma Negociação entre Cliente e Parceiro, oportunizando o Parceiro de Aceitar ou Rejeitar a requisição do cliente.Neste tipo de cancelamento o parceiro irá receber a justificativa do cliente e as imagens evidenciando o problema.Exemplo dos eventos que serão recebidos:HANDSHAKE_DISPUTE
{"id":"8290e4ac-8814-46d9-bf38-42d500ce933d", "orderId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "code":"HSS", "fullcode":"HANDSHAKE_SETTLEMENT", "merchantId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "createdAt":"2023-06-23T13:09:06.287636Z", "metadata":{"disputeId":"5166ded9-bdee-4440-8c73-b5488e8b1f83", "status":"REJECTED", "reason":"Razão por não aceitar a Dispute", "selectedDisputeAlternative":null, "createdAt":"2023-06-23T13:06:50.448434Z" }, "receivedAt":"2023-06-23T13:09:06.287636Z"}
Atributo
Possíveis Valores
status
ACCEPTED ou REJECTED
Durante o Preparo
Na solicitação de cancelamento Durante o Preparo antes do cancelamento ser efetivado será criado uma negociação na proposta de handshake, oportunizando o Parceiro de Aceitar ou Rejeitar a requisição do cliente.Neste tipo de cancelamento o parceiro irá receber apenas a justificativa do cliente.Exemplo dos eventos que serão recebidos:HANDSHAKE_DISPUTE
{"id":"8290e4ac-8814-46d9-bf38-42d500ce933d", "orderId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "code":"HSS", "fullcode":"HANDSHAKE_SETTLEMENT", "merchantId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "createdAt":"2023-06-23T13:09:06.287636Z", "metadata":{"id":"3216ded9-bdee-4440-8c73-b5488e8b1f83", "disputeId":"5166ded9-bdee-4440-8c73-b5488e8b1f83", "status":"REJECTED", "reason":"Razão por não aceitar a proposta", "selectedDisputeAlternative":null, "createdAt":"2023-06-23T13:06:50.448434Z" }, "receivedAt":"2023-06-23T13:09:06.287636Z"}
Atributo
Possíveis Valores
status
ACCEPTED ou REJECTED
Atraso na Entrega
Na solicitação de cancelamento por Atraso na Entrega antes do cancelamento ser efetivado será criado uma negociação na proposta de handshake, oportunizando o Parceiro de Aceitar ou Rejeitar a requisição do cliente.Neste tipo de cancelamento o parceiro irá receber apenas justificativa do cliente.Exemplos dos eventos que serão recebidos:HANDSHAKE_DISPUTE
{"id":"8290e4ac-8814-46d9-bf38-42d500ce933d", "orderId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "code":"HSS", "fullcode":"HANDSHAKE_SETTLEMENT", "merchantId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "createdAt":"2023-06-23T13:09:06.287636Z", "metadata":{"disputeId":"5166ded9-bdee-4440-8c73-b5488e8b1f83", "status":"REJECTED", "reason":"Razão por não aceitar a proposta", "selectedDisputeAlternative":null, "createdAt":"2023-06-23T13:06:50.448434Z" }, "receivedAt":"2023-06-23T13:09:06.287636Z"}
Atributo
Possíveis Valores
status
ACCEPTED ou REJECTED
Total com Proposta de Reembolso
Nos cenários de Solicitação de Cancelamento com Proposta de Reembolso, antes que o cancelamento seja efetivado, será iniciada uma negociação na Plataforma de Negociação, permitindo ao Parceiro ACEITAR, REJEITAR e PROPOR REEMBOLSO, com o objetivo de evitar o cancelamento total e, consequentemente, prejuízos financeiros.Nesse contexto de negociação, quando um Cliente expressa a intenção de cancelar um pedido, o Parceiro por meio do mecanismo de polling, receberá um evento de HANDSHAKE_DISPUTE que representa uma Dispute.O parceiro irá identificar que a Dispute possui a opção de Proposta de Reembolso, verificando o atributo alternatives. Se ela estiver preenchido, será possível realizar a proposta de reembolso.Para responder a essa Dispute, o Parceiro poderá utilizar os seguintes endpoints:
/accept: Para ACEITAR a solicitação de cancelamento.
/reject: Para REJEITAR a solicitação de cancelamento.
/alternative: Para enviar um valor monetário como contraproposta de reembolso ao Cliente, visando a resolução da situação e evitar o cancelamento do pedido.
Endpoints ACCEPT ou REJECTSe o parceiro executar a opção "accept" ou "reject", nenhuma proposta será enviada ao Cliente, e a negociação será encerrada.Endpoint ALTERNATIVECaso o parceiro faça uma requisição no endpoint alternative, o Cliente será notificado e poderá aceitar ou rejeitar a contraproposta. Após o processamento deste endpoint o parceiro receberá um evento HANDSHAKE_SETTLEMENT, formalizando o valor monetário enviado, o qual não requer nenhuma ação adicional e deverá aguardar a resposta do cliente.Após o cliente responder a proposta de reembolso, independentemente da resposta, o parceiro receberá um novo evento HANDSHAKE_SETTLEMENT informando a decisão tomada pelo Cliente.
TimeoutCaso o evento HANDSHAKE_DISPUTE não seja respondido dentro do prazo estabelecido, uma ação automática é acionada. Isso resultará na geração de um evento HANDSHAKE_SETTLEMENT com o status EXPIRED e a negociação será encerrada.
O prazo máximo para responder a uma proposta é definido pelo atributo expiresAt.
Ação automática a ser executada é descrita pelo atributo timeoutAction.
Para obter maiores detalhes sobre a resposta automática em caso de timeout, consulte a seção Timeout.
Fluxo executado sem Proposta de Reembolso
Caso o parceiro não faça uma proposta de reembolso, o fluxo se encerrará com o aceite ou a recusa do cancelamento.Diagrama de SequênciaDiagrama de Sequência de uma Proposta de Solicitação de Cancelamento Total executada pela Plataforma de Negociação.Exemplo dos eventos que serão recebidos:HANDSHAKE_DISPUTE
{"id":"8290e4ac-8814-46d9-bf38-42d500ce933d", "orderId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "code":"HSS", "fullcode":"HANDSHAKE_SETTLEMENT", "merchantId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "createdAt":"2023-06-23T13:09:06.287636Z", "metadata":{"disputeId":"5166ded9-bdee-4440-8c73-b5488e8b1f83", "status":"REJECTED", "reason":"Razão por não aceitar a proposta", "createdAt":"2023-06-23T13:06:50.448434Z" }, "receivedAt":"2023-06-23T13:09:06.287636Z"}
Atributo
Possíveis Valores
status
ACCEPTED ou REJECTED
Fluxo executado com Proposta de Reembolso
Caso o parceiro faça uma proposta de reembolso através do endpoint alternative, o cliente irá receber a proposta feita pelo parceiro, e após o cliente responder a contraproposta, o Parceiro irá receber o evento HANDSHAKE_SETTLEMENT informando e formalizando a decisão do Cliente.Diagrama de SequênciaDiagrama de Sequência de uma Proposta de Solicitação de Cancelamento Total com Proposta de Reembolso executada pela Plataforma de Negociação.Exemplos dos eventos que serão recebidos:HANDSHAKE_DISPUTEEvento recebido com opção de proposta de reembolso. Gerado após a utilização do endpointalternative.
HANDSHAKE_SETTLEMENTQuando a Dispute é respondida através do endpoint alternative será gerado um evento HANDSHAKE_SETTLEMENT formalizando a proposta de reembolso enviada para o cliente.
{"id":"8290e4ac-8814-46d9-bf38-42d500ce933d", "orderId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "code":"HSS", "fullcode":"HANDSHAKE_SETTLEMENT", "merchantId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "createdAt":"2023-06-23T13:09:06.287636Z", "metadata":{"disputeId":"5166ded9-bdee-4440-8c73-b5488e8b1f83", "status":"ALTERNATIVE_REPLIED", "reason":"Razão por não aceitar a proposta", "selectedDisputeAlternative":{"id":"54a402d2-5802-4178-b9e0-8c6af1705895", "type":"REFUND","metadata": {"amount": {"value": "2312","currency": "BRL" } } }, "createdAt":"2023-06-23T13:06:50.448434Z" }, "receivedAt":"2023-06-23T13:09:06.287636Z"}
Atributo
Possíveis Valores
status
ALTERNATIVE_REPLIED
HANDSHAKE_SETTLEMENTQuando a Dispute for respondida pelo cliente, será gerado um Evento HANDSHAKE_SETTLEMENT formalizando e informando a resposta do cliente em relação a proposta do reembolso feita pelo parceiro.
Nesse contexto de negociação, de solicitação de cancelamento total por atraso, antes do cancelamento ser efetivado será iniciado uma negociação na plataforma de handshake, oportunizando o Parceiro de aceitar o cancelamento ou propor um novo tempo de entrega ao cliente.Deste modo, o objetivo dessa negociação é evitar que o cliente cancele o pedido por atraso, através de um novo prazo de entrega proposto pelo parceiro.Quando um cliente expressa a intenção de cancelar um pedido, o parceiro, por meio do mecanismo de polling, receberá um evento de HANDSHAKE_DISPUTE que representa uma Dispute.Para responder a essa Dispute, o parceiro deve utilizar os seguintes endpoints:
/accept: Para ACEITAR a solicitação de cancelamento.
/alternative: Para negociar um novo tempo de entrega do pedido.
Para este fluxo não estará habilitada a possibilidade de recusar o cancelamento, ou seja, para este cenário a loja de aceitar o cancelamento ou propor um novo tempo de entrega. Caso o parceiro informe que deseja recusar o cancelamento, receberá um erro da api de negociações de cancelamento.
Endpoint ACCEPTSe o parceiro executar a opção "accept", nenhuma proposta será enviada ao Cliente, a negociação será encerrada e o pedido cancelado.Endpoint ALTERNATIVECaso o parceiro faça uma requisição no endpoint alternative, o Cliente será notificado e poderá aceitar ou rejeitar a negociação de atraso do pedido. Após o processamento deste endpoint o parceiro receberá um evento HANDSHAKE_SETTLEMENT, formalizando a quantidade de minutos a ser acrescido no tempo de entrega e o motivo disto, o qual não requer nenhuma ação adicional e deverá aguardar a resposta do cliente.Após o cliente responder à negociação de atraso na entrega, independentemente da resposta, o parceiro receberá um novo evento HANDSHAKE_SETTLEMENT informando a decisão tomada pelo Cliente, ou seja, se o cliente aceitou ou não esperar pelo tempo de entrega negociado.Endpoint REJECTReceberá o seguinte erro:
HTTP Status
Descrição
Causa
400 Bad Request
Solicitação de cancelamento com negociação de atraso não pode ter o cancelamento recusado.
Durante o cancelamento com negociação de atraso o endpoint de REJECT não pode ser utilizado.
Body
{"code":"CANCELLATION_WHILE_NEGOTIATION_TIME_CANNOT_BE_REJECTED", "message":"Cancellation while negotiation time cannot be rejected"}
TimeoutCaso o evento HANDSHAKE_DISPUTE não seja respondido dentro do prazo estabelecido, uma ação automática é acionada. Isso resultará na geração de um evento HANDSHAKE_SETTLEMENT com o status EXPIRED e a negociação será encerrada.
O prazo máximo para responder a uma proposta é definido pelo atributo expiresAt.
Ação automática a ser executada é descrita pelo atributo timeoutAction.
Para obter maiores detalhes sobre a resposta automática em caso de timeout, consulte a seção Timeout.
Fluxo executado sem Negociação de atraso
Caso o parceiro não faça uma proposta de reembolso, o fluxo se encerrará com o aceite da solicitação de cancelamento.Vale ressaltar que neste cenário é necessário enviar um motivo do aceite do cancelamento, assim como descrito aqui.Diagrama de SequênciaDiagrama de Sequência de uma Proposta de Solicitação de Cancelamento Total executada pela Plataforma de Negociação.Exemplo dos eventos que serão recebidos:HANDSHAKE_DISPUTE
{"id":"8290e4ac-8814-46d9-bf38-42d500ce933d", "orderId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "code":"HSS", "fullcode":"HANDSHAKE_SETTLEMENT", "merchantId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "createdAt":"2023-06-23T13:09:06.287636Z", "metadata":{"disputeId":"5166ded9-bdee-4440-8c73-b5488e8b1f83", "status":"ACCEPTED", "reason":"OTHER_REASONS","detailReason": "This is your detail reason, it is optional","createdAt":"2023-06-23T13:06:50.448434Z" }, "receivedAt":"2023-06-23T13:09:06.287636Z"}
Atributo
Possíveis Valores
status
ACCEPTED
Fluxo executado com Negociação de atraso
Caso o parceiro faça uma negociação de atraso através do endpoint alternative, o cliente irá receber a proposta feita pelo parceiro, e após o cliente responder a negociação de atraso, o Parceiro irá receber o evento HANDSHAKE_SETTLEMENT informando e formalizando a decisão do Cliente.Diagrama de SequênciaDiagrama de Sequência de uma Solicitação de Cancelamento Total com Negociação de atraso na entrega executada pela Plataforma de Negociação.Exemplos dos eventos que serão recebidos:HANDSHAKE_DISPUTEEvento recebido com opção de negociação de atraso na entrega.alternative.
HANDSHAKE_SETTLEMENTQuando a Dispute é respondida através do endpoint alternative será gerado um evento HANDSHAKE_SETTLEMENT formalizando a negociação com a quantidade de minutos a ser acrescido ao tempo de entrega e o motivo disto.
HANDSHAKE_SETTLEMENTQuando a Dispute for respondida pelo cliente, será gerado um Evento HANDSHAKE_SETTLEMENT formalizando e informando a resposta do cliente em relação a negociação de atraso na entrega feita pelo parceiro.
Para os cenários de Solicitação de Cancelamento Parcial Após Conclusão, antes do cancelamento ser efetivado será iniciado uma negociação na Plataforma de Negociação, oportunizando o Parceiro de Aceitar ou Rejeitar a requisição do cliente.Nesse cenário de negociação, quando um cliente expressa a intenção de cancelar um pedido, o parceiro, por meio do mecanismo de polling, receberá um evento de HANDSHAKE_DISPUTE que representa uma Dispute.Para responder a Dispute representada pelo evento HANDSHAKE_DISPUTE, o parceiro deve utilizar os seguintes endpoints:
/accept - Para ACEITAR a solicitação de cancelamento parcial
/reject - Para REJEITAR a solicitação de cancelamento parcial
Após a requisição bem-sucedida, a Plataforma de Negociação processará a solicitação de forma assíncrona. E, na próxima verificação de polling, o parceiro receberá os seguintes eventos:
HANDSHAKE_SETTLEMENT
TimeoutCaso o evento HANDSHAKE_DISPUTE não seja respondido dentro do prazo estabelecido, uma ação automática é acionada. Isso resultará na geração de um evento HANDSHAKE_SETTLEMENT com o status EXPIREDe a negociação será encerrada.
O prazo máximo para responder a uma proposta é definido pelo atributo expiresAt.
Ação automática a ser executada é descrita pelo atributo timeoutAction.
Para obter maiores detalhes sobre a resposta automática em caso de timeout, consulte a seção Timeout.
Diagrama de SequênciaSequência de execução de uma Negociação referente a uma Solicitação de Cancelamento para os cenários de Cancelamento Parcial Após Conclusão.
Parcial Após Conclusão
Ao solicitar um Cancelamento Parcial Após Conclusão, antes que o cancelamento seja efetivado, será iniciada uma negociação entre o Cliente e o Parceiro. Isso permite ao Parceiro ter a oportunidade de ACEITAR ou REJEITAR a requisição do Cliente.Nesse tipo de negociação, o Parceiro receberá a justificativa do Cliente, bem como as imagens que evidenciam os itens (Item) e/ou subItens (GarnishItem) envolvidos na solicitação de cancelamento parcial.Exemplo dos eventos que serão recebidos:HANDSHAKE_DISPUTE
{"id":"8290e4ac-8814-46d9-bf38-42d500ce933d", "orderId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "code":"HSS", "fullcode":"HANDSHAKE_SETTLEMENT", "merchantId":"23f5d785-6c76-47d8-bdd0-b3090c90a2a8", "createdAt":"2023-06-23T13:09:06.287636Z", "metadata":{"disputeId":"5166ded9-bdee-4440-8c73-b5488e8b1f83", "status":"REJECTED", "reason":"Razão por não aceitar a proposta", "selectedDisputeAlternative":null, "createdAt":"2023-06-23T13:06:50.448434Z" }, "receivedAt":"2023-06-23T13:09:06.287636Z"}
Atributo
Possíveis Valores
status
ACCEPTED ou REJECTED
Parcial com Proposta de Reembolso - Em Breve
Nos cenários de Solicitação de Cancelamento Parcial com Proposta de Reembolso, antes que o cancelamento seja efetivado, será iniciada uma negociação na Plataforma de Negociação, permitindo ao Parceiro ACEITAR, REJEITAR e PROPOR REEMBOLSO, com o objetivo de evitar o cancelamento parcial e, consequentemente, prejuízos financeiros.Nesse contexto de negociação, quando um Cliente expressa a intenção de cancelar alguns itens de um pedido, o Parceiro por meio do mecanismo de polling, receberá um evento de HANDSHAKE_DISPUTE que representa uma Dispute.O parceiro irá identificar que a Dispute possui a opção de Proposta de Reembolso, verificando o atributo alternatives. Se ela estiver preenchido, será possível realizar a proposta de reembolso.Para responder a essa Dispute, o Parceiro poderá utilizar os seguintes endpoints:
/accept: Para ACEITAR a solicitação de cancelamento parcial
/reject: Para REJEITAR a solicitação de cancelamento parcial.
/alternative: Para enviar um valor monetário como contraproposta de reembolso ao Cliente, visando a resolução da situação e evitar o cancelamento do pedido parcial do pedido
Endpoints ACCEPT ou REJECTSe o parceiro executar a opção accept ou reject, nenhuma proposta será enviada ao Cliente, e a negociação será encerrada.Endpoint ALTERNATIVECaso o parceiro faça uma requisição no endpoint alternative, o Cliente será notificado e poderá aceitar ou rejeitar a contraproposta. Após o processamento deste endpoint o parceiro receberá um evento HANDSHAKE_SETTLEMENT, formalizando o valor monetário enviado, o qual não requer nenhuma ação adicional e deverá aguardar a resposta do cliente.Após o cliente responder a proposta de reembolso, independentemente da resposta, o parceiro receberá um novo evento HANDSHAKE_SETTLEMENT informando a decisão tomada pelo Cliente.
TimeoutCaso o evento HANDSHAKE_DISPUTE não seja respondido dentro do prazo estabelecido, uma ação automática é acionada. Isso resultará na geração de um evento HANDSHAKE_SETTLEMENT com o status EXPIREDe a negociação será encerrada.
O prazo máximo para responder a uma proposta é definido pelo atributo expiresAt.
Ação automática a ser executada é descrita pelo atributo timeoutAction.
Para obter maiores detalhes sobre a resposta automática em caso de timeout, consulte a seção Timeout.
Fluxo executado SEM proposta de reembolso
Caso o parceiro não faça uma proposta de reembolso, o fluxo se encerrará com o aceite ou a recusa do cancelamento.Diagrama de SequênciaDiagrama de Sequência de uma Proposta de Solicitação de Cancelamento Parcial.Exemplos dos eventos que serão recebidos:HANDSHAKE_DISPUTE
Caso o parceiro faça uma proposta de reembolso através do endpoint alternative, o cliente irá receber a proposta feita pelo parceiro, e após o cliente responder a contraproposta, o Parceiro irá receber o evento HANDSHAKE_SETTLEMENT informando e formalizando a decisão do Cliente.Diagrama de SequênciaDiagrama de Sequência de uma Proposta de Solicitação de Cancelamento Parcial executada pela Plataforma de Negociação.Exemplos dos eventos que serão recebidos:HANDSHAKE_DISPUTEEvento recebido com opção de proposta de reembolso. Gerado após a utilização do endpointalternative.
Essa aba foi criada para fornecer um guia visual e detalhado sobre como testar cada fluxo de negociação de cancelamento. Ele é destinado a facilitar o entendimento e a execução dos procedimentos necessários. Importante destacar que este documento não incluirá descrições detalhadas de cada dado dos eventos de negociação, uma vez que essas informações já estão disponíveis nas guias anteriores.
Negociação de Cancelamento Após entrega
Cancelamento total
Esta negociação acontece quando o cliente recebe o pedido e então solicita o cancelamento de todo o pedido. O merchant receberá o pedido de cancelamento e então pode aceitar o cancelamento, recusar o cancelamento ou propor um reembolso ao cliente. Abaixo estão os passos para simular cada situação.
Aceitar a negociação de cancelamento
Criar um pedido
Merchant deve confirmar e despachar o pedido
Cliente deve confirmar o recebimento do pedido
Cliente deve solicitar o cancelamento do pedido
Para solicitar o cancelamento do pedido abra o app do cliente, abra o pedido, clique em Ajuda > Pedido veio errado > Preencha o formulário selecionando todos os itens > Envie as informações > Selecione a opção "Não quero receber reembolso em saldo iFood".
Neste momento a plataforma de cancelamento receberá a solicitação de cancelamento e após validação de políticas de cancelamento abrirá uma negociação junto ao restaurante. Esta negociação é representada pelo evento HANDSHAKE_DISPUTE, este evento ficará disponível para polling via merchant-api.
Após a resposta do merchant ficará disponível via polling na merchant-api um evento chamado HANDSHAKE_SETTLEMENT representando a opção que o merchant escolheu.
Para solicitar o cancelamento do pedido abra o app do cliente, abra o pedido, clique em Ajuda > Pedido veio errado > Preencha o formulário selecionando todos os itens > Envie as informações > Selecione a opção "Não quero receber reembolso em saldo iFood".
Neste momento a plataforma de cancelamento receberá a solicitação de cancelamento e após validação de políticas de cancelamento abrirá uma negociação junto ao restaurante. Esta negociação é representada pelo evento HANDSHAKE_DISPUTE, este evento ficará disponível para polling via merchant-api.
Após a resposta do merchant ficará disponível via polling na merchant-api um evento chamado HANDSHAKE_SETTLEMENT representando a opção que o merchant escolheu.
{"id":"4bf1cd30-e50b-41b8-9827-0ad448d3c700","code":"HSS","fullCode":"HANDSHAKE_SETTLEMENT","orderId":"6211e666-2fec-4369-b261-5a422c5ef350","merchantId":"d1a3bc50-6103-49e0-afeb-b619b753fe69","createdAt":"2024-04-25T18:03:43.186Z","metadata":{"createdAt":"2024-04-25T18:03:43.083117651Z","disputeId":"0a2d440f-98f3-4919-ac0b-aa5afe8f4135","reason":"teste teste teste","status":"REJECTED" }}
Enviar proposta de reembolso
Criar um pedido
Merchant deve confirmar e despachar o pedido
Cliente deve confirmar o recebimento do pedido
Cliente deve solicitar o cancelamento do pedido
Para solicitar o cancelamento do pedido abra o app do cliente, abra o pedido, clique em Ajuda > Pedido veio errado > Preencha o formulário selecionando todos os itens > Envie as informações > Selecione a opção "Não quero receber reembolso em saldo iFood".
Neste momento a plataforma de cancelamento receberá a solicitação de cancelamento e após validação de políticas de cancelamento abrirá uma negociação junto ao restaurante. Esta negociação é representada pelo evento HANDSHAKE_DISPUTE, este evento ficará disponível para polling via merchant-api.
Após a resposta do merchant ficará disponível via polling na merchant-api um evento chamado HANDSHAKE_SETTLEMENT representando a opção que o merchant escolheu.
Por fim, o merchant receberá via polling outro evento de HANDSHAKE_SETTLEMENT informando sobre a resposta do cliente, ou seja, se o cliente aceitou, recusou ou não respondeu a proposta de reembolso enviada pelo merchant. Neste caso o cliente aceitou o reembolso. Caso o cliente não aceite o reembolso o metadata status terá o valor REJECTED. Caso o cliente não responda a proposta de reembolso, o mesmo metadata terá o valor EXPIRED.
Esta negociação acontece quando o cliente recebe o pedido e então solicita o cancelamento de itens do pedido. O merchant receberá o pedido de cancelamento e então pode aceitar o cancelamento, recusar o cancelamento ou propor um reembolso ao cliente. Abaixo estão os passos para simular cada situação.
Aceitar a negociação de cancelamento
Criar um pedido
Merchant deve confirmar e despachar o pedido
Cliente deve confirmar o recebimento do pedido
Cliente deve solicitar o cancelamento do pedido
Para solicitar o cancelamento do pedido abra o app do cliente, abra o pedido, clique em Ajuda > Pedido veio errado > Preencha o formulário selecionando alguns itens > Envie as informações > Selecione a opção "Não quero receber reembolso em saldo iFood".
Neste momento a plataforma de cancelamento receberá a solicitação de cancelamento e após validação de políticas de cancelamento abrirá uma negociação junto ao restaurante. Esta negociação é representada pelo evento HANDSHAKE_DISPUTE, este evento ficará disponível para polling via merchant-api.
Após a resposta do merchant ficará disponível via polling na merchant-api um evento chamado HANDSHAKE_SETTLEMENT representando a opção que o merchant escolheu.
Para solicitar o cancelamento do pedido abra o app do cliente, abra o pedido, clique em Ajuda > Pedido veio errado > Preencha o formulário selecionando alguns itens > Envie as informações > Selecione a opção "Não quero receber reembolso em saldo iFood".
Neste momento a plataforma de cancelamento receberá a solicitação de cancelamento e após validação de políticas de cancelamento abrirá uma negociação junto ao restaurante. Esta negociação é representada pelo evento HANDSHAKE_DISPUTE, este evento ficará disponível para polling via merchant-api.
Após a resposta do merchant ficará disponível via polling na merchant-api um evento chamado HANDSHAKE_SETTLEMENT representando a opção que o merchant escolheu.
{"id":"7fb701a9-0996-4418-a3dc-8afa55786764","code":"HSS","fullCode":"HANDSHAKE_SETTLEMENT","orderId":"3c5332ee-0616-44de-bff3-37a40b93f834","merchantId":"d1a3bc50-6103-49e0-afeb-b619b753fe69","createdAt":"2024-04-25T19:06:38.788Z","metadata":{"createdAt":"2024-04-25T19:06:38.692323486Z","disputeId":"9eec04a6-5374-4e20-9713-29926924fbc1","reason":"testando o cancelamento parcial","status":"REJECTED" }}
Enviar proposta de reembolso
Criar um pedido
Merchant deve confirmar e despachar o pedido
Cliente deve confirmar o recebimento do pedido
Cliente deve solicitar o cancelamento do pedido
Para solicitar o cancelamento do pedido abra o app do cliente, abra o pedido, clique em Ajuda > Pedido veio errado > Preencha o formulário selecionando alguns itens > Envie as informações > Selecione a opção "Não quero receber reembolso em saldo iFood".
Neste momento a plataforma de cancelamento receberá a solicitação de cancelamento e após validação de políticas de cancelamento abrirá uma negociação junto ao restaurante. Esta negociação é representada pelo evento HANDSHAKE_DISPUTE, este evento ficará disponível para polling via merchant-api.
Após a resposta do merchant ficará disponível via polling na merchant-api um evento chamado HANDSHAKE_SETTLEMENT representando a opção que o merchant escolheu.
Por fim, o merchant receberá via polling outro evento de HANDSHAKE_SETTLEMENT informando sobre a resposta do cliente, ou seja, se o cliente aceitou, recusou ou não respondeu a proposta de reembolso enviada pelo merchant. Neste caso o cliente aceitou o reembolso. Caso o cliente não aceite o reembolso o metadata status terá o valor REJECTED. Caso o cliente não responda a proposta de reembolso, o mesmo metadata terá o valor EXPIRED.
Esta negociação acontece quando o cliente solicita o cancelamento enquanto o merchant prepara o pedido. O merchant receberá o pedido de cancelamento e poderá aceitar o cancelamento ou recusar o cancelamento. Abaixo estão os passos para simular cada situação.
Aceitar a negociação de cancelamento
Criar um pedido
Merchant deve confirmar o pedido
Cliente deve solicitar o cancelamento do pedido
Para solicitar o cancelamento do pedido abra o app do cliente, abra o pedido, clique em Ajuda > Comprei sem querer > Cancelar pedido > Preencha o formulário e envie.
Neste momento a plataforma de cancelamento receberá a solicitação de cancelamento e após validação de políticas de cancelamento abrirá uma negociação junto ao restaurante. Esta negociação é representada pelo evento HANDSHAKE_DISPUTE, este evento ficará disponível para polling via merchant-api.
{"id":"1d115926-c439-4cfb-a1df-f8fd4385f2aa","code":"HSD","fullCode":"HANDSHAKE_DISPUTE","orderId":"f98c70e9-7dc0-4a07-abd1-c8c33e1cd48c","merchantId":"d1a3bc50-6103-49e0-afeb-b619b753fe69","createdAt":"2024-04-25T19:46:10.350Z","metadata":{"action":"CANCELLATION","createdAt":"2024-04-25T19:46:10.252389Z","disputeId":"b1cab1e3-d4fd-4808-b9eb-5789b04870f2","expiresAt":"2024-04-25T19:51:10.252389Z","handshakeGroup":"CUSTOMER_ORDER_SUPPORT","handshakeType":"PREPARATION_TIME","message":"Teste teste teste","timeoutAction":"REJECT_CANCELLATION" }}
Merchant deve responder a solicitação de cancelamento
Para responder, o merchant pode optar em usar o Gestor de pedidos ou a merchant-api. Seguem exemplos das duas maneiras de interagir com a negociação.
Após a resposta do merchant ficará disponível via polling na merchant-api um evento chamado HANDSHAKE_SETTLEMENT representando a opção que o merchant escolheu.
Para solicitar o cancelamento do pedido abra o app do cliente, abra o pedido, clique em Ajuda > Comprei sem querer > Cancelar pedido > Preencha o formulário e envie.
Neste momento a plataforma de cancelamento receberá a solicitação de cancelamento e após validação de políticas de cancelamento abrirá uma negociação junto ao restaurante. Esta negociação é representada pelo evento HANDSHAKE_DISPUTE, este evento ficará disponível para polling via merchant-api.
{"id":"1d115926-c439-4cfb-a1df-f8fd4385f2aa","code":"HSD","fullCode":"HANDSHAKE_DISPUTE","orderId":"f98c70e9-7dc0-4a07-abd1-c8c33e1cd48c","merchantId":"d1a3bc50-6103-49e0-afeb-b619b753fe69","createdAt":"2024-04-25T19:46:10.350Z","metadata":{"action":"CANCELLATION","createdAt":"2024-04-25T19:46:10.252389Z","disputeId":"b1cab1e3-d4fd-4808-b9eb-5789b04870f2","expiresAt":"2024-04-25T19:51:10.252389Z","handshakeGroup":"CUSTOMER_ORDER_SUPPORT","handshakeType":"PREPARATION_TIME","message":"Teste teste teste","timeoutAction":"REJECT_CANCELLATION" }}
Merchant deve responder a solicitação de cancelamento
Para responder, o merchant pode optar em usar o Gestor de pedidos ou a merchant-api. Seguem exemplos das duas maneiras de interagir com a negociação.
Após a resposta do merchant ficará disponível via polling na merchant-api um evento chamado HANDSHAKE_SETTLEMENT representando a opção que o merchant escolheu.
Esta negociação acontece quando o cliente solicita o cancelamento porque o pedido está atrasado. O merchant receberá o pedido de cancelamento e poderá aceitar o cancelamento ou negociar um novo tempo de entrega. Abaixo estão os passos para simular cada situação.
Até o presente momento ainda esta feature ainda está em fase de rollout e por conta disto, para o merchant receber esta negociação o mesmo precisar ter a config LC_OPS_ORDER_LATE_MARKETPLACE_CHAT_HANDSHAKE_ENABLED seta com o valor S.
Aceitar a negociação de cancelamento
Criar um pedido
Merchant deve confirmar o pedido
Esperar o pedido ficar atrasado
Cliente deve solicitar o cancelamento do pedido
Para solicitar o cancelamento do pedido abra o app do cliente, abra o pedido, clique em Preciso de ajuda, então será aberto um chat. O cliente receberá uma mensagem, e aí deve dizer que ainda não chegou o pedido. Após isto, o cliente receberá outra mensagem com um botão de "Quero uma nova previsão", clique no botão.
Neste momento a plataforma de cancelamento receberá a solicitação de cancelamento e após validação de políticas de cancelamento abrirá uma negociação junto ao restaurante. Esta negociação é representada pelo evento HANDSHAKE_DISPUTE, este evento ficará disponível para polling via merchant-api.
Merchant deve responder a solicitação de cancelamento
Para responder, o merchant pode optar em usar o Gestor de pedidos ou a merchant-api. Seguem exemplos das duas maneiras de interagir com a negociação.
Imagem do Gestor de pedidos - Clique em "Pedido não será mais entregue"
Informe o motivo usando a caixa de seleção e se quiser, você pode especificar um pouco mais do porque o pedido não será mais entregue.
Request para merchant-api
Nesta negociação em específico, ao aceitar o cancelamento, o merchant deve informar o porque está aceitando o cancelamento informando um dos motivos que está listado no evento de HANDSHAKE_DISPUTE no metadata acceptCancellationReasons.
Após a resposta do merchant ficará disponível via polling na merchant-api um evento chamado HANDSHAKE_SETTLEMENT representando a opção que o merchant escolheu.
Para solicitar o cancelamento do pedido abra o app do cliente, abra o pedido, clique em Preciso de ajuda, então será aberto um chat. O cliente receberá uma mensagem, e aí deve dizer que ainda não chegou o pedido. Após isto, o cliente receberá outra mensagem com um botão de "Quero uma nova previsão", clique no botão.
Neste momento a plataforma de cancelamento receberá a solicitação de cancelamento e após validação de políticas de cancelamento abrirá uma negociação junto ao restaurante. Esta negociação é representada pelo evento HANDSHAKE_DISPUTE, este evento ficará disponível para polling via merchant-api.
Merchant deve responder a solicitação de cancelamento,
Para responder, o merchant pode optar em usar o Gestor de pedidos ou a merchant-api. Seguem exemplos das duas maneiras de interagir com a negociação.
Imagem do Gestor de pedidos
Preencha o formulário selecionando o tempo que vai atrasar e o motivo do atraso. Clique em "Atualizar previsão de entrega".
Request para merchant-api
Nesta negociação em específico, ao propor um novo tempo de entrega, o merchant deve informar a quantidade de tempo que vai atrasar e o motivo do atraso. As opções que o merchant pode escolher para isto está listado no evento de HANDSHAKE_DISPUTE, no metadata alternatives.metadata.allowedsAdditionalTimeInMinutes e alternatives.metadata.allowedsAdditionalTimeReasons respectivamente.
Após a resposta do merchant ficará disponível via polling na merchant-api um evento chamado HANDSHAKE_SETTLEMENT representando a opção que o merchant escolheu.
Por fim, o merchant receberá via polling outro evento de HANDSHAKE_SETTLEMENT informando sobre a resposta do cliente, ou seja, se o cliente aceitou, recusou ou não respondeu a proposta de reembolso enviada pelo merchant. Neste caso o cliente aceitou o reembolso. Caso o cliente não aceite o reembolso o metadata status terá o valor REJECTED. Caso o cliente não responda a proposta de reembolso, o mesmo metadata terá o valor EXPIRED.
Como visualizar as imagens de evidência de cancelamento
Nem toda negociação terá imagens de evidência de cancelamento. Quando houver evidências de cancelamento, basta fazer uma requisição GET no usando o link que contém no campo metadata.evidences[X].url. Segue um exemplo de código que recupera uma evidência de cancelamento.
<!DOCTYPEhtml><htmllang="pt"><head><metacharset="UTF-8"><metaname="viewport"content="width=device-width, initial-scale=1.0"><title>Imagem do Servidor</title></head><body><imgid="imagemServidor"src=""alt="Imagem do Servidor"style="max-width: 100%; height: auto;"><script>consturlImagem="https://merchant-api.ifood.com.br/order/v1.0/orders/abeff264-bf8b-472d-a6ad-11fea0096253/cancellationEvidences/89422573-3b50-421d-a0f4-051642e75f70";constopcoesFetch= {method:'GET',headers: {'Authorization':'Bearer jwt-token' } };fetch(urlImagem, opcoesFetch) .then(response=> {if (!response.ok) {thrownewError('Falha ao buscar a imagem: '+response.statusText); }returnresponse.blob(); }) .then(blob=> {consturlBlob=URL.createObjectURL(blob);document.getElementById('imagemServidor').src=urlBlob; }) .catch(error=> {console.error('Erro:', error); });</script></body></html>