BLIK a wytyczne App Store i Google Play — kiedy płatność zewnętrzna jest dozwolona

To jeden z najczęstszych powodów odrzucenia aktualizacji polskich aplikacji: zespół wdraża BLIK, wysyła build do App Store i dostaje odmowę z powołaniem na zasady dotyczące zakupów w aplikacji. Zwykle nie dlatego, że BLIK jest zakazany — bo nie jest — tylko dlatego, że to, co aplikacja sprzedaje, kwalifikuje się do mechanizmu zakupowego sklepu, a nie do zewnętrznej bramki.

Ten artykuł tłumaczy, gdzie dokładnie przebiega granica, jak wyglądają zasady po stronie Apple i Google, co zmieniły ostatnie lata regulacji oraz jak przygotować wdrożenie, żeby nie stracić tygodnia na odwołania.

Zasady sklepów i ich interpretacje zmieniają się szybciej niż większość dokumentacji technicznej — zwłaszcza od czasu unijnego aktu o rynkach cyfrowych (DMA) i sporów sądowych w USA. Opisujemy stan na połowę 2026 r. i wskazujemy mechanikę, która jest trwała; konkretne brzmienie wytycznych przed wdrożeniem sprawdź w aktualnych dokumentach App Store Review Guidelines i Google Play Payments Policy.

Reguła, od której wszystko zależy

Pytanie nie brzmi „czy mogę użyć BLIK-a", tylko: czy to, co użytkownik kupuje, jest konsumowane wewnątrz aplikacji jako treść lub funkcja cyfrowa?

• TAK — treści i funkcje cyfrowe w aplikacji. Subskrypcja premium, odblokowanie poziomu, waluta w grze, usunięcie reklam, dodatkowe filtry, pakiet treści. Tu sklepy wymagają swoich mechanizmów (In-App Purchase u Apple, Google Play Billing u Google). BLIK odpada.
• NIE — towary i usługi ze świata rzeczywistego. Jedzenie z dostawą, bilet na wydarzenie, przejazd, nocleg, produkt fizyczny, wizyta u lekarza, usługa wykonywana poza aplikacją. Tu własna bramka płatnicza jest dozwolona, a często wręcz oczekiwana — sklepy nie chcą pośredniczyć w takich transakcjach.

Ta sama reguła obowiązuje w obu sklepach. Różnice dotyczą wyjątków i sposobu, w jaki wolno o alternatywnej płatności informować użytkownika.

Przykłady po obu stronach granicy

Ostatnie dwa wiersze dobrze pokazują, gdzie zaczyna się szara strefa: ta sama branża, inny sposób dostarczenia usługi, inna zasada.

Apple — na co powołuje się recenzent

W praktyce odrzucenia opierają się na kilku punktach App Store Review Guidelines:

• Zakupy treści cyfrowych muszą przechodzić przez In-App Purchase. To reguła bazowa.
• Towary i usługi ze świata rzeczywistego rozliczasz poza IAP. Apple wprost wskazuje, że jego mechanizm nie służy do takich transakcji.
• Aplikacje typu „reader" (czytniki treści kupionych gdzie indziej — prasa, książki, wideo, muzyka, chmura) mają osobny tryb, który przy spełnieniu warunków pozwala na odesłanie użytkownika do zakupu na zewnątrz.
• Usługi wielo­platformowe — treść kupioną poza aplikacją użytkownik może w niej konsumować, o ile aplikacja nie zachęca do zakupu poza sklepem w sposób sprzeczny z wytycznymi.
• Usługi świadczone przez człowieka w czasie rzeczywistym, jeden na jednego — traktowane inaczej niż nagrane treści cyfrowe.

Dwie rzeczy warto podkreślić, bo wracają w każdym odrzuceniu:

