Features

Retry Failed Transfers

Retry a failed WooCommerce transfer without sending a second payment to a recipient that was already paid. FluentCart recovery is automatic and per transfer leg.

WooCommerce retry is available wherever Split Pay created or planned the original transfer. FluentCart recovery runs automatically per leg.

When do transfers fail?#

Resolve the cause shown in the order note before retrying. Common causes include:

  • A temporary Stripe API or network error.
  • A source charge, currency, requested amount, or earlier transfer tied to that charge that does not support the failed leg.
  • A connected account that is missing, restricted, or not ready for transfers.
  • An amount below the provider’s runtime minimum for that currency.

Split Pay records the exact result in the WooCommerce order notes and its transfer log.

How to retry#

Open the affected order under WooCommerce → Orders and read its latest Split Pay note.

Fix the condition proved by the order and Stripe records — for example, finish the recipient’s Stripe onboarding. Confirm the gateway is still using the original charge’s Test/Live mode and platform account. For an insufficient-balance message, first match the exact source charge, currency, requested amount, and earlier source-bound transfers.

Choose Retry Split Pay Transfers from the order’s Order actions dropdown.

Read the new order note. It tells you which failed leg was retried, which proven success was preserved, or why Split Pay stopped without sending money — including when a site-level safety gate declined the retry.

FluentCart has no manual Retry Split Pay Transfers order action. Split Pay recovers FluentCart transfer legs automatically; see FluentCart transfer recovery.

When is the retry action visible?#

The WooCommerce action can appear when:

  • The order is Processing, Completed, Cancelled, or Failed.
  • The order has a resolvable Stripe charge from a supported platform gateway.
  • The order is not currently being held by the WooCommerce Delay Transfers setting.

Do not use Retry to recalculate a successful transfer after changing its settings. A changed payout plan stops for review rather than replacing money already sent.

What happens during a retry#

A retry is a new attempt against the order’s saved payout plan, not permission to send every leg again:

  • The first genuine WooCommerce retry receives a fresh attempt identity, so Stripe can try a leg whose earlier request was clearly rejected.
  • Every leg already proven successful is skipped without another payment.
  • A clearly failed leg can be retried with the amount and recipient in the saved plan.
  • A changed plan, incomplete transfer inventory, or conflicting evidence stops before a new transfer.

Not every older order can be retried automatically. If Split Pay cannot prove exactly what Stripe already received, stop and review the order and Stripe transfer IDs — do not keep clicking Retry or create a replacement transfer manually.

Common retry scenarios#

Delayed payment settlement

A bank payment was still pending when the order first ran. Once the charge is successful, your gateway normally marks the order paid and Split Pay resumes. Use the WooCommerce retry action only if the order note still shows an unresolved transfer.

Temporary API error

A clearly rejected transfer can receive a fresh attempt after the temporary condition is resolved. An unknown outcome must be reconciled first.

Insufficient platform balance

Do not assume a delayed transfer or automatic payout caused this message. Every Split Pay transfer remains tied to the order’s original charge, and Stripe can accept a source-bound transfer while those charge funds are pending. Compare the exact charge ID, amount and currency with the failed leg and every earlier transfer tied to that charge; correct the proven mismatch, then retry only the failed WooCommerce leg.

Technical details#

Split Pay verifies the saved order plan, local transfer records, and Stripe’s transfer inventory before authorizing a new WooCommerce attempt. The safe outcomes are:

  • Already succeeded: preserve the transfer and send nothing.
  • Definitively failed: retry that leg with a fresh attempt identity.
  • Ambiguous or changed: send nothing and leave an order note requesting review.