Returns in PrestaShop: how to settle a partial order return?

A partial refund in PrestaShop should be settled at the level of specific order items and quantities. First, determine what the customer is returning and how much they actually paid for it. Then record the request, receipt of the parcel, and the refund separately. This way, returning one product does not turn into cancelling the entire order, and the next support agent can see what has already been done.

This guide is for store owners and after-sales support teams. It shows the process and a demonstration calculation for a cart with three items. The amounts and products are examples; they do not come from a customer order.

1. Start with the order, item and quantity

The message “I’m sending back the mug” is not enough for safe settlement. The order may contain two mugs, a different colour of the same model, or a product purchased as part of a bundle. The request should indicate the order number, the correct item, variant, and the number of units being returned. The person handling the case must also check previous returns related to that purchase.

The basis for the amount is the historical order record. The current catalogue price may have changed after the purchase, and the discount may have resulted from a product promotion, a cart code, or purchase conditions. Using today’s price or ignoring a previous settlement gives an incorrect result, even if the return form itself works correctly.

• Identify the customer and the order in the manner adopted by the store; the public order number alone should not disclose their data.
• Select the item and variant from the order instead of copying the name from the current product page.
• Check the quantity purchased, previously returned, and remaining to be settled.
• Record the date the statement was received regardless of the later parcel delivery date.

2. Separate the status of the request, parcel and money

The most common misunderstandings start with a single status: “return completed”. For the warehouse, this may mean a received parcel; for accounting, an issued document; and for the customer, money in their account. These events are not the same.

The table below is a proposed workflow, not an interface screenshot or mandatory module status names.

Receipt of goods should not automatically mean they are available for sale again. First assess their condition and determine the warehouse decision. Likewise, a correction document or a refund entry in the panel is not in itself proof of a transfer.

3. Example: one mug from a discounted cart

Let us assume the order is: a bottle for PLN 100, two mugs at PLN 50 each, and a blanket for PLN 100. The product value is PLN 300. The cart discount is PLN 30 and in this example applies proportionally to all products. Delivery cost PLN 15, so the customer paid PLN 285. They return one mug.

PLN 50 minus PLN 5 of assigned discount gives PLN 45 for the returned mug. We do not subtract the entire PLN 30 discount from one unit, and we do not refund the customer the price before the code was applied. However, the way the discount is allocated must be related to its actual conditions: a discount only on the bottle should not reduce the value of the mug.

The table calculates the product part and does not determine the final amount due. The original delivery cost, return shipping cost, and any return label require separate determination. In the case of a partial withdrawal, do not apply the automatic rule “we always refund the full delivery” or “we never refund it” without analysis. Do not deduct the label fee just because the field exists in the system.

If the customer later returns the second mug, support should see the first payout. Checking the remaining quantity and amount is necessary for subsequent requests and when correcting a failed operation.

4. Withdrawal from the contract vs complaint

In a typical online purchase, a consumer may, as a rule, withdraw from the contract without giving a reason within 14 days; there are statutory exceptions. A complaint due to non-conformity of goods with the contract, on the other hand, concerns a problem with the goods and has its own conditions and possible claims. The form should make it possible to identify the type of case instead of treating every complaint like a standard return of purchase. Explanations: UOKiK — withdrawal deadlines and UOKiK — non-conformity of goods with the contract.

UOKiK also distinguishes between the costs of delivering the order and the costs of returning the goods. In the case of withdrawal concerning the entire contract, significance is attached, among other things, to the cheapest ordinary delivery method offered by the seller. The rules for full withdrawal should not be transferred unreflectively to every partial refund configuration. Details and examples: UOKiK — withdrawal costs. The module settings must be adapted to the applicable rules and the specific situation; installation alone does not ensure the legal compliance of the process.

5. How to confirm the actual refund of money?

Before the payout, check the original payment method, transaction identifier, currency, and the remaining possible amount. For automatic integration, correct configuration of the given operator is required. The mere presence of its name on the list does not mean that a specific order can be settled via API.

After ordering, save the refund identifier and read its result. If a timeout occurs, do not immediately order a second payout: first check the first operation on the operator’s side. The request may have arrived despite the lack of a response in the panel. In the case of a manual refund, attach proof of execution and only then mark the case according to the adopted process.

The message “we have ordered the refund” should mean that the instruction has been sent. The message about a completed payout should result from a confirmed status. Do not promise the customer that the funds are already in their account when the system confirms only acceptance of the request.

6. Where does the Returns and Withdrawals Pro module help?

Returns and Withdrawals Pro organises requests, returned items, calculation and case history. The scope verified in the code of version 1.3.29 includes calculating amounts for selected quantities and taking into account discounts, delivery, fees, and the remaining order amount. The module has manual settlement paths and automatic integrations, the use of which depends on the configuration and the original payment.

The described example is a demonstration of the process and arithmetic. It does not constitute a payout test with every operator or confirmation of compatibility with any version of an external payment module.

Checklist before closing the case

• The item, variant and number of received units match.
• The calculation uses the order and takes the correct discount into account.
• Delivery and other settlements have a separately recorded basis.
• The history includes previous payouts and the identifier of the current operation.
• Documents, stock status and the customer message correspond to what was actually done.

Do you want to organise this process in your store? See partial refund handling in the Returns and Withdrawals Pro module. When choosing the configuration, indicate the payment method used and the way return parcels are handled.

Substantive verification: 13 September 2026. Demonstration example, without customer data. Material prepared on the basis of UOKiK documentation and the module code; it does not describe an executed refund transaction.