1. Sam link do strony z zakupem bywa problemem, nie tylko sama płatność. Historycznie Apple traktowało odesłanie użytkownika do zewnętrznego zakupu treści cyfrowych jako naruszenie, nawet jeśli w aplikacji nic się nie działo. Ten obszar zmieniają obecnie regulacje i orzeczenia — w UE w ramach DMA, w USA w wyniku sporu sądowego — ale zasady i towarzyszące im opłaty różnią się między regionami. Zanim oprzesz model biznesowy na linku wychodzącym, sprawdź warunki obowiązujące dla Twojego regionu i formalności (osobne uprawnienia, wymagane komunikaty, ewentualne opłaty).
2. Nie ma znaczenia, jak zgrabnie to ukryjesz. Ukryty webview z BLIK-iem za treść cyfrową to nie luka w regulaminie, tylko ryzyko usunięcia aplikacji ze sklepu.

Google Play — podobna zasada, inne wyjątki

Google Play stosuje analogiczny podział: treści cyfrowe przez Google Play Billing, towary i usługi ze świata rzeczywistego przez własną bramkę. Różnice, o których warto wiedzieć:

• Alternatywne systemy płatności. W Europejskim Obszarze Gospodarczym Google udostępnia tryby, w których deweloper może zaoferować własny system płatności obok rozliczeń Google — zwykle z niższą, ale nadal obowiązującą prowizją. To nie jest „darmowe obejście", tylko inny model rozliczeń, wymagający zgłoszenia i spełnienia warunków.
• Prowizja dla mniejszych deweloperów jest niższa niż stawka podstawowa, co realnie zmienia rachunek przy małej skali.
• Egzekwowanie bywa mniej rygorystyczne niż u Apple, ale to nie oznacza przyzwolenia — konsekwencją naruszenia jest usunięcie aplikacji, a nie tylko odrzucenie aktualizacji.

Praktyczny wniosek: planuj build pod bardziej restrykcyjny sklep. Jeśli przejdzie w App Store, przejdzie i w Google Play.

Przypadki graniczne, które najczęściej sprawiają problem

• Produkt hybrydowy. Aplikacja sprzedaje jednocześnie usługę fizyczną i subskrypcję cyfrową (np. rezerwacje bez opłat + abonament na dodatkowe funkcje). Trzeba rozdzielić ścieżki: abonament przez mechanizm sklepu, rezerwacje przez BLIK. Wspólny koszyk to prosta droga do odrzucenia.
• Doładowanie portfela w aplikacji. Jeżeli środki służą do zakupu treści cyfrowych, sklep potraktuje to jak zakup cyfrowy. Jeśli do opłacania usług fizycznych — zwykle nie.
• Aplikacje B2B i narzędzia dla firm. Sprzedaż licencji przedsiębiorstwom bywa objęta osobnymi zasadami; aplikacja dostępna publicznie w sklepie i tak podlega ogólnym regułom.
• Marketplace usług. Prowizja od transakcji między użytkownikami zwykle nie wymaga mechanizmu sklepu, o ile usługa jest wykonywana w świecie rzeczywistym.
• Kursy i treningi. Nagrania — cyfrowe. Zajęcia na żywo, indywidualne — zwykle nie. Grupowe transmisje bywają sporne.
• Darowizny. Dopuszczalne poza mechanizmem sklepu, ale przy spełnieniu warunków (np. brak świadczenia zwrotnego dla darczyńcy).

Jeśli Twój przypadek jest graniczny, przyjmij prostą zasadę: zaprojektuj model płatności zanim zbudujesz UI, a nie odwrotnie. Zmiana modelu monetyzacji po zbudowaniu checkoutu to zwykle tydzień pracy do wyrzucenia.

Jak przygotować wdrożenie, żeby nie dostać odrzucenia

