WooCommerce 11.0 restaura stock en órdenes fallidas

Actualizado el 30/07/2026: WooCommerce sumó un segundo cambio técnico a la versión 11.0. Desde el anuncio del 29 de julio de 2026, la acción woocommerce_removed_order_items ahora se dispara recién cuando la eliminación de items ya terminó en la base de datos, para frenar un bug que dejaba órdenes con el total correcto pero con 0 items cuando un checkout intermedio fallaba.

En pocas palabras: Sí. Desde WooCommerce 11.0, una orden que pasa al estado Failed y ya había descontado stock lo restaura automáticamente al inventario. Antes esto solo ocurría con órdenes canceladas; ahora WooCommerce engancha wc_maybe_increase_stock_levels() a woocommerce_order_status_failed.

WooCommerce 11.0 cambia cómo se maneja el inventario en órdenes fallidas: si una orden ya había descontado stock y después pasa al estado Failed, ahora WooCommerce restaura ese stock de forma automática. El cambio se hizo enganchando la función wc_maybe_increase_stock_levels() a la acción woocommerce_order_status_failed, según el anuncio oficial de WooCommerce.

La restauración de stock en WooCommerce 11.0 es un comportamiento nuevo que devuelve al inventario las unidades de una orden que se marcó como Failed (fallida) después de haber reducido stock. Antes solo pasaba con órdenes canceladas. Es una función del core de WooCommerce, el plugin de comercio electrónico de Automattic, y aplica a cualquier tienda que actualice a la versión 11.0.

WooCommerce es un plugin de comercio electrónico de código abierto, desarrollado por Automattic, que permite crear y gestionar tiendas online en WordPress. Es ampliamente utilizado para plataformas de e-commerce.

WooCommerce es un plugin de WordPress para e-commerce desarrollado por Automattic que permite crear tiendas en línea y gestionar productos, pagos e inventario. Es una solución de código abierto ampliamente utilizada en sitios de comercio electrónico.

¿Por qué antes el stock quedaba bloqueado en órdenes fallidas?

Porque hasta WooCommerce 10.x el core solo devolvía las unidades al inventario cuando una orden pasaba al estado Cancelled, nunca cuando terminaba en Failed. Resultado: una orden podía descontar stock, quedar en Failed y mantener ese stock reducido de forma indefinida. Nadie lo devolvía salvo que vos entraras a mano.

El caso típico son los métodos de pago asíncronos. Ponele que un cliente arranca una transferencia o un pago que la pasarela acepta «para procesar»: la orden pasa a Processing, descuenta las unidades y espera la confirmación. Si después el pago se rechaza, la orden termina en Failed. Con el comportamiento viejo, esas unidades seguían figurando como vendidas aunque no cobraste nada.

¿El efecto práctico? Sobre todo en tiendas con stock ajustado, terminabas mostrando «agotado» un producto que en realidad tenías. Perdías ventas por un fantasma en el inventario. Lo explicamos a fondo en mejorar la experiencia de compra.

¿Qué es una orden con estado «Failed» en WooCommerce?

Una orden Failed es una orden cuyo pago no se completó: la pasarela lo rechazó, hubo un error de procesamiento o la transacción quedó trunca. Es distinta de Cancelled (que suele cancelar el cliente o el admin) y de Processing (pago aceptado, pendiente de preparar). En términos de inventario, es el estado que más problemas daba antes de la 11.0.

• Failed (fallida): el intento de cobro no prosperó. Puede venir de una tarjeta rechazada o de un pago asíncrono que después se cae.
• Cancelled (cancelada): alguien la dio de baja a propósito. Acá el stock ya se restauraba desde antes.
• Processing (procesando): el pago entró y la orden está lista para preparar. Este estado sí descuenta stock.

El detalle fino: no toda orden fallida descontó stock antes. Y eso, como vas a ver, es justo lo que mira la función que hace la restauración. Ya lo cubrimos antes en mejorar la experiencia del cliente.

¿Cómo funciona la restauración automática del stock en WooCommerce 11.0?

Funciona con una sola línea: WooCommerce 11.0 engancha la función wc_maybe_increase_stock_levels() a la acción woocommerce_order_status_failed. Cuando una orden entra en Failed, se dispara esa acción, la función revisa si la orden había reducido stock y, si es así, lo devuelve al inventario. Todo automático, sin que toques nada.

La clave está en el «maybe» del nombre. La función no devuelve unidades a lo loco: primero chequea si esa orden en particular había descontado stock. Si nunca lo hizo, no cambia nada. Este guard es lo que evita que el inventario se infle por órdenes que jamás tocaron el stock. Cubrimos ese tema en detalle en usar plugins consolidados y ligeros.

