Order, payment and payout: three histories of one purchase

An order can be paid and shipped before its payout reaches the bank. A partial refund can coexist with the original successful payment. Problems begin when all of that must fit inside one green badge. An operational interface needs three connected histories and rules that stop one history silently overwriting another.

A practical operating model keeps three connected histories: the commercial order, the payment process and the movement of funds into the merchant's bank account. They belong on the same investigation screen, but they need their own states.

Follow one hypothetical purchase

Imagine an €80 order created at 10:00 on Monday. The provider confirms payment at 10:02, and the merchant receives the corresponding event at 10:04. The warehouse dispatches the package on Tuesday. Under our invented processing arrangement, the funds become available on Wednesday and are included in Thursday's payout.

On Tuesday the order is paid and dispatched, while the payout remains outstanding. Asking the customer to pay again would be an operational mistake. So would treating the absent bank deposit as proof that the earlier payment failed. Each team should investigate the record relevant to its question.

Now introduce a €20 partial refund after dispatch. In this simplified example, retain the original €80 payment and record the separate €20 refund. The remaining amount is €60 before fees. Replacing the original payment amount with €60 destroys the trail needed to reconcile the provider's records and explain the customer's statement.

Start with the commercial promise

An order describes what the customer bought and what the merchant must deliver. A business might use states such as received, accepted, preparing, dispatched, completed and cancelled. A paid order can still be cancelled. An order can also be partially delivered or funded through several payments. Its commercial state therefore cannot serve as the entire payment ledger.

A payment record describes an attempt to collect money. Card authorisation and capture can be separate stages; Adyen's lifecycle documentation distinguishes these from settlement. Do not assume every provider or payment method uses identical stages or names.

Some APIs introduce an object that tracks the wider payment process. For example, Stripe's PaymentIntent links the payment journey and its attempts. Before designing an internal model, identify which provider reference represents the process, which represents an attempt and which identifies a financial movement.

Write rules the system can actually check

Start with a few internal integrity conditions. Reprocessing an event identifier must not trigger fulfilment twice. A completed refund retains its link to the original payment. Every shipment has either acceptable payment evidence or an explicitly approved commercial exception. Amount and currency comparisons follow defined rules, with mismatches sent to review.

A single ordered list of states cannot express every legitimate outcome. Suppose an order is cancelled at 10:03 and a payment confirmation generated at 10:02 arrives at 10:04. The payment happened and the commercial order was cancelled. A sensible designed response is to preserve both facts, stop automatic shipment and create a case for an authorised resolution. The refund still needs approval and execution; cancellation of the order does not establish that money has been returned.

Show the operator why the case is waiting: “Payment confirmed; fulfilment stopped after cancellation.” Add an owner and permitted next actions. A generic Error label loses this information. The customer-facing explanation can be shorter, but it should refer to the same underlying record.

Give operators the fields they need

• The internal order ID and every associated provider payment reference.
• Original amount and currency, captured amounts and completed refund amounts.
• The provider's raw state alongside a clear internal interpretation.
• Both the source event time and the time your application received it.
• Payout reference, included movements, expected date and eventual bank match.

Keep funds availability separate from payout dispatch. Stripe's payout documentation, for example, separates settlement timing from the payout schedule. Your own arrangement may also involve cutoffs, non-working days or additional conditions. Record those terms instead of embedding a universal “money arrives tomorrow” assumption in the interface.

Test what happens with an old snapshot

Every screen presents information as of a particular moment. Place the last confirmation time and its source beside important statuses. If an operator opened the case twenty minutes ago, a money-moving action should check the current state again. Otherwise, two colleagues can make individually reasonable decisions using the same stale picture.

Add this hypothetical test: the first shift creates a refund; the second still sees the old screen and requests the same refund. Define the expected response in advance. The interface should expose the existing action, reference and status instead of silently creating an additional operation.

Keep the correction history separately from the original events. Tomorrow’s reviewer should be able to reconstruct both what happened and what the operator knew when deciding. This matters for delayed confirmations: knowledge acquired later should not be mistaken for information available earlier. A usable timeline distinguishes event time, receipt time and decision time without requiring the reviewer to read raw logs.

Manual decisions need a history too

A repeated notification must not create a second shipment. A late notification must not silently overwrite a newer conclusion. Adyen describes possible duplicates and chronological processing. Test these cases against your provider's documented event model.

Manual controls deserve the same care. A broad “mark as paid” button makes investigation convenient but can hide the absence of payment evidence. Prefer a controlled exception workflow that records the evidence, decision maker and reason. The person reviewing tomorrow's mismatch should be able to reconstruct what happened without asking yesterday's shift.

A small queue beats a vague dashboard

Review unmatched payments, orders awaiting confirmation, unresolved refunds and payouts without bank matches as separate queues. Add age, amount and next action to every entry. Agree which team owns each queue and when an item becomes overdue.

Test the model with an order cancelled before its payment confirmation arrives. It should preserve both facts, expose a resolution task and avoid a new charge or automatic shipment. That exercise tests the meaning of the states more effectively than changing badge colours.