Homologación del módulo de Order (pedidos)

La integración de pedidos es uno de los flujos más sensibles del recorrido de un usuario dentro de la plataforma iFood. Si la tienda no es capaz de recibir y confirmar los pedidos, los pedidos son cancelados y esto genera una mala experiencia para los usuarios de la plataforma.Por este motivo es importante que todas las aplicaciones que utilizan el módulo de pedidos de la API cumplan con los requisitos mínimos para garantizar una buena experiencia para nuestros clientes y socios.

Homologación

Para realizar la homologación de la aplicación es necesario que la misma ya esté lista. Las pruebas se realizan en la APP como un todo y no solo en las llamadas de nuestras APIs.

Pedidos de homologación con registros de cuenta Personal/Estudiante (CPF) no serán aceptados. Solo pedidos con registro de cuenta Profesional (CNPJ).

Criterios

La aplicación debe ser capaz de:

Recibir eventos de pedidos vía polling o vía webhook.
- En el caso del polling:
  - Hacer requests en el endpoint de /polling regularmente cada 30 segundos para no perder ningún pedido. Esto garantiza que el merchant se mantenga abierto en la plataforma; Utilice el header x-polling-merchants siempre que necesite filtrar eventos de uno o más merchants. También es posible filtrar los eventos que desea recibir por tipo y por grupo;
  - Enviar /acknowledgment para todos los eventos recibidos (con status code 200) inmediatamente después del request de polling;
- En el caso del webhook: responder con éxito a los requests del webhook, verificado por nuestra auditoría interna;
Recibir, confirmar y despachar un pedido delivery para ahora (orderType = DELIVERY / orderTiming = IMMEDIATE);
Recibir, confirmar y despachar un pedido delivery programado (orderType = DELIVERY / orderTiming = SCHEDULED). Es necesario mostrar la fecha y hora de la programación;
Recibir y cancelar un pedido delivery para ahora (orderType = DELIVERY / orderTiming = IMMEDIATE). Antes de solicitar una cancelación es obligatoria la consulta de los códigos/motivos disponibles para el momento del pedido a través del endpoint /cancellationReasons, esta lista de códigos/motivos deberá ser disponibilizada en el sistema de PDV, para que el usuario del PDV elija qué motivo usar;
Recibir, confirmar y avisar que está listo un pedido Para Retirar (orderType = TAKEOUT);
Recibir pedidos con pago en tarjeta y mostrar detalles del tipo de pago, como marca;
Recibir pedidos con pago en efectivo y mostrar el valor del cambio en la pantalla y/o comprobante impreso;
Recibir pedidos con todos los cupones de descuento y mostrar el valor y el responsable del subsidio (iFood / Tienda);
Mostrar observaciones de los artículos en la pantalla y/o comprobante impreso (Ej: Quitar cebolla);
Actualizar el estado de un pedido cancelado por el cliente o por iFood;
Actualizar el estado de un pedido que puede haber sido confirmado/cancelado por otra aplicación como por ejemplo el Gestor de Pedidos;
Recibir un mismo evento más de una vez en el polling y descartarlo en caso de que ese evento haya sido entregado más de una vez;
Informar el CPF/CNPJ en la pantalla en caso de que sea obligatorio por la tienda o ya completar en el documento fiscal automáticamente;
Recibir eventos de la Plataforma de Negociación de Pedidos y ser capaz de procesarlos a través de los endpoints disponibles;
Mostrar en la pantalla y/o impreso en el comprobante el código de recolección del pedido;

Requisitos no funcionales:

Renovar el token solamente cuando esté a punto de expirar o inmediatamente después de la expiración.
La aplicación debe respetar las políticas de rate limit de cada endpoint.

Deseable:

Que el comprobante impreso siga el modelo sugerido en la documentación es un requisito deseable.
Informar en la pantalla y/o comprobante impreso la información para indicar cualquier observación sobre la entrega del pedido (que viene en el campo delivery.observations)

Consejo Para validar si su aplicación es capaz de actualizar el estado de pedidos con los cambios realizados por otra aplicación, puede confirmar y cancelar pedidos de prueba usando el Gestor de Pedidos Web y acompañar el estado de estos pedidos en su aplicación.

Cómo programar

Para programar la homologación de su aplicación acceda al área de tickets y abra una solicitud para la homologación de su aplicación. Nuestro equipo se pondrá en contacto con usted para programar el proceso.

Nuevo Intento Antes de programar la homologación de su aplicación asegúrese de que cumple con todos los requisitos listados arriba. Es necesario esperar 15 días para un nuevo intento.

Preparación

Antes de iniciar, tenga a mano los datos de su tienda de prueba, como id y nombre de la tienda. Asegúrese de tener acceso a un servicio de internet estable

Duración

En el horario programado, un analista de nuestro equipo hará el acceso remoto para acompañar cada etapa de las pruebas. El proceso dura en promedio 45 minutos.

Reprogramación

En caso de que su aplicación no sea homologada, nuestro equipo registrará en el ticket los requisitos que no fueron cumplidos y usted deberá ajustar su software. Podrá programar una nueva homologación 15 días después del intento anterior.

¿Esta página fue útil?

Evalúa tu experiencia en el nuevo portal de desarrolladores: