BLIK and the App Store and Google Play guidelines — when external payments are allowed

This is one of the most common reasons Polish app updates get rejected: a team implements BLIK, submits the build to the App Store and receives a refusal citing the rules on in-app purchases. Usually not because BLIK is prohibited — it is not — but because what the app is selling qualifies for the store's purchase mechanism rather than an external gateway.

This article explains exactly where the boundary runs, what the rules look like on Apple's and Google's side, what recent years of regulation changed, and how to prepare an implementation so you do not lose a week to appeals.

Store rules and their interpretations change faster than most technical documentation — particularly since the EU's Digital Markets Act (DMA) and the litigation in the United States. We describe the position as at mid-2026 and point to the mechanics that are durable; check the exact wording in the current App Store Review Guidelines and Google Play Payments Policy before implementing.

The rule everything depends on

The question is not "can I use BLIK" but: is what the user is buying consumed inside the app as digital content or functionality?

• YES — digital content and features in the app. A premium subscription, unlocking a level, in-game currency, removing ads, extra filters, a content pack. Here the stores require their own mechanisms (In-App Purchase at Apple, Google Play Billing at Google). BLIK is out.
• NO — real-world goods and services. Food delivery, an event ticket, a ride, accommodation, a physical product, a doctor's appointment, a service performed outside the app. Here your own payment gateway is allowed, and often expected — the stores do not want to mediate such transactions.

The same rule applies in both stores. The differences concern the exceptions and the way you are allowed to tell users about an alternative payment.

Examples on both sides of the boundary

The last two rows illustrate nicely where the grey zone begins: the same industry, a different way of delivering the service, a different rule.

Apple — what the reviewer cites

In practice, rejections rest on a few points of the App Store Review Guidelines:

• Purchases of digital content must go through In-App Purchase. That is the base rule.
• Real-world goods and services are settled outside IAP. Apple states explicitly that its mechanism is not for such transactions.
• "Reader" apps (readers of content bought elsewhere — press, books, video, music, cloud) have a separate track that, on meeting the conditions, allows sending the user to buy externally.
• Multiplatform services — content bought outside the app may be consumed within it, provided the app does not encourage purchase outside the store in ways the guidelines prohibit.
• Real-time person-to-person services delivered by a human are treated differently from recorded digital content.

Two things are worth underlining, because they recur in every rejection:

1. The link itself can be the problem, not just the payment. Historically Apple treated sending users to an external purchase of digital content as a violation, even if nothing happened inside the app. That area is now being reshaped by regulation and court rulings — in the EU under the DMA, in the US as a result of litigation — but the rules and the fees attached to them differ by region. Before you build a business model on an outbound link, check the terms in force for your region and the formalities (separate entitlements, mandated disclosures, possible fees).
2. It does not matter how neatly you hide it. A concealed webview with BLIK behind digital content is not a loophole in the terms but a risk of removal from the store.

Google Play — a similar rule, different exceptions

Google Play applies an analogous split: digital content through Google Play Billing, real-world goods and services through your own gateway. The differences worth knowing:

• Alternative payment systems. In the European Economic Area Google offers modes in which a developer may provide their own payment system alongside Google's billing — usually with a lower, but still applicable, commission. This is not a "free workaround" but a different settlement model requiring enrolment and compliance with conditions.
• The commission for smaller developers is lower than the headline rate, which genuinely changes the maths at small scale.
• Enforcement tends to be less rigorous than Apple's, but that is not permission — the consequence of a breach is removal of the app, not merely a rejected update.

The practical conclusion: plan the build for the stricter store. If it passes in the App Store, it will pass on Google Play.

Borderline cases that cause the most trouble

• A hybrid product. The app sells a physical service and a digital subscription at the same time (e.g. free bookings plus a subscription for extra features). The paths have to be separated: the subscription through the store mechanism, the bookings through BLIK. A shared cart is a straight road to rejection.
• Topping up a wallet in the app. If the funds are used to buy digital content, the store will treat it as a digital purchase. If they pay for physical services — usually not.
• B2B apps and business tools. Selling licences to enterprises is sometimes covered by separate rules; an app publicly available in the store is nonetheless subject to the general ones.
• Service marketplaces. A commission on transactions between users usually does not require the store mechanism, provided the service is performed in the real world.
• Courses and training. Recordings — digital. Live, one-to-one sessions — usually not. Group broadcasts can be contentious.
• Donations. Permitted outside the store mechanism, but subject to conditions (e.g. no benefit returned to the donor).

If your case is borderline, adopt a simple rule: design the payment model before you build the UI, not the other way round. Changing the monetisation model after the checkout is built usually means a week of work thrown away.

How to prepare an implementation and avoid rejection

1. Classify every purchase type in the app — digital or real-world. Turn it into a table and attach it to the project documentation.
2. Separate the purchase paths — separate screens, separate buttons, no shared cart across the two worlds.
3. Do not encourage purchases outside the app where digital content is concerned, unless you hold formal permission for your region.
4. Describe the model in the notes for the reviewer — explain what BLIK is and that you are settling a service performed outside the app. It shortens the conversation with App Review.
5. Provide a test account and instructions — the reviewer has to be able to walk the purchase path without a Polish card and without a banking app.
6. Prepare your argument in case of rejection — an appeal with a factual explanation of what the transaction covers succeeds more often than you might expect.
7. Check the current wording of the guidelines before every major monetisation change — they really do change.

What to do after a build is rejected

• Read which point the reviewer cites — that determines your strategy, since some rejections stem from a misunderstanding of what the service is.
• Reply in the Resolution Center factually: what exactly the user is buying, and where and when the service is performed.
• Attach evidence — screenshots of the path, a description of the process, possibly a short recording.
• If the classification clearly falls on the digital content side — do not fight it, redesign the monetisation. The cost of the dispute exceeds the cost of the change.

Frequently asked questions

Is BLIK allowed in an iOS app? Yes, provided you use it to settle real-world goods or services. Digital content consumed in the app is subject to the App Store purchase mechanism.

Can I put a link in the app to a page where the user pays for a subscription with BLIK? This is the most volatile part of the rules. Historically such referrals were prohibited; regulation (the DMA in the EU) and rulings in the US are opening the possibility, but under strictly defined conditions, often with a separate entitlement and fees. Check the current rules for your region before implementing.

Does the store take a commission on a BLIK payment for a physical product? No. A transaction settled through an external gateway for real-world goods or services is not subject to a store commission — you pay only the payment operator's commission. You will find a comparison of rates in how much BLIK payment integration costs.

The app sells both physical services and a digital subscription — what now? Separate the paths and the mechanisms: the subscription through the store, the services through BLIK. A shared cart is risky.

Is Google Play more liberal? It has more exceptions (including alternative payment modes in the EEA), but the same base rule applies. Build for Apple's requirements and you will also satisfy Google's.

Summary

BLIK in a mobile app is entirely permitted — as long as you use it to settle what the stores consider the real world. The whole difficulty comes down to correctly classifying what you sell and separating the purchase paths when your product spans both worlds. Teams that do this analysis before designing the checkout publish without obstacles; those that do it after the first rejection lose a week and rewrite the payment screen.

At Mobilesoft we implement payments in mobile apps and guide clients through store requirements — from classifying the monetisation model to publication. If you are not sure which side of the boundary your product falls on, write to us — we will help settle it before work begins. We describe the technical side of implementation in the article BLIK integration in a mobile app.