Common Errors

Each section pairs an exact error message with the shortest verified fix. Use your browser’s find (Cmd/Ctrl + F) to jump to the message you see.

Stripe Connect account sync error#

You may see this error after clicking Refresh from Stripe in Connect Status:

Cause

You’ve pasted API keys from a connected account instead of your Stripe Platform account. Split Pay needs the Platform account’s keys because that account is the one processing transactions and initiating transfers.

Solution

How to identify your platform account

Your Stripe Platform account is the main account that:

• Is connected to whichever Stripe gateway adapter your store is using — the official WooCommerce Stripe Payment Gateway, Payment Plugins for Stripe WooCommerce (woo-stripe-payment), or FluentCart’s built-in Stripe module.
• Processes customer payments at checkout.
• Has connected accounts listed under Connect → Accounts in the Stripe Dashboard.

Connected accounts, by contrast, are the accounts that receive transfers. They appear as entries under your Platform’s Connect section.

---

Cannot create transfers on behalf of a Standard connected account#

If your Stripe account is connected to another platform, transfers will fail and you will see this error in your Stripe error log:

Cause

The active API key belongs to a Standard connected account, but Split Pay is attempting a platform transfer. That connected account is not the platform that owns the intended Connect relationship.

Common ways this happens:

• You created your Stripe account through WooCommerce’s built-in connection flow, which connected it to WooCommerce’s Stripe Platform.
• Your Stripe account is connected to another marketplace or SaaS platform.
• You’re using a Stripe account that was previously onboarded as a connected account for a different service.

Solution

---

Transfer amount below minimum#

Cause

The calculated leg is below the minimum Split Pay and Stripe enforce for that currency at runtime. There is no one fixed minimum that is correct for every currency and account.

Solution

Increase that recipient’s percentage or fixed amount, raise the eligible order amount, or remove the rule. Then use the exact amount and currency in the order note when verifying the correction.

---

Insufficient balance for transfer#

Cause

Every Split Pay transfer, including a delayed one, is tied to its original platform charge through Stripe’s source_transaction field. Stripe can accept that transfer while the charge funds are pending, and Stripe’s processing fee does not create a universal 96% or 97% ceiling. The message alone therefore does not prove that automatic payouts drained the balance.

Solution

Read the latest order note, then verify the exact source charge ID, charge amount and currency, failed transfer amount and currency, and every earlier transfer tied to that charge. Correct only the mismatch that evidence identifies. Do not add funds or change automatic payouts based on this message alone. After the cause is fixed, WooCommerce’s Retry Split Pay Transfers action retries the failed leg while preserving transfers already proven successful.

The optional Stripe-fee allocation setting changes how new WooCommerce plans share the exact fee; it is not a universal balance-error fix.

---

Retry stopped because saved records could not be matched#

Cause

Split Pay cannot prove that the saved transfer plan, local record, and Stripe result describe the same attempt.

Solution

Do not click Retry again and do not create a manual replacement transfer. Keep the order unchanged, collect the order number, exact note, redacted charge and transfer IDs, and contact support so the existing Stripe result can be reconciled first.

---

Product recipient settings changed while the order was prepared#

Cause

A product, variation, Bulk Editor, FluentCart product, or Global Transfer Settings save changed the verified routing generation while WooCommerce was preparing this order. Split Pay stopped that plan before attempting a transfer so it could not mix old and new recipient settings.

Solution

Let the settings save finish, review the current product or variation rules, then use Retry Split Pay Transfers once. If the same note returns when no settings save is running, stop and contact support instead of creating a manual transfer.

---

Global Transfer Settings were restored#

Cause

Split Pay could not prove that every Global Transfer Settings value was saved, so it restored the earlier form as one unit. Version 3.8.4 fixes the known upgraded-site case where a newly registered option still had only its default value and no stored database row.

Solution

Confirm that Split Pay 3.8.4 or later is active. If the message still appears, do not keep saving or rely on the unsaved values for new orders. Open WooCommerce → Status → Logs, select source split-pay, and find the entry beginning Global Transfer Settings save was rolled back:. Use that exact reason to correct the cause, or send the message and redacted log entry to support.

