Express Payment button not visibile on the Cart template #10043

ralucaStan · 2024-12-27T13:19:45Z

Describe the bug

When visiting the Page: Cart template, the button for express payment is not visible in the Cart block

To Reproduce

Go to Appearance > Editor > Templates > Page: Cart
Click on 'Edit'
Scroll down to the bottom of the template
Notice the express payment buttons aren't available

Actual behavior

The buttons are visible when navigating to the block via the Post editor. Admin > Pages > Cart

Screenshots

Page: Cart template

Cart Page

Expected behavior

The express payment buttons should show in the editor for the template as well

Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context

bborman22 · 2025-01-06T16:29:49Z

A quick note while triaging, I am able to see the express checkout buttons on the cart page when going to Admin > Pages > Cart, so some things to consider are that it requires HTTPS and a valid browser set up. But we'll definitely want to confirm the overall behavior, because if they are not appearing, than we shouldn't display a seemingly broken view like that.

danielmx-dev · 2025-01-09T17:03:56Z

Please add your planning poker estimate with Zenhub @FangedParakeet

danielmx-dev · 2025-01-24T16:38:59Z

In #10141 I'm proposing to stop using the Stripe Elements API to load the previews, and instead use the APIs provided directly by Google (https://developers.google.com/pay/api/web/guides/resources/customize) and Apple (https://developer.apple.com/documentation/apple_pay_on_the_web/displaying_apple_pay_buttons_using_css).

Here's how it looks in the Apple Pay / Google Pay Settings page (using Stripe):

Here's in the Template Editor (which previously didn't load, now it's using the Apple Pay and Google Pay APIs directly):

And here's in the live Cart page (Using Stripe):

Here is another example using different settings:

Settings:

Template Editor:

Cart Page:

In this last screenshot there seems to be an error with the margin calculation done by Stripe when using Safari, but it's outside of our control.

Finally here are screenshots using the Outline theme.

Settings:

Template Editor:

Cart Page:

