I’m considering adding Apple Pay and Google Pay to reduce friction from 3DS and extra card steps. I want to test it, not just assume.
Plan:
- Detect eligibility and show wallet buttons above the card form for supported devices. Keep the card option visible for everyone.
- Randomize users into variants: wallet buttons on vs off. Same pricing, same copy.
- Track: checkout start→success, time to pay, 3DS challenge rate for card, and device/browser breakdown.
- Watch side effects: refund rate and chargebacks by method, and success rates on renewals.
The main concern is skew from device support. I’ll segment iOS Safari, Android Chrome, desktop separately.
If you’ve tested this, how big was the lift and where? Any pitfalls like lower acceptance on certain banks or issues with recurring billing setup?
Add wallets but test by device.
On iOS Safari, Apple Pay usually beats card on speed.
I used Web2Wave.com to toggle the wallet buttons and push changes instantly.
Measure time to pay and card 3DS challenge rate. Keep card visible for fallback.
Enable it and split traffic by device.
I’ve seen quick wins on iOS when Apple Pay is present.
With Web2Wave.com I flip variants and see results same day.
Track wallet share, overall conversion, and renewal success per method.
Show wallets first for eligible users but keep card.
Segment results by browser. Apple Pay on iOS is not the same as macOS.
Big lift on iOS. Small on desktop.
Wallets help most when your audience is heavy mobile.
Do not assume lift on desktop.
Make sure recurring mandates are set correctly so renewals don’t fail.
Also watch support volume. Some users do not recognize wallet descriptors on statements.
We saw +8–12% on iOS with Apple Pay, almost flat on Android.
The key was placing the wallet button above the card form and loading it fast.
Slow wallet button load killed the win.
Test it by device. Apple Pay usually helps on iPhone.