En criollo: subís a la 11.0, una orden con pago asíncrono descuenta dos remeras, el pago se cae más tarde, la orden pasa a Failed y esas dos remeras vuelven solas al stock disponible, sin que un empleado tenga que acordarse de revisar la lista de órdenes rechazadas a fin de día.

¿En qué casos impacta más este cambio de inventario?

Impacta sobre todo en tiendas con métodos de pago asíncronos, donde el cobro se confirma después de crear la orden. Ahí es donde el stock quedaba trabado con más frecuencia. Si tu checkout depende de estos flujos, la 11.0 te saca un dolor de cabeza recurrente.

• Transferencias y pagos diferidos: la orden se crea y descuenta stock antes de que el dinero esté confirmado. Si el pago no llega, ahora el stock vuelve solo.
• Billeteras y pagos en revisión: cualquier pasarela que acepte «para procesar» y después pueda rechazar entra en este escenario.
• Tiendas con stock chico: si vendés unidades limitadas, un solo producto trabado te podía costar una venta. Acá el beneficio se nota rápido.

Para el ecommerce argentino esto suma, porque buena parte de las ventas locales pasa por medios que no confirman al instante. Y si estás moviendo tu tienda a un hosting WordPress como el de Donweb, actualizar a la 11.0 en el mismo movimiento te deja el manejo de inventario ya resuelto por defecto.

¿Qué pasa si mi tienda usa el estado «Failed» en extensiones personalizadas?

Si tenés extensiones o código propio que usa Failed para flujos que no son de pago, revisá tu lógica antes de actualizar. WooCommerce lo dice claro: la mayoría no necesita hacer nada, pero las tiendas que reutilizan ese estado para otra cosa deben chequear cómo manejan las órdenes y qué esperan del inventario.

Pensá en un caso raro: usás Failed como marca interna para órdenes que quedaron en espera de una validación manual, no porque falló un cobro. Con la 11.0, si esas órdenes habían descontado stock, ahora ese stock se restaura al pasar a Failed. Puede que no sea lo que querías. Esto se conecta con lo que analizamos en enriquecer tu catálogo con IA.

El tema es que el hook nuevo corre siempre que una orden entra en Failed. Si tu extensión hookeaba ese mismo estado con otra intención, ahora convive con la restauración del core. Probalo en staging y mirá el orden de ejecución de tus add_action. Un test rápido te ahorra una sorpresa en producción.

¿Cuáles son los requisitos para que la restauración de stock funcione?

La condición es una sola: la orden tiene que haber reducido stock antes de pasar a Failed. La función wc_maybe_increase_stock_levels() verifica ese dato en la orden y solo devuelve unidades si el descuento ocurrió. Órdenes que nunca tocaron el inventario no cambian nada al fallar. Para más detalles técnicos, mirá plugins compatibles con esta versión.

• Orden que descontó stock y pasa a Failed: restaura el stock. Este es el escenario que el cambio vino a resolver.
• Orden que nunca descontó stock y pasa a Failed: no cambia. El guard interno la deja intacta.
• Gestión de inventario activa: el mecanismo aplica a productos con control de stock. Si no manejás inventario en un producto, no hay nada que restaurar.

Comparativa: manejo de stock antes y después de WooCommerce 11.0

Situación	WooCommerce 10.x y anteriores	WooCommerce 11.0
Orden pasa a Cancelled con stock descontado	Restaura stock	Restaura stock
Orden pasa a Failed con stock descontado	No restaura (queda bloqueado)	Restaura de forma automática
Orden pasa a Failed sin haber descontado stock	No cambia	No cambia
Pago asíncrono rechazado tras Processing	Stock reducido indefinidamente	Stock devuelto al inventario
Intervención manual requerida	Sí, a mano por cada orden fallida	No, corre solo

WooCommerce 11.0: cambios en las acciones de los items del pedido

El segundo cambio de WooCommerce 11.0 para desarrolladores toca las acciones de los items del pedido: woocommerce_removed_order_items ahora se ejecuta después de que la eliminación de items terminó en la base de datos, no en el medio del proceso. Es un ajuste chico en el código del core, pero apunta a un bug concreto que rompía órdenes durante checkouts fallidos. WooCommerce lo detalló en su blog para desarrolladores el 29 de julio de 2026.

Para entender por qué importa hay que saber cuándo WooCommerce borra items de una orden. Pasa cuando un checkout se reanuda: si un cliente vuelve a intentar el pago sobre una orden en borrador, el core limpia los items viejos antes de escribir los nuevos. Ahí entran en juego estas dos acciones. El cambio de la 11.0 apunta justo a ese momento, y por eso el conjunto de WooCommerce 11.0 cambios acciones pedido merece una lectura aparte si mantenés extensiones.

