WebView App Rejected Under Guideline 3.1.1: Web Checkout Fix

Key takeaways

Inside a WebView app your website's checkout runs in the app, so for digital goods App Review treats it as a payment that bypasses In-App Purchase.
Digital content and subscriptions used in the app need In-App Purchase; physical goods and real-world services must use other methods (3.1.3(e)); reader apps follow their own rules.
As of October 2026, links to web purchases are allowed on the US storefront, need an entitlement in regions such as the EU, Japan and Brazil, and are not allowed elsewhere.
Hide or replace web purchase flows for every app user – never only during review – and give users a visible Restore Purchases option.
WebViewGold, built by our team, triggers StoreKit purchases, restores and the App Store country from your web code; its In-App Purchases need the Extended license.

Our recommended solution

Rebuild your wrapper with WebViewGold – a real app, not just a website in a frame

WebViewGold turns your website into native iOS and Android apps with push notifications, a native offline screen, deep links, a QR scanner and more – the building blocks App Store reviewers look for. Built by our own team, and we submit WebViewGold apps all the time.

Get WebViewGold How it helps ↓

What the rejection typically looks like

Guideline 3.1.1 - Business - Payments - In-App Purchase

We noticed that your app includes or accesses paid digital content, services, or functionality by means other than in-app purchase. Specifically, the app's premium membership can be purchased through the web checkout displayed in the app.

Next Steps

The paid digital content, services, or subscriptions included in or accessed by your app must be available for purchase in the app using in-app purchase.

Paraphrased example – the exact wording in your message may differ.

WebView app rejected under Guideline 3.1.1: why your checkout is the trigger

A WebView app rejected under Guideline 3.1.1 rarely contains a line of payment code. The checkout comes from the website: the app loads your pages, and your pages sell. App Review doesn't care where the HTML is hosted – it applies the first sentence of 3.1.1 (App Store Review Guidelines):

If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase.

The same paragraph rules out home-made unlocks: apps "may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets". In a wrapper, these web elements trip the rule most often:

Web element	Where it shows up in the app	Why App Review objects
Pricing page in the main menu	One tap from the start screen	Plans for digital access sold outside IAP
Upgrade banners and locked-feature pop-ups	Dashboard, course player, editor	Calls to action for a non-IAP purchase
Stripe Checkout, Payment Links, Paddle or Lemon Squeezy overlays	Opened directly in the WebView	Card payment for digital goods inside the app
PayPal buttons for memberships or credits	Product and account pages	The same issue with a different provider
Billing portal with plan switching	Account settings	Upgrades bought outside IAP
Coupon, license or access-code fields	Sign-up and redeem pages	An own unlock mechanism

One difference from a native app with a link to Safari is easy to miss: in a WebView app, the checkout runs inside the app. The US storefront rules discussed below cover buttons, links and calls to action – not card payments for digital goods processed in the app.

Digital, physical or reader content? Classify what your website sells

Before touching code, sort everything your website sells by what the buyer gets and where they use it. Typical website businesses come out like this:

Website type	What is sold	Payment inside the iOS app
Online shop on Shopify or WooCommerce	Physical products	Your own provider – 3.1.3(e) requires methods other than IAP, such as Apple Pay or card entry
Booking site for salons, studios or tours	Services consumed outside the app	Your own provider (3.1.3(e))
Coaching or tutoring platform	Live one-to-one sessions	Your own provider is allowed (3.1.3(d)); group classes and recorded courses need IAP
Membership site or online course	Access to digital content	In-App Purchase
SaaS dashboard	Pro plans, credits, extra features	In-App Purchase; plans bought on the web may be used if they are also offered as IAP (3.1.3(b)); team plans sold only to organizations can fall under 3.1.3(c)
News, magazine, audio or video library	Content subscriptions	Reader app rules (3.1.3(a)): existing subscribers may sign in; an informational sign-up link needs the External Link Account Entitlement except on the US storefront
Nonprofit or church website	Donations	Approved nonprofits may fundraise in the app with Apple Pay support; others collect funds outside the app, for example via Safari (3.2.2(iv))

Mixed businesses need two flows: Apple Pay or card entry for the physical part, IAP for the digital part. The complete list of exceptions is in our Guideline 3.1.1 guide. Borderline cases – a course with live sessions, a marketplace with digital extras – are where a second opinion from appsubmitter.io pays off before you build anything.

Rejected or stuck? Talk to an App Specialist – for free.

Book a free consultation call: we look at your rejection or setup, explain the fastest way forward and tell you honestly whether you need us. Prefer to hand it off? Book our AI-powered + human-powered service and we take care of it.

Free consultation call Book our service →

Can app users still buy on your website? External links by storefront

This area changes often, so treat the following as an October 2026 snapshot and check the details in the guide linked above before you ship:

