Troubleshooting

Common reasons transfers fail#

Start with the exact order rather than changing the whole site. Most cases fall into one of these groups:

1. The order is not paid#

WooCommerce must report payment complete, or FluentCart must report a paid order through its Stripe method. Split Pay does not create the original transfer from a generic Stripe webhook alone.

2. A transfer leg is invalid#

The saved percentage, fixed amount, product, shipping, tax, fee, or add-on rule may produce no eligible amount or an amount below the runtime minimum for that currency. Use the exact order note; do not assume one universal minimum.

3. The mode or platform identity is wrong#

The order charge, Split Pay platform key, and connected recipient must belong to the same Test or Live context. Email addresses and business names are labels, not account-identity proof. New or strict 3.8.4 routing uses exact site-scoped pairs; an existing 3.8.3 install can retain its legacy email/name/saved-ID resolver until strict identity is activated.

4. Stripe rejects the source-bound amount#

Every Split Pay transfer uses the original charge as its source_transaction, including a WooCommerce transfer released later by Delay Transfers. An insufficient-balance message must be checked against the exact source charge ID, its amount and currency, the attempted leg, and all earlier transfers tied to that charge. Delay timing or automatic payouts alone do not prove the cause.

5. The recipient cannot receive the transfer#

The connected account may be missing, restricted, incompletely onboarded, or ineligible for the requested currency or country combination.

6. The saved plan cannot be executed safely#

The order’s frozen plan may no longer match local records or Stripe. Split Pay stops before sending money when it cannot prove what already happened.

---

Four diagnostic steps#

Step 1: verify Connect readiness#

1. Open Split Pay → Connect Status.
2. Confirm the active Test or Live mode and exact platform account ID.
3. Confirm the affected recipient account ID is present and ready for transfers.

Start with the mode-matched platform key shown for the store adapter. Payment Plugins for Stripe WooCommerce prefers its Split Pay Advanced key for normal order transfers, delayed releases, guarded retries, and store-initiated refunds, and requires that key for the row’s readiness, account sync, and check. If Advanced is empty, those normal paths can fall back to Payment Plugins’ own same-mode secret key; that fallback does not make the row ready and must not be assumed for every asynchronous failure, dispute, or recovery handler. FluentCart uses its Advanced override first and otherwise uses Split Pay’s detected same-mode platform-key chain for its normal transfer path. Check Woo webhook and Check Woo webhook on key are read-only; the FluentCart row check reads only its Advanced key and looks for an exact official WooCommerce Stripe URL that Stripe does not mark disabled, so verify FluentCart’s own webhook in FluentCart.

Step 2: verify the exact order and plan#

1. Confirm whether the order is WooCommerce or FluentCart, which Stripe gateway processed it, and whether it is Test or Live.
2. Confirm the charge succeeded on the same platform account shown in Connect Status.
3. Review the rules and order data that applied when Split Pay froze the transfer plan. A delayed WooCommerce order can still read current product settings when it reaches Completed; before the first transfer request, Split Pay freezes the plan so later setting changes cannot alter that in-progress payout.

Step 3: match the records#

Read the newest Split Pay order note and, in PRO, the matching row under Split Pay → Transfers. Compare their redacted ch_, pi_, tr_, and acct_ IDs with the corresponding Stripe objects. The exact error text decides the next action; see Common Errors.

Step 4: recover safely#

• WooCommerce: after fixing the named cause, use Retry Split Pay Transfers. Proven successes remain untouched; clearly failed legs get a fresh attempt.
• FluentCart: recovery is automatic per leg. There is no manual Retry order action.
• Any safety-stop note: do not retry repeatedly or create a manual replacement transfer. Preserve the order and contact support.

---

If evidence points to a conflict#

Only isolate plugins or a theme after the order event and logs point to a hook or checkout conflict. Use a staging copy or Stripe Test mode, change one component at a time, and never use a live payment to diagnose it. Record the conflicting component’s exact name and version.

---

Contacting support#

Send the minimum facts needed to reproduce the case:

• Split Pay version.
• WooCommerce or FluentCart and the Stripe gateway used.
• Test or Live mode.
• Affected order number and exact error or order note.
• Redacted screenshots and relevant ch_, pi_, tr_, and acct_ IDs.

Do not send secret keys. WP Admin or SFTP access is not a default requirement; if later needed, support will ask for explicitly authorized, temporary, narrowly scoped access. Submit the case at gauchoplugins.com/support.