I lose most carts not on the product page, but on the very last screen - paying on a phone. The customer already wants to pay, has a card sitting in their Apple or Google wallet, and the store asks them to retype 16 digits off a piece of plastic, plus the expiry date and the CVV, with a thumb, on a small screen, usually in a hurry. That is the moment a lot of people simply give up.
Apple Pay and Google Pay solve exactly that problem. Instead of a form, the customer sees one button, touches the fingerprint reader or looks at the phone, and the payment is done. The card details already live on the phone; the store never sees them and never stores them. In Poland, BLIK does the same job - the customer types a six-digit code from their banking app instead of a full card number. Three different mechanisms, one goal: cut checkout down to the bare minimum.
In this post I explain why one-tap payments genuinely save mobile carts, how to enable them through a payment gateway and what to watch out for during setup - without hiding behind jargon. I measure where a store loses people first, then add exactly the thing that is clogging the funnel.
Why one-tap payment saves mobile carts
More than half the traffic in most stores I look at comes from phones. And the phone is exactly where checkout hurts most. Every extra form field is another reason to change your mind - and retyping a card number on a 6-inch screen is one of the most annoying moments in the whole purchase.
Apple Pay, Google Pay and BLIK turn that into a single action. The customer types neither address details nor a card number, because the gateway pulls them ready-made from the wallet on the phone. Fewer fields means fewer typos, fewer declined payments and fewer people who close the tab the second they see a long form. It is not magic - it is simply removing friction from the most important screen in the store.
There is a trust effect too. The “Buy with Apple Pay” button looks familiar and safe - the customer knows they are not handing a card number to a stranger, they are authorising a payment the same way they do in a hundred other places. For a new, unknown store that can be the difference between “I’ll try it” and “I’ll skip it”.
What helps: before you implement anything, check your analytics to see how many people reach checkout and drop off there - separately for phone and desktop. If mobile falls apart at the payment step, that is the first thing to fix, not another banner on the homepage.
How to implement it - through a gateway, not by hand
Good news: you are not coding this from scratch and you are not integrating directly with Apple or Google. Apple Pay and Google Pay in WooCommerce are switched on through a payment gateway that already handles cards - the gateway supplies the button as an extra method.
In practice it goes like this: you pick a gateway that supports these methods (there are several popular ones - Stripe, for example, and Polish operators such as Przelewy24 or PayU add BLIK and local bank transfers on top), you install its official WooCommerce plugin, and in the gateway dashboard you enable Apple Pay and Google Pay. The exact steps and screen names differ between operators, so I stick to the general principle here and you take the details from your gateway’s documentation - not from guesswork.
A few things worth thinking through when choosing a gateway:
- BLIK - if you sell in Poland, this often matters more than Apple or Google Pay; Polish operators support it, foreign ones not always.
- Express payment on the product page and in the cart - good plugins can show the Apple/Google Pay button right on the product page, not only on the final screen.
- Fees and payout schedule - compare the real per-transaction cost and how often money lands in your account, because it affects cash flow.
- Support in your language and proper invoices - when a payment breaks, you want to sort it out fast.
What helps: do not stack gateways. One well-chosen gateway that handles cards, Apple Pay, Google Pay and BLIK at once is simpler to maintain and less confusing for the customer than three separate methods from three providers.
Technical requirements - HTTPS and domain verification
There are two hard requirements here, and nothing works without them, so it pays to know them before you start.
First - HTTPS across the whole site. Apple Pay and Google Pay only work on a site with a valid SSL certificate. If your store still has mixed content anywhere (some assets loaded over http), the button may simply not appear. In practice every serious store should already be fully on HTTPS - it is a trust and SEO requirement anyway.
Second - domain verification for Apple Pay. Apple requires proof that the domain is yours. Usually this comes down to placing a special verification file under the .well-known path on the server - most gateway plugins do it automatically at the click of a button, but sometimes you have to upload the file by hand. Without that verification the Apple Pay button will not show up, even though cards keep working normally. Google Pay is more relaxed here and usually needs no separate domain verification.
And one thing that is easy to forget: you will only see the Apple Pay button on Apple devices in Safari (iPhone, iPad, Mac), and Google Pay in Chrome with a Google account signed in. If you are testing on Android in Chrome and do not see Apple Pay - that is normal, not a bug. Which is why you test on real devices, not just on your own laptop.
What to watch out for during setup
Turning the method on is not the end - a few things can quietly hurt conversion even though everything “technically works”.
- Test on a real phone. One-tap payments have to be checked on a real iPhone and a real Android, ideally by buying something cheap through the live gateway in test mode. A simulator will not catch everything.
- Cache must not eat the checkout. Cart and checkout pages in WooCommerce should never be cached. A badly configured cache can show the customer a stale cart or block the payment button - the same problem I describe in the piece on carts abandoned for purely technical reasons.
- Button visibility. Express payment makes the most sense high up - on the product page and at the top of the cart, not tucked away under a fold at the very bottom of checkout. If the customer has to scroll to find it, half the benefit is gone.
- Consistency with the rest of the store. If the store is generally slow, an Apple Pay button alone will not save conversion - the customer drops off earlier. Speed and payments are one organism.
- Invoices and order data. With wallet payments some data arrives from the phone - check that the order actually carries what you need for invoicing (especially for B2B sales and VAT numbers).
What helps: treat the rollout as a change to your sales funnel, not as a plugin install. Switch it on, test on real devices, and after two weeks check in analytics whether mobile checkout abandonment actually dropped. If it did not - keep looking, because the problem sits elsewhere.
When it really pays off
One-tap payments deliver the most where a lot of traffic comes from phones and where the purchase is impulsive or repeated - fashion, cosmetics, supplements, small electronics, food. The lower the price and the faster the customer wants it done and dusted, the harder a shortened checkout works.
It makes less difference in stores where the purchase is rare, expensive and considered - there the customer will sit down to it calmly anyway, often on a desktop. But even then it is worth having these methods enabled, because they cost nothing beyond the transaction fee you would pay for a card regardless.
Put simply: if your WooCommerce store sells to phones, missing Apple Pay, Google Pay and BLIK is a hole that drops part of your carts every single day. And it is one of the cheapest things in the whole store to fix.
Summary
Apple Pay, Google Pay and BLIK turn the hardest screen in a store - paying on a phone - from a form into a single touch. You enable them through a payment gateway, not by hand; you need HTTPS across the whole site and domain verification for Apple Pay, then a test on real devices. This is not cosmetics, it is unblocking the funnel exactly where the money leaks.
If you do not know how many carts you lose at payment, or whether these methods work correctly on your store - send me a link. I will do a free review, check the checkout on mobile and tell you exactly what is worth adding or fixing so that the last screen stops scaring customers away.
Frequently asked questions
Do I have to sign a separate contract with Apple or Google? No. You enable Apple Pay and Google Pay through the payment gateway you already have a card-processing contract with. The gateway is the middleman - you switch the method on in its dashboard, and the formalities on the Apple and Google side are handled by them.
Is BLIK the same thing as Apple Pay and Google Pay? No, it is a different mechanism. With BLIK the customer types a six-digit code from their banking app; with Apple Pay and Google Pay they confirm with a fingerprint or face, because the card already lives on the phone. The effect for the store is the same - a shorter checkout - but BLIK is mostly supported by Polish operators, so if you sell in Poland it pays to pick a gateway that has all three at once.
Why can I not see the Apple Pay button in my store? Usually one of three reasons: you are testing on something other than an Apple device in Safari, the store does not have full HTTPS across all assets, or the domain verification Apple requires has not gone through. Cards keep working normally in that case, only the button is missing - which is why you check this on a real iPhone, not on a laptop.
How much does enabling one-tap payments cost? Payment providers usually do not charge a separate subscription for the method itself - they make money on the transaction fee you pay for the card anyway. So the real cost is the setup and testing work, not a new fixed fee. If you want to know whether it works correctly on your store, send me a link - the checkout review is free.
Running a store where something does not work the way it should? I build and rebuild WooCommerce stores - from a single fix to reworking the whole sales flow. Tell me what you are dealing with and I will send back a scope and a price.