Pricing Experiments You Can Run on Web

What you'll walk away with: Five concrete experiments you can start this week, Stripe setup steps for each, the Dipsea data caveat (web converts fewer users upfront - here's how to account for it), and the one experiment to run first if you're not sure where to start.

Experiment 1: Custom Annual Pricing

Break out of Apple's price tiers - test any number

Apple requires you to choose from their fixed price tiers: $4.99, $9.99, $14.99, $19.99... and so on. You can't offer $67/year or $84/year in the App Store. On web via Stripe, you create a product at any price in any currency, update it in seconds, and test which number converts best - without shipping a new build.

CardPointers tested Stripe-powered web checkout to escape the Apple tier constraint. The result: ~27% lower fees on web purchases vs their App Store IAP rate. The margin benefit compounds with better pricing - lower fees and optimized price points.

Experiment 2: Coupon Codes and Flash Sales

Run time-limited discounts without touching a line of app code

Apple has no in-app coupon code mechanism. You can run offer codes on the App Store, but they require App Store products, pre-approval, and can't be dynamically generated. On Stripe, you create a coupon in 30 seconds, attach it to a payment link, and distribute it anywhere.

# Stripe CLI - create a 20% off forever coupon
stripe coupons create \
  --percent-off=20 \
  --duration=once \
  --id=PODCAST20 \
  --max-redemptions=500 \
  --redeem-by=1735689600  # Unix timestamp for expiry

# Link it in your checkout URL
https://checkout.stripe.com/c/pay/...?prefilled_promo_code=PODCAST20

Experiment 3: Dynamic Pricing by Segment

Different prices for different traffic sources - no extra code in your app

Apple shows one price to everyone on the App Store. On web you can serve different checkout URLs to different segments - podcast listeners get one price, newsletter subscribers get another, paid ad traffic gets a third. You're not changing your in-app IAP at all. Just routing different users to different Stripe checkout links based on where they came from.

CardPointers uses UTM parameter tracking for podcast attribution. Users from specific podcasts land on a URL with their coupon pre-applied. Conversion from that traffic segment is higher because the offer matches the context. You can see which channels drive the best-converting web traffic, then double down.

Experiment 4: Trial Length Testing

Find the trial length that converts best - before committing it to the App Store

In the App Store, your trial length is baked into an IAP product. Changing it means creating a new product, shipping an update, and running the experiment over weeks. On Stripe, you change the trial_period_days on a subscription in the dashboard and the change is live instantly.

The SOSA 2026 data on day-zero cancellations is significant: if more than half of your trials cancel before the user does anything, the trial length isn't your problem - your onboarding is. Test trial lengths once you've solved the day-zero problem, not before.

On web, test 3-day vs 7-day vs 14-day by routing traffic segments to different Stripe checkout configurations. Find the conversion sweet spot, then apply the winning trial length to your App Store product.

# Create a price with a 7-day trial
stripe prices create \
  --product=prod_YOURPRODUCTID \
  --unit-amount=999 \
  --currency=usd \
  --recurring[interval]=month \
  --recurring[trial_period_days]=7

# Or set trial on a Payment Link via dashboard:
# Payment Links → Edit → Subscription → Add free trial

Experiment 5: Price Anchoring and Comparison

Show "was $99, now $69" - and control the full presentation

Apple controls what your paywall looks like in-app. You can display your IAP product names and prices, but elaborate UI like crossed-out original prices, "Save $X" callouts, or comparison tables get scrutinized in App Review. On web, you own the page entirely.

Hard paywalls convert 5× better than freemium by day 35 (SOSA 2026: 10.7% vs 2.1%). The presentation of the paywall matters as much as the price. On web you can test hero copy, urgency timers, social proof, annual vs monthly comparison tables, and "most popular" badges - none of which require an app update or App Review.

The Dipsea Data Caveat

The right interpretation: web isn't a replacement for IAP. It's a different channel for different traffic. Use it where you have control over user intent - email subscribers, paid ad traffic, podcast listeners. Don't expose web checkout to low-intent organic users who are casually browsing. Keep IAP as the default for in-app organic traffic.

Start Here: The Easiest First Experiment

If you're not sure where to start, start with coupon codes. Here's the exact sequence:

Tools & Reference