--- title: "Common Errors" description: "Solutions for common Split Pay Plugin errors including Stripe Connect account sync errors, 'Cannot create transfers on behalf of a Standard connected account', insufficient balance, minimum amount failures, the WC_Stripe_Logger fatal, empty Transfers tab, lost vendor selections, vendor missing from synced accounts, the get_transaction_url() fatal, and Name Your Price percent miscalculations." url: "https://docs.splitpayplugin.com/support/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: **"You cannot access the connected accounts of your Platform's connected accounts."** ### 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 Make sure your API keys come from your **Stripe Platform account** — not from one of the connected accounts that receive transfers. To verify: log into the [Stripe Dashboard](https://dashboard.stripe.com) with your Platform account, go to **Developers → API Keys**, copy the keys from there, and paste them into your Split Pay settings. ### 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: **"Cannot create transfers on behalf of a Standard connected account."** ![Cannot create transfers on behalf of a Standard connected account error](../../images/not-allowed-connected-account-error.png) Cannot create transfers on behalf of a Standard connected account error ### 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 Create a **new, standalone Stripe account** that isn’t connected to any other platform. * The new account can be registered under the same business or individual — it’s normal to have multiple Stripe accounts. * The key requirement: the account is a standalone Platform account, not connected to any other Stripe Platform. * Once it’s created, point both your Stripe gateway plugin (the official WooCommerce Stripe Payment Gateway, Payment Plugins’ `woo-stripe-payment`, or FluentCart’s built-in Stripe module — whichever one your store uses) and Split Pay at the new account’s credentials. * * * ## Transfer amount below minimum You may see transfer failures if the calculated transfer amount falls below Stripe's minimum: **"Amount must be at least 50 cents"** (or equivalent in local currency) ### 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](https://docs.stripe.com/currencies#minimum-and-maximum-charge-amounts) reference. ### Solution Make sure your transfer percentages or fixed amounts always clear the per-currency Stripe minimum. A few ways: * Increasing transfer percentages for low-priced products. * Using a fixed transfer amount that clears the per-currency floor (look up your store currency in Stripe’s [currency minimums table](https://docs.stripe.com/currencies#minimum-and-maximum-charge-amounts)). * Setting minimum product prices high enough that the percentage transfer meets the threshold. * * * ## Insufficient balance for transfer Transfers may fail when your Stripe pending payout balance cannot cover the full transfer amount: **"You have insufficient funds in your Stripe account"** ### 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 Two recommended approaches: * **Reduce the transfer percentage** slightly (e.g., 96–97% instead of 100%) to account for Stripe fees * **Extend your payout schedule** in the Stripe Dashboard (e.g., weekly or monthly payouts) so that your accumulated balance from other transactions covers the difference You can also use a plugin like [Payment Gateway Based Fees](https://woo.com/products/payment-gateway-based-fees/) to pass transaction fees to customers during checkout, ensuring your full balance is available for transfers. * * * ## Cross-border transfer failed If you attempt to transfer funds to a connected account in an unsupported region, Stripe will reject the transfer: **"The destination account cannot receive transfers from this country"** (or similar region mismatch error) ### 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 Check the **Split Pay → Integrations** tab (top-level menu, 3.7.0+) for the built-in region mismatch warning. Options include: * Ensure connected accounts are within the supported corridor (US, CA, UK, EEA, CH) * Register your platform Stripe account in the same country/region as your vendors * Use manual payout methods (bank wire, PayPal, Wise) for vendors in unsupported regions See [International Transfers](../../faqs/international-transfers/) for full details and workarounds. * * * ## Call to undefined method `WC_Stripe_Logger::log()` [Resolved in 3.7.3](../changelog/#v3-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: **"Call to undefined method `WC_Stripe_Logger::log()`"** ### 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 Update Split Pay to **v3.7.3 or later**. All five namespaced classes now route through the guarded `safe_wcs_log()` helper, which falls back to `WC_Stripe_Logger::debug()` and then PHP `error_log()` when the legacy class is missing. A new `IntegrationLogGuardTest` regression test scans the `includes/Core/` and `includes/Integrations/` trees on every release to prevent the issue from recurring. See the [v3.7.3 changelog](../changelog/#v3-7-3) and the [Payment Plugins for Stripe WooCommerce](../../features/integrations-and-compatibility/payment-plugins-for-stripe-woocommerce/) integration page. * * * ## Transfers admin tab is empty even though Stripe shows transfers [Resolved in 3.7.3](../changelog/#v3-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 Update Split Pay to **v3.7.3 or later**. The fix has three parts: * The `TransferEngine` now stamps `stripe_mode`, `charge_amount`, `charge_date`, `charge_description`, `date_created`/`date_modified`, and per-transfer audit columns on every row. * `TransferLogger` defaults the mode if any caller forgets, so future regressions cannot silently drop rows from the UI again. * The `migration-373` backfill runs once on upgrade and updates historical rows written by 3.7.0+ so existing transfer logs become visible again. It also defensively adds the `integration_source` and `source_order_id` columns on installs that activated before the legacy `plugins_loaded` migration could run. No manual database action is needed. See the [v3.7.3 changelog](../changelog/#v3-7-3). * * * ## Vendor selection on a product disappears after Save [Resolved in 3.7.3](../changelog/#v3-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 Update Split Pay to **v3.7.4 or later**. 3.7.3 closed the inner percent/amount gate, but 3.7.4 closes the wider *outer* erasure path: the entire class of bug where Split Pay product settings get silently wiped when the product is saved through a code path that doesn’t include the Split Pay tab’s fields (variable products’ parent save, `max_input_vars` truncation, JS render failure, programmatic `wp_update_post` / WC REST saves, third-party plugin product saves). 3.7.4’s fix uses a hidden form-presence marker emitted by the SPP product tab; both the simple-product and variation save handlers short-circuit when the marker is absent. A `ProductTabFormPresenceMarkerTest` regression lock prevents the marker from being silently removed in future releases. If your store ran 3.6.x – 3.7.3 and you suspect this happened to historical products, the 3.7.4 upgrade also **automatically rebuilds erased configuration** from your transfer log — see [Recovering Lost Product Settings](../recovering-lost-product-settings/). See the [v3.7.3 changelog](../changelog/#v3-7-3) and the [v3.7.4 changelog](../changelog/#v3-7-4). * * * ## Selected vendor is missing from the dropdown after Save [Resolved in 3.7.4](../changelog/#v3-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 `