Payments in a Polish mobile app: BLIK, Przelewy24, Stripe and Apple Pay — what to choose and what the App Store demands

Choosing a payment method for a mobile app looks like a marketing decision on the surface ("let's add BLIK, Poles like it"), while in practice it is a legal and technical decision that can block your App Store release or take 30% of your revenue. Before you choose between BLIK, Przelewy24, Stripe and Apple Pay, you have to answer one question: what exactly are you selling in the app? Everything else follows from that answer.

This article walks you through the decision step by step — from the most important App Store rule, through the characteristics of each method, to a ready decision matrix and an implementation checklist.

The rule everything depends on: digital content vs the real world

Apple and Google split what you sell into two categories — and it is that split, not your preferences, that determines the permitted payment method.

1. Digital content and services consumed in the app — premium subscriptions, feature unlocks, in-game currency, online courses, e-books read in the app, AI credits. Here Apple requires the use of its In-App Purchase (IAP) mechanism, and Google requires Google Play Billing. In this case you may not wire in BLIK or Stripe as the main purchase path. The platform commission is normally 30% (or 15% for small publishers in the Small Business programme and for subscriptions after the first year).

2. Physical goods and services delivered in the real world — a food order, e-commerce purchases, a train ticket, a taxi ride, a hotel booking, a parking fee, a top-up of a bank account. Here it is the other way round: Apple and Google prohibit the use of IAP and require an external payment gateway. This is where BLIK, Przelewy24, Stripe, Apple Pay and Google Pay come in — and where you pay the platform no transaction commission at all.

The most common beginner mistake: trying to sell a digital subscription through Stripe to avoid Apple's commission. That is an almost certain rejection in review (App Store Review guideline 3.1.1). The reverse mistake — trying to sell pizza through IAP — will also be rejected.

If you sell physical goods or real-world services, the rest of this article applies to you in full. If you sell digital content, skip to the section on App Store IAP — that is where we explain what changed thanks to the EU's DMA and the court rulings in the US.

BLIK — a must-have for Polish users

In Poland BLIK is the de facto standard for mobile payments. The user confirms a transaction with a six-digit code generated in their banking app (or — increasingly — with a single tap using codeless "one-click" BLIK). For a Polish customer, the absence of BLIK at checkout is a genuine reason to abandon the purchase.

How to integrate it in practice. BLIK is rarely integrated directly with the scheme (Polski Standard Płatności). It is far more common and cheaper to plug it in through an aggregator — Przelewy24, Autopay (formerly Blue Media), Tpay, PayU or Stripe — which exposes BLIK as one of the methods in its API. That way a single integration gives you BLIK, cards, instant transfers and Apple/Google Pay all at once.

What to know technically:

• BLIK works asynchronously — after the code is entered, the transaction status reaches you via webhook, not synchronously in the response. Your backend has to handle confirmation "in the background" and only then release the goods or service.
• Recurring payments (subscriptions) and codeless BLIK require prior authorisation of a so-called alias — a separate flow that has to be planned for.
• BLIK is a Poland-only method — it will not work for a customer from abroad. If you are also targeting markets outside Poland, treat it as one of several methods rather than the only one.

Przelewy24 — the Polish all-in-one aggregator

Przelewy24 (P24) is the most popular payment aggregator in Poland. Its strength is locality: one API gives you BLIK, pay-by-link to practically every Polish bank, cards, Apple Pay, Google Pay and deferred payments. For an app aimed mainly at Polish customers, it is the fastest route to a complete set of methods.

Strengths:

• Full coverage of the Polish market (banks, BLIK) — hard for foreign players to match.
• Polish support, a Polish contract, settlement in PLN, familiarity with local realities (invoices, SAF-T reporting).
• A relatively simple REST + webhook integration; SDKs and ready-made modules available.

What to watch out for:

• It is a solution optimised for Poland — if you plan international expansion, you will quickly hit its limits (currencies, local methods in other countries).
• The settlement model is sometimes based on periodic payouts rather than instant ones — worth checking against your cash flow.
• The compliance burden (terms, information duties) sits with you as the merchant.

Alternatives in the same league: Autopay, Tpay, PayU — choosing between them is mainly a matter of pricing, support quality and API details. It is worth collecting offers from two or three of them.

Stripe — when you think globally and care about good APIs

Stripe is the choice when you want the best developer experience (documentation, mobile SDKs, ready UI components such as the Payment Sheet) and international reach — dozens of currencies and local methods.

When Stripe makes sense:

