Si quiero evitar etiquetas duplicadas, stock tomado de más y mensajes de tracking que fallan, arranco el flujo solo cuando el pedido está pago. Esa es la idea central: primero order paid, después validaciones, luego etiqueta, fulfillment y automatización en WhatsApp para ecommerce.
En esta guía, yo me quedo con este orden:
order paid, no order createdDicho simple: si el pago no está acreditado, no emito nada. Y cuando sí está acreditado, no mando la etiqueta “de una”: primero valido datos, freno duplicados y recién ahí despacho. En Argentina, donde una transferencia puede demorarse horas o días, este orden evita errores caros y baja el trabajo manual.
Ese enfoque también me ayuda a despachar dentro de una ventana razonable: una mediana de 30 a 60 minutos en horario hábil, con 90 % de los pedidos moviéndose dentro de las primeras 2 horas desde el pago.
Flujo de Automatización de Envíos desde Pedido Pago
Con order paid ya recibido, el flujo no crea la etiqueta de una. Antes hay un paso clave: validar el pedido. se genera el envío.
El evento de pago confirmado cambia según la plataforma. En Shopify es orders/paid. En desarrollos propios, el sistema de pagos suele emitir un evento order_paid con, como mínimo, order_id, payment_status, paid_at en formato ISO 8601 - por ejemplo, 2026-08-08T14:32:10-03:00 - y el monto total en ARS.
Cuando entra el webhook, el primer control es la firma. Si no coincide, devolvé 401 o 403 y descartá el evento. Después revisá la antigüedad del timestamp. Si llegó demasiado tarde o trae una fecha futura, se marca como sospechoso y queda afuera del flujo automático.
El segundo punto es la idempotencia. Esto evita que el mismo pago genere dos etiquetas por reintentos o fallas pasajeras. La forma más simple es usar order_id junto con el nombre de la plataforma como clave única en una tabla webhook_events.
El comportamiento esperado es este:
El log mínimo por evento tiene que incluir order_id, platform, idempotency_key, processing_status (pending, success, failed, skipped_idempotent) y error_code.
Con un evento único y validado, recién ahí el sistema pasa a revisar el pedido.
Antes de llamar a la API del operador logístico, el flujo tiene que atravesar una capa de validaciones. Si una sola falla, el proceso se frena y el pedido queda para revisión manual. Acá no conviene “probar igual”. Una dirección rota, un peso mal cargado o un pago en revisión te puede trabar toda la operación.
Dirección: los campos obligatorios son first_name, last_name, street, street_number, city, province, postal_code y country_code = AR. El código postal puede venir en formato numérico tradicional, como 1425, o en CPA alfanumérico, como C1425ABC. Si el operador acepta solo formato numérico, el sistema puede normalizarlo antes de seguir. Esta validación no se negocia: una dirección incompleta corta la entrega.
Stock y riesgo fraudulento: hay que confirmar que cada SKU tenga reserva o disponibilidad suficiente. Si el stock se reservó al crear el pedido, en este punto se valida que esa reserva siga vigente. Si el pago figura con riesgo alto o quedó en revisión por la pasarela, el flujo no sigue y el pedido se marca internamente como Fraude / Revisión.
Peso y dimensiones: cada SKU debe tener unit_weight_kg y medidas en centímetros: length_cm, width_cm, height_cm. En pedidos con varios ítems, el sistema calcula el peso total y el embalaje según la matriz de packaging, y aplica la regla de peso volumétrico del operador. Si algún SKU tiene peso nulo, cero o un valor fuera de rango, el flujo se detiene y el pedido pasa a Revisión manual – peso/medidas.
| Validación | Condición para continuar | Estado si falla |
|---|---|---|
| Dirección completa | Todos los campos obligatorios presentes y CP válido | Revisión manual – dirección incompleta |
| Pago confirmado y sin fraude | payment_status = paid y riesgo bajo | Revisión manual – fraude / revisión |
| Stock disponible o reservado | Reserva vigente para cada SKU | Revisión manual – sin stock |
| Peso y dimensiones | Valores no nulos, dentro de límites del operador | Revisión manual – peso/medidas |
Solo si pasa estos filtros, el sistema crea el envío y solicita la etiqueta.
Con el pedido validado, el flujo define operador y servicio según destino, método, tipo de producto, peso y SLA. Recién después crea el envío.
Dicho simple: primero decide el motor de ruteo el par operador + servicio. Después se manda el payload. Cuando el envío ya existe, toca escribir tracking, estado de fulfillment y avisarle al cliente.
El cuerpo de la solicitud tiene que incluir, como mínimo:
1.25 - y dimensiones en cmDespués, esa estructura interna se mapea a los nombres de campo de cada integración.
La respuesta devuelve tracking, ID del envío y la etiqueta en PDF, ZPL o base64. Guardá esos datos en Shipment: shipment_id, order_id, carrier_name, carrier_shipment_id, tracking_number, service_code, status, label_url o label_file_id, label_generated_at y handed_to_carrier_at.
También conviene guardar una copia del PDF. No es un detalle menor: algunos links vencen o tienen topes de acceso.
Ese mapeo sale de reglas de ruteo previas, no de una decisión manual por pedido.
| Regla | Condición | Servicio seleccionado | Fallback |
|---|---|---|---|
| Same-day AMBA liviano | CABA/GBA, peso ≤ 5 kg, pedido pago antes de las 11:30, método = same-day | Operador same-day habilitado | Segundo operador next-day |
| Estándar AMBA a domicilio | CABA/GBA, peso ≤ 25 kg, método = standard | Operador estándar AMBA | Segundo operador estándar AMBA |
| Interior estándar a domicilio | Destino fuera de AMBA, doméstico, peso ≤ 20 kg | Operador interior estándar | Segundo operador interior habilitado |
| Pesado Patagonia | Provincias patagónicas, peso > 20 kg y ≤ 40 kg | Operador habilitado para cargas pesadas | Revisión manual |
| Retiro en sucursal | Método = pickup, destino con cobertura de red | Operador con red de sucursales | Segundo operador con red propia |
| Frágil o electrónica | Producto con is_fragile o categoría electrónica | Operador con manejo especial y seguro | Operador estándar + seguro adicional |
Las reglas de ruteo tienen que vivir en una configuración centralizada, ya sea una tabla en base de datos o un archivo versionado. Así el equipo de operaciones puede ajustarlas sin tocar código.
En Argentina esto pesa mucho. Tarifas, coberturas y tiempos de tránsito cambian seguido, así que tener esa capa fuera del código te evita fricción innecesaria.
Con el envío generado y la etiqueta lista, el flujo sigue con la actualización del estado de fulfillment y el aviso automático al cliente mediante WhatsApp.
Con el envío ya creado, el paso que sigue es dejar ese cambio reflejado en la orden antes de avisarle al cliente.
Una vez emitida la etiqueta, actualizá el pedido con el tracking y el estado. El orden acá no es un detalle menor: si el mensaje sale antes de que el fulfillment esté al día, el link de seguimiento puede fallar o mostrar datos que no cierran.
Cuando el operador devuelva shipment_id y tracking_number, actualizá el pedido con:
Además, guardá metadatos internos para trazabilidad: carrier_code, service_code, shipment_id, automation_run_id y processed_at en zona horaria America/Argentina/Buenos_Aires, con formato dd/mm/yyyy HH:mm:ss. Por ejemplo: 08/08/2026 14:32:10.
También registrá una tabla inmutable de eventos (fulfillment_events) con event_type, previous_values, new_values, initiated_by_type y timestamp_utc. Esa tabla inmutable sirve para reconstruir cada cambio sin perder historial.
Con el pedido ya actualizado, recién ahí dispará la notificación. Enviá el WhatsApp solo después de persistir el fulfillment y marcar notification_sent = true.
El mensaje tiene que ser corto y directo, en es-AR:
¡Tu pedido #12345 ya fue despachado! Tracking: AND123456789AR Seguimiento: [link] Entrega estimada: entre el 12/08 y el 15/08.
Cuando algo falla, el flujo tiene que detectar el tipo de error y responder sin frenarse. Si el operador se cae o el pedido queda trabado, el proceso no debería cortarse de golpe: cambia de estado y deriva el caso para que siga por otro camino.
Separá los errores de integración, de datos y de negocio. No todos se tratan igual, y ahí está buena parte del orden del sistema.
Si los reintentos no destraban el envío, el pedido pasa a revisión manual.
Antes de volver a intentar, hacé una verificación simple pero clave: si ya existe tracking_number, cancelá el intento. Ese chequeo evita meter la pata y generar una segunda etiqueta para un pedido que ya salió.
También conviene usar una clave idempotente: fulfillment_request_id = shop_id + '-' + order_id. Dicho simple, esa clave le marca al operador que ese pedido ya tuvo una solicitud de despacho, y ayuda a frenar etiquetas duplicadas.
Cuando un pedido entra en revisión manual, Burbuxa recibe la señal y manda por WhatsApp un aviso breve al cliente, con el motivo de la demora y, si hace falta, un pedido de confirmación de datos.
Con estas reglas, podés seguir el rendimiento del flujo con indicadores bien concretos:
| Métrica | Meta |
|---|---|
| Tiempo desde pago hasta etiqueta emitida | Mediana < 30–60 min en horario hábil; 90 % dentro de 2 horas |
| Tasa de éxito en creación de etiquetas | > 95 % sin intervención manual |
| Tasa de etiquetas duplicadas | < 0,1 % (cualquier valor mayor requiere revisión de idempotencia) |
| Volumen de pedidos en revisión manual | 2–5 % aceptable; objetivo < 2 % con buena validación de datos |
| Tiempo hasta aviso al cliente con número de seguimiento | 90 % de los clientes notificados dentro de la primera hora desde el pago |
Porque order.paid pone en marcha la logística solo cuando el pago ya está confirmado. En cambio, order.created aparece apenas arranca la compra.
Eso evita errores operativos bastante comunes, como generar envíos o etiquetas para pedidos que después se cancelan o terminan con pagos fallidos. Con Burbuxa, esa sincronización en tiempo real activa únicamente las gestiones que hacen falta cuando el pedido está efectivamente pago.
Hace falta una gestión seria de errores y logs. Y, además, conviene validar el estado del pedido en tiempo real antes de disparar cualquier automatización.
También vale la pena revisar el identificador único del pedido para evitar acciones repetidas si el webhook llega más de una vez. Eso ayuda a mantener una experiencia consistente y evita notificaciones duplicadas o enviadas fuera de momento.
Conviene enviarlo por WhatsApp en momentos clave del pedido: cuando cambia a enviado, en camino o entregado.
Automatizar estos avisos hace que el cliente sepa dónde está su paquete sin tener que escribirle a tu equipo. Con Burbuxa, estas actualizaciones pueden salir justo cuando corresponde y, al confirmar la entrega, también podés pedir una evaluación del producto en la misma conversación.