Refunding through the payment gateway so the corrective invoice adds up

A customer returns two of the five units in an order. Someone logs into the gateway dashboard and refunds the amount. Someone else generates the credit slip in PrestaShop. At the end of the month, the accountant sees a negative movement in the bank and looks for the corrective invoice. And it does not add up: the gateway refunded the shipping, the credit slip does not include it and the corrective invoice has yet another amount because someone recalculated it by hand.

A refund leaves a trace in three places: the payment gateway (the money), the store (the order and its credit slip) and the accounts (the corrective invoice, known in Spain as factura rectificativa: the document that legally amends an invoice already issued). This article is about making all three say the same thing.

The three records and what each one means

Making a refund from the gateway dashboard creates nothing in the store. Generating a credit slip in PrestaShop moves no money. And neither of them, on its own, guarantees that the corrective invoice is correct. They have to come from the same data.

The order that avoids mismatches

1. Decide what is being refunded in the store: lines, quantities, whether shipping is included, whether there is any charge. That is the starting data.
2. Calculate the amount from those lines, with their taxes. Not the other way round: a round amount typed in by hand rarely breaks down neatly into tax bases and tax amounts.
3. Carry out the refund on the gateway for that exact amount.
4. Generate the corrective invoice with those same lines and amounts.
5. Update the order: status, stock restored if applicable, internal note with the reason.

If the refund fails on the gateway, do not generate the corrective invoice until it is resolved. If you have already generated it, do not delete it: document and correct.

The cases that cause the most mismatches

Partial refunds with discounts

If the order had a 10% voucher and the customer returns one line, how much do you refund? The price they actually paid for that line, with the discount prorated. Refunding the catalogue price means refunding too much; a fixed-amount voucher spread across lines with different VAT rates is the trickiest case.

Shipping costs

Decide on a clear policy: when an order is withdrawn from in full, consumer law requires you to refund the basic delivery costs of the original shipment; for partial returns or returns for other reasons it depends on your terms. Whatever it is, the refund, the credit slip and the corrective invoice have to treat shipping the same way.

Gateway fees

The fee the gateway charged for the original payment may not be returned when you refund, depending on the provider. That is your cost, not an amount owed by the customer: do not deduct it from the refund unless your terms provide for it, and do not mix it into the corrective invoice.

Repeated refunds

A connection that fails, someone who clicks twice, an automatic retry. Without control, the customer gets the money twice. Any refund system has to check what has already been refunded before issuing another.

Refunds outside the gateway

Bank transfers, vouchers or store credit. There is no movement on the gateway, but there still has to be a credit slip and a corrective invoice, plus a note of how the money was returned.

Order statuses and stock

The refund also has to be reflected in the order, and not just for tidiness: sales reports, statistics and any integration with an ERP or with analytics read the status.

• Full refund: the order moves to a refunded status. If it stays as “Delivered”, your reports count a sale that no longer exists.
• Partial refund: a dedicated partial refund status, or a clear note, so that nobody refunds again what has already been returned.
• Stock: restock only what has come back to the warehouse in a saleable condition. A product returned broken is refunded but does not go back into available stock.
• Cancellations before shipping: if the order was paid and is cancelled before it leaves, there is a refund, but if it had not yet been invoiced you do not need a corrective invoice: simply do not invoice it.

If you measure sales with GA4 or other platforms, send them the refund too. Otherwise, their revenue will still include money you have already returned.

Reconciling at the end of the month

A simple reconciliation that catches almost every problem:

1. Export the refunds for the period from the gateway.
2. Export the credit slips or corrective invoices for the same period from the store.
3. Match them by order and amount.
4. Review the leftovers on each side: refunds without a corrective invoice (documentation missing) and corrective invoices without a refund (money not yet returned, or returned some other way).

Do it every month. A one-month mismatch is fixed in minutes; a one-year one, in days. And decide who can refund: if any employee with access to the gateway dashboard can return money without going through the store, refunds without documents will keep appearing.

How to handle it in PrestaShop

RKR Refound Orders refunds all or part of an order on the original gateway without leaving the back office (Stripe, PayPal, Redsys and Bizum, Paycomet, manual or via a hook for other payment modules). From the order you select lines and quantities or a free amount, choose whether to include shipping and the reason, and each refund generates its own corrective invoice as a PDF with its own numbering. It prevents refunding twice by order, amount and connector, can require approval above a set amount, optionally restocks and changes the order status, and keeps an audit trail of every call. If a credit slip generated by PrestaShop came out wrong, the corrective invoice editor lets you correct lines, amounts with and without VAT, shipping, discounts and date from the back office, with recalculate and reset from the order; do it before that document reaches your accounts or your invoicing system.