Checkout and authentication
Capture at Fulfillment or per Fulfillment: Avoid Charging for the Wrong Scope
Choose the fulfillment-triggered capture mode by the payment scope you intend to collect. Capturing when the entire order is fulfilled is different from capturing as individual fulfillments occur. On split orders, that distinction can determine whether early-shipped items remain authorized but uncaptured or whether money is collected in stages.
Start with the actual payment method, plan, and fulfillment integration. A setting name alone does not establish that every route supports multiple partial captures. Verify the exceptions before telling customers when they will be charged.
Understand the two scopes
Shopify's capture documentation distinguishes whole-order capture from capture per fulfillment. Whole-order capture waits for complete fulfillment. Per-fulfillment capture, available on Shopify Plus, captures eligible line items as fulfilled, with remaining components collected at final fulfillment under the documented rules.
The payment provider must support the required authorization and capture behavior. Shopify also documents that unsupported multiple-partial-capture methods can lead to the entire amount being captured at the first fulfillment. That exception is material to both cash planning and customer expectations.
Do not assume a split shipping presentation at checkout creates staged payment collection. Shipping choices and payment capture are related operationally but are separate controls. Consult Shopify's split-shipping guidance to identify what the customer sees about delivery.
Compare the modes against your parcel plan
| Operational question | Entire-order capture | Capture per fulfillment |
|---|---|---|
| First parcel ships while another item remains | Does not by itself complete the whole-order trigger | May trigger capture for fulfilled items on supported routes |
| Final parcel ships | Can trigger the whole-order capture | Can collect remaining components under the documented rules |
| Long gap between parcels | Authorization timing needs close attention | Remaining authorized amounts still need attention |
| Payment method lacks required support | Verify available behavior before release | Do not promise staged charges |
| Fulfillment app requires paid status | Check compatibility before adoption | Check compatibility before adoption |
The comparison is not a substitute for checking the current account and method. It gives the payment and fulfillment teams a shared set of questions to answer before changing a live workflow.
Identify the event that marks an item fulfilled in the system. If that event occurs when a label is created rather than when the parcel actually leaves, the payment trigger may be earlier than staff or customers expect. Align the operating definition with the supported integration behavior.
A hypothetical split-order calculation
Assume a hypothetical order contains one USD 60 item and one USD 40 item, plus USD 10 shipping, with no taxes or discounts in this simplified example. The first item is ready now; the second will ship later. Both fulfillments are assumed to occur within the valid authorization period.
Under whole-order capture, shipping the USD 60 item alone does not complete the whole-order trigger. Under a supported per-fulfillment arrangement, the first item can produce a USD 60 capture, followed by USD 50 at final fulfillment for the second item and shipping.
Those amounts illustrate scope only. Real discounts, taxes, duties, payment methods, and order changes can alter allocation. Use the actual transaction record rather than multiplying a parcel's share of the order total by a rough percentage.
Now change one hypothetical fact: the payment method does not support the required multiple partial captures. The merchant cannot assume the two-charge pattern remains available. Verify the documented behavior and explain the resulting payment expectation before dispatch.
Test changes that can interrupt automation
Include partial fulfillment, final fulfillment, manual capture, cancellation of a fulfillment, refund, and return in your test plan where those actions are relevant. Shopify documents conditions that remove per-fulfillment automation; a process that works only on an untouched order is incomplete for real operations.
For each test, record starting payment state, action taken, resulting capture references, remaining amount, and whether automation remains active. Use approved test methods and label any unexecuted scenario as a planned check rather than a tested result.
Assign a payment owner to review orders whose automation has stopped or whose state differs from expectation. Fulfillment staff should not repeatedly mark items fulfilled or reverse statuses to force a payment event. Reconcile the real state and use the supported next action.
Give finance and support one payment map
Retain the order-to-fulfillment-to-capture relationship. Finance needs it to explain which goods correspond to each collection. Support needs it to explain why the customer sees one charge or several without confusing partial delivery with duplicate payment.
Before adopting either mode, confirm the eligible route, trigger event, authorization coverage, integration compatibility, treatment of changes, and backup owner. The decision is complete when the teams can predict the supported capture scope for their actual parcel plan and recognize an exception before it becomes an unpaid shipment or an unexpected charge.
See the order and dispute information available in Lower Chargeback.
Related reading in this collection:
- Test Your Shopify Checkout for Dispute-Causing Surprises
- Shopify Quantity Limits: When They Help and When Buyers Can Still Split Orders
- Shopify Order Routing: Avoid Promising Stock From the Wrong Location