Common Errors

Most of what looks like a Split Pay failure is actually one of a small set of misconfigurations on the Stripe side. Each section below pairs the exact error text you’ll see with what causes it and how to fix it. Use your browser’s find (Cmd/Ctrl + F) to jump straight to the message you’re looking at.

Stripe Connect account sync error#

You may see this error after clicking the Synchronize Stripe Accounts button in your Split Pay settings:

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

Your Stripe account is itself a connected account under someone else’s Stripe Platform (for example, WooCommerce’s own platform, or another marketplace service). Stripe doesn’t let an account that’s already connected to one platform act as a platform of its own and initiate transfers.

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#

You may see transfer failures if the calculated transfer amount falls below Stripe's minimum:

Cause

Stripe enforces a per-currency minimum on every transfer. The minimum is roughly equivalent to $0.50 USD but varies by currency — for example, £0.30 GBP, €0.50 EUR, $0.50 CAD, JPY 50 (no fractional minor units), Mex$10 MXN, R$0.50 BRL. If a low-priced product is combined with a small transfer percentage, the resulting transfer amount may fall below the threshold for that currency.

For example, a $2.00 USD product with a 20% transfer would attempt to transfer $0.40 — below the $0.50 USD minimum. The exact minimum for a given currency is whatever Stripe applies to charge / transfer minimums for that currency on the day of the transfer; see the Stripe minimum and maximum charge amounts reference.

Solution

---

Insufficient balance for transfer#

Transfers may fail when your Stripe pending payout balance cannot cover the full transfer amount:

Cause

When you attempt to transfer 100% (or a very high percentage) of a transaction, Stripe fees (~2.9% + $0.30 for US accounts) reduce the available balance below the transfer amount. For example, a $100 payment has approximately $3.20 in Stripe fees, leaving only $96.80 available — but a 100% transfer tries to send $100.

Solution

---

Cross-border transfer failed#

If you attempt to transfer funds to a connected account in an unsupported region, Stripe will reject the transfer:

Cause

Your platform Stripe account and the connected account are in different countries/regions that do not support cross-border transfers. Stripe supports cross-border transfers between US, Canada, UK, EEA, and Switzerland only. All other combinations require accounts to be in the same country.

Solution

---

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() static method only ships with the official WooCommerce Stripe Payment Gateway. When that plugin is not installed, the symbol does not exist and any unguarded call site throws a fatal. Split Pay 3.7.1 added a guarded safe_wcs_log() helper for the legacy main class, but the new namespaced classes introduced in 3.7.0 (WooCommerceIntegration, WCStripeGateway, WooStripePaymentGateway, TransferEngine, WebhookHandler) had their own unguarded calls that re-introduced the fatal in 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

---