¿Cuándo se ejecuta woocommerce_removed_order_items en WooCommerce 11.0?

En WooCommerce 11.0, woocommerce_removed_order_items se dispara recién cuando la eliminación de los items ya se completó en la base de datos. Antes corría durante el proceso de borrado, con la operación a medio terminar. El cambio es de timing: la acción se difiere (deferred) hasta el final, así el callback recibe una orden con los items ya efectivamente eliminados, no en un estado intermedio.

La diferencia se ve mejor en secuencia. En 10.9, el flujo era: arranca el borrado, se dispara removed_order_items, y recién después la base de datos termina de confirmar la eliminación. En 11.0 el orden se invierte: primero se completa el borrado en la base, y solo entonces se dispara la acción. El hook queda al final de la cadena.

Para un callback que lee el estado de la orden, esto es un cambio real. Si tu código asumía que los items todavía estaban ahí cuando la acción se ejecutaba, ese supuesto ya no se sostiene. Ahora, cuando tu función corre, los items no están más. El comportamiento es más predecible, pero distinto al que había.

¿Por qué WooCommerce cambió el timing de la acción en la versión 11.0?

Para cerrar un bug donde una orden podía quedar con el total correcto pero con 0 items. El escenario aparecía cuando un checkout se reanudaba y algo fallaba en el medio: la acción vieja corría antes de que la base terminara de reconstruir los items, y si el resume se caía, la orden quedaba a mitad de camino. Total calculado, carrito vacío. Un estado inconsistente que después había que reparar a mano.

Al diferir la acción hasta después del borrado, WooCommerce mantiene la atomicidad del flujo. La idea es que la operación de eliminar items sea un bloque cerrado: o se completa entera, o no dispara la acción que otros procesos escuchan. Así se evita que un callback enganchado a removed_order_items actúe sobre una orden que todavía está en un estado transitorio. Te puede servir nuestra cobertura de automatización inteligente de tu tienda.

El beneficio práctico es evitar pérdida de datos cuando un resume de checkout falla. Antes, un pago que se reintentaba y se caía en el momento justo podía dejar el rastro roto. Con el nuevo timing, si el borrado no llega a completarse, la acción no corre, y no arrastra a otras extensiones a operar sobre datos a medio escribir. Es el mismo principio de manejo cuidadoso del inventario que vimos con las órdenes fallidas, aplicado ahora al ciclo de vida de los items.

¿Cuál es la diferencia entre woocommerce_remove_order_items y woocommerce_removed_order_items?

La diferencia está en el momento del flujo: woocommerce_remove_order_items (sin la «d») se dispara al inicio, antes de borrar nada, y sigue igual en la 11.0; woocommerce_removed_order_items (con la «d») se dispara al final, y es la que cambió de timing. Una marca el arranque de la operación, la otra su cierre. Solo la segunda se movió.

• woocommerce_remove_order_items: corre al comienzo, cuando WooCommerce está por eliminar los items. Sin cambios en la 11.0. Si tu código necesita leer los items antes de que desaparezcan, este es tu hook.
• woocommerce_removed_order_items: corre al final, ahora recién cuando el borrado ya se completó en la base. Es la que se difirió. Si tu código actúa después de la limpieza, acá está el cambio de comportamiento.

Aspecto	WooCommerce 10.9 y anteriores	WooCommerce 11.0
Momento de woocommerce_removed_order_items	Durante la eliminación	Después de completarla en la base
Estado de los items dentro del callback	Podían no estar borrados aún	Ya eliminados por completo
woocommerce_remove_order_items (al inicio)	Sin cambios	Sin cambios
Checkout resumido que falla	Riesgo de total correcto con 0 items	Flujo atómico, sin órdenes inconsistentes
Acción requerida en la mayoría de extensiones	—	Ninguna

¿Qué extensiones WooCommerce necesitan actualización?

Las extensiones que necesitan revisión son las que enganchan un callback a woocommerce_removed_order_items y esperaban leer los items dentro de esa función. Con el timing viejo, algunas dependían de que los items todavía estuvieran presentes cuando la acción se disparaba. Ese supuesto ya no vale: ahora, cuando tu callback corre, los items no están más. Si tu extensión no toca ese hook, no hay nada que hacer.