United States storefront: guidelines 3.1.1(a) and 3.1.3 say the ban on buttons, external links and other calls to action does not apply there, and no entitlement is needed. Litigation over these rules is ongoing, so they may change again.
EU, Japan, Brazil and other listed regions: alternative options need Apple's StoreKit External Purchases or Offers Entitlement or a program-specific entitlement, use Apple's API with a system disclosure sheet and come with commissions and rules on how prominently IAP must appear.
All other storefronts: no buttons, links or other calls to action that lead to purchases outside IAP – in the app or in its metadata.

Three consequences for a WebView app. First, even where links are allowed, the lowest-risk setup is IAP inside the app plus an optional link that opens your checkout in Safari; the guidelines don't explicitly say you may drop IAP for digital goods sold in the app. Second, the decision has to follow the App Store storefront – not device language, region setting or IP address – and a website can't see the storefront on its own, so the native layer must tell it. Third, the entitlement programs run through native StoreKit APIs, which means native code in your project, not just a link on a page.

App mode: replace the web purchase flow for every app user

Once you know what needs IAP, make your website behave differently inside the app – consistently, for every app user:

Detect the app with a custom user agent token, the same way you would for layout changes.
Swap the paywall, not just the button. In app mode, the pricing page leads to your IAP offer with prices for the user's storefront, and routes such as /checkout or /billing redirect there.
Replace codes: drop access-code fields and use App Store offer codes for promotions.
Handle web subscribers. They sign in and get access; outside the US storefront, show their status without web prices or links.
Send Apple subscribers to Apple for billing changes and cancellations instead of your web billing portal.
Test four users: new, web subscriber, IAP subscriber and expired.

What you must not do is hide the paywall only while the app is in review. That shows the reviewer a different app than your users get – the pattern behind many Guideline 5.6 rejections. A new purchase flow is also new functionality that belongs in your review notes, as our article on Guideline 2.3.1 for WebView apps explains.

The fastest fix for most WebView rejections

WebViewGold: native features for your web app

Instead of building native features from scratch, start from WebViewGold. You get ready-made Xcode and Android Studio projects for your website, with native modules you switch on in the configuration:

Push notificationsOneSignal or Firebase, for real, personal events
Native offline screenNo browser error pages when the connection drops
Native splash screenApp-like start instead of a loading web page
Deep linksLinks open the right screen inside the app
QR & barcode scannerDevice features the website alone can't offer
In-app purchasesNative purchase flows where the store requires them

No tool guarantees an approval: Apple still judges what your app offers. Use the native features in your main user journey – our App Specialists review your WebViewGold app before it goes to the App Store.

Discover WebViewGold Let us submit your WebViewGold app

Adding In-App Purchase to a WebView app with WebViewGold

You don't have to write a StoreKit layer from scratch. WebViewGold, the website-to-app product our team builds, includes In-App Purchases that your web code triggers with links. Using the feature in a published app requires the Extended license. The building blocks:

Purchases and subscriptions: a link such as inapppurchase://?package=PRODUCT_ID&successful_url=https://example.com/thanks opens the native purchase sheet; subscriptions use inappsubscription:// with an extra address for expired subscriptions.
RevenueCat or manual setup: WebViewGold works with RevenueCat, which receives your own user ID, or with a manual configuration in Config.swift.
Restore and management: restoreinapppurchases:// restores purchases, cancelinapppurchase:// opens Apple's subscription management.
Storefront: getstorelocation:// passes the App Store country code to your JavaScript, for example to decide whether a US-only link may appear. Its URL handling settings can send your checkout domain to Safari.

The products themselves you set up in App Store Connect: an active Paid Apps Agreement, metadata and a review screenshot per product, and the first in-app purchase of each type submitted with a new app version. Subscription paywalls must also meet 3.1.2 – billed amount, period, terms and privacy links – see our 3.1.2 Subscriptions guide. No tool can promise an approval, but this setup removes the usual WebView payment gaps.

Keep website and app purchases in sync

Most WebView apps share accounts with the website, so a purchase has to unlock the same account everywhere:

Sign in before buying. Every App Store transaction should belong to an account. With WebViewGold, your success page still sees the user's session; RevenueCat receives your user ID; native StoreKit code can attach an app account token to a purchase.
Validate on your server with the App Store Server API instead of trusting the device.
Listen to App Store Server Notifications. Renewals, refunds and expirations arrive server-to-server, so web access ends when the subscription ends.
Keep one entitlement per user with its source – Apple, Stripe or another provider – so nobody pays twice and support knows where a cancellation belongs.
Put Restore Purchases in the account area, not only on the paywall. 3.1.1 asks for a restore mechanism for any restorable purchase.

Resubmitting: what App Review needs to see

