Чому платіжні додатки, створені на основі «вайб-кодингу», відхиляють в App Store

Платіжні додатки, створені на основі вайб-кодингу, відхиляють в App Store частіше, ніж будь-що інше в черзі на перевірку, і причини зазвичай взагалі не пов'язані з якістю коду. Додаток, створений на вайбі — тобто такий, який ви побудували, просто описавши свої побажання ШІ-асистенту, і випустили те, що він написав — зовні може виглядати невідрізнимо від професійної роботи. Проте модератори Apple не оцінюють красу коду. Вони перевіряють, хто подав додаток, який платіжний механізм обробляє певний тип товарів, чи були окремо схвалені апаратні дозволи та чи може модератор здійснити реальну транзакцію. Це саме ті речі, які ШІ-асистент згенерувати не може.

Це стіна, в яку впираються всі після створення кастомної POS-системи за допомогою моделі ШІ: код з'являється за один день, але перенесення його на iPhone як реального додатка для оплати — це процес відповідності вимогам, а не завдання з програмування.

Чи направив ваш ШІ платежі через неправильну систему?

Найпоширеніша причина відхилення — використання неправильного платіжного механізму для товарів, що продаються, і ШІ-асистенти надзвичайно часто припускаються цієї помилки. Правила перевірки додатків App Store проводять жорстку межу. Цифровий контент і послуги, що споживаються всередині додатка, повинні використовувати вбудовані покупки Apple відповідно до Правила 3.1.1. Фізичні товари та послуги в реальному світі — кава, стрижка, доставка замовлення — мають робити протилежне відповідно до Правила 3.1.5(a): вони взагалі не можуть використовувати вбудовані покупки Apple і вимагають зовнішнього способу оплати.

Модель для кодингу просто відтворює той шаблон платежів, який переважав у її навчальних даних — шаблонний код вбудованих покупок із посібників із підписок або веб-сценарій оплати з прикладів електронної комерції — навіть не запитуючи, що саме ви продаєте. Попросіть її створити «додаток, який приймає платежі», і ви отримаєте один із двох варіантів, вибраний на основі статистики, а не правил Apple. Ці правила також відрізняються залежно від регіону: після судового рішення у справі Epic у 2025 році додатки в американському магазині можуть посилатися на зовнішні варіанти купівлі цифрових товарів, але це виключення діє лише в США. Додаток, що розповсюджується по всьому світу, все одно має відповідати суворішим правилам у всіх інших країнах.

Чи маєте ви взагалі право подавати платіжний додаток?

Apple вимагає, щоб додатки, які займаються управлінням фінансами або фінансовими послугами, подавалися безпосередньо установою, яка фактично надає ці послуги, з наявністю необхідних ліцензій у кожному регіоні, де доступний додаток — це Правило 3.2.1. Окремий розробник, який випускає створений ШІ платіжний додаток, не є ліцензованою фінансовою установою, як і агентство, що подає його для клієнта. Пропозиція додатка в країні, де немає відповідної ліцензії на переказ коштів, призведе до такого ж відхилення, просто з іншою позначкою.

Модератори Apple не оцінюють, наскільки хороша ваша програма відповідності вимогам; вони перевіряють, чи правильна юридична особа подала додаток, і відхиляють його, якщо це не так. Жоден промпт цього не виправить.

Чому Tap to Pay — це окремий процес затвердження?

Для прийому безконтактних карток на iPhone потрібен дозвіл Tap to Pay on iPhone — це окрема заявка до Apple, незалежна від модерації додатка, яка надається юридичній особі, а не кодовій базі. Дозвіл на розробку зазвичай затверджується за день-два. Дозвіл на публікацію проходить через операційну команду Apple, зазвичай займає від одного до двох тижнів і вимагає роботи з підтримуваним постачальником платіжних послуг. ШІ-асистент із радістю напише код для Tap to Pay, навіть не згадавши про це; подайте додаток до отримання дозволу, і він буде відхилений.

Прийом карток на місці також тягне за собою вимоги, які не належать Apple: сертифіковане термінальне обладнання, правила EMV та відповідність вимогам PCI для всього, що торкається даних карток. Нічого з цього не з'явиться з моделі, яка просто пише код на Swift.

Чи може модератор насправді завершити транзакцію?

Правило 2.1 «Повнота додатка» тихо відхиляє більше платіжних додатків, ніж безпосередньо правила платежів. Модератори повинні мати можливість протестувати додаток повністю, включаючи процес оплати. Платіжний додаток зазвичай вимагає наявності облікового запису продавця, верифікації особи, іноді банківського рахунку — речей, які модератор не може створити під час перевірки. Створені на вайбі додатки постійно зазнають невдачі на цьому етапі, оскільки розробник часто сам ніколи не підключав реальний обліковий запис продавця; додаток тестувався лише на тестових даних, які ШІ згенерував разом із кодом. Без робочого демо-акаунта та можливості провести тестову транзакцію додаток відхиляють як незавершений, а кожна повторна подача коштує ще одного циклу очікування.

То що ж у підсумку потрапляє в реліз?

Найскладнішою частиною ніколи не був код. ШІ-асистент може створити робочий інтерфейс оплати за один день, але дистрибуція в App Store — це смуга перешкод із дозволів, ліцензування та правил модерації, які повністю лежать поза межами можливостей будь-якого промпту. Демо-версія працює, але інфраструктури під нею немає.

Для продавця, який реалізує фізичні товари, практичний висновок набагато простіший: не ставайте в цю чергу. Вашому бізнесу потрібна робоча оплата, а не власна сторінка в App Store — витрати на ліцензування, сертифікацію обладнання та проходження модерації мають сенс лише для компаній, чиїм продуктом є саме платіжне програмне забезпечення. Працюйте на POS-платформі, яка вже взяла ці витрати на себе (Final побудовано саме так — платежі через Final Pay із сертифікованим термінальним обладнанням, без необхідності публікувати власний додаток), а гроші, які могли піти на цикли модерації, інвестуйте в речі, що приносять дохід, наприклад, у швидший процес оплати та нижчі ефективні комісії за картками.

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