Customer says they paid, order says pending: should you dispatch?

Hold dispatch until someone verifies the payment

Do not release goods solely because a customer reports payment or sends a screenshot. Put the order on a fulfilment hold and ask an authorised reviewer to match it to the provider record. A customer message is a useful lead, but it does not resolve a disagreement between systems. Equally, do not declare the payment failed just because the shop still says pending. The practical decision is whether there is enough verified evidence to release this particular order, under your existing stock, delivery and risk checks.

There are three workable routes. Wait for the normal confirmation when the provider still shows an unresolved payment; have a reviewer reconcile confirmed payment with a stale shop record; or escalate an untraceable or conflicting transaction. Dispatching before confirmation is a separate commercial credit decision, with the possibility of losing the goods. If an owner approves that exception, record the approver and exposure separately instead of marking an unconfirmed payment as paid. A courier cutoff is a reason to escalate quickly, not evidence of payment.

Read the provider state, not just the shop label

Stripe is the named example here, not a recommendation to change providers. Its guidance distinguishes processing from succeeded; requires_capture means capture is still needed. It recommends server-side webhook monitoring because customers can leave after paying. Refunds and disputes appear on the Charge even if the PaymentIntent remains succeeded. These are Stripe-specific facts; use your provider’s own status definitions elsewhere.

For your operating procedure, require the reviewer to open the matching transaction through approved staff access. Compare the order reference, payment reference, amount and currency, then record the state and the time checked. If staff cannot interpret an authorisation, partial payment or other unusual state, keep the hold and hand it to the payments owner. Never resolve an unfamiliar status by guessing from a green icon. Give warehouse staff the resulting release instruction; they should not need access to payment credentials to do their job.

Give each pending case a home and an owner

Start with a restricted shared queue or the case view already available in your order system. It must be visible to customer service and the release owner, with a clear hold visible in the warehouse workflow. The queue is an operating design proposed here, not a provider requirement. A note buried in a chat thread is too easy to lose during a shift change. Name one reviewer and a backup, and agree the next review time around opening hours and dispatch cutoffs rather than promising that every payment clears within a fixed interval.

Keep payment status and fulfilment status as separate fields. A reviewer may verify payment while the parcel remains held for an address check; a manager may accept a credit exception while payment remains unconfirmed. Record the reason for either decision. Store references to the relevant records rather than copying full card details into the queue. Close the case only after the warehouse instruction and customer explanation agree with the recorded outcome.

Two cases to rehearse before the next dispatch

Consider an illustrative local pickup order: the customer pays, closes the browser tab and arrives at the shop, but the order remains pending. The counter colleague opens a case instead of asking for immediate payment again. The reviewer checks the matching provider record and finds confirmed success. Under the proposed procedure, they document that evidence, confirm the goods have not already been handed over, and authorise the order-system release. The customer’s closed tab is part of the explanation, not the proof used to hand over the parcel.

In a second illustrative case, the shop has not received an updated status before the courier cutoff. The reviewer also finds that the provider has not yet confirmed success. Keep the parcel in the hold area, set the next check and tell the customer which delivery commitment may change. If the provider is unavailable, the outcome is still unresolved. If later verification confirms success, apply the release checks; if it confirms failure, explain the available payment route. Do not ask the customer to pay again merely to make the queue disappear.

Test the handover with your existing setup

At the next operations meeting, choose one release owner and walk through both examples with customer service and warehouse staff. Check that each person can find the hold, the evidence and the next action without contacting the original colleague. Also rehearse a later refund or dispute: send it to the appropriate after-payment review rather than assuming an earlier success closes every future issue. If the missing piece is record ownership or visibility, scope that specific integration change before considering a replacement checkout.