Recovering Lost Product Settings 3.7.4+
If a product’s Split Pay configuration (vendor, percentage / fixed amount, shipping) was ever erased — by an earlier-version save bug, a buggy bulk update, a manual database edit, a third-party plugin save path, or any other cause — Split Pay 3.7.4+ can rebuild it from your historical Stripe transfer log.
Overview#
Split Pay 3.7.4 ships with two recovery tools, both backed by the same algorithm. They scan the bsd_scsp_transfer_log table for orders that contain the product, find the most recent successful Stripe transfer for that product, and re-apply the vendor + percentage/amount that actually moved money:
- One-time recovery migration — runs once, automatically, on upgrade to 3.7.4. Scans every product on your store. See One-Time Recovery Migration below.
- Per-product Recover button — perpetual, always available on each WooCommerce product’s Split Pay tab. Use any time to rebuild a single product’s configuration. See Per-Product Recover Button below.
Recovery never overwrites existing configuration. Both the migration and the per-product button are additive by default — if a product already has a vendor saved, recovery is skipped for that product. The per-product button has an explicit Force overwrite checkbox if you want to override an existing-but-wrong configuration.
When you’d need this#
Recovery is useful any time historical product configuration is gone but you know transfers used to fire on those products:
- You’re upgrading from a 3.6.x or 3.7.0–3.7.3 release that had the silent erasure bug fixed in 3.7.4 (the most common case).
- A bulk update went wrong and overwrote a category of products with empty values.
- A manual database edit (or a database restore from a stale snapshot) wiped the
_bsd_spscwt_product_connected_accountmeta on some products. - A third-party plugin doing its own product save erased Split Pay’s meta on the products it touched.
- You restored from a staging snapshot where the product configuration didn’t match production.
- A future bug (in any plugin) silently empties one of Split Pay’s product meta fields.
One-Time Recovery Migration 3.7.4 upgrade#
When you upgrade to 3.7.4, Split Pay automatically runs migration-374.php once. The migration:
- Walks every row of
bsd_scsp_transfer_lognewest-first (capped at 5,000 rows for safety). - For each order in the log, expands the line items (including variations) to the product IDs that were paid.
- For each product whose
_bsd_spscwt_product_connected_accountmeta is currently empty, applies the vendor + percentage / amount that actually moved money on the most recent transfer for that product. - Writes a forensic snapshot of the pre-recovery state to
_bsd_spscwt_pre_374_state, and a recovery marker with the source order ID and charge date to_bsd_spscwt_recovered_in_374. - Skips products that already have a vendor configured — recovery never overwrites existing data.
- Skips multi-product orders where each product routes to a different destination at a different value (those would be ambiguous to attribute).
Dashboard summary notice#
After the migration runs, Split Pay shows a one-time, dismissible admin notice on every WordPress admin page until you dismiss it. The notice tells you exactly what happened:
?spp_show_374_recovery=1 on the Split Pay settings page.The notice has three possible shapes:
- Healthy install (notice-info): “No Split Pay product settings needed recovery on this site. Either all products still have their saved vendor + percentage / amount, or the transfer log has no historical data to reconstruct from.” — this is what most up-to-date stores see.
- Recovered (notice-warning): “Recovered Split Pay settings for N products after scanning M orders. The vendor + percentage / amount values were reconstructed from the most recent successful Stripe transfer for each product.” Followed by a clickable preview of up to 10 sample products that were rebuilt.
- Partial (notice-warning): above plus “N orders had multiple products routing to multiple destinations — those products could not be auto-recovered. Please review them manually using the Transfers tab and re-enter the vendor on those product Split Pay tabs as needed.”
Re-surfacing the notice after dismissal#
If you dismissed the notice and want to look at the recovery summary again later, append ?spp_show_374_recovery=1 to the Split Pay settings page URL:
/wp-admin/admin.php?page=bsd-split-pay-stripe-connect-woo-settings&spp_show_374_recovery=1The notice re-renders from the persisted bsd_split_pay_374_recovery_stats option (which is kept around even after dismissal for forensic reference).
Forensic meta on recovered products#
Each recovered product gets two meta keys you can inspect directly via WP-CLI or phpMyAdmin if you want to audit or revert:
| Meta key | What it stores |
|---|---|
_bsd_spscwt_pre_374_state |
The product’s pre-recovery state — connected, type, pct, amt, ship_type, ship_pct, ship_amt, plus a snapshot_at timestamp and a source tag identifying which recovery wrote the snapshot (migration_374 or manual_per_product_button). |
_bsd_spscwt_recovered_in_374 |
The recovery audit trail — recovered_at, source_order_id, source_charge_date, vendor_acct, entered_value, transfer_type_int, transfer_type_str, source, and force flag. |
Inspect either with WP-CLI:
wp post meta get <product_id> _bsd_spscwt_recovered_in_374
wp post meta get <product_id> _bsd_spscwt_pre_374_statePer-Product Recover Button 3.7.4 perpetual#
For situations where the one-time migration didn’t cover a product (because the product had data when 3.7.4 ran but later lost it again), or when you simply want to rebuild a single product’s configuration from the transfer log, every WooCommerce product’s Split Pay tab has a perpetual recovery panel at the top.
Where to find it#
- Open the product in WooCommerce → Products and click Edit.
- Scroll to the Product data meta box.
- Click the Split Pay Plugin tab in the left sidebar of the product data box.
- The Recover Split Pay settings from transfer log panel renders at the very top of the tab, above the regular vendor / percentage / shipping rows.
WooCommerce-only at the moment. The per-product Recover button currently lives on the WooCommerce product edit screen. FluentCart’s product UI does not yet expose an equivalent button — on FluentCart you can still rely on the one-time migration (which scans bsd_scsp_transfer_log regardless of which integration wrote the rows) and on the Reset to Defaults guidance for clearing local state if you need to re-run.
How to run it#
- If the product currently has no Split Pay configuration (the typical recovery case), simply click Run recovery from transfer log. The button will fire an AJAX request, scan the log, and reconstruct the configuration if a candidate is found.
- If the product currently does have a saved vendor (and you still want recovery to apply — for example, to overwrite an incorrect manual entry with what was last actually transferred), tick the Force overwrite the current vendor selection for this product checkbox before clicking. Without that checkbox, the button reports “This product already has a vendor configured — skipping” and exits without changes.
- Reload the product edit page after a successful recovery to see the restored values populated in the regular vendor / percentage / amount rows.
What the button reports#
| Outcome | Result text | What it means |
|---|---|---|
| Recovered | “Recovered. Vendor acct_xxx with N (percentage / amount) restored from your transfer log. Reload to see it on the form.” |
A historical transfer was found for this product and its vendor + value have been written back to the post meta. |
| Skipped (already configured) | “This product already has a vendor configured — skipping (check Force overwrite to override).” | The product’s connected-account meta is non-empty. Use Force overwrite if you actually want to replace it. |
| Nothing to recover | “No historical Stripe transfer found for this product in the log. Nothing to recover from.” | The product has no rows in bsd_scsp_transfer_log, or every order containing it was multi-product with multiple destinations (ambiguous). Re-enter the configuration manually on the form. |
| Permission denied | “Permission denied.” (HTTP 403) | Current user lacks edit_post on this product. Sign in as a user who can edit it. |
| Recovery failed | “Recovery failed.” or “Recovery request failed (network or server error).” | An unexpected server / WordPress error occurred. Check the WP debug log; the same safe_wcs_log() guard now used elsewhere in the plugin will surface details there. |
“Last recovery on this product” status row#
If the product has been recovered before (either by the one-time migration or by a previous click of the per-product button), the panel renders an extra status row above the action button summarising the prior recovery: “Recovered on YYYY-MM-DD HH:MM:SS — vendor acct_xxx, value 80 (percentage). Sourced from Stripe transfer dated YYYY-MM-DD.”
This is the same data that lives in the _bsd_spscwt_recovered_in_374 meta. It’s informational — clicking Run recovery from transfer log again will re-run the scan from scratch, not just re-display the same row.
When recovery can’t help#
Recovery scans the transfer log only. If a product never had a successful Stripe transfer recorded in that table, there is nothing to reconstruct from. The most common scenarios where recovery returns “Nothing to recover from”:
- Brand-new product — never sold yet, so no transfer log entries exist. Configure the vendor / percentage / amount manually on the form.
- Multi-product orders with mixed routing — if every order containing this product ALSO contained other products routed to different vendors at different values, the per-product attribution is ambiguous and recovery skips the order. Use the Transfers tab to review the historical transfers manually and re-enter the configuration.
- Pre-3.7.0 install with a wiped transfer log — if you cleared the
bsd_scsp_transfer_logtable at some point (e.g. a full reset to defaults), the recovery source is gone. - Transfers fired only from FluentCart with no WooCommerce product mapping — the per-product recovery button maps log rows back to WooCommerce orders. FluentCart-only history is recovered by the one-time migration but not the per-product button (yet).