dev

Hello,

Just to recap, since 9.7.0 the gateway validates required fields when creating the Stripe Customer. In guest/auto-account/wallet flows, WC_Customer can still be empty while order/posted billing fields are presen, so we get “Missing required customer field: address->line1” before any PI exists.

What changed upstream was
– 9.7.0 added early “create customer” validation.
– 9.8.0 removed the classic checkout validation before PaymentMethod creation (mitigates pre-PI failures on classic).
– 9.8.1 relaxed validation for Pay-for-Order. GitHub
– 9.9.1 validates order when verifying the PI (post-PI stage).

Status on our side
We can still reproduce a first-submit fail / second-submit pass on classic checkout with auto account creation enabled, and originally saw it on product/cart wallet buttons. First attempt: no PI gets created. Immediate retry: succeeds (sometimes after 3DS).

What we’re seeing on prod is with classic checkout:

1. Enable Guest checkout and Auto create account during checkout.
2. Fill billing incl. Address line 1; submit.
3. Occasionally first submit fails with “Missing required customer field: address->line1” and no PI in Stripe logs; re-submit succeeds and creates the PI.

Please confirm whether there’s a known gap for guest + auto account timing and/or wallet flows after 9.8.1. If so, can the validator be updated to prefer order billing (or posted fields) when available? If you need a minimal patch, we can share a 10-line hook that syncs POST → WC_Customer before your validation runs.

Hello,

We’re already on that version specifically and there is nothing in the change log or code about changes which fix this issue. They were examples of others having similar issues.

That is also very generic advise which does not impact or any and changes to the issue at hand.

Hello

Unfortunately, due to compliance and operational policies, we cannot provide you with direct access to staging/dev environments or system status reports. The only access we can facilitate is via a recorded screen share, which I understand is not an option for this forum.

Our latest findings so far:

• Issue is not limited to Express Checkout. We can reproduce the failure with card payments as well.
• Error message: Payment failed: Missing required customer field: address->line1
• The failure occurs before a PaymentIntent is created, so no Stripe webhook events are triggered.
• The WC_Order object does contain a valid billing_address_1 at checkout.
• Wallet tokens (Google Pay, Apple Pay) also contain address_line1.
• The error occurs because validation is being performed against the WC_Customer object at customer creation time, which in some flows (guest checkout, auto-account creation, wallets) does not yet have billing fields populated even though the order does.

Checkout fields

• On our install, billing_address_1 remains a required field, confirmed via CLI and frontend inspection.
• Plugins checked: no filters unset billing_address_1 or mark it non-required.
• The only modifications are:
  • Klaviyo adds a newsletter checkbox.
  • WooCommerce EU VAT Compliance adds a VAT number field.

References

• Similar reports and fixes are discussed here:
  • PR 4576: https://github.com/woocommerce/woocommerce-gateway-stripe/pull/4576
  • Issue 4588: https://github.com/woocommerce/woocommerce-gateway-stripe/issues/4588
  • Third-party patch plugin: https://github.com/freedjack/woocommerce-stripe-address-fix/blob/main/woocommerce-stripe-address-fix.php
• Our findings match the analysis in those threads: the validator is checking the wrong object (customer vs. order) or doing so too early.

Main question

At this stage, our main concern is whether this has been properly resolved in versions after 9.8.1.

We rolled back to 9.8.1 due to a cached pricing issue with Apple Pay, but if 9.9.0/9.9.1 resolves the billing validation bug then we can retest an upgrade.

Could you confirm whether the validation logic has been updated since 9.8.1 to address this customer vs. order mismatch? And if not, is applying the standalone patch plugin (or equivalent snippet) still the recommended workaround until a core fix is released?

Hi @mosesmedh

Thanks for the follow-up. We’ve done more triage and can now reproduce the issue without relying on express. Updated summary

• Error shown in WooCommerce (first attempt):
  Payment failed: Missing required customer field: address->line1
• No PaymentIntent is created for the failing attempt (so no Stripe webhooks).
• Immediately retrying (same session) often succeeds and creates a PI, sometimes after 3DS.

Where it happens

Originally observed with Google Pay on product/cart pages. We have since disabled express on product/cart (checkout-only now). We can still trigger the failure on the standard card Payment Element at checkout with auto account creation enabled.

What Stripe sees on failing attempts

Browser creates PaymentMethods with a full line1 each time (examples from 21 Sept 2025, times UTC):