1. Zaklasyfikuj każdy typ zakupu w aplikacji — cyfrowy czy rzeczywisty. Zrób z tego tabelę i dołącz do dokumentacji projektu.
2. Rozdziel ścieżki zakupowe — osobne ekrany, osobne przyciski, brak wspólnego koszyka dla obu światów.
3. Nie zachęcaj do zakupu poza aplikacją, jeśli dotyczy treści cyfrowych, a nie masz na to formalnej zgody dla swojego regionu.
4. Opisz model w notatkach dla recenzenta — wyjaśnij, czym jest BLIK i że rozliczasz nim usługę wykonywaną poza aplikacją. To skraca rozmowę z App Review.
5. Dodaj konto testowe i instrukcję — recenzent musi móc przejść ścieżkę zakupu bez polskiej karty i bez aplikacji bankowej.
6. Przygotuj argumentację na wypadek odrzucenia — odwołanie z rzeczowym wyjaśnieniem, czego dotyczy transakcja, jest częściej skuteczne, niż się wydaje.
7. Sprawdź aktualne brzmienie wytycznych przed każdą większą zmianą monetyzacji — one naprawdę się zmieniają.

Co zrobić po odrzuceniu buildu

• Przeczytaj, na który punkt powołuje się recenzent — to determinuje strategię, bo część odrzuceń wynika z nieporozumienia co do charakteru usługi.
• Odpowiedz w Resolution Center rzeczowo: co dokładnie kupuje użytkownik, gdzie i kiedy usługa jest wykonywana.
• Załącz materiał dowodowy — zrzuty ekranu ścieżki, opis procesu, ewentualnie krótkie nagranie.
• Jeśli klasyfikacja jest jednoznacznie po stronie treści cyfrowych — nie walcz, przeprojektuj monetyzację. Koszt sporu jest wyższy niż koszt zmiany.

Najczęstsze pytania

Czy BLIK jest dozwolony w aplikacji na iOS? Tak, o ile rozliczasz nim towary lub usługi ze świata rzeczywistego. Za treści cyfrowe konsumowane w aplikacji obowiązuje mechanizm zakupowy App Store.

Czy mogę dać w aplikacji link do strony, gdzie użytkownik zapłaci BLIK-iem za subskrypcję? To najbardziej zmienny fragment zasad. Historycznie takie odesłanie było zabronione; regulacje (DMA w UE) i orzeczenia w USA otwierają tę możliwość, ale w ściśle określonych warunkach, często z osobnym uprawnieniem i opłatami. Przed wdrożeniem sprawdź aktualne zasady dla swojego regionu.

Czy sklep pobiera prowizję od płatności BLIK za produkt fizyczny? Nie. Transakcja rozliczana zewnętrzną bramką za towar lub usługę ze świata rzeczywistego nie jest objęta prowizją sklepu — płacisz wyłącznie prowizję operatora płatności. Porównanie stawek znajdziesz w artykule ile kosztuje wdrożenie płatności BLIK w aplikacji.

Aplikacja sprzedaje i usługi fizyczne, i subskrypcję cyfrową — co robić? Rozdzielić ścieżki i mechanizmy: subskrypcja przez sklep, usługi przez BLIK. Wspólny koszyk jest ryzykowny.

Czy Google Play jest bardziej liberalny? Ma więcej wyjątków (m.in. tryby alternatywnych płatności w EOG), ale ta sama zasada podstawowa obowiązuje. Buduj pod wymagania Apple, a spełnisz też wymagania Google.

Podsumowanie

BLIK w aplikacji mobilnej jest w pełni dozwolony — o ile rozliczasz nim to, co sklepy uznają za świat rzeczywisty. Cała trudność sprowadza się do poprawnej klasyfikacji tego, co sprzedajesz, i do rozdzielenia ścieżek zakupowych, gdy Twój produkt łączy oba światy. Zespoły, które robią tę analizę przed projektowaniem checkoutu, publikują bez przeszkód; te, które robią ją po pierwszym odrzuceniu, tracą tydzień i przepisują ekran płatności.

W Mobilesoft wdrażamy płatności w aplikacjach mobilnych i przeprowadzamy klientów przez wymagania sklepów — od klasyfikacji modelu monetyzacji po publikację. Jeśli nie masz pewności, po której stronie granicy leży Twój produkt, napisz do nas — pomożemy to rozstrzygnąć przed rozpoczęciem prac. Techniczną stronę wdrożenia opisujemy w artykule integracja BLIK w aplikacji mobilnej.