Hey folks,
When a buyer uses Apple Pay or Google Pay from the product page or cart page, the validation function is triggered at the checkout completion step and surfaces our validation error - but the error makes no sense in this context, as it instructs the buyer to fill in information they have no way to fill in at that point.
This is in contrast to initiating Apple Pay or Google Pay from within checkout, where the payment fails gracefully - the dialog closes and the buyer lands in Shopify checkout where they can resolve the validation and continue.
Expected behavior: When Apple Pay or Google Pay is initiated from the product or cart page, the buyer should be redirected to checkout rather than shown a validation error they cannot act on.
Is this a known issue?
Hi @Patrick_Jakubik
Thanks for describing this - the expected behavior (redirect to checkout on validation failure) is essentially what the recovery flow does, but only for Apple Pay on one-page checkout. The same experience is currently not supported on accelerated checkout from product/cart pages (and Google Pay). To help us evaluate allocating resources to build for this, how important is this for your app? What usecases will this support?
This affects merchants using pickup point delivery - a core use case for our app. Our validation prevents orders from being placed when no pickup point has been selected, and since pickup point carriers are often the cheapest option, they frequently get pre-selected. So this issue ends up blocking express checkout for a meaningful share of sessions, not just edge cases.
We don’t have a way to estimate exact scale, but the current workaround - disabling Apple Pay/Google Pay on product and cart pages - is a real conversion hit for merchants. A platform-level fix would be much preferable.
Hi,
We as a merchant experienced the issue firsthand. Our orders have free home delivery from 200€. Below this amount, pickup delivery is the cheapest so it makes our express checkout fail when used from the cart drawer.
Right now our only options are to either hide the accelerated checkout completely, or conditionally display it when the cart amount is equal or superior to 200€. Both are far from ideal.
I believe the error message and behavior to be confusing enough to prevent customers from checking out at all if Apple Pay/Paypal is their preferred payment method (that’s actually how we got the error reported in the first place, from a customer thinking Apple Pay was not available at all). It would be best to be redirected to the checkout first, where a unified error handling would take place ; the current behavior when clicking an accelerated payment button directly in the checkout is satisfying.
Hi,
We’re also facing the same issue with cart_checkout_validation (2025-04 API), and wanted to share a full use case for clarity.
Use case:
A validation rule is set (e.g., minimum 12 quantity required for a specific product).
If the condition is not met:
-
A validation message is returned
-
The message is displayed on checkout
-
Checkout should be blocked
Expected behavior:
Actual behavior:
-
The validation message is correctly displayed on checkout
-
Checkout is blocked when using native payment methods
-
However, with express checkout options:
-
Apple Pay
-
Shop Pay
-
PayPal
→ The message is visible on checkout, but customers are still able to complete the payment
Key issue:
The validation is triggered and the message is shown on checkout, but it is not enforced in express checkout flows, allowing users to bypass the rule.
Additional context:
We’re also attaching a screenshot showing Apple Pay visible and usable even when the validation message is already displayed on checkout.
Just wanted to check:
Is there any fix already available for this?
Or is a fix planned in upcoming releases?
This impacts core use cases like minimum order quantity and other checkout enforcement rules.
Thanks!
Hi @Liam-Shopify, just wanted to follow up on this - we’re starting to see more merchants affected by this issue lately, so I wanted to check in and see if there’s any update.