If your app is rejected under Guideline 3.1.1, the most common cause is how purchases are presented and verified, not a mysterious ban. This article shows where Apple permits charging outside In-App Purchase (IAP), the minimum presentation and server checks reviewers expect, and practical fixes you can typically implement in 2-6 weeks depending on engineering bandwidth.
Early proof - quick charge-type comparison
- Allowed outside IAP: physical goods and services - food delivery, rides, salon appointments use merchant payments.
- Allowed outside IAP: person-to-person and charity payments - tipping and donations are usually fine when not tied to digital content.
- Require IAP: in-app digital content and features - levels, power-ups, virtual currency must use IAP.
Explanation: This is a decision rule, not a loophole - real-world fulfillment or direct person transfers are the key tests.
Interpretation: If value is delivered outside the app or is a direct transfer, external processors are acceptable; otherwise plan for IAP or server-side work.
Reader impact: Use this rule to classify items before changing UI or servers - it removes the most common review disputes.
How subscription apps get rejected and how to prevent it iphone goes deeper on the ideas above and adds concrete next steps.
When can you charge outside Apple's IAP?
Apple allows external payments for physical goods, services, and many person-to-person transfers. What reviewers want in practice is clear payment messaging and server-side verification that the app should trust.
Immediate takeaway for founders
If the purchase is consumed in the real world, use a third-party processor and build entitlement checks. If the purchase unlocks digital features inside the app, expect to use IAP or move the purchase entirely off-app and validate access server-side. One thing worth noting - moving purchases to the web can cut fees but usually reduces conversion until account-linking UX is improved.
When you move from outline to execution, Stripe in Mobile Apps: App Store and Google Play Rules helps close common gaps teams hit here.
What does App Review flag under Guideline 3.1.1?
A stepwise flow diagram mapping three rejection triggers (external purchase CTA, missing server entitlement, misleading copy) on the left to three concrete fixes on the right (remove CTA + use sign-in, implement server-side checks, rewrite copy + reviewer note). Arrows show reviewer decision points.
Category: What you can charge for
Statistic: Allowed
Label: Physical goods & services
Context: Use a box + calendar icon; checkout can be outside IAP when fulfillment is real-world
Category: What you can charge for
Statistic: Allowed
Label: Person-to-person payments
Context: Use a tip/donation icon; frame as voluntary transfers, not gated features
Category: What triggers rejections
Statistic: IAP Required
Label: In-app digital content
Context: Use a locked coin icon; if it unlocks in-app content/features, route payment through IAP
Apple typically flags three signals: UI that points users to external buys for digital content, missing server-side entitlement checks, and copy that tells users to pay outside the app. Fix each signal before resubmission.
Classify every item
Map each product or feature as physical, service, person-to-person, or digital in-app. This focused product exercise usually takes a day or two and gives you the documentation reviewers want.
Remove external purchase CTAs from in-app screens
Replace "Buy on website" buttons for digital features with neutral actions like "Sign in" or "Manage account online." Plan a UI sweep of about 2-7 days including QA.
Add server-side entitlement verification
Implement a server truth that the app checks before unlocking any content. Typical effort: 1-3 weeks depending on existing APIs and webhook maturity. Call out risks reviewers care about, such as webhook delivery failures, clock skew, and replay protection.
Payment processor records transaction
Ensure your processor posts signed, idempotent webhooks to your server and keep logs.
Server updates entitlement SKU for user
Store SKU, timestamp, transaction ID, and a server signature that the app can validate or that you can show a reviewer.
App checks server before unlocking
App calls /entitlements and only honors server-confirmed flags. Cache securely and revalidate periodically to handle offline use and revoked access.
The practical takeaway: reviewers expect a verifiable server endpoint and at least one real transaction you can point them to during review.
Prepare reviewer workflow and demo assets
Provide a demo account, short reproduction steps, and a sample transaction ID in your App Review notes. Assembling this usually takes a few hours and reduces back-and-forth; be ready to respond within 24-72 hours while the review is active.
Document where purchases occur
In submission notes, state the processor, where purchases happen (web, phone), and how the app verifies access. Keep it concise and factual.
Top rejection triggers and fixes
Don’t be surprised: these are the common failure modes and the straightforward remedies.
Trigger: Visible "Buy on website" button for digital content.
Fix: remove the button and document alternate flows in submission notes.Trigger: Unlocking content without server check.
Fix: implement verification and attach sample logs or a transaction ID.Trigger: Copy that instructs users to buy outside the app.
Fix: use neutral promotional language and accurate reviewer notes.
A complementary angle worth comparing lives in Top 5 Ways to Monetize Your First iOS App.
What are the strategic trade-offs and a 2-6 week plan?
A compact 4-week timeline block showing week-by-week milestones: Week 1 classification & UI sweep, Week 2 server entitlements, Week 3 QA & reviewer prep, Week 4 submit & monitor. Each week has a one-line outcome and a key owner (product, eng, QA, ops).
Moving purchases to the web can reduce App Store fees but increases account-linking friction, operational overhead, and fraud monitoring. Choose based on resources and measurable goals, not ideology.
Repackage - 2-4 weeks
Move some features to web purchases and add SKU mapping. Expect engineering work on sign-up flows, analytics updates, and a conversion dip for a few weeks while users adapt. You will likely need extra support for customer service and fraud detection.
Clean UI - 1 week
Sweep screens to remove external checkout CTAs and replace them with neutral account actions. Low effort, high immediate reduction in rejection risk.
Reviewer-ready evidence - 1 week
Gather logs, demo credentials, a short video, and a one-paragraph submission note. Plan to respond to follow-ups within 24-72 hours.
Metrics to watch after rollout
- App Review payment-related rejection rate - aim to materially reduce it after a couple of releases, but expect reviewer subjectivity to cause some variance.
- Web-to-app linking rate - a practical target is 60-80% for paid users within 30 days, but your channel mix and onboarding matter.
- Net revenue after fees - track refunds and chargebacks for 60-90 days to assess whether fee savings outweigh ops costs.
Final checklist and quick rollout
Start small and iterate; this 4-week plan is a practical minimum for many teams.
Week 1 - classify & sweep UI
Inventory products, remove risky CTAs, and prepare a short reviewer note.
Week 2 - server entitlements
Add or extend a /entitlements endpoint and webhook handling. Run a few test transactions.
Week 3 - QA and reviewer assets
Capture logs, make a 1-minute demo video, and create demo creds.
Week 4 - submit and monitor
Submit with clear notes, watch review feedback, and be ready to respond within 24-72 hours.
For tradeoffs, checklists, and edge cases, Top 5 Things Every Founder Must Do Before Submitting an App rounds out this section.
