Apple Pay checkout screen: what buyers see

Your store controls the button and the amount it sends to the wallet. Everything after the tap belongs to the device. The sheet opens over Safari with the total and the card the buyer picked, and your page cannot restyle it or see the card. A buyer on Safari with a card in Wallet sees the sheet. A buyer on another browser may see no button, and both can be right for their device. An owner who tests from one laptop sees only one of those screens, and the gap shows up as fewer Apple Pay orders from one kind of phone, not as an error.

• Load the cart and product pages in Safari, then in one other browser, and note where the button shows.
• Compare the total inside the sheet with the cart total, including shipping and tax.
• Check the item and size in the sheet match the variant the shopper chose.
• Note which phones show the button; a missing button is a device fact before it is a bug.
• Open a finished order in your admin and confirm it shows Apple Pay as the payment method.

The Apple Pay button is offered by the browser, not by your theme. In practice that means Safari on a device with a card set up in Wallet. A buyer on Chrome for Windows, or on an Android phone, may not get that button, and the checkout they see may have card fields or other wallet options instead. None of that is a bug in your product. It is how the buyer's device is set up, which is why a test from your own laptop can miss the problem entirely.

The useful check separates two questions. First, does the button appear for this device at all? Second, when it appears, does the sheet carry the total and the items the cart had? The first depends on the device and browser, and you cannot fix it on the page. The second depends on your cart and payment setup, and that part is yours to fix. Owners who mix the two often rebuild a checkout that was only missing a button for some visitors.

Once the buyer taps Apple Pay, the sheet is a system screen. It shows the total your page sent, the address the buyer chooses and the card they pick. Your page never sees that card and cannot change how the sheet looks. That is also why a simulated visitor cannot take you past the sheet: it needs a real card in a real wallet, and a simulated visitor has neither.

So split the work. Mimiq shows you which visitors saw the button, the cart total at each step and where each visitor stopped. You then check the sheet yourself on an iPhone with a card in Wallet. The final confirmation screen needs an order, so if your payment setup has a test mode, use it. If it does not, place a small order, refund it, and write down the amount on both screens.

The mismatch buyers catch first is the total. Shipping, tax and discounts are often added at a later step, so the sheet can show a number the cart did not show when the buyer tapped. A buyer who sees a higher number inside a system window reads it as a trap and backs out. Before you trust the sheet, test a cart with a discount code, a cart with two items and a cart that needs a shipping rule to price correctly. Open the finished order in your admin and read the line items, not only the summary total, because the summary can match while the items do not.

Apple Pay placement often lives in a theme or a payment app, so an update can hide the button on the cart or push it below the fold. Rerun the same simulated visitors on the cart page after each theme or app change, then check the Safari sheet again on your own phone.