App Store у Південній Кореї: зовнішня оплата і 26%

У Південній Кореї застосунок, який поширюється лише в корейській вітрині, може приймати оплату через місцевого платіжного провайдера, наприклад KCP або Toss, замість вбудованих покупок Apple. Тоді Apple бере 26% від сплаченої ціни з ПДВ, а комісія провайдера йде зверху. Для невеликого розробника, який завдяки Small Business Program платить 15% із вбудованими покупками, цей варіант обходиться дорожче.

У цьому гайді ти знайдеш точний entitlement, окремий бінарник лише для Кореї, ставки та кожен крок. Усе за сторінками Apple, які я перечитав 27 жовтня 2026 року. Я не тестував цей варіант: приклад із цифрами нижче є розрахунком, а не виміром. Вбудовані покупки в Кореї лишаються доступними, і це вибір за замовчуванням. Винятки для інших країн зібрані в гайді з guideline 3.1.1. Для Японії і Бразилії є окремі гайди.

Що дозволяє корейський варіант

Згідно зі сторінкою Apple про Південну Корею, яка є й корейською, усе почалося з поправок до корейського закону про телекомунікації (Telecommunications Business Act, 전기통신사업법). Застосунок, що поширюється в App Store лише в Південній Кореї, може передати свої вбудовані покупки іншому платіжному провайдеру. Apple називає це право StoreKit External Purchase Entitlement.

Усе інше визначають три правила:

• entitlement діє лише для застосунку iOS або iPadOS у корейській вітрині;
• він застосовується до нового бінарника, який поширюється лише в Кореї;
• він не може співіснувати з вбудованими покупками Apple в одному застосунку.

Оплата відбувається в застосунку, через твого провайдера. Сторінка не передбачає кнопки на твій сайт: користувач залишає застосунок, лише якщо цього вимагає закон для завершення покупки.

Комісія 26%: що вона охоплює

Apple стягує 26% від ціни, яку сплатив користувач, «gross of any value-added taxes», тобто з ПДВ. Apple подає цю ставку як знижену, бо вона не включає обробку платежу. Цю обробку тобі виставляє твій провайдер, окремо.

Порівняно з вбудованими покупками змінюються три речі:

• податки лягають на тебе: ти сам їх збираєш і сплачуєш, згідно з додатком до entitlement для Кореї;
• сторінка не наводить жодної зниженої ставки: ні для Small Business Program, ні для підписок після першого року;
• база розрахунку включає ПДВ, тоді як комісія за вбудовані покупки рахується від ціни без зібраних податків, згідно з розділом 3.4 додатка 2 до ліцензійної угоди Apple Developer Program.

Іноді ти побачиш «27%»: це ставка інших схем, як-от для застосунків знайомств у Нідерландах, де Apple знижує комісію на 3 пункти. Для Кореї сторінка Apple каже 26%.

Схвалені платіжні провайдери

Apple перелічує чотирьох провайдерів, уже кваліфікованих для корейської вітрини: KCP, Inicis (이니시스), Toss (토스) і NICE.

Можеш запропонувати іншого. Тоді Apple перевіряє його безпеку, боротьбу з шахрайством, способи оплати, білінг підписок і здатність сплачувати комісію безпосередньо Apple. Провайдер поза цим списком може затримати твою заявку або призвести до відмови.

На один entitlement дозволено лише одного провайдера, а щоб його змінити, є форма оновлення. Ти не можеш сам зберігати чи передавати платіжні дані. Комісій провайдерів на сторінці Apple немає, і я їх не збирав: запитай у кожного.

Бінарник лише для Кореї

Це обмеження, яке вирішує все. Entitlement запитують для bundle ID, який ніколи не публікувався в App Store. Отже, твій поточний застосунок його отримати не може. Ти створюєш інший застосунок, зі своїм bundle ID, доступний лише в Кореї.

• Цей бінарник не містить вбудованих покупок Apple.
• Якщо новий застосунок є версією застосунку, який уже продає через вбудовані покупки, ти маєш прибрати старий із корейської вітрини, перш ніж Apple схвалить новий.
• Новий застосунок має власну сторінку: у Кореї він стартує без оцінок та історії старого.

Тож ти підтримуєш два застосунки: глобальний із вбудованими покупками і корейський із твоїм провайдером. Кожне оновлення подаєш двічі.

26% чи 15%: розрахунок для невеликого розробника

Small Business Program знижує комісію за вбудовані покупки до 15%, після реєстрації, поки твій чистий дохід (proceeds) не перевищує 1 мільйона доларів за календарний рік. На його сторінці немає винятку для Кореї, лише окремий випадок для Європейського Союзу. Умови детально описані в гайді з Small Business Program.