• Extensiones de logging o auditoría: las que registraban qué items se borraban leyéndolos dentro del callback. Ahora tienen que capturar esos datos en remove_order_items, no en removed_order_items.
• Sincronización con sistemas externos: plugins que empujaban cambios a un ERP o CRM al detectar la eliminación. Si dependían del estado intermedio, hay que ajustar cuándo leen la orden.
• Lógica de checkout personalizada: cualquier extensión que reaccionaba al borrado de items durante un resume de pago conviene revisarla en staging.

¿Los síntomas de incompatibilidad? Un callback que antes leía la lista de items y ahora la recibe vacía, logs que quedan incompletos, o datos que no se sincronizan porque el código busca items que ya se eliminaron. Nada de esto rompe el checkout del cliente, pero puede vaciar de sentido a tu extensión sin tirar un error visible.

¿Cómo actualizar tu extensión para WooCommerce 11.0 y mantener compatibilidad hacia atrás?

El paso central es mover cualquier lectura de items que hacías en removed_order_items hacia remove_order_items, que corre antes del borrado y donde los items todavía existen. Reservá removed_order_items para lo que tenga sentido hacer después de la limpieza: confirmar, notificar, cerrar. Revisá tus add_action y separá qué necesita el «antes» y qué el «después».

• Revisá tus callbacks: listá qué funciones enganchás a cada acción y qué leen de la orden. Marcá las que dependían de items ya presentes durante el borrado.
• Ajustá el orden de ejecución: si tu código leía y actuaba en el mismo hook, dividilo. Capturá los datos en remove_order_items y ejecutá la consecuencia en removed_order_items.
• Testeá en ambas versiones: generá un checkout que se reanude y falle en 10.9 y en 11.0, y compará el resultado. Un staging con las dos ramas te da la foto real.

Para soportar 10.9 y 11.0 a la vez sin ramificar todo el código, podés detectar la versión con la constante WC_VERSION y ajustar la lógica según el timing esperado. No siempre hace falta: si movés la lectura de items al hook que no cambió, tu extensión funciona igual en las dos versiones porque remove_order_items se comporta idéntico. La detección de versión queda para casos borde donde de verdad necesitás dos caminos distintos. Lo explicamos a fondo en pasos para actualizar correctamente.

¿Qué ocurre si la extensión no se actualiza para WooCommerce 11.0?

Si una extensión que dependía del timing viejo no se actualiza, sus callbacks se ejecutan en un momento inesperado: corren cuando los items ya no están. El código no se rompe con un error fatal, pero puede leer datos vacíos, saltear pasos o actuar sobre una orden que ya cambió de estado. El resultado suele ser silencioso, y esos son los peores de detectar.

• Posibles race conditions: si tu extensión asumía un orden de operaciones que ya no se cumple, dos procesos pueden pisarse.
• Datos inconsistentes en el resume de checkout: logs incompletos o sincronizaciones que reflejan un estado que ya no existe.
• Comportamiento difícil de reproducir: como el bug aparecía en checkouts que fallaban en el medio, el síntoma es intermitente. Testear con un resume forzado a fallar ayuda a exponerlo.

¿Conviene actualizar a WooCommerce 11.0 por estas mejoras?

Para la mayoría de las tiendas, sí, y sin trámite: tanto la restauración de stock como el cambio de timing corren automáticos y no piden configuración. El propio anuncio aclara que, para la mayoría de las tiendas y extensiones, no se requiere ninguna acción. Si vendés con pagos asíncronos, el beneficio de inventario es directo. Si mantenés extensiones que hookean el borrado de items, primero probá en staging.

• Hacé backup: antes de cualquier actualización de WooCommerce, respaldá base de datos y archivos.
• Probá en staging: replicá tu tienda, actualizá ahí y generá una orden que falle y un checkout que se reanude para ver ambos cambios en vivo.
• Revisá extensiones de stock e items: si tenés plugins de inventario o hooks propios sobre Failed o sobre las acciones de items, confirmá que conviven bien con el comportamiento nuevo.

Qué está confirmado y qué queda por ver

• Confirmado: WooCommerce 11.0 restaura stock en órdenes que pasan a Failed y habían descontado inventario, vía wc_maybe_increase_stock_levels() sobre la acción woocommerce_order_status_failed.
• Confirmado: woocommerce_removed_order_items ahora se difiere hasta después de completar la eliminación de items en la base de datos.
• Confirmado: woocommerce_remove_order_items no cambió; sigue disparándose al inicio del borrado.
• Confirmado: la mayoría de tiendas y extensiones no necesita hacer nada tras actualizar.
• Por ver: cómo reacciona cada extensión de terceros que hookea esos estados o esas acciones. El core recomienda revisar, no publica una lista de plugins afectados.
• Por ver: comportamientos borde en flujos donde Failed o el borrado de items se usan fuera del contexto estándar de pago. Ahí la recomendación es testear caso por caso.

