No express pay is a choice to lose the sale

No express pay? You are giving the customer another reason to buy somewhere else.

I have been making some version of that argument for years, especially about Apple Pay for eligible shoppers in the U.S. It comes from a fairly simple buying preference: if I can get the same thing without typing my life into a phone, that store has my attention.

The headline is a judgment about avoidable friction, not a claim that every missing wallet button loses a sale. Your customers, market, devices, products, and payment options determine what matters. I do not have a universal conversion uplift to attach to it.

I do have very little patience for a checkout that makes buying harder than it needs to be.

What does express checkout actually remove?

Express checkout can reuse payment credentials and contact information the customer already has available through a wallet or accelerated checkout service. It can reduce the typing and repeated decisions required to complete a purchase.

It does not remove the merchant’s obligations. The basket still needs the right variants, prices, promotions, delivery options, tax, and final amount. The payment and order systems still need to agree about the transaction.

Apple’s Apple Pay planning guidance describes an encrypted payment token and the contact information available through the payment sheet. It recommends using that information instead of asking the customer to type it again, and offering account registration after purchase.

One distinction matters here: payment authentication is not the same as authentication to the customer’s store account. Receiving a wallet email address does not establish permission to open an existing account, view its order history, or redeem its private benefits. Account linking needs its own verified flow.

Fewer fields should not mean weaker authorization.

One button can expose an entire checkout dependency chain

A wallet button can be correctly rendered while the purchase behind it is still awkward or broken.

Suppose shipping eligibility is only calculated after a particular address form runs. The accelerated path skips that form. Now the wallet has a delivery address, but the commerce flow has not performed the work that makes its shipping choices valid.

Or a promotion changes the basket after the payment amount has been prepared. Or the stock check happens so late that the shopper authorizes payment for something the order flow cannot accept.

Those are illustrative failure cases, not claims about a particular platform. They are also why I want checkout state and business rules exposed through reusable services instead of hidden in page transitions.

The button is easy to point at. The dependencies are the work.

A successful payment response is not the whole order

A reliable express checkout needs a deliberate relationship between basket validation, payment authorization, order creation, and capture. The exact sequence depends on the platform, provider, and business.

What matters is knowing what state the system reached when something fails.

If authorization succeeds but order creation fails, who reconciles that authorization? If the customer closes the page after submitting, how do they discover whether an order exists? If they retry, what prevents duplicate payment or duplicate orders?

Use idempotency at the operations that need it, retain references that let support reconcile the transaction, and define the recovery behavior. The customer should not have to diagnose a disagreement between the payment provider and the commerce platform.

This is why the OMS belongs in the customer-experience conversation. A fast payment sheet is not much comfort when nobody can find the order.

Test the journey, including the way out

I would use an approved test environment with wallet test credentials and a supported-device matrix. No surprise live charges in the name of an audit.

Start from a product link on a phone, not a logged-in employee session on a laptop:

1. Select a real variant and quantity. Check wallet visibility and eligibility on the devices and browsers you support.
2. Change the delivery address or shipping option. Confirm that the basket and payment sheet converge on the same final amount.
3. Apply a promotion. Check exclusions, threshold changes, and anything that changes shipping eligibility.
4. Cancel out of the wallet, then return. The cart should remain usable, and the normal checkout should still work.
5. Exercise a declined payment, an interrupted response, and a retry. Confirm the actual payment and order state, including duplicate prevention.
6. Complete a sandbox purchase. Check confirmation, order lookup, fulfillment handoff, and the support path.

That last part matters. Test the purchase the company has to operate, not just the interaction the design team can screenshot.

Measure eligible shoppers, not just button clicks

For measurement, distinguish customers who could use the wallet from customers whose device, market, or payment setup made it unavailable. Then follow exposure, initiation, authorization, order completion, and failure reasons.

Keep the conventional checkout in the comparison. A wallet can be useful without being the right route for every order. Guest checkout still needs to work. So do payment methods your customers actually prefer.

Watch support contacts and duplicate transactions alongside conversion. A faster path that creates cleanup work elsewhere is worth understanding before calling it a win. Integration debt becomes operating debt very quickly in payments.

Make the total trustworthy. Make the order recoverable. Stop asking people to retype information you can already use safely.

Then put the button somewhere they can find it.