In Chrome the borders render fine (Although Apple Pay is not supported, so it won't render at all):

danielmx-dev · 2025-01-28T15:51:51Z

I created a follow-up issue to track the problem with the white/outline buttons in safari (I also confirmed that the issue is present in the current develop branch): #10258

FangedParakeet · 2025-01-28T20:45:51Z

Just dropping a last call for feedback on this issue. It appears that the current solution in #10141 is a large improvement over the non-functionality reported in this issue, has been reviewed by Heisenberg, and offers visual parity with checkout with the sole exception of the difference described in #10258, which can be completed as a follow-up issue.

I've added this issue to the 8.9.0 milestone and we will look to merge our solution before the end of the week, since the PR has been approved. Am extending a final opportunity to suggest any alterations to the given solution, in case there is any critical shortfall in visual appearance or functionality. Let us know if anyone has any cause to pause and review the implementation here, otherwise we will be closing out this issue once merged and if there are further changes required, we can continue the conversation in #10248. Cheers in advance and apologies for frivolous pings! 🙏

CC @ralucaStan @pierorocca @elizaan36

pierorocca · 2025-01-29T00:26:48Z

The downside of this approach is that, if more express payment methods are added, we'd need to implement a way to render the buttons ourselves. An alternative would be to just show placeholder buttons and don't worry too much about the styling, but please let me know what do you think

At some point soon Amazon Pay may be added. Stripe Link is an option and Klarna is in Beta. So if this isn't scalable I'd suggest other options.

danielmx-dev · 2025-01-29T15:41:09Z

At some point soon Amazon Pay may be added. Stripe Link is an option and Klarna is in Beta. So if this isn't scalable I'd suggest other options.

We could limit the new solution to Google Pay/Apple Pay only, and once the new express payment methods are added we can work individually in their previews (in the meantime the previews would be rendered using Stripe, although that may not work in the template editor as explained in the present issue).

The only other alternative would be to use regular unstyled buttons as placeholders.

pierorocca · 2025-01-29T19:19:52Z

Amazon might be easier to have a placeholder since it has only 1 theme and no configurable text. In principle using real not dummy data is preferred as it scales better and is easier to maintain.

danielmx-dev · 2025-01-30T13:52:47Z

I'll add a change to my PR so when a new express payment method is added it will use the Stripe preview, that should give us time to implement the custom preview button in the future.

pierorocca · 2025-01-30T23:33:53Z

@danielmx-dev one thing I need to clear up for my understanding. Brian was able to see the buttons in the editor, and Raluca was not. What's the difference?

danielmx-dev · 2025-01-31T13:58:11Z

Brian was able to see the buttons in the editor, and Raluca was not. What's the difference?

The buttons will show up when using the page editor but they won't when using the template editor (FSE). Although these editors are really similar, the template editor is actually using an iframe to display a preview of the website. The Stripe iframe that we use to display the express checkout buttons don't work as expected when embedded inside this internal iframe. I wasn't able to find any solutions to this particular problem.

pierorocca · 2025-01-31T18:28:58Z

@nerrad education opportunity for me here, do you have any historical background why the editor edits in these two ways? Is it because the template has to be inserted into the page? Does this cause a broader issue for payments where iFrame usage is common.

nerrad · 2025-01-31T19:40:46Z

Although these editors are really similar, the template editor is actually using an iframe to display a preview of the website.

Some original context here on when template/site editors were moved to be in an iframe.

When this was initially added, the post editor was not iframed, however that has changed (as of WP 6.3). Now if all registered blocks are using the latest apiVersion 3, and there are no classic metaboxes added by plugins in the editor, then the editor is iframed.

I'm not sure what exactly prompted the different experiences here but read over those posts (particularly the WP 6.3 link) because I suspect there is a way assets can be registered so they work in both contexts - it's possible WooPayments isn't following the recommended path here.

pierorocca · 2025-01-31T20:48:19Z

Helpful thank you as always @nerrad. @danielmx-dev @FangedParakeet what's your take on the suggested options within @ellatrix post?

danielmx-dev · 2025-02-03T14:39:01Z

The linked resources are very helpful; however, the issue still can't be fixed since there are dependencies outside of our control.

Using the provided enqueue_block_assets filter I was able to include the Stripe SDK within the iframe; however, when I try to initialize the express checkout buttons within the iframe manually, I get the following warning:

[Stripe.js] You are testing over HTTP, so Google Pay will not appear. You must use HTTPS in order to use Google Pay.

This means that the Stripe library detects that the iframe is using HTTP as its protocol even if the parent page is being served through HTTPS. My guess is that the library is looking at the window.location.protocol or window.location.href values expecting to get https: back, however inside the iframe the protocol is blob:.

Besides the issue above, it looks like the react-stripe-js is also having issues properly attaching the event listeners for its rendered components, since the onReady handler is never called (we rely on this handler to determine if the buttons will be appear or not). Unfortunately the library doesn't give back any debug information telling us what exactly went wrong, so even if we are able to reach out to stripe to fix the issue with the iframe protocol, we'd probably also need to re-work our implementation so we can initialize the components manually instead of using React.

pierorocca · 2025-02-04T00:37:31Z

Thanks @danielmx-dev for diving into that.

@ellatrix I'm keen to get your thoughts here as payments is an area that's often more complex and that has different needs/realities. The implication is that things related to payments like express checkout buttons, BNPL messaging, and payment methods may not render at all in FSE or it provides misleading UI to users who may think the site or the payment provider is not functioning.

Daniel was looking at a workaround above. I'm highly concerned about going down that path. It's not true to live production experience and because it puts the burden on the plugin to figure out how to manage two different implementations and to keep them in sync...especially if some of the decisions to show or not show a button are out of our control and it can't be simulated with confidence.

mgascam · 2025-02-10T10:48:52Z

Hi @danielmx-dev 👋 I'm the release lead of WooPayments 9.0.0. I was checking the previous GH milestone (8.9.0) and this issue is part of it. Given the recent release, would it be okay to remove this issue from the 8.9.0 milestone? Thanks for your help!

danielmx-dev · 2025-02-10T13:35:44Z

Thanks for the heads up @mgascam, I have removed this issue from the previous 8.9.0 milestone. I'll keep the field empty until the issue is unblocked.

pierorocca · 2025-02-10T17:36:31Z

@ralucaStan want to get your perspective as well and if we should pull this into an internal discussion as this seems like a blocker for payments integrations.

FangedParakeet · 2025-02-11T13:55:26Z

I just want to quickly sum up our potential options and the various pitfalls here for @ralucaStan.

Essentially, the preview for EPM buttons on the blocks FSE is not loading correctly, since the button iframe is not loading correctly within the FSE iframe, as described in #10043 (comment).

The solution that @danielmx-dev has devised bypasses Stripe and uses custom Google and Apple libraries to present a preview of the button in #10141. This code is custom though relatively compact and has the following characteristics.

Appearance incorporates custom checkout styling and is visually very close (if not, identical) to actual appearance.
As long as Stripe does not make significant departures from default EPM appearance, this should remain relatively close to the actual appearance over time.
While the appearance may remain stable, the implementation is custom, which raises issues with long-term maintainability.
While some of the preview components can be reused, we would need to add a new implementation to support additional EPM payment methods (e.g. Amazon Pay, Klarna, etc.)

The ideal solution would be to incorporate Stripe's payment element, as this would be the most maintainable and likely only involve a single of difference between implementation for different payment methods (setting the payment method type). We could delay this resolution and seek to understand how we could defeat our iframing issues, but this would take significant effort and the pathway towards achieving this does not seem immediately apparent.

One more solution could be to use a static placeholder to present this preview as a short-term solution. This would be lightweight and could also incorporate custom checkout styling. However, this would be challenging to maintain, as we would need to be vigilant of the malleable appearance of the button at checkout and could run afoul of violating recommended appearance if Stripe/Apple/Google decide to drastically modify the appearance of their button at checkout. We would essentially need to maintain this preview manually and reactively, which would be challenging and repetitive.

Hopefully, I managed to summarise this scenario somewhat accurately, but feel free to let us know if you have any more questions!

ralucaStan · 2025-02-14T17:11:24Z

Thank you for the ping.
I can bring some input on the checkout block experience. We recently brought in some merchant-defined style controls for these buttons; see More options coming to the express checkout.

First and foremost, we are asking all payment extensions to render the full express payment buttons in the editor instead of preview images. Up until now, image previews were encouraged in the editor instead of the actual buttons rendered on the front-end for shoppers. With these recent changes, the merchant UX will be greatly improved if all the payment extensions could render the full buttons in the editor.

It's good that the solution from #10141 renders buttons, but do they react when the Apply uniform styles option? If we could make them react then we could use this as a temporary solution until we iterate more on the iframing issues. I prefer this over the static placeholder.

danielmx-dev · 2025-02-14T17:39:50Z

Thanks for your input @ralucaStan

It's good that the solution from #10141 renders buttons, but do they react when the Apply uniform styles option?

Yes, the buttons react to the available uniform styles options:

danielmx-dev · 2025-02-18T16:53:09Z

@pierorocca given that the workaround meets the required criteria, should we move forward with it? Or do you have other concerns that should be addressed before moving forward?

pierorocca · 2025-02-18T18:34:00Z

@danielmx-dev Samir sums up the issues well. My main concern is we're creating a non-tenable scenario by having the editor be a different implementation that the front-end. Sooner than later we're going to need a way around this limitation and was hoping we'd get an informed perspective from @ellatrix.

In this direct implementation I assume the same browser compatibility matrix applies to the Stripe implementation? i.e. we're not showing Apple Pay as being visible on desktop Chrome?

danielmx-dev · 2025-02-18T18:45:39Z

In this direct implementation I assume the same browser compatibility matrix applies to the Stripe implementation? i.e. we're not showing Apple Pay as being visible on desktop Chrome?

This is correct.

ellatrix · 2025-02-19T00:26:16Z

It sounds like the last blocker here is the blob protocol. I've actually created a solution for that in Gutenberg, because it was also problematic for Playground. It's not my favourite solution because it would been the block editor becomes dependent on a server side call. See WordPress/gutenberg#55152.

I'm not sure if it's possible to initialise the script outside of the iframe and target an element within the iframe, while also adding the styles within the iframe. I don't know how the Stripe API works. But that could be an alternative solution.

FangedParakeet · 2025-02-21T23:03:04Z

@ellatrix, is there a reason why WordPress/gutenberg#55152 wasn't continued? That PR looks quite old: is there a way to build off of or continue the work that was commenced in that PR?

Currently, the perfect, optimal solution would be to reuse the Stripe element inside the FSE iframe, after resolving the issues with Gutenberg. However, to me at least since I have a lot less familiarity with Gutenberg, the pathway to get there still seems a little unclear. If we found a solution in Gutenberg to solve the blob/iframe kerfuffle, we would need to retest our integration to see if our Stripe component would then play nicely with it and, if not, we would regretfully be back where we started.

Are we able to perhaps size this effort on the Gutenberg side or is there any clear timeline to understand when this might be available to us?

I'm not sure if it's possible to initialise the script outside of the iframe and target an element within the iframe, while also adding the styles within the iframe.

I believe this might not be viable sadly, but I will defer to @danielmx-dev.

With regards to our available options, the provided solution in #10141 does appear to match the customisability and appearance presented by Stripe's own element. It may not be fully extensible, but considering the effort required to create the PR, I feel an effort to add other future express payment methods to this implementation would be sized similarly or smaller.

If we could more clearly understand the pathway to get to an optimal solution without the iframe friction, I think that would help us to understand the benefit of using #10141 as a stop-gap solution instead.

If this seems like a solution that is within our reach now, I would definitely support pausing the work on #10141 to focus on that much preferred option instead.

If the optimal solution seems like it might be a medium-term solution, available sometime in Q2 or early Q3 let's say, I think it makes sense to use #10141 as a stop-gap solution, since this short-term fix is already ready now and by the time we are at the point of being ready to integrate new EPMs that would make this implemented fix suffer, we would also be ready to replace #10141 with our optimal Stripe iframe iteration instead.

If the optimal solution seems like it might be a long-term solution, available sometime even later than that, then I also think that #10141 has value as a stop-gap solution, since no other solution appears to be available and until the point that there is one, we would simply be unable to show any preview of the EPM button within the cart template at all.

That's my assessment of our current predicament at my own level of understanding so far, but let me know if anyone has any wiser opinions or can answer any of the questions I posed with regards to resolving this scenario via Gutenberg. 🙏

ellatrix · 2025-02-26T07:37:33Z

Why was it not finished before? Because there was only one problem with it and I wanted to leave time to find other approaches or solutions. I would've rather seen a fix that made the blob protocol work. However, with additional issues, maybe it should be done.

All these Gutenberg things are currently on hold. That's not to say that a temporary hack on the WooCommerce side would not be possible, but that again increases the maintenance cost. I'm not sure what's the best thing to do here.

ellatrix · 2025-02-26T07:43:29Z

I've inquired whether it's something that could make the next WP release or not.

ellatrix · 2025-02-26T16:59:10Z

It can definitely not make the this WP release.

FangedParakeet · 2025-02-26T23:29:19Z

It can definitely not make the this WP release.

It sounds like sadly this solution will not be something that is within our grasp in the near-future. I believe, referring back to #10043 (comment) this sets us in either of the two following scenarios.

If the optimal solution seems like it might be a medium-term solution, available sometime in Q2 or early Q3 let's say, I think it makes sense to use #10141 as a stop-gap solution, since this short-term fix is already ready now and by the time we are at the point of being ready to integrate new EPMs that would make this implemented fix suffer, we would also be ready to replace #10141 with our optimal Stripe iframe iteration instead.

If the optimal solution seems like it might be a long-term solution, available sometime even later than that, then I also think that #10141 has value as a stop-gap solution, since no other solution appears to be available and until the point that there is one, we would simply be unable to show any preview of the EPM button within the cart template at all.

@pierorocca, are you still opposed to using #10141 as even a temporary solution until we are able to resolve this more holistically with Gutenberg support? The only other alternative is that we mark this issue blocked and leave the EPM preview vacant, until the Gutenberg solution has been integrated. 🙏

pierorocca · 2025-02-27T00:15:08Z

@pierorocca, are you still opposed to using #10141 as even a temporary solution until we are able to resolve this more holistically with Gutenberg support? The only other alternative is that we mark this issue blocked and leave the EPM preview vacant, until the Gutenberg solution has been integrated. 🙏

I don't think we have any choice at this moment except to fake it and deal with the consequences of the editor experience possibly not reflecting the live front-end experience. Thanks all for doing the due diligence on this and sharing info across functions. :)

ralucaStan added the type: bug The issue is a confirmed bug. label Dec 27, 2024

vbelolapotkov added the focus: checkout payments label Dec 30, 2024

danielmx-dev self-assigned this Jan 7, 2025

pierorocca added the priority: high The issue/PR is high priority—it affects lots of customers substantially, but not critically. label Jan 8, 2025

danielmx-dev mentioned this issue Jan 13, 2025

Show Express Checkout button previews in editor #10141

Merged

6 tasks

FangedParakeet added the needs demo PR should provide screenshot or gif of changes to be reviewed by product and design label Jan 23, 2025

FangedParakeet added this to the WooPayments 8.9.0 milestone Jan 28, 2025

danielmx-dev removed this from the WooPayments 8.9.0 milestone Feb 10, 2025

danielmx-dev mentioned this issue Feb 20, 2025

WooPayments card form fields are showing up in dark mode #10335

Closed

danielmx-dev closed this as completed in #10141 Feb 28, 2025

danielmx-dev mentioned this issue Feb 28, 2025

Spike: Render Stripe Iframes properly within the Site Editor #10474

Open

FangedParakeet added this to the WooPayments 9.1.0 milestone Mar 7, 2025

Everade mentioned this issue May 6, 2025

Apple-Pay Button Misaligned & Oversized on Key Pages #10750

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Express Payment button not visibile on the Cart template #10043

Express Payment button not visibile on the Cart template #10043

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Express Payment button not visibile on the Cart template #10043

Express Payment button not visibile on the Cart template #10043

Comments

Describe the bug

To Reproduce

Actual behavior

Screenshots

Expected behavior

Desktop (please complete the following information):

Smartphone (please complete the following information):

Additional context

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!