Home › Fintech › Split shipment payment capture
Split shipment payment capture connects each parcel to a separate collection of part of an order’s authorized amount. It needs a supported multiple-capture flow, a record of the balance still available, and a way to recognize when the final shipment or cancellation closes the payment.
A smaller capture can close the balance
A retailer may take one order but dispatch it in several parcels. If collection happens on shipment, the payment workflow must distinguish the first parcel from the last. “Capture less than the full amount” and “keep the remainder available for another capture” are separate capabilities.
Adyen documents the difference directly. With a single partial capture, the unused amount is automatically canceled. In a multiple-partial-capture setup, the remainder is not automatically canceled after the first capture; the documentation gives separate shipments as a use case. The feature is disabled by default and must be enabled through Adyen. Adyen capture modes
The operational consequence is important for a split order. A first capture can succeed while closing the remaining payment balance if the integration uses the wrong mode. The shipping system needs to know the configured behavior before it treats the rest of the order as funded.
Mark the final collection deliberately
Stripe’s capture API exposes amount_to_capture, which defaults to the full capturable balance if omitted. Its final_capture parameter defaults to true. Setting that parameter to false asks Stripe to retain remaining uncaptured funds, and is available only where the PaymentIntent supports multicapture. Stripe capture API
That is an eligibility condition, not permission to send the flag on every payment. Keep provider capability and current payment state available to the fulfillment workflow. A warehouse event should request a supported collection operation; it should not infer payment-method features from the number of parcels in an order.
For a hypothetical two-parcel order, the internal record might associate the first shipment with a non-final partial capture and the later shipment with the closing capture. If an item is canceled instead, the record needs to explain which part of the order remains payable. These are design examples, not instructions to apply the same API settings across providers.
Keep an allocation record per shipment
A useful review artifact is a small allocation record linking the order, shipment, items, currency, requested capture amount, capture reference and confirmed outcome. The amount assigned to a parcel should remain understandable when a later parcel changes.
Work through how discounts, delivery charges and canceled items are allocated before generating capture requests. An order-level total alone cannot explain why two shipment-level collections differ. Preserve the calculation used for each collection so support can explain it without reconstructing old cart data.
This is a proposed merchant-side design, not a claim that either provider creates the allocation record for you. The journal’s financial reconciliation guide covers how the collection records relate to later settlement reporting.
A dispatch event and a payment outcome are different records
Adyen’s capture response supplies a reference for the capture request, distinct from the authorization reference, and processes the request asynchronously. Its documentation also describes rare later capture failures. Keep a shipment’s requested collection and its eventual outcome connected. Adyen capture outcomes
If an event is delivered twice, the order system should identify the same shipment operation instead of allocating another amount. If a response is uncertain, establish that operation’s result before creating a replacement. These checks should be exercised alongside the team’s API idempotency design.
The customer-facing order history also needs enough detail to explain multiple collections against one order. A support view that shows only the original total and a “paid” badge hides the shipment-level explanation.
A later parcel still faces the authorization deadline
Retaining an uncaptured remainder does not establish an unlimited authorization lifetime. Adyen documents expiry as a capture failure requiring a new authorization; supported recovery options depend on the payment method and flow. Repeatedly sending an unchanged late capture is not a substitute for that recovery decision. Adyen failure guidance
Review delayed dispatch, an item canceled after the first parcel, a failed later capture and a duplicate warehouse event. Identify who resolves each exception and what the customer sees. Record the evidence of the final state before considering the order’s payment work complete.
These scenarios are suggested checks based on the documentation. No processor sandbox or live payment was tested for this article.
Reporting & Sources
Documentation checked November 1, 2026. This is an operational analysis of split fulfillment, not a product announcement or reported test. Stripe’s API example displayed version 2026-10-28.endive.