Ось приклад для покупки за 10 000 вон з ПДВ. Припущення для розрахунку: ти не резидент Кореї, а ціна включає ПДВ 10%, що варто підтвердити в бухгалтера. Комісія провайдера не врахована.

За 10 000 сплачених вон	Small Business	Стандартна ставка	Зовнішня оплата
База комісії	9 091 вона	9 091 вона	10 000 вон
Ставка Apple	15%	30%	26%
Комісія Apple	1 364 вони	2 727 вон	2 600 вон
ПДВ 909 вон	Сплачує Apple	Сплачує Apple	Сплачуєш ти
Платіжні збори	Включені	Включені	Окремо
Тобі лишається	7 727 вон	6 364 вони	6 491 вона до зборів

Що показує таблиця:

• Порівняно зі Small Business Program зовнішня оплата коштує тобі 1 236 вон із кожного продажу, тобто 16% того, що тобі лишається, ще до зборів провайдера.
• Порівняно зі стандартною ставкою 30% ти виграєш 127 вон, тобто 1,3% ціни. Різниця в 4 пункти між 30% і 26% тане до 1,3 пункта, бо 26% рахуються від ціни з ПДВ.
• Для підписки за стандартною ставкою комісія вбудованих покупок падає до 15% після року оплаченої підписки, згідно з тим самим розділом 3.4. Зовнішня оплата лишається на 26%: корейська сторінка не обіцяє жодного зниження.

Колонка «Зовнішня оплата» враховує не все. Додай другий бінарник, який треба підтримувати, щомісячний звіт про продажі, підтримку клієнтів щодо платежів і ПДВ, який декларуєш сам.

Зовнішня оплата вигідніша за вбудовані покупки, лише якщо ти платиш 30%, а провайдер коштує тобі менше ніж 1,3% ціни.

Метод і обмеження

Я читав HTML-код корейської сторінки Apple, сторінки Small Business Program і ліцензійної угоди, без автоматичних підсумків. Розрахунок спирається на три правила: 26% з ПДВ для зовнішньої оплати, комісія від ціни без зібраних податків для вбудованих покупок (додаток 2, розділ 3.4) і ПДВ, який Apple сплачує за розробників-нерезидентів Кореї (додаток B до додатка 2, «Exhibit B»).

Якщо ти резидент Кореї, ти сам сплачуєш ПДВ навіть із вбудованими покупками. Тоді Apple віднімає оцінений ПДВ від ціни, перш ніж рахувати комісію (додаток B), і додає корейський ПДВ на цю комісію (додаток C, розділ 7). Попроси бухгалтера перерахувати.

Обмеження: ПДВ 10% є припущенням, збори провайдерів не враховані, жодного реального тесту не було.

Кроки, щоб отримати entitlement

1. Перерахуй усе зі своїми реальними цінами і зборами, які називає провайдер.
2. Обери схваленого провайдера: KCP, Inicis, Toss або NICE. Перевір, що він підтримує підписки, якщо ти їх продаєш, і що його процес оплати нативний.
3. Підготуй новий bundle ID, ніколи не опублікований, лише для корейського застосунку.
4. Заповни форму заявки як власник акаунта (Account Holder). Apple просить назву застосунку, його опис, bundle ID, провайдера, домен твого сайту й адресу сайту підтримки клієнтів. Також ти приймаєш умови entitlement.
5. Дочекайся листа-підтвердження від Apple, потім увімкни entitlement для App ID у Certificates, Identifiers & Profiles.
6. Налаштуй бінарник і обов'язковий код StoreKit, як описано нижче.
7. Створи сторінку в App Store Connect з доступністю лише в Південній Кореї.
8. Подай застосунок, коли провайдер готовий приймати платежі, зі скриншотами екранів, де ти інформуєш користувача. Якщо новий застосунок є версією застосунку, що продається в Кореї через вбудовані покупки, прибери старий із цієї вітрини.

Apple попереджає: неповна заявка або несхвалений провайдер подовжують перевірку чи ведуть до відмови.

Налаштування бінарника: Xcode або Expo

Entitlement працює починаючи з iOS 15 та iPadOS 15. У Xcode змінюються два файли.

У файл .entitlements додай entitlement:

• ключ: com.apple.developer.storekit.external-purchase;
• тип: Boolean;
• значення: true.

В Info.plist додай ключ SKExternalPurchase типу масив рядків із кодом Південної Кореї. Корейська сторінка Apple пише KR. Довідка щодо ключа вимагає код малими літерами і вказує kr для Південної Кореї. Я б ставив kr, як у технічній довідці.