Guideline 2.1(b) asks that in-app purchases be "complete, up-to-date, visible to the reviewer and functional". For a WebView app that means: the products are attached to the version, the paywall is reachable with the demo account and the notes say where it is. If some purchases are physical goods or one-to-one services paid through your own provider, name the sub-clause – 3.1.3(e) or 3.1.3(d) – so the reviewer doesn't have to guess.

Then reply on the rejected submission with what changed, the product IDs and a screen recording of purchase and restore. appsubmitter.io can take this off your plate: our App Specialists sort your offers into the right payment routes, set up products and listing, check app mode in a pre-submission review and handle the conversation with App Review in your own developer account. Code changes are discussed and quoted upfront. Book the iOS service or book a free consultation call to sort out your payment setup first.

Template: how to reply to App Review

Adapt this template to your situation. Keep it factual, short and specific – and only claim what you have actually changed.

Hello App Review Team,

Thank you for reviewing [App name] (version [x.y], build [build number]) and for your feedback regarding Guideline 3.1.1.

Our app displays our website [domain]. We have changed how purchases work inside the app for all app users:

- [Premium membership] is now available via In-App Purchase (product IDs: [com.example.premium.monthly], [com.example.premium.yearly]). The web checkout no longer appears in the app.
- Restore Purchases is available at [Account > Restore Purchases].
- [Optional: Physical products in our shop continue to use [Apple Pay / card payment], as required by Guideline 3.1.3(e).]
- [Optional: On the United States storefront only, the app also shows a link to purchase on our website, which opens in Safari.]

To test: sign in with [username] / [password], open [Menu > Premium] and tap [Subscribe]. A screen recording of the purchase and restore flow is attached.

Best regards,
[Your name]
[Company]

Checklist before you resubmit

Every paid item on your website is classified as digital, physical, real-world service, one-to-one service or reader content.
Digital items used in the app can be bought with In-App Purchase inside the app.
Web checkouts from Stripe, Paddle, PayPal and others no longer open inside the WebView for digital goods.
Pricing, upgrade and billing pages lead to the IAP offer in app mode – for every app user, not only during review.
Access codes and license keys are gone; promotions use App Store offer codes.
Any external purchase link depends on the App Store storefront and follows that storefront's current rules.
Physical goods and real-world services still use your own payment provider, not IAP.
Restore Purchases is visible and works after reinstalling the app.
Transactions are validated on your server, and App Store Server Notifications update the shared account.
The IAP products are attached to the version, and the review notes explain where the paywall is.

Frequently asked questions

Why was my WebView app rejected under Guideline 3.1.1 when the payment happens on my website?

Because your website runs inside the app. When users can pay for digital content or features in that WebView, App Review sees a purchase inside the app that bypasses In-App Purchase. Hide or replace the web checkout in app mode and offer the same digital products through StoreKit.

Can I keep Stripe for physical products in my iOS app?

Yes – in fact you have to. Guideline 3.1.3(e) requires purchase methods other than In-App Purchase, such as Apple Pay or card entry, for physical goods and services consumed outside the app. A shop for clothing, food orders or event tickets can keep its Stripe or PayPal checkout inside the WebView.

Can I open my web checkout in Safari instead of the WebView?

Only where Apple allows purchase links. As of October 2026 the US storefront allows buttons and links to your website, entitlement programs cover regions such as the EU, Japan and Brazil, and other storefronts allow no such calls to action. Gate the link by App Store storefront and keep IAP in the app as the safe default.

Do I need the WebViewGold Extended license for In-App Purchases?

Yes. WebViewGold, made by our team, includes StoreKit purchases, subscription, restore and storefront links, with RevenueCat or a manual setup, and its documentation requires the Extended license when you use the feature in a published app. Both licenses are one-time purchases.

What about users who already subscribed on my website?

They can sign in and use what they bought, as long as the same content or subscription is also available as In-App Purchase in the app (3.1.3(b)). Reader apps for magazines, books, audio, music and video have their own rules. Outside the US storefront, don't show web prices or links to the web checkout inside the app.

Can I hide the paywall only while the app is in review?

No. A paywall that disappears during review and returns afterwards shows App Review a different app than your users get. That is exactly the hidden behavior behind Guideline 5.6 rejections, and it can put your developer account at risk. Apply app mode to every user, all the time.

Do I need a Restore Purchases button in a WebView app?

If you sell restorable purchases such as subscriptions or non-consumables, yes – Guideline 3.1.1 asks for a restore mechanism. In a WebViewGold app, a link to restoreinapppurchases:// on your account page triggers it. Test it after deleting and reinstalling the app, and with a second device.

Sources and further reading

Store policies and third-party products change regularly – always check the current versions. This article is independent advice and not affiliated with or endorsed by Apple, Google or any other company or product mentioned; all trademarks belong to their owners. WebViewGold and appsubmitter.io are made by our team at jocapps GmbH.

WebView App Rejected Under Guideline 3.1.1: What to Do With Your Website's Checkout Inside the App