Reconcile payment and order status as separate lifecycles

Do not collapse everything into complete

A single green success label hides important differences. Your team needs to know whether the order was requested, accepted, queued, prepared, handed off or cancelled. Payment has a separate set of states, such as authorization, capture, failure, void and refund. The exact states depend on the processor and your service model.

Document which party is allowed to advance each state. A delivery platform marking a courier pickup should not silently prove that the restaurant received payment. A customer receipt does not prove that the KDS displayed the correct modifiers.

Create a reconciliation record

• Source channel and source order reference.
• Destination order ID, location and kitchen acknowledgement.
• Payment reference and verified current payment state, without card numbers.
• Expected total and actual captured or refunded total.
• Exception owner, investigation note and next action.

Keep only the information staff need. Do not put payment-card details, credentials or unnecessary guest information in a shared debugging document. Use the payment provider’s own secure tools for sensitive payment operations. This reference and its validator do not accept or process payments.

Test the uncomfortable combinations

Include accepted order plus failed payment, successful payment plus unknown order submission, partial cancellation after capture and a later refund. For each case, identify the system of record and the person who can correct the mismatch. Ask whether a refund in one system automatically updates the other or requires a separate step.

If you collect payment at pickup, record that explicitly. The correct pre-pickup state may be unpaid by design, not failed. If a marketplace is the merchant for the transaction, understand what settlement evidence the restaurant receives and when it becomes available.

Reconcile during the pilot, not just at month end

Start with a manageable review cadence appropriate to order volume and staffing. Compare the source-channel totals, accepted orders, kitchen exceptions and payment events. Investigate mismatches while the shift context is still available. Aggregate totals can match while individual orders are wrong, so sample the linked records too.

In the workflow validator, payment reconciliation is a dependency for any channel collecting money before fulfillment. Pay-at-pickup and marketplace-managed payment use different checks. The output identifies planning gaps; it cannot certify accounting or payment compliance.

Customer evidence for this order workflow

Use a two-state decision before recovery

If payment is captured but the order state is unknown, first locate the accepted order through the approved reference. If an order is accepted but payment failed, follow the restaurant’s unpaid-order policy. Neither case justifies a second charge or a second order without reconciliation.

Loman’s plan descriptions and Toast workflow page are starting points for checking payment scope. Ask who owns authorization, capture, reversal and support in the contracted flow. Keep card details outside this worksheet.