Channel/order mismatch should read as processing

What it is

The rail may already have authorized or declined while the order system has not written the matching state—a window of seconds to minutes. That window should read processing: not a success receipt, not a failure retry, two ledgers not yet aligned. It is the mismatch window between rail and order, not whether the client clock timed out first, and not how many days a double-charge refund takes.

Why it happens

Two systems align on async messages. Reordering, retries, and batch recon leave people seeing a capture in the bank app while the merchant still says unpaid, or a merchant paid while the bank has nothing. People act on whichever side they can see: pay again, or chase shipment. Processing swaps action for wait and lookup, and says “bank and order are aligning.” Success in this window may ship an empty order; failure may pay again. Processing must exit to order detail, also processing—not pretending the order does not exist.

Studying it

Delay order writes or rail callbacks. Compare showing unpaid, showing paid, showing processing with an expected align time. Watch second pays and shipment chases.

Independent variables: copy in the mismatch window, whether pay is still offered, whether a recon expectation is given. Dependent variables: second pay in the window, empty shipment, what people tell support.

Use an environment where both sides are visible (simulated bank record + merchant order). Do not only score final agreement—the wrong act in the window already happened.

Where it stops holding

If mismatch outlives its own promise, processing must upgrade to “recon exception + ticket,” not infinite processing. When the rail has clearly declined and the order is failed, leave processing. Cash-on-delivery has no rail auth; do not reuse processing. If people already see a bank capture, copy should admit that and say the recon result wins, not deny the capture.

Applying it

• When rail state and order state differ, mark processing on both order and pay page, hide pay-again, offer lookup and a support id.
• Give an order-of-magnitude align time (minutes / a recon batch); auto-escalate on overrun.
• After align, leave processing for a success receipt or actionable failure, and notify.
• Verify by delaying the callback and letting people see a simulated bank record and the merchant order together. Merchant unpaid and still payable, or merchant success with no auth, fails the window. Correct is processing and not payable.

Related

• Within the group: H7.13.1 Timeout is not failure; query first · H7.13.2 Released stock and coupons must return promptly · H7.13.4 Auto-refund for double charge needs a stated arrival window
• Adjacent: H7.06 Payment failure · H3.13 Handling partial failure · H7.05 Order confirmation
• Search terms: payment processing · ledger mismatch · reconciliation delay