• You sell abroad, or plan to within 12–24 months.
• You want one provider covering cards, Apple Pay, Google Pay and selected local methods, including BLIK (Stripe supports BLIK as a Polish payment method) and Przelewy24 (as a pay-by-link method).
• You value a polished SDK (Stripe iOS/Android, React Native, Flutter) and a fast Payment Sheet rollout instead of building your own UI.

What to watch out for:

• Stripe's coverage of Polish banks is narrower and delivered indirectly — for a Poland-only app, a domestic aggregator will often come out better and cheaper.
• Settlement, support and part of the documentation are in English; tax matters (invoices, VAT) have to be closed out on your side.
• The pricing is transparent, but at high volumes a local aggregator can often offer a lower per-transaction rate.

Apple Pay and Google Pay — these are methods, not a separate provider

Here is the most common misunderstanding: Apple Pay is not the same thing as Apple In-App Purchase. Apple Pay is a convenient way to authorise a card payment (with a fingerprint or face) that plugs into your external gateway — Stripe, Przelewy24, Autopay and so on. You use it to pay for physical goods and real-world services, with no Apple commission. IAP is an entirely different mechanism, mandatory for digital content and subject to commission.

In practice you do not choose "Apple Pay instead of Stripe" — you enable Apple Pay and Google Pay as additional buttons within the aggregator you already use. They deliver the highest conversion rate (one tap, no card number to type), so it is worth having them enabled everywhere you can. Apple Pay requires a one-off certificate configuration (merchant ID) in Apple Developer.

App Store IAP — what exactly it enforces and what the DMA changed

If you sell digital content, IAP applies to you — but the rules landscape has shifted in recent years and it is worth knowing where things stand in 2026.

The base rule (still in force globally): a purchase of digital content consumed in the app has to go through IAP / Google Play Billing, with a 30% commission (or 15% under the small business programme and for subscriptions continuing beyond a year).

European Union — the Digital Markets Act (DMA). Since 2024, as a result of the DMA, Apple has had to open the system in the EU: developers may offer alternative payment methods in the app and direct users to an external purchase page (link-out / steering). In exchange Apple introduced new fee models (including reduced commissions and separate distribution/technology fees) that in many scenarios do not bring the cost down to zero. The practical conclusion: in the EU you now have a choice, but the profitability of bypassing IAP has to be calculated individually for your model and volume.

USA — link-out after the Epic v. Apple dispute. In the United States, following years of litigation, Apple was compelled to allow links to external payment methods in apps, without taking a commission on purchases completed outside the App Store. That genuinely changed the calculation for the US market.

What this means for you in 2026: the rules are no longer uniform globally — they differ by region (EU, US, rest of the world) and get updated. Do not plan digital monetisation by feel. Before deciding between IAP and link-out, run the actual numbers for your markets, because your product margin depends on them.

The decision matrix — where to start

Always start with the question of what kind of good you are selling, and then the market:

A mixed model is entirely permitted and common — the key is that each purchase type follows the right path. That is the most frequent source of rejections: a single screen that mixes both logics.

Implementation checklist

• Classify every product/plan as either "digital, in-app" or "real goods/service" — that determines the path.
• For the external path: pick an aggregator to match your market (PL → Przelewy24/Autopay/PayU; global → Stripe) and enable BLIK plus Apple/Google Pay.
• Design handling of webhooks and asynchronous statuses (BLIK, pay-by-link) — never release goods before confirmation.
• For recurring subscriptions, plan a separate flow (BLIK alias / recurring payments).
• For digital content: configure IAP/Play Billing and calculate the economics of link-out per region (EU/US).
• Configure Apple Pay (merchant ID + certificate) and Google Pay in the provider's console.
• Close out compliance: payment terms, information duties, invoices/VAT, GDPR for transaction data.
• Test the flows in a sandbox environment before submitting to App Store / Google Play review.

Summary

Choosing payments for a mobile app is not a ranking of "which gateway is best" but a sequence of decisions: first the type of good (digital vs real), which settles the permitted path and whether you pay the platform a commission; then the market (Poland vs global), which points you to a Polish aggregator or Stripe; and finally the set of methods — BLIK as mandatory for Polish customers, and Apple Pay and Google Pay for the highest conversion. The App Store rules around digital content are now regional and still changing (the DMA in the EU, link-out in the US), so always run digital monetisation through hard numbers for your own markets.

Planning payments for a new app, or want to tidy up what you already have so that it passes review and stops handing over commission unnecessarily? Let's talk about your project — at Mobilesoft we implement mobile payments from both the technical and product side, taking App Store and Google Play requirements into account.