fix(stripe-checkout): guard null/WP_Error customer in run_preflight by superdav42 · Pull Request #1126 · Ultimate-Multisite/ultimate-multisite

superdav42 · 2026-05-06T02:31:36Z

Summary

Fixes a fatal TypeError reported via support that crashed Stripe Checkout for some merchants:

WP_Ultimo\Gateways\Stripe_Checkout_Gateway::sync_billing_address_to_stripe():
Argument #1 ($stripe_customer_id) must be of type string, null given,
called in .../class-stripe-checkout-gateway.php on line 230

Root cause

run_preflight() consumed $s_customer->id without checking the documented \Stripe\Customer|\WP_Error return contract of get_or_create_customer().

When the stored gateway_customer_id belongs to a different Stripe account than the currently active API keys (most commonly after a test↔live mode switch, key rotation, or Stripe account swap), the retrieve call throws and is silently swallowed. Execution falls through to customers->create(), which can also fail (e.g. authentication error, network failure). get_or_create_customer() then returns WP_Error, whose magic __get returns null for ->id, and PHP fatals on the typed string parameter of sync_billing_address_to_stripe().

Fix

Three layered changes so this failure mode can't recur:

Stripe_Checkout_Gateway::run_preflight() — handles WP_Error and empty-id results from get_or_create_customer() and surfaces them as a clean checkout error rather than fatalling. The checkout flow already handles WP_Error returns from preflight.
Base_Stripe_Gateway::get_or_create_customer() — self-heals: when a stored cus_* cannot be retrieved (any reason), the swallowed exception is now logged via wu_log_add('stripe', …), and the function falls through to creating a fresh Stripe customer rather than bubbling an opaque error. A final defensive guard ensures the caller receives either a usable \Stripe\Customer or a WP_Error — never an object whose id is null.
Stripe_Checkout_Gateway::sync_billing_address_to_stripe() — adds a defensive empty() short-circuit for any future caller that might bypass run_preflight.

After this, account/key mismatches will quietly recover on the next checkout attempt, and any genuinely unrecoverable failure produces a WP_Error shown to the customer instead of a fatal stack trace.

Tests

Added three regression tests to tests/WP_Ultimo/Gateways/Stripe_Checkout_Gateway_Run_Preflight_Test.php:

test_run_preflight_returns_wp_error_when_customer_creation_fails — both retrieve and create throw; preflight must return WP_Error, never fatal.
test_get_or_create_customer_self_heals_on_stale_stored_id — stored cus_* is unretrievable but create succeeds; a fresh customer id must be returned.
test_sync_billing_address_to_stripe_short_circuits_on_empty_id — empty input must not produce any API call.

$ vendor/bin/phpunit --filter Stripe_Checkout_Gateway_Run_Preflight_Test --no-coverage
OK (6 tests, 34 assertions)

$ vendor/bin/phpunit --filter 'WP_Ultimo\\Gateways\\(Stripe_Gateway_Test|Base_Stripe_Gateway_Test|Stripe_Checkout_Gateway_Run_Preflight_Test|Stripe_Gateway_Process_Checkout_Test)' --no-coverage
OK (148 tests, 296 assertions)

PHPCS is clean for the touched lines (the two pre-existing warnings on lines 2918/3295 of class-base-stripe-gateway.php are unrelated to this change). PHPStan: no errors.

Risk

Low. Behavioural changes are all in failure paths:

The success path is unchanged.
A previously-fatal request now returns a WP_Error to the checkout flow.
A previously-failing checkout caused by a stale stored cus_* now silently self-heals.

Files changed

inc/gateways/class-stripe-checkout-gateway.php
inc/gateways/class-base-stripe-gateway.php
tests/WP_Ultimo/Gateways/Stripe_Checkout_Gateway_Run_Preflight_Test.php

aidevops.sh v3.14.75 plugin for OpenCode v1.14.33 with claude-sonnet-4-6 spent 1d 21h on this as a headless worker.