• pm_1S9p8m… @ 16:25:28 — billing_details.address.line1 = "ADDRESS"
• pm_1S9p9S… @ 16:26:10 — line1 = "ADDRESS"
• pm_1S9p9x… @ 16:26:41 — line1 = "ADDRESS"

In the first, failing submission there is no corresponding PaymentIntent creation in logs; minutes/seconds later a new attempt creates pi_3S9pA5… and completes after 3DS. Our working hypothesis

Since 9.7, the gateway validates required billing fields on the WC_Customer object at customer-creation time. In flows with Guest checkout allowed + Auto account creation enabled, there are moments where the order and PaymentMethod both have billing_address_1, but the WC_Customer does not yet (AJAX/timing), so validation fails “early”, before PI creation.

This aligns with the public report about 9.7 validation and customer meta timing (we’re not using Woo Address Book):
https://github.com/woocommerce/woocommerce-gateway-stripe/issues/4524 Repro (our side)

1. Enable Guest checkout and Auto create account during checkout.
2. Use Stripe Payment Element (no express) on checkout.
3. Fill billing incl. Address line 1; submit.
4. Occasionally (especially after field changes that trigger AJAX updates), the first submit fails with the “address->line1” notice and no PI is created; re-submit succeeds and a PI is created/confirmed.

What we’re asking

• Can the gateway validate against the order billing fields (or the posted data) rather than only the WC_Customer meta at that instant?
• Alternatively, delay the customer-creation validation until after Woo has synced the posted billing fields to the customer.
• If this is expected, could the docs call out the auto-account + Payment Element timing, and/or provide a recommended hook sequence?

Hello,

From what we can tell this is express (so far google pay) on the product pages as it seems to affect single item orders. This has since been disabled to rule that out but it doesn’t occur for all orders.

I can share this via email not public forum as its for a whole multi-site and this only relates to a single subsite.

We’ve also noticed that the plugin is making external API calls even when simply viewing the Products/Posts list table in wp-admin.

At the moment, the ST4_columns_content() callback calls:

$shortlink = shortcm_get_shortlink($permalink, $post_ID);

That function may trigger shortcm_generate_shortlink() and make a network request to Short.io, even if the shortlink was already generated before. On sites with lots of products, this means every list view can generate dozens or hundreds of outbound API requests, which slows the page significantly.

For the list table column, it should only read the saved _shortcm post meta and display it if it exists. If a shortlink is missing, show a placeholder like “(not generated)” instead of generating it automatically. That way:

• The Products/Posts list page loads instantly, without waiting on Short.io.
• New shortlinks are still generated on publish/update via shortcm_generate_shortlink().
• If needed, a small “Generate” button could be added so users can create a link on demand.

Example adjustment:

function ST4_columns_content($column_name, $post_ID) {
if ($column_name !== ‘Short URL’) return;

$shortlink = get_post_meta($post_ID, '_shortcm', true); // meta only, no API call

if ($shortlink) {
    $url = esc_url($shortlink);
    echo '<div class="copy_text" data-toggle="tooltip" title="Copy to Clipboard">' . $url . '</div><br>';
    echo '<img style="width:20px;color:#2271b1;" src="' . SHORTCM_URL . '/shortlink_copy.png" class="copy" cus_link="' . $url . '">';
} else {
    echo '<em>(not generated)</em>';
}

}

After making this change, our own Products list page is noticeably faster, since it no longer fires off Short.io requests for every row. The plugin only talks to the API when it actually needs to create a link (on publish/update).

This would be a nice quality-of-life improvement for anyone with a larger WooCommerce catalogue or a high post count.

Hi team,

We’ve identified and resolved a critical issue affecting our WordPress site that we originally suspected might be related to Spectra blocks. Summary:

We were encountering the following fatal error:

nginx

CopyEdit

PHP Fatal error: Uncaught TypeError: array_intersect_key(): Argument #1 ($array) must be of type array, string given in /wp-includes/block-supports/layout.php:600+

After extensive debugging, we’ve determined the actual cause was the core core/social-links block, which was passing parentLayout as a string ("flex") instead of the expected array structure. This led to array_intersect_key() being called on a string and crashing the page. Why this matters:

Although Spectra blocks appeared to be involved initially (due to their heavy use of layout structures), the issue was unrelated to Spectra’s block rendering. Resolution:

We patched WordPress core (layout.php) to add sanity checks before array_intersect_key() is called. Specifically:

• We now confirm parentLayout and layout are arrays.
• If not, we log the issue and safely skip processing to avoid breaking the page.

This resolved the issue completely.

Hello,

Not locate the trigger yet nor have further details, but its showing in the woocommerce logs.