Change an order's status according to the payment method in PrestaShop

In PrestaShop, the payment module takes part in assigning the order's initial status. Before changing it, find out what that status means in your shop and what actions it triggers: stock reservation, invoice, email, fulfilment or logistics integration.

Do not mark an order as paid before the payment has actually been confirmed. A status is part of the business flow, not just a coloured label.

Look for a maintainable option

1. Note the PrestaShop version, the payment module and the status currently assigned.
2. Check whether the module lets you configure the initial status.
3. Review that status's settings and its effects on payment, stock and documents.
4. If you need development work, use a module or extension mechanism compatible with that version.
5. Test the change on a clone with test gateways before applying it to production.

The payment modules documentation helps the developer review the contract for the relevant version. Do not copy a patch from another branch without checking the full flow.

Historical reference: ps_cashondelivery

In older implementations of ps_cashondelivery, the controllers/front/validation.php file called validateOrder() passing the status identifier as the second argument. An expression such as Configuration::get('PS_OS_PREPARATION') retrieved the status configured for preparation.

This reference helps you recognise an old customisation. It is not an instruction to edit the current module: an update can overwrite the change and the implementation may be different.

Keys such as PS_OS_PAYMENT, PS_OS_CANCELED or PS_OS_REFUND refer to configured statuses, not to a bank confirmation. Do not hardcode numbers copied from another shop or assume that every key from an older version exists in yours.

Test the full flow

Check pending order, confirmation, failure, cancellation and refund where relevant. Include late or repeated notifications from the gateway: they should not duplicate charges, orders or emails.

Review the order history, stock, invoice and what the customer sees. Changing the status manually for a test does not necessarily reproduce the module's real callback.

If the shop relies on an old patch, document it and plan its replacement before updating. Keep a copy of files and data and define how to roll back without losing new orders.