Customer report: Stripe Checkout was fatalling with TypeError: Stripe_Checkout_Gateway::sync_billing_address_to_stripe(): Argument #1 ($stripe_customer_id) must be of type string, null given, called in .../class-stripe-checkout-gateway.php on line 230 Root cause walk: 1. run_preflight() calls get_or_create_customer(), which is documented to return \Stripe\Customer|\WP_Error. 2. The retrieve path silently swallows exceptions (e.g. stored cus_* belongs to a different Stripe account after a test/live switch or key rotation), then falls through to creating a new customer. 3. If the create call also throws, get_or_create_customer() returns a WP_Error. 4. run_preflight() never checked for WP_Error and read $s_customer->id — WP_Error's magic getter returns null for unknown properties — so PHP fatals on the typed string parameter of sync_billing_address_to_stripe(). Fix: - run_preflight() now returns the WP_Error from get_or_create_customer() unchanged, and returns a fresh WP_Error if the result is otherwise unusable (no id). The checkout flow already handles WP_Error returns. - get_or_create_customer() self-heals when the stored Stripe customer id cannot be retrieved (most common: test/live key mismatch or account swap) by logging the cause and creating a fresh customer instead of bubbling an opaque error. - Added a final defensive return guard so the caller is guaranteed to receive either a usable Stripe customer or a WP_Error — never an object whose id is null. - sync_billing_address_to_stripe() short-circuits on empty input as belt-and-braces for any future caller. Tests: - New: returns WP_Error when both retrieve and create fail. - New: self-heals (creates fresh customer) when stored cus_* cannot be retrieved. - New: sync_billing_address_to_stripe() never calls the API on empty id. - All 148 Stripe-related tests pass.

coderabbitai · 2026-05-06T02:31:42Z

Warning

Rate limit exceeded

@superdav42 has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 15 minutes and 48 seconds before requesting another review.

To continue reviewing without waiting, purchase usage credits in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 6f8a1fac-e4af-410a-bbbc-2973b3b66a78

📥 Commits

Reviewing files that changed from the base of the PR and between 22bafcc and 56b2bdd.

📒 Files selected for processing (3)

inc/gateways/class-base-stripe-gateway.php
inc/gateways/class-stripe-checkout-gateway.php
tests/WP_Ultimo/Gateways/Stripe_Checkout_Gateway_Run_Preflight_Test.php

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch fix/stripe-checkout-null-customer

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

github-actions · 2026-05-06T02:34:19Z

🔨 Build Complete - Ready for Testing!

📦 Download Build Artifact (Recommended)

Download the zip build, upload to WordPress and test:

Build: ultimate-multisite
⬇️ Download from GitHub Actions
⬇️ Download without Github Account (nightly.link)

🌐 Test in WordPress Playground (Very Experimental)

Click the link below to instantly test this PR in your browser - no installation needed!
Playground support for multisite is very limitied, hopefully it will get better in the future.

🚀 Launch in Playground

Login credentials: admin / password

github-actions · 2026-05-06T02:38:19Z

Performance Test Results

Performance test results for 6a22b1a are in 🛎️!

Note: the numbers in parentheses show the difference to the previous (baseline) test run. Differences below 2% or 0.5 in absolute values are not shown.

URL: /

Run	DB Queries	Memory	Before Template	Template	WP Total	LCP	TTFB	LCP - TTFB
0	40 (-1 / -3% )	37.73 MB	832.00 ms (-47.00 ms / -6% )	170.50 ms (-8.00 ms / -5% )	1046.00 ms (-47.00 ms / -4% )	1998.00 ms	1904.35 ms	88.40 ms (+2.30 ms / +3% )
1	56	49.11 MB	929.00 ms	144.00 ms (-7.50 ms / -5% )	1073.00 ms (-25.50 ms / -2% )	2050.00 ms	1966.30 ms	83.20 ms (+2.45 ms / +3% )

superdav42 · 2026-05-06T02:38:36Z

Summary

Fixes a fatal TypeError reported via support that crashed Stripe Checkout for some merchants:

WP_Ultimo\Gateways\Stripe_Checkout_Gateway::sync_billing_address_to_stripe():
Argument #1 ($stripe_customer_id) must be of type string, null given,
called in .../class-stripe-checkout-gateway.php on line 230

Root cause

run_preflight() consumed $s_customer->id without checking the documented \Stripe\Customer|\WP_Error return contract of get_or_create_customer().
When the stored gateway_customer_id belongs to a different Stripe account than the currently active API keys (most commonly after a test↔live mode switch, key rotation, or Stripe account swap), the retrieve call throws and is silently swallowed. Execution falls through to customers->create(), which can also fail (e.g. authentication error, network failure). get_or_create_customer() then returns WP_Error, whose magic __get returns null for ->id, and PHP fatals on the typed string parameter of sync_billing_address_to_stripe().

