“Checkout form – Electronics 3” no showing Apple and Google payment

Hello,

I am reporting an incompatibility between a Woodmart custom checkout
layout and the official WooCommerce Stripe Gateway plugin. The express
checkout buttons (Apple Pay / Google Pay) never render on the checkout
page. They work correctly on single product pages.

I have measured each step, and the results are below.

ENVIRONMENT

Woodmart 8.6.1
WooCommerce 11.1.2
WooCommerce Stripe Gateway 11.0.0
WordPress current
PHP 8.4.22
Checkout layout “Checkout form – Electronics 3”
(Woodmart custom layout, Gutenberg based)
Stripe live mode, domain verified for Apple Pay
Tested on Safari / iPhone, with a card in Wallet
(verified working on applepaydemo.apple.com)

SUMMARY

The custom checkout layout does not fire the standard WooCommerce
checkout template hooks, and does not output the #order_review
element. As a consequence:

– the Stripe plugin never outputs its express checkout container ;
– WooCommerce’s own wc_get_pay_buttons() is never executed either ;
– the “updated_checkout” event is never emitted on page load, so the
Stripe script never initialises.

FINDING 1 — checkout template hooks never fire

Measured with did_action() in wp_footer, on the checkout page, with a
non-empty cart and the full form displayed:

woocommerce_before_checkout_form = 0
woocommerce_checkout_before_customer_details = 0
woocommerce_checkout_billing = 0
woocommerce_checkout_order_review = 0
woocommerce_proceed_to_checkout = 0
woocommerce_review_order_before_payment = 1

Only the last one fires.

The theme template woodmart/woocommerce/checkout/form-checkout.php
does contain these do_action() calls, so it is the custom layout that
replaces it.

FINDING 2 — callbacks are registered but never called

On the same page request, the callbacks registered on
woocommerce_checkout_before_customer_details are:

priority 1 : WC_Stripe_Express_Checkout_Element::display_express_checkout_button_html
priority 30 : wc_get_pay_buttons

Both are waiting for a do_action() that never happens. Note that
wc_get_pay_buttons is WooCommerce core, not a third-party plugin —
other standard features are silently inactive on this layout.

FINDING 3 — #order_review is missing, updated_checkout never fires

document.querySelectorAll(‘#order_review’).length = 0

WooCommerce’s checkout script relies on this element. Measured over
5 seconds after page load:

update_checkout events = 0
updated_checkout events = 0

Triggering jQuery(document.body).trigger(‘update_checkout’) manually
works and does emit updated_checkout, so the AJAX flow itself is
functional — it is simply never started.

This matters because of how the Stripe plugin initialises
(build/express-checkout.js):

( is_product_page || is_pay_for_order || is_cart_page
|| is_change_payment_method ) && C.init();
…
$( document.body ).on( “updated_checkout”, () => { C.init() } );

“is_checkout_page” is deliberately absent from the first condition:
on the checkout page, initialisation depends entirely on
updated_checkout.

WORKAROUNDS TRIED, AND WHAT REMAINS

1. Adding a “Hook WooCommerce” block set to
woocommerce_checkout_before_customer_details inside the layout.
Result: the container <div id=”wc-stripe-express-checkout-element”>
is now output, with its separator. Verified in the page source.

2. Triggering update_checkout once on page load, from a small mu-plugin.
Result: updated_checkout now fires (measured: 2 occurrences).

After both workarounds, the button still does not render. A
MutationObserver watching the whole document for 12 seconds recorded
no creation and no removal of the child element that the plugin always
appends before mounting:

renderButton: (e, r) => {
if ( t(“#wc-stripe-express-checkout-element”).length ) {
const n = wc-stripe-express-checkout-element-${r};
t(#${n}).length || t(“#wc-stripe-express-checkout-element”)
.append(<div id="${n}"></div>);
e.mount(#${n});

So C.init() is reached but createExpressCheckoutElement() never
appends. This measurement does not depend on the device or on wallet
availability.

The data passed to the script is valid on the checkout page:

wc_stripe_express_checkout_params.stripe.is_apple_pay_enabled = true
wc_stripe_express_checkout_params.stripe.is_google_pay_enabled = true
wc_stripe_express_checkout_params.cart = {
total: 780390, currency: “eur”, requestShipping: true,
requestPhone: false,
displayItems: [ Subtotal, VAT, { key: “total_shipping”, … } ]
}

These values are identical in nature to those of the product page,
where the button renders correctly. The failing path is the one shared
by the cart and checkout pages:

} else { const t = _t(“cart”); if ( t && ! v ) … }

The cart page is affected in the same way: the container is output but
no button is ever created. Only the is_product_page branch works.

WHAT I AM ASKING

Could you check how the custom checkout layout interacts with the
WooCommerce Stripe Gateway express checkout, and in particular:

1. whether the standard checkout hooks could be fired by the layout,
or documented as not fired so that integrators know ;
2. whether #order_review can be preserved, since WooCommerce’s own
checkout script and several plugins depend on it ;
3. why the cart/checkout code path of the Stripe plugin does not
create its element on this layout, while the product page path
does.

I am happy to run any additional test on the site and to provide
temporary access if that helps.

Thank you,