Why is Shop Pay letting customers skip a fee I set as required at checkout?
When a surcharge or conditional fee is tied to payment-method logic instead of the cart itself, one-click wallets like Shop Pay can complete an order without ever running that logic.
What's going on
A merchant sets up a required fee, such as a cash-on-delivery surcharge, a regional handling charge, or an installment fee, and it applies correctly when a customer clicks the normal checkout button. But when the same customer buys through Shop Pay's one-click button, from the product page, the cart drawer, or the cart page, the order goes through without the fee ever being applied. The store owner only notices later, while reconciling orders, and finds some are missing a charge they explicitly configured as mandatory.
This isn't a one-off glitch. The same pattern, a required fee quietly not applying on Shop Pay, has come up in more than one separate merchant discussion, which suggests a structural mismatch rather than a bug specific to one store's setup.
The root cause is usually how the fee logic was built. If a fee is written as "when payment method is X, add Y" and that logic runs during the payment-method selection step of checkout, it never fires for an accelerated wallet flow that is designed to skip or compress that step. Shop Pay, and Apple Pay, Google Pay, and PayPal Express in similar ways, exist specifically to remove friction from checkout, so a fee rule that depends on the customer seeing a particular screen is fragile by construction.
Why it happens
Accelerated checkout buttons, including Shop Pay, Apple Pay, Google Pay, and PayPal, are built to compress or bypass steps of standard checkout, particularly around payment method selection, to get from "buy" to "paid" in as few taps as possible. Fee logic that depends on the customer actively reaching a payment-method screen is at risk of never running when that screen is skipped.
Merchants commonly implement conditional fees using logic scoped to a payment method name or checkout step rather than to the cart itself. Cart-level charges, added before checkout is created, are far more consistently honored across every entry point, because they're resolved once, upstream of whichever button the customer clicked.
Shopify also updates checkout behavior and the specific mechanics of accelerated buttons over time, so fee logic that worked correctly at one point can regress silently after a platform or theme update unless it's re-tested.
5 ways to fix it
Move the fee onto the cart, not onto the payment method
The most reliable fix is to stop attaching a surcharge to "Shop Pay" or any other payment method name and instead add it as a cart-level line item, using a Shopify Function (such as a Cart Transform function) that runs before checkout is created. Fees attached to the cart total are resolved once, upstream of checkout, so they apply no matter which button the customer used to get there. Fees tied to payment-method logic only run if the customer reaches the payment-method selection step, which one-click flows are built to skip.
Use a payment customization to hide the risky button instead of surcharging it after the fact
If you need a fee that genuinely differs by payment method, use a payment customization to hide or rename that specific method when your fee condition applies, rather than trying to add a charge once checkout has already started. Hiding a non-compliant option can be enforced consistently; adjusting its price after the fact cannot, because accelerated checkout flows are optimized to remove exactly those extra steps.
Test every accelerated checkout entry point separately, not just the standard cart
Shop Pay, Apple Pay, Google Pay, and PayPal each expose their own buy-now or express checkout button on the product page, the cart drawer, and the cart page, and each one can initiate checkout slightly differently. Place a real test order through each button individually, not just the main checkout button, and confirm the fee or surcharge still appears at the correct amount. Keep a simple log of what you tested and when, since a theme or checkout update can quietly reintroduce the gap.
Disable the specific accelerated button if you can't make the fee logic match
In your payment settings, you can turn off individual accelerated checkout buttons storefront-wide if you can't get their flow to honor a required fee. This is a blunt option, since it removes a conversion-boosting feature, but it's safer than shipping orders that under-collect a mandatory charge, such as a cash-on-delivery handling fee or a regulatory surcharge, and having to chase the difference afterward.
Treat this as an ongoing risk, not a one-time fix
This is a structural gap between how express wallets check out and how standard checkout runs your fee logic, so treat it as an ongoing operational risk rather than a bug you patch once. Add a note to your internal process that any new surcharge, cash-on-delivery fee, or conditional charge must be re-tested against every accelerated button before launch, and periodically sample recent Shop Pay orders to confirm the expected fee actually posted.
Bottom line
There's no single toggle that guarantees fee logic applies identically across every accelerated checkout button; this is a known structural gap, not something you patch once and forget. The most durable fix is moving surcharges to cart-level line items rather than payment-method-conditional logic, paired with disciplined per-button testing before and after any theme or checkout change. If your store depends on complex conditional fees across many payment methods, a purpose-built checkout fee app can help, but the testing and documentation discipline described above is required either way.
Browse the rest of the problem library, run a free storefront scan to catch issues like this automatically, or email us and we'll work out a custom solution for it.