El pedido pagado de VendeWare puede quedarse sin surtir, sin aviso y sin reembolso

Ya documentamos dos hallazgos sobre cómo VendeWare mueve el dinero de una venta: el CFDI global armado sin comparar contra una venta real y la merma confirmada sin aviso de destrucción al SAT. Este es distinto: no es sobre facturación ni inventario, es sobre la promesa más básica de una tienda en línea —cobrar y entregar—. Verificamos en el código de VendeWare qué pasa cuando esa promesa no se puede cumplir por falta de existencia: el pedido queda pagado, sin surtir, sin ninguna acción automática que lo repare.

La ley no exige que nunca falte inventario — exige respetar lo que se ofreció

El artículo 7 de la Ley Federal de Protección al Consumidor (LFPC, texto vigente publicado por la Cámara de Diputados) es la cláusula general que obliga a cualquier proveedor, en cualquier venta, a sostener lo que ofreció:

"Todo proveedor está obligado a informar y a respetar los precios, tarifas, garantías, cantidades, calidades, medidas, intereses, cargos, términos, restricciones, plazos, fechas, modalidades, reservaciones y demás condiciones aplicables en la comercialización de bienes, productos o servicios [...]"

Una tienda en línea que acepta el pago de un pedido está conviniendo, en ese mismo acto, entregarlo. El artículo 1, fracción VIII, de la propia ley extiende esta protección expresamente a las transacciones "efectuadas a través del uso de medios convencionales, electrónicos, ópticos o de cualquier otra tecnología" —el caso exacto de una compra en el storefront de VendeWare—. La LFPC no tiene, a diferencia del CFF con el CFDI global, un artículo que nombre literalmente "cuando falte existencia para surtir un pedido ya pagado": lo que existe es esta obligación general de respetar la condición convenida (entregar lo que se cobró), que no distingue el motivo del incumplimiento.

Agenda una demo gratis

La sanción: hasta $4,274,960.73 por incumplir esa condición

El artículo 128 de la LFPC fija la multa para quien infrinja, entre otros, el propio artículo 7:

"Las infracciones a lo dispuesto por los artículos 7 [...] serán sancionadas con multa de $1,093.02 a $4,274,960.73."

Montos vigentes por la actualización de multas de PROFECO para 2026, publicada en el Diario Oficial de la Federación en diciembre de 2025. El monto concreto dentro del rango lo determina la autoridad —normalmente a partir de una queja del consumidor ante PROFECO— y no es automático por cada pedido: es el techo de exposición si la autoridad decide sancionar el patrón.

Elemento	Qué dice la norma
Protección extendida a compras por medios electrónicos	Art. 1, fr. VIII, LFPC
Obligación de respetar plazos, fechas y condiciones bajo las que se ofreció/convino la entrega	Art. 7, LFPC
Infracción al art. 7	Multa de $1,093.02 a $4,274,960.73 (art. 128, LFPC; PROFECO, montos 2026, DOF dic-2025)

Verificado en el código: el pedido revierte a "paid" y ahí se queda

Confirmamos el hallazgo directamente en el código de VendeWare (repo medware-di, servicio storefront). El pedido nace en orders.service.ts::create() sin reservar inventario —el propio docstring del método lo dice: "NO descuenta stock (sin reserva)" (apps/services/storefront/src/orders/orders.service.ts:49)—, así que un pedido puede cobrarse sin que el sistema haya confirmado, en ese momento, que hay existencia para surtirlo.

El descuento real de inventario ocurre después, cuando el personal surte el pedido en admin.service.ts::confirmPayment(). Si en ese momento no hay existencia, la creación de la remisión falla y el catch del método revierte el pedido a su estado previo —this.repo.setStatus(c, orderId, prevStatus) (apps/services/storefront/src/admin/admin.service.ts:230-232)— para que el personal pueda reintentarlo más tarde. Es un diseño razonable para no perder un pedido por un problema temporal de stock. Pero revisamos qué más ocurre en ese catch, y qué no: no hay ninguna llamada a un servicio de correo, notificación o reembolso —confirmado con una búsqueda de "refund", "notify" y "mailer" en todo apps/services/storefront/src, que no encuentra una sola coincidencia real—. El pedido simplemente vuelve a "paid", como si el intento de surtido nunca hubiera pasado.

