Cambiar el estado de un pedido según el método de pago en PrestaShop

En PrestaShop, el módulo de pago participa en la asignación del estado inicial del pedido. Antes de cambiarlo, identifica qué significa en tu tienda y qué acciones provoca: reserva de stock, factura, correo, preparación o integración logística.

No marques un pedido como pagado antes de la confirmación real del cobro. Un estado es parte del flujo del negocio, no solo una etiqueta de color.

Buscar una opción mantenible

1. Anota versión de PrestaShop, módulo de pago y estado que se asigna ahora.
2. Comprueba si el módulo permite configurar el estado inicial.
3. Revisa la configuración de ese estado y sus efectos sobre pago, stock y documentos.
4. Si necesitas desarrollo, utiliza un módulo o mecanismo de extensión compatible con esa versión.
5. Prueba el cambio sobre un clon con pasarelas de prueba antes de aplicarlo a producción.

La documentación de módulos de pago sirve al desarrollador para revisar el contrato de la versión correspondiente. No copies un parche de otra rama sin comprobar el flujo completo.

Referencia histórica: ps_cashondelivery

En implementaciones antiguas de ps_cashondelivery, el archivo controllers/front/validation.php llamaba a validateOrder() pasando el identificador del estado como segundo argumento. Una expresión como Configuration::get('PS_OS_PREPARATION') recuperaba el estado configurado para preparación.

Esta referencia ayuda a reconocer una personalización antigua. No es una instrucción para editar el módulo actual: una actualización puede reemplazar el cambio y la implementación puede ser distinta.

Claves como PS_OS_PAYMENT, PS_OS_CANCELED o PS_OS_REFUND hacen referencia a estados configurados, no a una confirmación bancaria. No hardcodees números copiados de otra tienda ni supongas que todas las claves de una versión antigua existen en la tuya.

Probar el flujo completo

Comprueba pedido pendiente, confirmación, fallo, cancelación y devolución cuando procedan. Incluye notificaciones tardías o repetidas de la pasarela: no deberían duplicar cobros, pedidos ni correos.

Revisa el historial del pedido, stock, factura y lo que ve el cliente. Cambiar el estado manualmente para una prueba no reproduce necesariamente el callback real del módulo.

Si la tienda depende de un parche antiguo, documéntalo y prepara su sustitución antes de actualizar. Conserva una copia de archivos y datos y define cómo revertir sin perder pedidos nuevos.