Під час наступного білду Xcode побачить, що профіль підготовки (provisioning profile) більше не відповідає, і запросить новий.

В Expo обидва ключі задаються в app.json, через ios.entitlements та ios.infoPlist:

{
  "expo": {
    "ios": {
      "bundleIdentifier": "com.example.myapp.kr",
      "entitlements": {
        "com.apple.developer.storekit.external-purchase": true
      },
      "infoPlist": {
        "SKExternalPurchase": ["kr"]
      }
    }
  }
}

Bundle ID тут вигаданий. Щоб мати один проєкт і випускати два застосунки, Expo документує варіанти застосунку через app.config.js. Глобальний варіант зберігає вбудовані покупки, корейський отримує ці ключі. Твій звичний paywall, підключений до вбудованих покупок, як у гайді з RevenueCat, лишається в глобальному варіанті. Не вкладай вбудовані покупки в корейський варіант, навіть вимкнені: Apple забороняє будь-які приховані або сплячі платіжні функції. А от обов'язкові виклики StoreKit, описані нижче, лишаються: вони пишуться на Swift, тож з Expo закладай нативний модуль, наприклад через Expo Modules API.

Інформаційне вікно і процес оплати

Apple вимагає три виклики StoreKit:

• перевіряти canMakePayments перед кожним процесом покупки чи введення платіжних даних, щоб знати, чи має користувач право платити;
• показувати інформаційне вікно Apple через API StoreKit External Purchase, викликом presentNoticeSheet(), починаючи з iOS 15.4;
• підтверджувати вітрину через Storefront або SKStorefront, коли ти не викликаєш це API: перед кожним процесом вітриною користувача має бути Корея.

Документація presentNoticeSheet() додає два правила: спершу перевіряти ExternalPurchase.canPresent, доступний з iOS 17.4, і відкривати вікно лише після свідомої дії користувача, наприклад натискання кнопки. Якщо користувач не продовжує, ти не показуєш зовнішню покупку.

На iOS від 15.0 до 15.3 ти точно відтворюєш дизайн і текст, які надає Apple. У будь-якому разі вікно з'являється перед кожною покупкою і кожним введенням способу оплати, доки користувач не натисне «계속» (Continue), на кожному пристрої окремо.

Його корейський заголовок: «이 앱은 App Store의 안전한 비공개 지불 시스템을 지원하지 않습니다.» Тобто застосунок не підтримує захищену оплату App Store. Текст попереджає, що керування підписками, сімейний доступ і повернення коштів через Apple будуть недоступні.

Сам процес оплати має бути:

• нативним, у застосунку, ніколи не у web view;
• без прихованих, сплячих чи незадокументованих платіжних функцій;
• без оманливих практик: інакше Apple видалить застосунок і може виключити тебе з програми.

Запитай провайдера, чи його платіжний модуль відкривається у web view, ще до того, як напишеш хоч рядок коду.

Після релізу: звіт, рахунок і підтримка

• Щомісячний звіт про продажі через форму, на яку посилається сторінка Apple, протягом 15 календарних днів після кінця фінансового місяця Apple. Apple надає приклад звіту.
• Рахунок, який треба оплатити протягом 45 днів після кінця фінансового місяця.
• Право на аудит: Apple може перевірити точність твоїх декларацій.
• У разі несплати: Apple може зарахувати борг за рахунок того, що вона винна тобі в інших країнах, видалити застосунок або виключити тебе з програми.
• Підтримка клієнтів на тобі: Apple не бачить цих покупок, тож не займається ні поверненнями, ні історією, ні керуванням підписками.

Що відбувається з корейським регулятором

Перевірено 27 жовтня 2026 року. У 2023 році корейський регулятор телекомунікацій, тоді 방송통신위원회, оголосив про намір покарати Apple і Google за нав'язування власної платіжної системи. У 2025 році закон замінив його на 방송미디어통신위원회, за даними Digital Daily. 12 жовтня 2026 року його голова планував рішення до кінця місяця, за даними SBS Biz. 27 жовтня те саме видання вважало ймовірним остаточне голосування на пленарному засіданні 28 жовтня.

Того ж дня, за даними CBS Nocut News, одне питання лишалося дискусійним: чи зобов'язати Apple і Google дозволити застосункам інформувати користувачів про оплату поза системою Apple чи Google і спрямовувати їх туди. Йдеться про зобов'язання «anti-steering».

