External Purchases

rshankras/claude-code-apple-skills/skills/monetization/external-purchases

by rshankras9ffb83138209No license784 starsListed Oct 9, 2026Updated Oct 9, 2026Repository updated 2 months ago

US web checkout via the StoreKit External Purchase Link entitlement — currently 0% Apple commission (litigation ongoing), how to ship it safely, and how to architect for a commission flip so a future ruling is a config change, not a rewrite. Use when adding external purchase links, weighing web checkout vs IAP, or planning US-storefront pricing strategy.

AI-generated overview

Guides US-only StoreKit external purchase links for web checkout, including compliance rules and a configurable commission-flip architecture.

What it does
Explains how to add US-storefront external purchase links for digital goods using the StoreKit External Purchase Link entitlement, covering entitlement and Info.plist requirements, storefront scope, and disclosure expectations. It recommends centralizing link-outs, keeping a remote-configurable CommissionPolicy, and logging funnel analytics so a future commission ruling becomes a config change. It also provides a decision sketch comparing web checkout with IAP and a short output checklist.
When to use it
Use when adding a web checkout or external purchase link for digital goods, deciding between IAP and web checkout for a US-heavy revenue base, or reviewing external links for compliance. Also relevant when planning US-storefront pricing strategy.
Requirements
Instructions only; no scripts. Requires reading and editing project files (Read, Write, Edit, Glob, Grep). References Apple StoreKit entitlement documentation and assumes an app with StoreKit and Info.plist configuration.

External Purchases (US Web Checkout)

On the US storefront, apps may link out to a web checkout for digital goods using the StoreKit External Purchase Link entitlement — and as of mid-2026, court orders have Apple's commission on those purchases at 0%, with the fee case still moving through district court. This is the largest indie revenue unlock of the era, and it is reversible by a ruling — so the engineering rule is: ship it now, architect it so a commission can be flipped on later.

Verify current state before relying on this: the entitlement terms, the commission rate, and the litigation status have each changed more than once. Treat every number here as "true as of 2026-07, re-check."

When This Skill Activates

  • "Add a web checkout / Stripe / external purchase link" for digital goods
  • Deciding IAP vs web checkout for a US-heavy revenue base
  • The store-growth audit flags P8.4
  • Reviewing an app whose external links might be non-compliant (wrong storefront, no entitlement)

The rules of the road

  • US storefront only — elsewhere Guideline 3.1.1 still applies (EU/JP/KR have separate entitlements/terms; don't extrapolate from the US).
  • Entitlement required: com.apple.developer.storekit.external-purchase-link + matching Info.plist declaration — a bare Link("Buy", …) without it is still a rejection (see app-store/rejection-handler §3.1.1).
  • Present the link per the entitlement's UI terms (StoreKit's ExternalPurchaseLink / disclosure sheet where required). Don't dark-pattern the IAP option away if you keep both.
  • Purchases made on the web are your customer relationship — payment processor, refunds, taxes; Apple's merchant-of-record role no longer applies.

Architecture: the commission flip

Design so that a future "Apple takes N% of external purchases initiated in-app" ruling changes a config value, not your codebase:

  • ✅ Route every in-app-initiated web checkout through one link-out service that stamps the session (source=app, timestamp, storefront) — web-organic checkouts stay unstamped. If a commission returns, it applies to a knowable, logged subset.
  • ✅ Keep a single CommissionPolicy (remote-configurable): rate, applies_to, effective_date. Report/accrue against it from day one — at 0% it's just a counter.
  • ✅ Log day-one analytics: link taps → checkout starts → completions, vs the IAP funnel. The conversion drop through a web checkout (Apple's sheet, Safari hop, payment form) is real; whether 0% beats IAP's frictionless 85–70% is an empirical per-app question.
  • ❌ Scattering openURL("https://…/buy") calls through features — un-auditable, un-flippable.
  • ❌ Ripping out StoreKit. Keep IAP as a fallback path (non-US storefronts still need it, and some US users convert better in-sheet).

Decision sketch

SituationLean
Subscriptions, US-heavy, ARPU high enough to absorb processor fees + your own supportWeb checkout for new subs; keep IAP for the rest of world
Impulse-priced consumables/unlocksIAP — checkout friction eats more than 15–30% commission
Existing subscriber base on IAPDon't force-migrate; offer web at renewal decision points
B2B/prosumer, invoicing needsWeb checkout regardless of commission math

Output Format

Status: entitlement present? · storefront scope correct (US-only gating)? ·link-out service centralized? · CommissionPolicy flippable? · funnel analytics live?Verdict + the one next step.

References

Source and attribution

Source:rshankras/claude-code-apple-skillsinskills/monetization/external-purchasesat commit9ffb831

License: No license

Content belongs to its original authors. SourceWeft indexes it from a public repository.

Report or request removal