Features / How to Transfer Payments

Delay Transfers Until Order Complete PRO

Hold Stripe transfers until the WooCommerce order status reaches Completed, so vendor payouts only fire after you confirm fulfillment, shipment, or service delivery.

PRO Feature. Delay Transfers Until Order Complete is available in Split Pay PRO. Added in Split Pay 3.7.0.

What this feature does#

By default, Split Pay fires Stripe transfers as soon as the payment succeeds — the connected account receives its share immediately. This is the right behavior for digital goods, instant downloads, or any flow where the customer’s purchase is fulfilled the moment they pay.

When Delay Transfers Until Order Complete is enabled, transfers no longer fire on payment. Instead, the plugin waits until the WooCommerce order status transitions to Completed and only then executes the configured transfers to your connected Stripe accounts. The payment is captured normally at checkout — only the transfer to the connected account is deferred.

When to use it#

This setting is designed for fulfillment-gated payouts. Hold the vendor's payout until the seller has confirmed that the goods shipped or the service was delivered. Common scenarios:

  • Physical goods marketplaces — release the vendor's cut only after the order ships and you mark it Completed.
  • Made-to-order or print-on-demand stores — hold vendor payouts until production is finished and the order is fulfilled.
  • Service-based bookings — wait until the appointment, lesson, or job is delivered before paying out the service provider.
  • Stores with high dispute or chargeback risk — reduce exposure by keeping funds in the platform balance until the order is closed out.

Default state#

The setting is OFF by default. Existing installations upgrading to Split Pay 3.7.0 continue to behave exactly as they did in 3.6.x — transfers fire immediately on payment. The new behavior is fully opt-in: you only get fulfillment-gated transfers if you check the box.

If you're upgrading from 3.6.x and want the legacy “transfer on payment” behavior, do nothing — that's still the default. Only flip this setting on if you actually want fulfillment-gated payouts.

How to enable#

In your WordPress admin, navigate to Split Pay → Main (top-level menu, added in 3.7.0).

Open the Global Transfer Settings panel (see Global Transfers for an overview).

Check the box labeled “Delay transfers until order is marked Completed (WooCommerce).”

Click Save Changes.

The setting applies store-wide — once enabled, every order's transfers are gated on the Completed status, regardless of whether the transfer was configured globally, at the product level, or per variation.

How to verify it's working#

After enabling the setting, place a test order on whichever platform you’re running:

Run a test purchase through your storefront (WooCommerce or FluentCart) so a new order is created in its initial not-yet-completed status — Processing on WooCommerce, the FluentCart equivalent on Stack B.

Open the Transfers tab. The transfer row for the test order should be listed as “pending” — the payment was captured, but no Stripe transfer has fired yet.

Open the order in your store admin and mark it Completed:

  • WooCommerce: WooCommerce → Orders → open the order → change status to Completed and save.
  • FluentCart: FluentCart → Orders → open the order → mark it as Completed/Fulfilled per FluentCart’s order workflow.

Note: the v3.7 Main-tab UI still labels the trigger “Order is set to Completed (WooCommerce)” because the feature was originally written for WooCommerce. The matching FluentCart trigger fires from FluentCart’s own “order completed” lifecycle event.

Refresh the Transfers tab. The previously pending transfer should now show as completed, with a Stripe transfer ID attached, and the originating order’s notes should record the executed transfer.

If a pending transfer never fires, double-check that the order actually reached Completed status. Orders that stay in Processing (or get cancelled before being completed) will keep their transfers in the pending state indefinitely.

Behavior on refund before completion#

If an order is refunded before it reaches the Completed status, the pending transfer is never executed — the funds are returned to the customer and nothing is sent to the connected account. Because the transfer hadn't fired yet, there's nothing to reverse on the connected account: the payout was held precisely so this scenario stays clean.

If an order is refunded after it has been marked Completed (and the transfer has already fired), standard refund handling kicks in. See Refund Handling for how transfers are reversed on the connected account when a Completed order is refunded.

Cancelled orders. If an order is Cancelled instead of refunded, the pending transfer is also discarded — the connected account is never paid for an order that didn't fulfill.

Interaction with other features#

  • Shipping fee transfers follow the same gating — they fire when the order is Completed, not on payment.
  • Retry Failed Transfers still works as expected. If the transfer fails when the order reaches Completed (for example, insufficient platform balance), you can retry from the order actions dropdown.
  • Override hierarchy (global → product-level → variation) is unaffected. The delay setting only changes when transfers fire, not which rules apply.
  • Multiple connected accounts on a single order are all gated together — the full set of transfers fires when the order reaches Completed.

When not to use it#

Leave this setting OFF if:

  • You sell digital goods or downloads where fulfillment is instant — there's nothing to wait for.
  • Your vendors expect to be paid immediately on sale (e.g., affiliate-style splits with no fulfillment dependency).
  • You don't reliably mark orders as Completed (e.g., you leave everything in Processing) — transfers would never fire.

How this differs from Stripe’s “separate charges and transfers” pattern#

Stripe documents a generic pattern called Separate charges and transfers (SCT) where the platform charges the customer at one moment and creates the transfer to the connected account some time later. Split Pay implements a specific, opinionated version of that pattern:

  • The gate is always the WooCommerce order status reaching Completed. You don’t pick an arbitrary point in time, and there’s no manual “Transfer now” button on the order page.
  • The transfer is still tied to the original charge via Stripe’s source_transaction mechanism, so funds settle automatically without you having to manage available-balance vs pending-balance separately.
  • The set of vendors and amounts is determined by your existing global / product-level / variation rules — you don’t describe each transfer in code at trigger time.

In other words: if you want a turn-key “hold the payout until I confirm fulfillment” toggle, this is it. If you need fully bespoke timing or per-order programmatic control over when the transfer fires, you’d roll your own SCT flow against the Stripe API directly.