Features

Retry Failed Transfers

When a transfer fails due to temporary errors, insufficient balance, or delayed payment settlement, Split Pay PRO lets you retry with a single click from your store’s order edit screen — the WooCommerce order page on Stack A, or the FluentCart order screen on Stack B.

PRO Feature. Retry Failed Transfers is available in Split Pay PRO.

When do transfers fail?#

Transfers can fail for several reasons:

  • Temporary Stripe API errors — Network timeouts, rate limits, or brief service disruptions.
  • Insufficient platform balance — Your pending Stripe balance didn't have enough funds at transfer time.
  • Delayed payment settlement — Bank-based payment methods (ACH, SEPA) hadn't settled when the transfer was attempted. See Delayed Settlement Methods.
  • Connected account issues — The connected account was temporarily restricted or had an incomplete onboarding status.
  • Transfer amount below minimum — Individual transfers must be at least $0.50 USD (or equivalent).

When any transfer fails, the plugin adds a detailed order note with the Stripe error message and marks the order with a spp_has_failed_transfers flag.

How to retry#

Navigate to the order in your store admin and open the order that has failed transfers:

  • WooCommerce stacks: WooCommerce → Orders.
  • FluentCart stack: FluentCart → Orders.

Find the Retry Split Pay Transfers action. On WooCommerce it lives in the Order actions dropdown (top-right of the order edit screen). On FluentCart, Split Pay registers an equivalent action in FluentCart’s order detail UI — see the FluentCart integration page for the exact location.

Trigger Retry Split Pay Transfers. The plugin clears the previous transfer metadata, retrieves the original PaymentIntent from Stripe, and re-runs the full transfer process.

Check the order’s order notes for the results. Each transfer will be logged with its success or failure status.

When is the retry action visible?#

The "Retry Split Pay Transfers" action appears in the order actions dropdown only when:

  • The order status is Processing or Completed, AND
  • At least one of the following is true:
    • Transfers were never completed (is_transfer_process_done is empty)
    • One or more transfers failed (spp_has_failed_transfers is set)

If all transfers completed successfully, the retry action is hidden — there's nothing to retry.

What happens during a retry#

The retry process is a full re-execution of the transfer logic:

  • Previous transfer metadata on the order is cleared (the existing is_transfer_process_done flag is removed).
  • The plugin retrieves the original Stripe PaymentIntent associated with the store order (WooCommerce or FluentCart).
  • A synthetic payment_intent.succeeded event is constructed from the live PaymentIntent data and passed through the standard transfer pipeline.
  • All configured transfer rules (global, product-level, shipping) are evaluated and executed fresh.
  • Order notes document each step of the retry process.

The retry re-runs the entire transfer process, not just individual failed transfers. Make sure any underlying issue (balance, account status, etc.) is resolved before retrying.

Common retry scenarios#

Delayed payment settlement

A customer pays with ACH Direct Debit. The charge is initially pending, so transfers are deferred. A few days later the charge succeeds. Use the retry action to trigger the transfers now that funds are available.

Temporary API error

Stripe experienced a brief rate limit or timeout during transfer creation. The payment succeeded, but one or more transfers failed. Wait a few minutes and retry.

Insufficient platform balance

Your pending Stripe balance was too low at transfer time (e.g., a large refund reduced it). Once new payments have restored the balance, retry the transfers.

Technical details#

For developers:

  • WooCommerce order action hook: woocommerce_order_action_spp_retry_transfers; visibility via woocommerce_order_actions based on order meta.
  • FluentCart equivalent: Split Pay’s FluentCart integration registers an analogous order-level retry trigger; it shares the underlying retry pipeline so behaviour matches the WooCommerce implementation.
  • PaymentIntent retrieval: The PaymentIntent ID is read from order meta. On Stack A1 (official WC Stripe) the key is _stripe_intent_id; Payment Plugins (Stack A2) and FluentCart (Stack B) write equivalent keys via their own gateway adapters — Split Pay’s adapter reads whichever key is present for the order’s gateway.
  • Event reconstruction: Builds a synthetic Stripe Event JSON containing the PaymentIntent data, passed to transfer_controller().
  • Meta cleared on retry: is_transfer_process_done and spp_has_failed_transfers.