---

Cross-border transfer failed#

Cause

Stripe rejected the current platform, connected-account country, currency, or capability combination. These rules are provider- and account-specific and can change.

Solution

Open Split Pay → Connect Status and confirm the exact platform and recipient account IDs for the active mode. Use the exact Stripe error to determine whether that connected account can receive the requested transfer; do not rely on email address or business name as identity proof. See International Transfers.

---

Call to undefined method WC_Stripe_Logger::log() Resolved in 3.7.3#

Sites running Payment Plugins for Stripe WooCommerce (woo-stripe-payment) without the official WooCommerce Stripe Payment Gateway could hit a fatal during certain logging code paths:

Cause

The legacy WC_Stripe_Logger::log() method only ships with the official WooCommerce Stripe Payment Gateway. When that gateway isn’t installed the symbol doesn’t exist, so any unguarded call throws a fatal — which is what happened on some Payment-Plugins-only and FluentCart sites running 3.7.0–3.7.2.

Solution

---

Transfers admin tab is empty even though Stripe shows transfers Resolved in 3.7.3#

On stores upgraded to Split Pay 3.7.0–3.7.2, the Split Pay → Transfers admin tab could appear empty even though the Stripe Dashboard showed successful transfers under Connect → Transfers.

Cause

The 3.7.0–3.7.2 namespaced TransferEngine wrote rows to the transfer log without populating the stripe_mode column. The Transfers tab filters WHERE stripe_mode = 'test' or WHERE stripe_mode = 'live', so rows with a NULL or empty stripe_mode were silently filtered out of the UI — the data was in the database, just not visible.

Solution

---

Vendor selection on a product disappears after Save Resolved in 3.7.3#

On Split Pay versions before 3.7.3, selecting a vendor on the Split Pay tab of a WooCommerce product and saving while the percentage and amount fields were both empty silently erased the vendor selection on reload.

Cause

The legacy save handler gated persistence of the connected-account selection on either the percentage or fixed-amount field being non-empty. If a store was building up a configuration in stages — pick the vendor first, then come back to set the percentage — the selection would not be saved, and the dropdown would reset on reload.

Solution

---

Selected vendor is missing from the dropdown after Save Resolved in 3.7.4#

You select a vendor on the Split Pay tab of a product, click Update, and on reload the dropdown shows the placeholder “Select” text instead of your saved vendor — even though the underlying meta value is still correct in the database.

Cause

Before 3.7.4, the product Split Pay dropdown was rendered from the locally-synced accounts cache only. If the saved Stripe Connect account ID for the product was not present in that cache (because the cache hadn’t been re-synced after a connected account was added or after a switch to a different platform Stripe account), the <select> silently fell back to the placeholder option. Visually this looked identical to the save-erase bug fixed in 3.7.3, which made the two issues hard to triage.

Solution

---

Transfers tab fatal: Call to a member function get_transaction_url() on null Resolved in 3.7.4#

Opening Split Pay → Transfers could crash with a fatal error rendered mid-table:

Cause

The Transfers admin tab renders a per-row link to the originating charge in the customer’s payment-gateway dashboard. To do that, it looks up the gateway object using the payment_method column stored on each transfer log row. If that gateway is no longer instantiable — the gateway plugin was deactivated since the transfer fired, a third-party gateway publishes a non-object via the woocommerce_payment_gateways filter, or the row was logged with a stale gateway ID — the lookup returns null, and the previous isset() guard let the call go through anyway.

Solution

---

Percentage transfers are 100× too small with Name Your Price plugins Resolved in 3.7.3#

Stores using WPC Name Your Price, WooCommerce Name Your Price, or other “customer chooses the price” plugins could see percentage-based transfers that were dramatically smaller than expected. For example, an 80% split on a $100 customer-chosen-price order would transfer only $0.80 instead of $80.

Cause

Per-product percentage transfers were being computed against the product’s configured base price (often $1, set by the Name Your Price plugin as a placeholder) instead of the customer-chosen line subtotal. Both the legacy gateway-webhook path and the new namespaced WCOrderAdapter derived the unit price from the product object instead of the order line.

Solution

---