Did Apple Pay create new orders?

01The question

Did launching Apple Pay as an express option — on product pages and at the top of checkout — create net-new orders, or just shift shoppers who would have paid by card anyway?

Apple Pay wasn't new; it had been an available tender for some time. What changed in October was placement. North America got mobile web product pages first, with checkout following two weeks later. Europe and the UK launched both together, after a payments routing migration that had a brief rollback.

02Why it was harder than it looked

The obvious analysis is a trap. Apple Pay volume rose after launch, and so did its share of orders — but every shopper who would have paid by card anyway and tapped the new button inflates both while adding zero incremental orders. Volume is not incrementality. I named that risk before a single query was written, because it dictates what the design has to rule out.

The harder problem came earlier, and wasn't analytical. This competed for the same engineering capacity as everything else, and "add an express button for a tender we already support" is easy to push down the list. Getting it prioritized was the real lift.

My case was about friction, not novelty. Among customers who reached the payment step, Apple Pay attempts were more likely to succeed than card attempts — plausibly because a wallet keeps credentials current, though that's my hypothesis, not something I measured. The flow was also familiar and short. That argument won the project — which is partly why I wanted a real incrementality read afterward: to test whether it was true.

One more wrinkle: One-Page Checkout launched on web the same day as Apple Pay at checkout, tangling two launches together.

03Approach

1. Clean windows. Two weeks before any launch against two weeks after both were live, excluding the ramp and the routing rollback.
2. Seasonality control. Each period compared against the same calendar dates the prior year.
3. Difference-in-differences. Surfaces that could show Apple Pay (iPhone browsers, desktop Safari) against surfaces that couldn't (desktop Chrome, Edge, Firefox, Android) as the counterfactual.
4. Isolating the confound. A separate team A/B test had already shown One-Page Checkout didn't meaningfully move conversion. I also caught that it had shipped on desktop — which is what made desktop Safari a clean Apple Pay-only read.
5. Triangulation. Orders by payment type, payment-step attempts and success, and session conversion. Where they disagreed, I documented it rather than picking the flattering one.

I ran the analysis with an AI assistant connected to our data warehouse, using shared analyst skills for querying. I set the direction, challenged the assumptions behind each cut, and corrected a wrong assumption it made about the launch scope. The tooling made iteration fast; the design decisions and the scepticism were the part that mattered.

04What we found

All figures are estimates from the first two weeks.

• Apple Pay's share of web orders rose from ~20% to ~25% in North America, and ~22% to ~34% in Europe
• About half that growth looked net-new; the rest was shoppers switching from card
• Desktop Safari gained ~3.5% in purchases relative to control — the cleanest single read
• Mobile web gained ~6.9% relative to control
• Estimated net-new orders came to ~3% of web orders

Then the part that corrected my own pitch. After launch, Apple Pay's payment success rate was no longer higher than cards. The advantage I had argued from didn't hold once the feature was live at scale. So the gain wasn't Apple Pay converting better at payment — it was more shoppers reaching payment at all. The placement worked by removing steps earlier in the funnel. That's a different mechanism, and it changes where the next bet should go.

I also flagged an operational issue the analysis surfaced incidentally: in Europe, Apple Pay payment success dropped and retries rose after launch. I raised it to investigate with the payment processor rather than treating it as noise.

05What I'd do differently, and what's next

Two weeks isn't enough data, and the window included a sale event. The mobile estimate rests mainly on one control group; a second, much smaller control pointed the other way, which I reported rather than dropped. Some of the web gain may be shoppers moving over from the iOS app, so the honest framing is incremental web orders.

• A placebo test on pre-launch weeks, to confirm the groups normally move together — the assumption the design rests on
• A daily-level model with confidence intervals
• Extending the window to four to six weeks, past the sale event
• The in-app Apple Pay A/B test already running, as the cleanest causal read available

06Skills demonstrated

• Stakeholder influence — won prioritization against competing roadmap work
• Quasi-experimental design — difference-in-differences where no A/B test existed
• Confound identification — and the cut that turned one into an advantage
• Triangulation — three sources, disagreements documented
• Calibrated reporting — including the finding that undercut my own argument
• AI-assisted analysis — tooling directed, judgment kept human