Exact App Review Notes That Got Approved
The precise wording Apple approved for external payment links. Three copy-paste templates, before/after language examples, and a screenshot checklist so your submission doesn't bounce.
Apple's May 2025 Guideline Update
US storefront apps no longer need the External Link Account entitlement to include external payment links. Apple removed the entitlement requirement following the Epic v. Apple ruling. What remains: your app must pass human review, which means your App Review notes need to clearly explain the flow. Ambiguity gets rejected. Clarity gets approved.
What you'll walk away with: Three copy-paste templates covering the most common app types (subscription app, gated content app, reader app), a before/after table showing language that gets rejected vs. approved, a list of the five most common rejection reasons with exact fixes, and a screenshot checklist.
The sentence reviewers look for
"Users receive identical access regardless of purchase method."
Include this verbatim, or a direct equivalent. It signals entitlement parity - the one thing reviewers need confirmed before they approve.
The Templates
These are structured for the App Review Notes field when submitting a new version. Adapt the specifics (payment processor, SDK name) to match your stack. Don't change the structural logic - the sentences are ordered intentionally.
Subscription App with US-Only Web Checkout
Use this for any subscription app where only US users see a web payment option, and all other users go through IAP as normal.
This version introduces web checkout as an alternative payment method for US App Store users only.
How it works: Users on the US storefront see both the standard Apple In-App Purchase option and a "Subscribe on Web" button. Tapping the web option opens our Stripe checkout page in Safari. After completing payment, RevenueCat sends the user a redemption link via email. Tapping that link opens the app and unlocks the subscription. Users on all other storefronts see In-App Purchase only - no web option is displayed.
Storefront detection uses StoreKit 2's Storefront.current API at paywall render time. The web checkout feature is controlled by a remote config flag that can be disabled instantly without an app update.
Users receive identical access regardless of purchase method. Entitlements are synced through RevenueCat and are indistinguishable at the feature level.
Gated Content App
For apps where premium content is locked behind a subscription - news, education, fitness, etc. Emphasize that content is gated, not just the purchase button. This directly addresses 3.1.1(a) compliance.
This version adds a web payment option for US App Store users as permitted under guideline 3.1.1(a).
Our app gates all premium content behind an active subscription. Users must subscribe before accessing any premium features - content is not accessible without a valid entitlement, regardless of how the subscription was purchased.
US storefront users see both Apple In-App Purchase and a web checkout option. Non-US users see In-App Purchase only. Storefront detection uses StoreKit 2's Storefront.current. Web purchases are processed via Stripe and synced to RevenueCat, which issues the entitlement in the app.
Entitlements are identical for IAP and web subscribers. We comply with 3.1.1(a): content is fully gated, not just the purchase flow. There is no pricing information shown in the app that compares IAP and web pricing.
Reader / Media App (Guideline 3.1.3)
For apps qualifying under the reader rule - books, magazines, newspapers, streaming video/audio. Reference both 3.1.1(a) and 3.1.3 explicitly. The anti-steering prohibition no longer applies on US storefront.
This version adds web checkout as an alternative subscription option for US App Store users. We are a reader app as defined under guideline 3.1.3.
The External Link Account entitlement is not required on the US storefront per Apple's May 2025 guideline update. We comply with both 3.1.1(a) and 3.1.3. The anti-steering provision no longer restricts us from showing web purchase options on the US storefront.
Implementation: Storefront detection via StoreKit 2 Storefront.current. US users see both IAP and web option. Non-US users see IAP only. Web purchases sync through RevenueCat via a redemption link sent to the user's email.
All content is gated behind an active subscription. Web and in-app subscribers receive identical access. There is no pricing comparison shown in the app.
Language That Gets Rejected vs. Approved
Reviewers read hundreds of notes. Specific, technical language reads as confidence. Vague or marketing-style language reads as evasion. Here's the difference in practice.
"We offer a web checkout option that may have different pricing."
"There is no pricing comparison shown in the app. Entitlements are identical regardless of purchase method."
"Users can choose how they want to pay."
"US storefront users see both IAP and a web checkout option. Non-US users see IAP only. Storefront detection uses StoreKit 2's Storefront.current API."
"We comply with all applicable guidelines."
"We comply with 3.1.1(a). The External Link Account entitlement is not required on the US storefront per Apple's May 2025 guideline update."
"The web checkout flow is straightforward."
"User taps 'Subscribe on Web' → Safari opens to Stripe checkout → payment completes → RevenueCat emails a redemption link → user taps link → app opens → entitlement unlocks."
The 5 Most Common Rejection Reasons
These account for the vast majority of rejections on this feature. If you get a rejection message, check which one applies before doing anything else.
Missing entitlement parity statement
The reviewer doesn't know that web subscribers get the same access as IAP subscribers. Without this confirmation, they must assume the app is creating a two-tier system - which violates guidelines.
Fix: Add "Users receive identical access regardless of purchase method" to your notes verbatim.
Flow description is too vague
Reviewers need to mentally trace the full payment → entitlement path. "We use web checkout" gives them nothing. They need to know exactly how a web subscriber ends up with a valid entitlement in your app.
Fix: Write the full step-by-step as an arrow chain. Tap → Safari → Stripe → email → redemption link → app → unlock.
Storefront detection method not specified
Saying "only US users see this" isn't enough. If you don't explain how you detect the US storefront, the reviewer has no way to verify the non-US flow is safe. They may assume you're guessing - and test it incorrectly.
Fix: Name the API. "Storefront detection uses StoreKit 2's Storefront.current API at paywall render time."
Screenshots missing or showing the wrong flow
Notes without screenshots are asking reviewers to take your word for it. They won't. Missing screenshots of the non-US flow is especially common - and the non-US IAP-only state is exactly what reviewers want to verify.
Fix: Attach all five screenshots listed in the checklist below. Label them in your notes: "See attached screenshot 1 (US paywall), screenshot 2 (non-US paywall)..."
Implied pricing differences in-app
If your web checkout button says anything that implies a price difference - "Save 30% on web", "Better price on our website", etc. - you're steering users away from IAP in a way that Apple still prohibits. This applies to the button label, any nearby text, and tooltip copy.
Fix: Use neutral labels ("Subscribe on Web" or "Subscribe via Website") and confirm in your notes: "No pricing comparison is shown in the app."
Screenshot Checklist
Attach these to your App Review submission as attachments (not inline in the notes field). Reference them by number in your notes text. Missing any screenshot, especially screenshot 2 (non-US paywall), consistently delays approval.
Paywall - US Account
Shows both IAP option and web checkout option visible simultaneously. The web button should be clearly visible but not dominant - it should appear as an equal alternative, not a promotion.
Paywall - Non-US Account Most critical
Shows IAP only - no web checkout button visible. This is the screenshot reviewers zoom into first. It must unambiguously show that non-US users cannot access the web checkout path.
Web Checkout Page
Screenshot of your Stripe or RevenueCat checkout page in Safari (not in the app). Shows the subscription price and product clearly. Confirms the web flow is a real, functioning checkout - not a placeholder.
Post-Redemption - App Unlocked
Shows the app state after a web purchase is redeemed - content unlocked, subscription active. Confirms the redemption link flow works end-to-end and the entitlement is visible in the app.
Account / Subscription Management Screen
Shows an active subscription state (web subscriber). Demonstrates the app surfaces subscription status unified regardless of purchase source. Confirms there's no dead-end for web subscribers managing their subscription.
Resubmitting after a rejection?
Don't just fix the thing they flagged. Read the whole rejection reason and check all five patterns above - Apple reviewers often only report one issue at a time, even when multiple issues exist. Fix everything, rewrite the notes from scratch using the templates above, and reattach all screenshots. Don't reply to the rejection with a partial fix.
Reference
Related Articles
Want someone to review your notes before you submit?
Book a quick call and we'll go through your notes and screenshots together before you hit Submit.
Book a 15-min Call →