RevenueCat’s Express Checkout puts Apple Pay and Google Pay buttons directly on web paywalls and funnels, letting a user complete a purchase without typing card details or leaving the page. It’s a genuine friction reducer — one-tap payment methods routinely convert better than a manual card form — but it also creates a second, structurally different purchase path sitting next to the existing one. A paywall that used to have one conversion funnel now has two, and any revenue dashboard that still treats “purchase completed” as a single undifferentiated event will blend two behaviourally distinct populations into one misleading average.
That matters because express checkout users and traditional-checkout users don’t behave the same way going in or coming out. A one-tap payer skips form fields that used to double as a light commitment signal, and a wallet-based purchase can complete in seconds rather than the minute or more a manual card entry takes. If a team optimises paywall copy or pricing based on aggregate conversion rate without splitting by payment path, they’re tuning for a mix of two different funnels and can easily draw the wrong conclusion about what actually moved the number.
Data Points to Track
- Payment method selected, tagged on every purchase-initiated and purchase-completed event as
apple_pay,google_pay, orcard, so conversion rate, refund rate, and LTV can all be split by path - Time-to-purchase from paywall view, measured separately for express checkout versus manual card entry, to quantify how much of any conversion lift is coming from reduced friction versus other paywall changes
- Express checkout button visibility versus click-through, since wallet availability depends on device and browser support — track whether the button was even shown before comparing conversion rates across users
- Drop-off point within each path, distinguishing an abandoned wallet sheet from an abandoned card form, since the causes and fixes for each are different
- Post-purchase refund and chargeback rate by payment method, to catch if the reduced-friction path is bringing in lower-intent purchases that get refunded at a different rate than card payments
Setup Steps
- Confirm the RevenueCat SDK is emitting a distinct payment-method property on purchase events, and pass it through to your analytics pipeline rather than treating all completions as one event type.
- Segment existing paywall funnels by payment method retroactively, where historical data allows, to establish a pre-launch baseline before comparing post-launch conversion.
- Instrument button-visibility events separately from click events, so the denominator for express checkout conversion rate reflects users who could actually see the option.
- Add payment method as a standard breakdown dimension on revenue dashboards — LTV, refund rate, and repeat-purchase rate should all be viewable split by
apple_pay/google_pay/cardfrom day one, not bolted on after the fact. - Run a short observation window before changing paywall copy or pricing, so any A/B test results aren’t confounded by an uneven mix of express-checkout and card users between variants.
Actionable Insights
Express checkout should be evaluated as its own funnel, not folded into an aggregate purchase-completed metric. A conversion lift that’s really just a larger share of eligible users seeing a lower-friction option looks identical, in a blended number, to a genuine improvement in paywall persuasiveness — and the fix for each is completely different. Splitting by payment method from the first day of rollout is what turns “conversion went up” into an answer a team can actually act on.
Related Resources
Need help tracking this in your app?
Our team sets up analytics pipelines for mobile and web teams every day. Talk to us and get your first events flowing in under an hour.
Talk to an expert