Online Payments: How to Handle Paid, Failed, and Refunded Orders

The most costly mistake isn't the order that never gets paid: it's the package shipped for a payment that never arrived, and the refund issued twice because two people looked at two different screens. It happens because in the store, in the payment system, and in the mind of whoever is working, the word “order” means three different things. This guide puts them in order and sets out, for each status, what is allowed.

Three events, not one

• The order created. The customer has filled in the cart and their details, and an order number exists. From a money standpoint, nothing has happened yet.
• The payment started. The customer has been sent to pay or has entered their card details. From this point on, the outcome no longer depends on your store.
• The payment collected. The payment system reports that the transaction was successful. This is the only event that authorizes preparing the goods.

The typical confusion is treating the thank-you page as a confirmation. That page only says that the customer has returned to the site: they can land on it even after a declined payment, and may never land on it after a successful one.

Confirmation arrives later, and not from the browser

The notification that counts is the one the payment system sends to yours, without going through the customer. It can arrive in a few seconds or after hours, depending on the method. This imposes four rules.

• No order becomes paid because the customer landed on a certain page.
• The same notification can arrive more than once. The system must be able to receive it twice without creating two orders, two emails, or two inventory movements.
• Notifications can arrive out of order: first the cancellation of an attempt, then the confirmation of an earlier one. The outcome wins, not the order of arrival.
• An order can legitimately stay pending. You need a stated maximum time for each payment method, after which the order closes and the reserved stock becomes available again.

The table of statuses and allowed actions

A table like this one, decided once and posted where orders are prepared, prevents most mistakes. The names should be adapted to match your system, but the meaning must stay the same.

A refund is a status, not an email

In most cases a double refund doesn't come from carelessness, but from the fact that a refund can be issued from two different places.

• You need to decide who is authorized to issue it, and from which screen. One place, always the same one.
• A refund issued from the payment system's dashboard without going through the store is the most frequent cause of duplication: the second person to look at the order still sees it as paid and repeats the operation.
• Every refund is recorded in the order with amount, date, reason, and the name of whoever issued it.
• A partial refund must state which line it applies to: without that detail, neither the accounting nor the inventory will add up.
• Goods return to stock after inspection, not at the moment of the refund.

Reconciling: the comparison you need to do regardless

Three lists need to tell the same story: the store's orders, the payment system's transactions, and the credits to the account. They never match on the first try, for normal reasons: fees withheld, grouped credits, transactions spanning two days, refunds that follow their own timing.

1. Set a fixed schedule and stick to it: doing this on and off builds up differences that no one can later reconstruct.
2. Compare by order number, never by amount: two orders of the same value on the same day make comparing by amount useless.
3. Keep a written list of normal, expected differences, so that only the ones needing an explanation stay visible.
4. Assign unexplained differences to one person, with a deadline to close them.

Anomalies must be reported to a person

Some situations aren't visible when you look at orders one by one, because each one looks normal. They need to be searched for on purpose and flagged.

• Paid orders that remain unprepared beyond the time you've set for yourselves.
• Orders prepared or shipped without a payment confirmation.
• Payment system notifications that your site rejected or failed to process.
• Refunds recorded on only one side.
• Orders with a different amount between the store and the payment system.

An alert no one looks at isn't an alert. Every item needs a named recipient, and the first week should be used to remove useless alerts: if there's too much noise, the list gets ignored within a few days.

What this guide doesn't cover

This guide describes the flow and who does what. The economic and contractual terms — fees, settlement times, liability in case of a dispute, verification requirements — are found in your vendor's contract, not deduced from a guide. The obstacles that cause cart abandonment before payment, and the messages to send customers after the order, are covered elsewhere.