Y el tipo de datos sí contempla un estado para esto: StoreOrderStatus incluye 'cancelled' junto a 'pending_payment' | 'paid' | 'fulfilled' (packages/shared-types/src/storefront.ts:27). Pero ese valor nunca se asigna a un pedido en ningún punto del código —cada coincidencia real de 'cancelled' en storefront/src pertenece a suscripciones o a payment_intents, nunca a orders—. El estado para marcar "esto no se pudo cumplir" ya existe en el modelo; el flujo de falta de stock simplemente no lo usa.

Del lado del cliente, el detalle del pedido en apps/web-store/app/cuenta/pedidos/[id]/page.tsx:67-71 muestra el mismo mensaje mientras order.status === 'paid', sin condición adicional: "Pago confirmado. Estamos preparando tu pedido para envío." Si el personal ya intentó surtir el pedido y chocó con la falta de stock, el cliente no lo sabe: ve exactamente el mismo aviso tranquilizador que vería un pedido que sí va a tiempo, indefinidamente, hasta que alguien —del lado del comercio, a mano— resuelva la existencia o le devuelva el dinero por fuera del sistema.

Agenda una demo gratis

Qué significa en la práctica, y qué falta en el producto

Con el diseño actual, un comercio con VendeWare puede cobrar pedidos que después no puede surtir, sin que el sistema distinga ese caso de uno que simplemente va tarde. Nada obliga al personal a reembolsar o avisar en un plazo determinado; nada se lo recuerda tampoco, porque el pedido no cambia de estado ni aparece en ninguna cola de "pedidos atorados". Lo que falta no es una funcionalidad nueva, es usar el estado que ya existe: que el catch de confirmPayment() pueda marcar el pedido 'cancelled' tras N reintentos fallidos por stock, dispare un aviso al cliente y, si ya hubo cobro, inicie el reembolso —en vez de dejarlo indistinguible de un pedido sano. Puedes ver ese recorrido completo, del pago al intento de surtido, en del pago al surtido: el flujo completo en VendeWare, o estimar la exposición con tus propios números en la calculadora de exposición por pedidos pagados sin surtir.

Preguntas frecuentes

¿VendeWare bloquea el cobro de un pedido si no hay existencia?
No. El pedido se crea sin reservar inventario; el sistema sólo valida la existencia real al momento de surtirlo, que puede ser horas o días después del cobro.

¿Qué pasa si el surtido falla por falta de stock?
El pedido revierte a su estado previo ('paid' o 'pending_payment') para que el personal pueda reintentarlo. No se genera ningún reembolso, correo o alerta automática; el cliente sigue viendo el mismo aviso de "pago confirmado".

¿La Ley Federal de Protección al Consumidor obliga a reembolsar automáticamente?
La LFPC no fija un plazo automático de reembolso para este supuesto específico. Lo que sí exige el artículo 7 es respetar las condiciones bajo las cuales se ofreció la venta —incluida la entrega—; no hacerlo es infracción sancionable conforme al artículo 128, con multa de $1,093.02 a $4,274,960.73.

¿Esto significa que a todos los comercios que usan VendeWare se les han quedado pedidos sin surtir?
No necesariamente: el gap es que el sistema no lo detecta ni lo repara solo, no que ya haya ocurrido en tu comercio. Si tu equipo revisa a diario los pedidos "paid" sin remisión, hoy no tienes el problema —pero tampoco tienes ninguna alerta si algún pedido se te pasa.

Fuentes consultadas: Ley Federal de Protección al Consumidor, texto vigente publicado por la Cámara de Diputados del H. Congreso de la Unión, artículos 1, 7 y 128. Actualización de montos de operaciones y multas de PROFECO para 2026, Diario Oficial de la Federación, diciembre de 2025. Este artículo es orientativo y no sustituye una revisión de tu caso por tu abogado o asesor legal.