Resolved in Split Pay 3.7.3. Both the legacy gateway-webhook path and the new namespaced WCOrderAdapter now derive the unit price from the order line’s subtotal, so percentage transfers apply to the customer-chosen amount. Update if you’re on 3.7.0–3.7.2.

Known compatible plugins#

  • WPC Name Your Price for WooCommerce — tested with the customer-chosen line-subtotal flow.
  • WooCommerce Name Your Price (the official extension).
  • Deposit plugins that override the cart-line price for partial-payment installments.
  • Donation plugins that let the customer enter an arbitrary contribution amount.

The fix is generic — it applies to any plugin that writes the customer-chosen price to the WooCommerce order line subtotal. If you use a plugin we haven’t listed here and you confirm the percentage transfer is hitting the customer-chosen amount on a 3.7.3+ test order, please let us know via support and we’ll add it to this list.

Why it broke in 3.7.0–3.7.2#

The 3.7.0 release introduced a new namespaced WCOrderAdapter (part of the modular adapter architecture). The adapter pulled the unit price from the WooCommerce product object ($product->get_price()) instead of from the order line. For Name Your Price-style plugins, the product object still holds the configured base price (often a $1 placeholder), so the percentage was applied to that placeholder.

The visible symptom was dramatic: an 80% split on a $100 customer-chosen-price order would transfer only $0.80 instead of $80. The customer was charged correctly — the gateway saw the real $100 — but Split Pay’s transfer math was based on the wrong unit price.

The 3.7.3 fix#

Both the legacy gateway-webhook code path and the new namespaced WCOrderAdapter now compute the unit price from the WooCommerce order line item:

  • Source: $item->get_subtotal() / max( $item->get_quantity(), 1 )
  • Effect: percentages always apply to what the customer actually paid for that line, regardless of whether the price came from the product’s base price, a Name Your Price override, a deposit override, or a donation amount.

A regression test — TransferPercentParsingTest — locks the new behavior so the bug can’t silently return.

Upgrade checklist#

  1. Update Split Pay to 3.7.3 or later (see v3.7.3 changelog).
  2. Place a test order using a Name Your Price product with a chosen price clearly different from the configured base price.
  3. Open the Transfers tab and confirm the transfer amount equals chosen_price × configured_percentage.
  4. If the transfer amount still looks wrong on 3.7.3+, open a support ticket with the order ID, the chosen price, the configured percentage, and the actual transfer amount.

What about orders placed during 3.7.0–3.7.2?#

Past transfers don’t auto-correct — Stripe transfers can’t be retroactively resized. If you have impacted past orders, you can:

  • Use the Retry Failed Transfers order action where the transfer log shows a stuck row, so the retry uses the corrected math.
  • Manually create top-up transfers via the Stripe Dashboard or API for the difference between what was sent and what should have been sent. Stripe’s Transfers API takes a destination account ID and an amount in the smallest currency unit.

See also#

Split Pay 3.7.3 changelog Common Errors — Percentage transfers are 100× too small