Fix

Three layered changes so this failure mode can't recur:

Stripe_Checkout_Gateway::run_preflight() — handles WP_Error and empty-id results from get_or_create_customer() and surfaces them as a clean checkout error rather than fatalling. The checkout flow already handles WP_Error returns from preflight.
Base_Stripe_Gateway::get_or_create_customer() — self-heals: when a stored cus_* cannot be retrieved (any reason), the swallowed exception is now logged via wu_log_add('stripe', …), and the function falls through to creating a fresh Stripe customer rather than bubbling an opaque error. A final defensive guard ensures the caller receives either a usable \Stripe\Customer or a WP_Error — never an object whose id is null.
Stripe_Checkout_Gateway::sync_billing_address_to_stripe() — adds a defensive empty() short-circuit for any future caller that might bypass run_preflight.
After this, account/key mismatches will quietly recover on the next checkout attempt, and any genuinely unrecoverable failure produces a WP_Error shown to the customer instead of a fatal stack trace.

Tests

Added three regression tests to tests/WP_Ultimo/Gateways/Stripe_Checkout_Gateway_Run_Preflight_Test.php:

test_run_preflight_returns_wp_error_when_customer_creation_fails — both retrieve and create throw; preflight must return WP_Error, never fatal.
test_get_or_create_customer_self_heals_on_stale_stored_id — stored cus_* is unretrievable but create succeeds; a fresh customer id must be returned.
test_sync_billing_address_to_stripe_short_circuits_on_empty_id — empty input must not produce any API call.

$ vendor/bin/phpunit --filter Stripe_Checkout_Gateway_Run_Preflight_Test --no-coverage
OK (6 tests, 34 assertions)
$ vendor/bin/phpunit --filter 'WP_Ultimo\\Gateways\\(Stripe_Gateway_Test|Base_Stripe_Gateway_Test|Stripe_Checkout_Gateway_Run_Preflight_Test|Stripe_Gateway_Process_Checkout_Test)' --no-coverage
OK (148 tests, 296 assertions)

PHPCS is clean for the touched lines (the two pre-existing warnings on lines 2918/3295 of class-base-stripe-gateway.php are unrelated to this change). PHPStan: no errors.

Risk

Low. Behavioural changes are all in failure paths:

The success path is unchanged.
A previously-fatal request now returns a WP_Error to the checkout flow.
A previously-failing checkout caused by a stale stored cus_* now silently self-heals.

Files changed

inc/gateways/class-stripe-checkout-gateway.php
inc/gateways/class-base-stripe-gateway.php
tests/WP_Ultimo/Gateways/Stripe_Checkout_Gateway_Run_Preflight_Test.php

aidevops.sh v3.14.75 plugin for OpenCode v1.14.33 with claude-sonnet-4-6 spent 1d 21h on this as a headless worker.

Merged via PR #1126 to main.
Merged by deterministic merge pass (pulse-wrapper.sh).

superdav42 merged commit 217b5dd into main May 6, 2026
11 checks passed

superdav42 deleted the fix/stripe-checkout-null-customer branch May 7, 2026 02:36

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(stripe-checkout): guard null/WP_Error customer in run_preflight#1126

fix(stripe-checkout): guard null/WP_Error customer in run_preflight#1126
superdav42 merged 1 commit intomainfrom
fix/stripe-checkout-null-customer

superdav42 commented May 6, 2026

Uh oh!

coderabbitai Bot commented May 6, 2026

Rate limit exceeded

Uh oh!

github-actions Bot commented May 6, 2026

Uh oh!

github-actions Bot commented May 6, 2026

Uh oh!

Uh oh!

superdav42 commented May 6, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Conversation

superdav42 commented May 6, 2026

Summary

Root cause

Fix

Tests

Risk

Files changed

Uh oh!

coderabbitai Bot commented May 6, 2026

Rate limit exceeded

Uh oh!

github-actions Bot commented May 6, 2026

🔨 Build Complete - Ready for Testing!

📦 Download Build Artifact (Recommended)

🌐 Test in WordPress Playground (Very Experimental)

Uh oh!

github-actions Bot commented May 6, 2026

Uh oh!

Uh oh!

superdav42 commented May 6, 2026

Summary

Root cause

Fix

Tests

Risk

Files changed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant