“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,

Hello,

Thank you for purchasing WoodMart, and thanks for writing in. We’re happy to help.

Could you share your admin login details in the Private content field? Then we can check your settings and find what’s actually causing this instead of guessing. Only our support team can see that field, and we keep your details confidential.

Best regards,
XTemos Studio

[Author]

Posts