O gerenciamento de pedidos é feito através de APIs REST, com as quais você consegue realizar ações dependendo do status atual do pedido.

As alterações de status do pedido, desde o momento da criação até a conclusão da entrega serão notificadas via webhook contendo em seu body o resource e o user_id.

O atributo resource retorna o shipment_id que será utilizado para qualquer operação envolvendo o pedido e o atributo user_id retorna a identificação do usuário da loja que recebeu o pedido.

Com o shipment_id em mãos, você consegue:

• Obter dados do pedido.
• Aceitar pedidos.
• Imprimir o comprovante do pedido.
• Cancelar o pedido.

Dentro do Mercado Pago Delivery existem duas modalidade de logística. Dessa forma, o fluxo de estados pode variar de acordo com a modalidade de logística que estará vinculado ao pedido. Abaixo segue a descrição desses dois fluxos.

Essa modalidade de logística é usada geralmente em restaurantes que possuem entregadores próprios. Os entregadores deverão ter acesso ao aplicativo de celular Mercado Envios Flex para realizar a leitura do código QR para registrar e realizar a entrega. Com a leitura desse código QR, os compradores serão notificados de que o pedido está a caminho. É possível utilizar o código QR presente no pdf disponível na API ou gerar o código QR em sua integração. As informações, que deverão estar contidas no código QR, podem ser obtidas através da API do Mercado Pago Delivery utilizando o endpoint de consulta, onde esses dados serão retornadas no atributo “extension.qr”. É importante que o código QR seja disponilizado no ticket do pedido para que o fluxo de entrega possa ser realizado corretamente. A seguir, segue a descrição dos status de todas as notificações que chegarão ao webhook de pedidos atrelados a essa modalidade de logística:

• ready_to_ship/ready_to_print: Status inicial de um pedido. Nesse Status, alguma ação deve ser realizada (aceitar ou cancelar) em no máximo 5 minutos, caso contrário o pedido será cancelado por timeout.
• cancelled/cancelled_manually: Status indicando que uma operação de cancelamento foi executada no pedido.
• cancelled/time_expired: Nesse Status, o pedido foi cancelado por timeout devido ao fato de não ter sido realizada nenhuma operação nos primeiros 5 minutos desde sua criação.
• ready_to_ship/printed: Status que indica que o pedido foi aceito.
• shipped/out_for_delivery: Status que indica que o pedido está a caminho do seu local de destino. Esse Status é gerado logo após o entregador realizar a leitura do código QR do pedido, utilizando o aplicativo Mercado Envios Flex.
• shipped/delivery_failed: Status que indica que ocorreu algum problema durante a entrega do pedido. Esse é gerado através do aplicativo Mercado Envios Flex quando o entregado não consegue realizar a entrega.
• delivered: A entrega foi concluida com sucesso. Esse Status é gerado através do aplicativo Mercado Envios Flex pelo entregador logo após a conclusão da entrega.

Essa modalidade de logística é utilizada por restaurantes que concordaram que empresas logísticas, que estejam integradas com Mercado Pago, realizem a entrega dos seus pedidos. Nesse fluxo, logo após aceitar um pedido, será enviada uma notificação de que um entregador estará a caminho para receber o pedido. É importante notar que diferentemente do fluxo que foi apresentado anteriormente, nessa modalidade de Dropoff os pedidos não terão um código QR e, devido a isso, ao realizar uma consulta sobre o pedido utilizando a API do Mercado Pago Delivery, o atributo extension.qr será vazio. Com esse tipo de logística, é possível que tenhamos um entregador atribuído antes do pedido ter sido aceito. Ao aceitar o pedido seguindo o fluxo normal, seria mostrado o status/substatus: ready_to_ship / ready_to_print ao realizar o primeiro GET, mas nos casos em que há um entregador atribuído muito rapidamente (antes de aceitar o pedido) é possível ter o status/substatus: ready_to_ship / on_route_to_pickup no primeiro GET. Portanto, a recomendação para esse tipo de logística é aceitar os pedidos observando apenas o status (ready_to_ship). Mesmo com o entregador atribuído, é necessário aceitar o pedido em até 5 minutos após sua criação e, caso contrário, ele será cancelada por timeout. E uma vez atribuído o entregador, os estados anteriores do fluxo não serão mostrados no GET. A seguir, segue a descrição dos status de todas as notificações que chegarão ao Webhook de pedidos atrelados a essa modalide de logística:

• ready_to_ship/ready_to_print: Nesse status, alguma ação deve ser realizada (aceitar ou cancelar) em no máximo 5 minutos, caso contrário o pedido será cancelado por timeout.
• cancelled/cancelled_manually: Status indicando que uma operação de cancelamento foi executada no pedido.
• cancelled/time_expired: Nesse status, o pedido foi cancelado por timeout devido ao fato de não ter sido realizada nenhuma operação nos primeiros 5 minutos desde sua criação.
• ready_to_ship/printed: Status que indica que um pedido foi aceito.
• ready_to_ship/on_route_to_pickup: Esse status indica que o entregador está a caminho do restaurante. É importante observar que os pedidos podem ter um entregador mesmo sem o pedido estar aceito, mas ainda sim é necessário aceitar o pedido em até 5 minutos, caso contrário ele acabará sendo cancelado por timeout.
• ready_to_ship/picking_up: Esse status indica que o entregador está retirando o pedido no restaurante.
• shipped/out_for_delivery: Indica que o entregador já saiu para entregar o pedido.
• shipped/at_the_door: Indica que o entregador chegou ao destino do pedido.
• delivered: A entrega foi bem sucedida.
• not_delivered: Houve um problema e o entregador não conseguiu concluir a entrega.