This guide explains how a Shop site can let customers edit an order until a deadline, then collect payment from a saved payment method after the order is locked.
It is intended for site owners who configure the flow and support staff who follow up on unpaid orders. For payment-method setup and gateway credentials, see Payment Methods.
Order locking and payment collection are separate steps:
Locking is never dependent on a payment attempt. An order remains locked when payment needs recovery, so that staff can resolve payment without the customer changing what is being charged.
OnDemand and legacy checkout share OrderPaymentDeferralPolicy. OrderService remains the authority for editability and its deadline; the shipping editing flag alone does not make every order deferrable.
For a future-editable, unlocked order using authorization-at-lock, an enabled saved-card-capable payment method and a usable account-owned card, OnDemand persists the card relation and runs normal placement without creating a PaymentIntent or calling authorization/capture. The card must remain valid beyond the editing deadline. Placement does not mark the order paid or captured.
An absent, incompatible or expired card retains the normal online authorization flow. First-use reusable-card registration is a separate flow; an ordinary order payment does not prove that a reusable card was saved. A missing return URL cannot waive online authorization. Manual/deferred-billing providers retain their existing placement behavior.
Use this flow when customers should be able to adjust an order until a known deadline and the site should charge a saved card afterwards. Typical examples are scheduled meal orders and recurring deliveries.
Do not use automatic collection when payment is handled by invoice, bank transfer, cash, or another external process. Those orders can still be locked, but Shop will not make a payment attempt.
The selected payment provider must support charging a saved payment method. Enable payment subscriptions on the payment method so that customers can register a card before their order is collected.
Keep test and live credentials separate. Test the full customer journey with a disposable subscription before enabling the flow for live orders.
The shipping method is the policy source for what happens after an order is locked. Choose one of these outcomes:
| Desired outcome | Shipping-method policy |
|---|---|
| Reserve the amount after locking and capture it later through the normal payment process | Enable payment authorization for locked orders. |
| Take payment immediately after locking | Enable payment capture for locked orders. Shop authorizes and captures as one collection action. |
| Do not collect payment automatically | Leave both options disabled. This is appropriate for deferred billing such as invoicing. |
Choose the outcome deliberately for every shipping method used by the site. A capture collects money; it should only be enabled where that timing matches the site’s terms and fulfilment process.
Enable customer order editing only where customers should be able to change a placed order. Set the editing deadline on the shipping method or ordering configuration used by the site.
When the deadline is reached, Shop locks the order. The order will no longer be editable by the customer, and the payment collection flow can begin independently. Administrators and payment providers retain their existing operational access where permitted.
Use a test payment method and a disposable saved-card subscription. Verify all of the following:
The order’s payment collection state describes the next operational step. It does not replace the payment transaction status or the order’s paid/captured indicators.
| State | Meaning | Support response |
|---|---|---|
| Due for payment collection | Shop is ready to attempt collection. | Normally wait for the scheduled collection run. |
| Awaiting payment provider | The provider accepted a request but has not supplied its final result. | Do not retry payment. Wait for the provider result or use reconciliation if it remains unresolved. |
| Payment recovery required | Collection needs administrator attention before another attempt. | Check the provider result and customer’s saved payment method. Reattempt only after an explicit decline or a resolved configuration problem. |
| Payment collection completed | The required collection action has completed. | Confirm whether the order is authorized or captured according to the site’s policy. |
| Payment collection not required | This order’s policy does not require Shop to collect payment. | Follow the site’s normal invoicing, cash, or external-payment process. |
| Not eligible | The order is not scheduled for automatic collection. | Treat it as an existing/historical order and follow the site’s normal payment process. |
A reattempt does not reopen customer editing and does not change the order contents.
An Awaiting payment provider result means Shop cannot safely tell whether the provider has charged the customer. Do not reattempt payment directly, because that could create a duplicate charge.
Use Reconcile payment collection to ask a supporting provider for the final result. If the provider confirms a decline, the order can move to Payment recovery required and be reattempted after the cause is resolved. Escalate to the payment provider when reconciliation cannot determine the outcome.
An order can be locked without automatic payment collection. This is expected for deferred billing and does not indicate an error. Support staff should follow the site’s agreed invoicing or offline-payment process instead of trying to force a card charge.
This flow collects payment after locking; it does not automatically cancel unpaid orders, notify customers, or delay capture until fulfilment. Sites that need any of those processes should define them separately before launch.
OnDemand checkout emits DEBUG checkout-timing entries correlated by its GUID request ID. Stage start/end entries cover source quoting, the order transaction (including commit), order creation, saved-card lookup, placement, confirmation and provider initialization. Placement attempts also identify set-placed, audit, stock reservation and automatic-capture time. Repeated attempt entries and gaps expose existing retry waits. Only fixed stage names, correlation IDs and elapsed milliseconds are recorded; tracing does not change retry or payment behavior. Inspect the local debugger log output for the correlated entries; a stage start without its end identifies work still running or interrupted at a breakpoint.
Order audit recognizes a deferred sandbox payment before a transaction exists only when the enabled test payment method and the order's pinned test subscription match, the card belongs to the order account, and the shared deferral policy still permits authorization at lock. An unexplained test flag retains the normal administrator restriction.
Operators can invoke Order.Lock for a placed, editable, unlocked order from the order context menu. The server requires administrator/provider-operator access and order write permission. This uses the scheduled lock transition and records the operator request; it updates payment-collection state and emits the existing lock effects without charging or dispatching. Payment collection remains a separate operation/job.