Errores comunes al actualizar a WooCommerce 11.0

• Actualizar directo en producción: subir la 11.0 sin pasar por staging. Si tenés lógica custom sobre Failed o sobre las acciones de items, el orden de tus hooks puede cambiar. Corré una orden de prueba antes.
• Asumir que arregla el stock viejo: el cambio actúa de acá en adelante, sobre órdenes que pasan a Failed después de actualizar. El inventario que ya quedó trabado en órdenes fallidas viejas hay que ajustarlo a mano.
• No revisar los callbacks de items: dar por hecho que una extensión que lee items en removed_order_items sigue igual. Con el nuevo timing, esos items ya no están dentro del callback.
• Ignorar las extensiones de inventario: si alguna hookeaba Failed con otra intención, ahora convive con la restauración del core y puede duplicar o pisar acciones.
• No hacer backup: el clásico. Una actualización de WooCommerce toca la capa de comercio de tu sitio; sin respaldo, cualquier sorpresa se vuelve un problema serio.

Preguntas Frecuentes

¿Cuándo se ejecuta ahora woocommerce_removed_order_items en WooCommerce 11.0?

Se ejecuta recién cuando la eliminación de los items ya se completó en la base de datos, no durante el proceso de borrado como antes. WooCommerce difirió la acción hasta el final para que el callback reciba una orden con los items ya eliminados. En 10.9 podía correr con la operación a medio terminar; en 11.0 corre al cierre.

Esto lo tocamos con más detalle en cambios en WooCommerce 11.0.

¿Qué extensiones necesitan actualización por el cambio en WooCommerce 11?

Las que enganchan un callback a woocommerce_removed_order_items y leían los items dentro de esa función, esperando que todavía estuvieran presentes. Con el nuevo timing, esos items ya se borraron cuando el callback corre, así que la lectura devuelve vacío. La solución es mover esa lectura a woocommerce_remove_order_items, que se dispara antes del borrado y no cambió.

¿Qué cambió en WooCommerce 11.0 con la gestión de stock?

WooCommerce 11.0 restaura automáticamente el stock de una orden cuando pasa al estado Failed, siempre que esa orden haya descontado inventario antes. Hasta la versión 10.x, el stock solo se devolvía en órdenes canceladas, así que las fallidas mantenían el inventario reducido de forma indefinida. Para más detalles técnicos, mirá actualizar WooCommerce a versión 11.0.

¿Necesito hacer algo en mi tienda si paso a WooCommerce 11.0?

Para la mayoría de las tiendas, no: los dos cambios de la 11.0 son automáticos y no piden configuración. La excepción son las tiendas o extensiones que usan el estado Failed para flujos que no son de pago, o que hookean las acciones de items del pedido, que deberían revisar su lógica antes de actualizar.

¿Por qué WooCommerce cambió el timing de woocommerce_removed_order_items?

Para evitar un bug donde una orden quedaba con el total correcto pero con 0 items cuando fallaba un checkout que se estaba reanudando. Al diferir la acción hasta después de completar el borrado en la base, WooCommerce mantiene la operación atómica y evita que otras extensiones actúen sobre una orden en estado intermedio, previniendo la pérdida de datos si el resume falla.

Conclusión

WooCommerce 11.0 trae dos cambios que apuntan a lo mismo desde ángulos distintos: que el estado de una orden sea siempre consistente. Por un lado, una orden que falla y había descontado stock ahora devuelve esas unidades sola. Por el otro, la acción woocommerce_removed_order_items se difiere hasta que el borrado de items terminó, para que nadie actúe sobre una orden a medio armar.

Qué hacer: si tu tienda usa flujos estándar de pago, actualizá con un backup y listo, el core hace el resto. Si mantenés extensiones que hookean Failed o las acciones de items del pedido, montá un staging, generá una orden que falle y un checkout que se reanude, y verificá que tus callbacks siguen leyendo lo que esperan. De acá en adelante, conviene seguir el blog para desarrolladores de WooCommerce: los cambios de la 11.0 llegan de a poco y algunos, como este, solo se notan si tenés código propio enganchado al ciclo de vida de la orden.

Fuentes

• Developer Blog de WooCommerce – cambio de timing en las acciones de items removidos del pedido (29/07/2026)
• Developer Blog de WooCommerce – anuncio oficial del cambio de stock en órdenes fallidas
• Developer Blog de WooCommerce – documentación y novedades para desarrolladores
• WooCommerce – sitio oficial del plugin de comercio electrónico