Express checkout wallets let a shopper pay in one tap using credentials already on their device, skipping the address and card forms. On Magento and Adobe Commerce with Hyvä, the practical set is Apple Pay, Google Pay, PayPal, and Amazon Pay, surfaced on the product page, cart, mini cart, or checkout through your payment provider. Shop Pay is Shopify’s own wallet and is not natively available on Magento, which surprises merchants who see it everywhere.
Wallets matter because they attack the two biggest sources of checkout abandonment at once: forced form filling and low trust in entering card details. But the same buttons can quietly drag down Core Web Vitals if their SDKs load carelessly, which undercuts the speed a Hyvä store was built for. This guide covers which wallets you can actually offer, where the buttons belong, how each provider surfaces them on Hyvä, the Shop Pay question, and how to keep the wallet scripts from sabotaging performance.
Why express wallets convert
A standard guest checkout asks for an email, a shipping address, a billing address, and card details. Every field is a chance to abandon, especially on mobile where typing is slow. An express wallet collapses all of it: the shopper taps Apple Pay or Google Pay, authenticates with a fingerprint or face scan, and the address and payment details flow in from the device. Trust rises too, because the buyer is using a stored credential from Apple, Google, PayPal, or Amazon rather than keying a card into a store they may not know.
The lift is largest for two groups: mobile shoppers and first-time buyers with no stored account on your store. Placing the button early, on the product page or in the mini cart, lets a high-intent shopper buy without ever seeing the full checkout. That is why express wallets belong in a broader conversion program alongside the fundamentals in our Magento checkout optimization playbook.
Which wallets you can offer, and where the buttons go
Wallet availability is set by your payment service provider, not by Magento itself. Here is how the common providers surface express wallets on a Magento or Adobe Commerce store.
| Provider | Apple Pay | Google Pay | PayPal | Amazon Pay | Typical button placements |
|---|---|---|---|---|---|
| Adyen | Yes | Yes | Yes | Via config | Product page, mini cart, cart, checkout |
| Stripe (Express Checkout Element) | Yes | Yes | Yes | Yes | Product page, cart, checkout |
| PayPal / Braintree | Via wallet | Via wallet | Yes | No | Cart, checkout, product page |
| Authorize.net | Yes | Yes | No | No | Payment step |
The strongest placements are the ones that shorten the path to purchase:
- Product page. For single-item, high-intent purchases, an express button here removes the cart step entirely.
- Mini cart. Captures the shopper the moment they add to cart, before second thoughts.
- Cart page. The classic express position, above or beside the standard checkout button.
- Checkout. Still valuable as a faster alternative to the form, even when the shopper has reached checkout.
Adyen’s express implementation is a good reference for full coverage, offering Apple Pay and Google Pay express buttons on the product page, mini cart, and cart. Adyen also publishes a Hyvä example integration on GitHub showing how its methods run against a Hyvä frontend.
The Shop Pay question, answered honestly
Merchants ask for Shop Pay constantly, because it is one of the fastest and most recognized wallets. The honest answer is that Shop Pay is Shopify’s proprietary accelerated checkout, tied to the Shopify network, and it is not available as a general wallet on a self-hosted Magento or Adobe Commerce store. If Shop Pay is a hard requirement, that is a platform decision, and it is one of the genuine trade-offs to weigh when comparing Adobe Commerce with Shopify or other platforms such as BigCommerce and Shopware. On Magento, the equivalent one-tap experience comes from Apple Pay, Google Pay, PayPal, and Amazon Pay, which together cover the overwhelming majority of US device wallets. For most merchants that combination delivers the same conversion benefit shoppers associate with Shop Pay, without leaving the platform.
How wallets work on a Hyvä storefront
Hyvä changes the frontend, not the payment rails, so wallet support depends on your PSP having a Hyvä-compatible module. The good news is that the major providers do: Hyvä Checkout is supported by PayPal, Stripe, Adyen, Braintree, Mollie, and others, and community or vendor modules extend the list further. Two integration realities shape a Hyvä build:
- Default Hyvä theme checkout versus Hyvä Checkout. The wallet button rendering differs between the standard Luma-replacement checkout and the dedicated Hyvä Checkout product. Confirm which one your store runs and that your PSP module targets it. If you are still choosing, our Hyvä Checkout rollout guide covers the compatibility gates in depth.
- Alpine.js and event timing. Hyvä’s inline Alpine.js model means wallet buttons and their callbacks must be wired to the theme’s events rather than to legacy RequireJS modules. A wallet button that works on Luma can need adaptation on Hyvä, which is the same compatibility work any interactive third-party feature requires.
Stripe’s current approach is worth calling out because it simplifies multi-wallet support. Its Express Checkout Element renders Apple Pay, Google Pay, PayPal, Amazon Pay, and Link from a single component, automatically showing only the wallets a given browser and device support and sorting them by relevance. It is Stripe’s recommended replacement for the older, now deprecated Payment Request Button, so a new build should start there rather than on the legacy element.
Setup gates that trip merchants up
Wallets are not a simple on switch. Each has requirements that block the button from appearing if missed:
- Domain verification. Apple Pay requires you to verify every domain that shows the button, and Stripe and other PSPs require domain registration in both test and live environments. A missing verification file is the single most common reason an Apple Pay button silently fails to render.
- HTTPS everywhere. Wallets only work on secure origins, which any production store already satisfies, but staging and preview environments often do not, causing confusing test failures.
- Device and browser gating. Apple Pay shows on Safari and Apple devices; Google Pay shows where Google Pay is set up. A button not appearing in your test browser is usually correct behavior, not a bug. Detect availability programmatically rather than assuming a button will always show.
- Currency and country support. Buttons appear only for supported currencies and merchant countries, which matters for cross-border stores.
Budget time for these in any wallet project. They are quick individually but cause outsized confusion when a stakeholder cannot see a button that is working exactly as designed on a different device.
The performance trap: keeping wallet SDKs off the critical path
Here is the part most wallet tutorials ignore, and the part that matters most on Hyvä. Wallet buttons are powered by third-party JavaScript, and if those SDKs load eagerly on every page, they add render-blocking script, extra network requests, and main-thread work to pages that may never reach checkout. That directly threatens the Interaction to Next Paint and Largest Contentful Paint scores a Hyvä store works hard to protect.
The discipline is straightforward:
- Load wallet SDKs only where the button appears. A product-page express button should not pull a payment SDK onto the blog or the home page.
- Defer and lazy-load. Initialize the wallet script on interaction or when the button scrolls into view, not during initial page load, so it never competes with your LCP element.
- Reserve layout space. Give the button a fixed slot so it does not shift content when it renders, protecting Cumulative Layout Shift.
- Measure the real cost. Check the wallet’s effect on field data, applying the same INP discipline covered in reducing Magento INP with Alpine.js patterns.
A wallet that adds a tap-to-pay button but costs you 200 milliseconds of INP on every product view is a bad trade. Done correctly, the button loads lightly and only where it earns its place.
Wallets versus buy now, pay later
Express wallets and buy now, pay later solve different problems and often ship together. Wallets speed up payment for people ready to buy; BNPL changes the affordability calculation for higher-ticket carts. Many PSPs surface both through the same integration layer, so it is common to evaluate them in one project. If installments are on your roadmap, pair this guide with our write-up on buy now, pay later on Magento and Hyvä, which covers the same performance caution for provider scripts.
For a full comparison of the underlying gateways that power all of this, including fees and 3DS handling, see our breakdown of Magento payment gateways on Hyvä. This article is about the express buttons; that one is about the rails beneath them.
FAQ
Can I get Shop Pay on Magento or Adobe Commerce?
No. Shop Pay is Shopify’s proprietary accelerated checkout and is not available as a wallet on a self-hosted Magento or Adobe Commerce store. The equivalent one-tap experience comes from Apple Pay, Google Pay, PayPal, and Amazon Pay, which cover the vast majority of US device wallets.
Where should I place express checkout buttons?
Place them as early in the journey as makes sense: the product page for single-item high-intent buys, the mini cart to capture the add-to-cart moment, and the cart page as the classic express position. Keeping a button at checkout is still useful as a faster alternative to the form.
Do express wallets work on a Hyvä theme?
Yes, provided your payment provider ships a Hyvä-compatible module, which the major PSPs do. Confirm whether your store uses the default theme checkout or the dedicated Hyvä Checkout, because wallet rendering differs between them and your PSP module must target the right one.
Why is my Apple Pay button not showing up?
Usually one of three reasons: the domain is not verified with Apple and your PSP, the browser or device does not support Apple Pay, or the store currency or country is unsupported. A button correctly hidden on an unsupported device is expected behavior, so test on Safari and an Apple device.
Will adding wallet buttons slow down my store?
It can, if the wallet SDKs load on every page. Load them only where the button appears, defer or lazy-load the scripts, and reserve layout space to protect Cumulative Layout Shift. Measured against field data, a well-integrated wallet adds negligible cost while lifting conversion.
Should I use Stripe’s Express Checkout Element or the Payment Request Button?
The Express Checkout Element, on a new build. It renders Apple Pay, Google Pay, PayPal, Amazon Pay, and Link from one component and is Stripe’s recommended replacement for the deprecated Payment Request Button, which should not be used for new integrations.
Express wallets are among the highest-return checkout changes a store can make, but only when the buttons are placed where intent is high and the scripts are loaded without harming performance. That balance, conversion up and Core Web Vitals held, is exactly the kind of work a performance-first agency does. Bemeir builds and optimizes Magento and Adobe Commerce stores on Hyvä, integrates wallets through a deep payments and technology partner network, and is the USA’s first Hyvä Gold Partner. Learn more about Bemeir or reach the team from our home page.
