Build a web checkout to avoid app store fees

Kite decides what goes on the web checkout by asking where the fee savings matter most and what will make customers switch. Annual plans usually come first. They carry the largest single payments, so they save the most per sale, and a customer who commits for a year on the web stays off the app store's books for that whole year.

Kite also proposes a reason to buy on the web, because a customer who already has Apple Pay one tap away needs one. The most common reason is a lower price, which you can afford because you keep more of each sale. Say your annual plan is $59.99 in the app and you keep about $51 after Apple's 15 percent. Selling it for $49.99 on the web leaves you about $48.24 after Stripe's fees, nearly the same amount, with a price that's easy for customers to notice. Other reasons include a longer free trial, a bonus feature, or an annual plan that the app doesn't offer at all.

Kite checks the plan against what you've already told customers before it settles anything. If your website lists the annual plan at $59.99 but the app store shows $69.99, Kite points out the difference and asks which price is right.

A web checkout page for an app subscription should tell the customer what they're buying, why to buy it here, and what happens after they pay. Kite writes and builds the page in your brand's voice and visual style, and it usually includes:

• The plan and its full price, with the billing period and the renewal terms written plainly. If the web price is lower than the app's, the page says so and shows both.
• What the plan unlocks in the app, using the same feature names customers see in the app.
• A short line on why paying on the web is safe. The page names Stripe as the payment processor and explains how to cancel, so the customer isn't left wondering why they're leaving the App Store.
• A buy button beside the price and again near the bottom of the page. It opens Stripe's own checkout, which shows Apple Pay and Google Pay on devices that support them, so paying takes about as long as it does in the app.
• A thank-you page that tells the customer to sign in to the app with the same email address and includes a button that opens the app.

Phones get special attention, because most visitors to an app's checkout arrive on one. Kite keeps the price and the buy button on the first screen a phone shows, and it checks the page on small screens before asking you to publish.

On a website Kite hosts, it builds the page there, and you can preview it before it goes live. If your site runs on Webflow, Kite publishes the page through your connected Webflow account. For a site hosted anywhere else, Kite gives you the page copy, the payment link, and the places on the page each button should point.

Kite sets up the checkout in your own Stripe account, so the money and the customer records are yours from the first sale. It searches your existing products and prices first, so a plan you already sell on the web isn't created twice. When nothing matches, it creates the product with its customer-facing name and description, adds a recurring price with the right amount and billing period, and creates a payment link for it.

Kite sets up the link's checkout options to match the offer. A subscription checkout says subscribe on its button, collects only what the purchase needs, and turns on the promotion code field when your campaign uses a code. Kite can also create the coupon and promotion code in Stripe, such as 30 percent off the first year for existing app subscribers who switch. After payment, the link sends the buyer to the thank-you page.

Yes, if the customer is in the United States. Apple's current US rules let an app show a button or link that opens your web checkout. Outside the United States, you can link out only through Apple's specific programs, so check which ones apply to your app before adding the button.

The button itself is a job for your developers, and Kite gives them what they need. That means the payment link URL, the wording for the button and the line beside it, and the way to tell Stripe who's paying. A Stripe payment link accepts the customer's account ID and email address as additions to the link's address. When the app adds them, the purchase arrives in Stripe already tied to the person who made it, and your app can unlock their plan as soon as Stripe reports the payment. Subscription tools such as RevenueCat can also connect Stripe purchases to app accounts if your developers already use one.

Kite writes the in-app wording to fit Apple's rules and your brand. A line like "Save $10 a year when you subscribe on our website" gives a clear reason to tap, and it states a fact the customer can check on the page.

Most of the fee savings come from customers who reach the web checkout without ever opening the app's purchase screen. That's why Kite treats the checkout as a destination for your marketing, not only as a link inside the app. It looks for the places your customers already hear from you and proposes how each one can point to the web checkout.

That can include:

• An email to your current subscribers, offering the web price or a switching discount. Kite writes it, and once you approve it, sends it from your Kite team address or your connected email product. Subscribers who switch need to cancel their App Store subscription themselves, so the email explains how to do that.
• Changes to your website, such as a pricing page that shows the web price and a subscribe button in the main navigation.
• Landing pages for paid ads. Many apps run ads that send people to a web page first, where they choose a plan and pay before they download the app. Kite researches the ads your competitors run, writes the ad copy, and builds the landing page that leads into the checkout.
• Posts and creator briefs that link to the web offer instead of the app store listing.

You approve each email, page, and post before it goes out.

Kite measures the web checkout by how much revenue moves off the app stores, not only by how many people visit the page. It reads your Stripe checkout sessions to see how many buyers opened the checkout, how many finished paying, and which plan they chose. On a page Kite hosts, its built-in analytics count the visitors and the clicks on each buy button, so Kite can tell a page that doesn't get clicks apart from a checkout that loses buyers after they click.

Your in-app sales live in App Store Connect and Google Play Console, which Kite doesn't connect to. Share an export of those numbers, or the totals from a tool like RevenueCat, and Kite puts the two side by side. That shows what share of new subscriptions now come through the web and how much you saved in fees that month.

Kite also reads cancellations and refunds in Stripe, because a discount that brings in buyers who refund in the first week isn't a win. Then it proposes the next change. If many buyers open the checkout and leave, Kite might suggest showing the annual price as a monthly amount or removing a field the checkout doesn't need. On a page Kite hosts, it can test two versions against each other, asking for your approval before the test starts and again before it makes the winning version permanent.

For more on testing what buyers see at checkout, see Test offers at checkout and Test your pricing and pricing page.