Станом на 27 жовтня 2026 року рішення не ухвалено: описані тут правила відповідають сторінці Apple на цю дату. Санкція може їх змінити, особливо якщо вона запровадить це право інформувати. Перечитай сторінку Apple і корейську пресу, перш ніж подавати заявку.

Чи варто робити корейський бінарник?

Твоя ситуація	Моя порада
Учасник Small Business Program	Залишай вбудовані покупки
Стандартна ставка, збори вище 1,3%	Залишай вбудовані покупки
Застосунок уже має оцінки в Кореї	Залишай вбудовані покупки
Стандартна ставка, збори нижче 1,3%	Перерахуй усе повністю

Для більшості інді-розробників відповідь: ні. Можливий виграш малий і лише за стандартної ставки, а фіксовані витрати гарантовані. Твоя енергія принесе більше деінде: правильна модель ціни, про яку я писав у статті підписка чи разова покупка, і реалістичні доходи застосунку в статті скільки заробляє мобільний застосунок.

Поширені запитання

Яка комісія Apple за зовнішню оплату в Південній Кореї?

26% від ціни, сплаченої користувачем, з ПДВ. Збори платіжного провайдера йдуть зверху, а податки збираєш і сплачуєш ти.

Яких платіжних провайдерів Apple приймає в Кореї?

KCP, Inicis, Toss і NICE уже схвалені. Можеш запропонувати іншого, але Apple має його перевірити, що може затримати заявку або призвести до відмови. Один провайдер на entitlement.

Чи можна в Кореї пропонувати вбудовані покупки і зовнішню оплату в одному застосунку?

Ні. Entitlement не може співіснувати з вбудованими покупками Apple в одному застосунку. Потрібен окремий бінарник, який поширюється лише в Кореї.

Чи можна додати зовнішню оплату до вже опублікованого застосунку?

Ні. Entitlement надається лише bundle ID, який ніколи не публікувався. Якщо новий застосунок є версією твого поточного, що продається в Кореї через вбудовані покупки, прибери поточний із корейської вітрини до схвалення нового.

Чи діє Small Business Program для корейської зовнішньої оплати?

Сторінка Apple про Корею не наводить жодної зниженої ставки. 15% Small Business Program стосуються вбудованих покупок. Саме тому вбудовані покупки обходяться невеликому розробнику дешевше.

Чи може іноземний розробник використовувати зовнішню оплату в Кореї?

Сторінка Apple не вимагає бути зареєстрованим у Кореї: вона стосується застосунків, що поширюються лише в Кореї. Але ти стаєш відповідальним за корейські податки з цих продажів, тоді як із вбудованими покупками Apple сплачує їх за тебе, якщо ти нерезидент. Також запитай провайдера, чи приймає він продавця без компанії в Кореї.

Який ключ Info.plist потрібен для зовнішньої оплати в Кореї?

SKExternalPurchase, масив рядків із кодом Південної Кореї, kr згідно з довідкою щодо ключа. Entitlement називається com.apple.developer.storekit.external-purchase, це булеве значення true.

Чи вже покарав корейський регулятор Apple?

Станом на 27 жовтня 2026 року, дату цієї перевірки, ні: рішення не ухвалено. За даними SBS Biz, остаточне голосування тоді очікувалося 28 жовтня. Перечитай корейську пресу і сторінку Apple, перш ніж вирішувати.

Джерела

• Distributing apps using a third-party payment provider in South Korea, Apple Developer: умови, провайдери, налаштування, комісія, звіти. Корейська версія.
• App Store Small Business Program, Apple Developer: комісія 15% та її умови.
• Apple Developer Program License Agreement, додаток 2, розділ 3.4, а також додатки B і C до нього: база розрахунку комісії та збір податків.
• SKExternalPurchase, External Purchase і presentNoticeSheet(), документація Apple.
• Конфігурація застосунку, варіанти застосунку і Expo Modules API, документація Expo.
• SBS Biz, 12 жовтня 2026 і 27 жовтня 2026, та CBS Nocut News, 27 жовтня 2026: графік і суть рішення регулятора. Digital Daily, 27 вересня 2025: створення 방송미디어통신위원회.

Як брати за застосунок правильну ціну

Перш ніж обирати спосіб оплати, пройди безкоштовну діагностику: вона покаже, що насправді гальмує твій проєкт, і надішле тобі мій чекліст проти відмов Apple.

iOS Kit містить стартовий код моїх застосунків з онбордингом, paywall і підписками, уже реалізованими на вбудованих покупках, а також шлях із чотирьох кроків до App Store, який проходиш у своєму темпі. Повне налаштування підписки, від продуктів в App Store Connect до paywall, детально описане в статті підписка in-app на iOS.