Stripe’s diagnosis is exactly right, and I can point to the exact code path that causes it. The Checkout Session flow (Adaptive Pricing / Elements ui_mode) is built by WC_Stripe_Checkout_Sessions_Ajax_Handler::create_checkout_session(), and its payment_intent_data comes from build_payment_intent_data() — which only ever sets metadata. It never calls WC_Stripe_Helper::get_payment_intent_description( $order ), which is the plugin’s own helper that produces the “{blog name} – Order {number}” string you saw on the working payments. That helper is used by the classic direct-PaymentIntent flow elsewhere in the plugin, just not by this one.
So it’s not intermittent in the sense of a race condition — it’s fully deterministic per code path: any payment that goes through the Checkout Sessions ajax handler will never carry a description, full stop. Whether a given order hits that handler depends on which checkout flow initiated it, which is worth confirming on your end — if you’re running Adaptive Pricing / multi-currency Stripe checkout, that’s the flow, and every payment through it will show this gap. If some other flow is also missing the description, that would be a second, separate spot to find.
Two ways to close it, since payment_intent_data isn’t filterable in that specific request array today:
1. File it as a bug against woocommerce/woocommerce-gateway-stripe on GitHub — the fix is a one-line addition (‘description’ => WC_Stripe_Helper::get_payment_intent_description( $order )) inside build_payment_intent_data(), but there’s no hook wired into that array yet for a site-side patch to reach it without a custom fork of the handler.
2. Workaround in the meantime: metadata (unlike description) *is* set reliably in both flows, including site_url. If your Stripe email templates or any downstream reconciliation script can key off metadata instead of the description field, you get the order association back without waiting on upstream.
One question that would confirm which orders are affected: are you running Adaptive Pricing / a multi-currency Stripe checkout, or a different Elements/block checkout? That tells you whether this is universal for your store or only a subset.
Hi @smams!
Thanks for bringing this to our attention and for sharing the detailed information from Stripe, including the two Payment Intent examples.
Our developers are aware of this issue and are actively working on a fix.
The additional details you provided, including Stripe’s findings and the example Payment Intent IDs, are very helpful and have been noted for the investigation.
We appreciate you taking the time to report this issue and provide these details.
