BLIK integration in a mobile app — how it works and what to choose

In Poland BLIK is the number one payment method in the mobile channel. If you are building an app in which users buy anything at all, the question is not "whether BLIK" but "how to integrate it and through whom". And it is that second question where most teams come unstuck, because a myth circulates online about direct BLIK integration — something that is simply not available to the vast majority of companies.

This article explains how BLIK works under the hood, what the payment flow looks like, how direct integration differs from integration through an operator, what you actually get in a BLIK API, and which BLIK variants are worth implementing in a mobile app.

How BLIK works — who is who in this arrangement

A BLIK transaction involves four participants, not two:

The key conclusion: your app never talks to the BLIK scheme directly. It talks to the payment operator's API, and the operator passes the transaction onwards.

The BLIK payment flow step by step

A classic six-digit code payment looks like this:

1. The user selects BLIK in your app and moves to the payment screen.
2. They open their banking app and generate a six-digit code, valid for about two minutes.
3. They enter the code in your app. You send it from your backend to the operator's API together with the amount, currency and order identifier.
4. The operator passes the transaction to PSP, which routes it to the bank that issued the code.
5. The bank sends a push notification to its banking app: the amount, the payee's name and a request to confirm with a PIN or biometrics.
6. The user confirms. The bank authorises the debit and the information travels back down the chain: bank → PSP → operator → your backend (webhook).
7. Your backend verifies the status, marks the order as paid, and only then does the app show success.

Two things in this flow determine whether the implementation is correct:

• The server confirms the payment, not the phone. The mobile app can only poll for status. Order fulfilment must always rest on the webhook or on verification made by the backend.
• The "pending" state lasts a real amount of time. Between entering the code and confirming it, a dozen or several dozen seconds pass while the user switches to another app. Your screen has to survive that: retain state, handle the return, the timeout, a rejection and no reaction at all.

Direct BLIK integration or through an operator?

This question comes up in almost every project, so let us answer it plainly.

Direct integration with the BLIK scheme means connecting to the infrastructure of Polski Standard Płatności as one of its participants. In practice that route is open to banks and licensed acquirers — entities with the appropriate authorisation, settlement infrastructure, compliance capability and full complaints handling. An ordinary store or app will not be granted such access, and even if it could be, the cost of licensing, certification and maintenance would be incomparably higher than the commissions paid to an operator.

Integration through a payment operator is the route 99% of companies actually take. You sign an agreement with an acquirer, go through verification (company KYC, a description of your business), receive API keys and a sandbox, and implement.

So the practical question is not "direct or through an operator" but "through which operator".

What to compare when choosing an operator

• The commission for BLIK and for the other methods — BLIK is often cheaper than cards, but what counts is the whole basket of methods you need.
• The settlement model — payout cycle (D+1, D+2, weekly), payout threshold, currencies.
• API and SDK quality — documentation, sandbox, libraries, signed webhooks, idempotency.
• Support for BLIK one-click and recurring payments — not every operator offers the full set.
• Support for mobile apps — a native SDK versus a web form only.
• Complaints and refunds procedure — who handles them, in what time, through which channel.
• Stability and a status page — a gateway outage is your outage in the customer's eyes.

In brief, this is how the market looks from a product team's perspective:

The final decision almost always comes down to three things: the commission at your volume, the availability of BLIK one-click and the quality of the mobile SDK. You will find a broader comparison of providers and methods in the article BLIK, Przelewy24, Stripe or Apple Pay — which payment method to implement in your app.

BLIK API — what you get from an operator

Whichever provider you pick, the set is similar:

• Creating a transaction — amount, currency, order identifier, merchant details, return URL and webhook URL.
• Passing the BLIK code — an endpoint accepting the six digits, or a ready component/SDK that collects the code for you.
• Status query — polling for the UI, in case the webhook is delayed.
• Status change webhook — the source of truth. It must be signed and verified.
• Refunds — full and partial, usually with their own status cycle.
• Alias registration — the basis for BLIK one-click and recurring payments.
• Sandbox — a test environment simulating confirmation and rejection.

Idempotency and statuses — where most implementations break

Send every payment initiation request with an idempotency key tied to the order. Without it, a double tap on the button or a retry after a network timeout can create two transactions. The webhook, in turn, has to be idempotent on the receiving side — operators deliver it with retries, so the same status will sometimes arrive several times and must not fulfil the order twice.

Plan for every state, not just the happy path: initiated, awaiting confirmation, confirmed, rejected by the user, rejected by the bank (insufficient funds), expired, technical error, refunded. Each of them needs its own message in the UI and its own reaction on the order.

BLIK variants worth knowing about

• The six-digit code — the basic variant, available everywhere.
• BLIK one-click (alias) — the user pays once with a code and consents to being remembered; subsequent payments are approved with a confirmation in the bank alone, with no code to retype. For a mobile app this is the most important variant: it shortens the checkout to a single tap and genuinely lifts conversion on repeat purchases.
• Recurring payments — subscriptions based on a registered alias.
• Transfer to a phone number (P2P) — significant in financial and social products, not in a typical checkout.
• BLIK deferred payment — pay later; availability depends on the operator and the merchant's profile.
• Contactless BLIK — paying by phone at a terminal, handled in the banking app rather than yours.

BLIK in a mobile app — how it differs from a web implementation

A web implementation usually comes down to redirecting to the operator's page. In an app you have three approaches:

1. A native form + the operator's API — the best UX and full control over the screen, but you are responsible for handling the states and complying with the operator's requirements.
2. The operator's SDK — a compromise: ready components, less work, less control over the look.
3. A WebView with the gateway — the fastest to implement, the worst received. The user can see they have "left" your app, and returns from a WebView often lose state.

Whichever variant you pick, take care of:

• The return from the banking app — a deep link or universal link back to the right screen, plus handling the case where the system killed your app in the background.
• A waiting screen with a sensible countdown — the user needs to know they must confirm the payment in their bank and how long they have.
• Resuming after a restart — on returning, the app asks the backend for the order status instead of starting over.
• A numeric keyboard and paste support — a detail that genuinely shortens the checkout.

Common mistakes when integrating BLIK

• Fulfilling the order based on the response in the app rather than on the webhook on the server. The classic hole through which someone can "buy" without paying.
• Not verifying the webhook signature — the payment endpoint is public, so without a signature anyone can report "paid".
• No idempotency — double charges and double fulfilment.
• No reconciliation — nobody compares the operator's report against the orders. Discrepancies only surface in the accounts.
• The amount calculated on the client — the amount is always set by the backend, never by the app.
• Forgotten refunds — refunds added six months after launch, manually, through the operator's panel.
• Testing only in the sandbox — before launch, run production transactions for small amounts, including a refund.

BLIK implementation checklist

1. Choose an operator and sign the agreement — merchant verification usually takes from several days to a couple of weeks.
2. Design the order and payment data model with the full set of statuses.
3. Implement transaction initiation on the backend, with idempotency.
4. Expose a webhook with signature verification and idempotent handling.
5. Build the BLIK screen in the app: code, countdown, error states, resumption.
6. Add one-click if you sell repeatedly.
7. Implement refunds — including partial ones.
8. Set up reconciliation and monitoring of failed transactions.
9. Test in production, and only then publish.

Frequently asked questions

Can I integrate BLIK without a payment operator? In practice, no. Direct access to the BLIK scheme belongs to banks and licensed acquirers. Stores and apps integrate through an operator.

Does BLIK work outside Poland? BLIK is a Polish standard tied to Polish bank accounts. Selling abroad, you additionally need cards and wallets.

Does BLIK have chargebacks like a card? Not in the same form. BLIK does not operate on card scheme rules — complaints run through the operator and the bank, and the merchant initiates the refund. That is why a well-designed refund process on your side matters more here than with cards.

How long does it take to implement BLIK in an app? The basic integration itself is usually several days to a couple of weeks of team effort. The real schedule, however, is set by merchant verification at the operator and by production testing. We break the costs down in detail in the article how much BLIK payment integration costs.

Does BLIK in an iOS app require In-App Purchase? It depends on what you sell. For digital content consumed in the app the stores require their own purchase mechanisms; for real-world goods and services you may settle with BLIK. We describe the boundary in BLIK and the App Store and Google Play guidelines.

Summary

Integrating BLIK in a mobile app means, in practice, integrating with the API of your chosen payment operator — a direct connection to the BLIK scheme is reserved for banks and acquirers. You settle the choice of provider on commission, API quality and the availability of BLIK one-click, and the quality of the implementation on correct handling of statuses, webhooks and idempotency.

At Mobilesoft we implement payments in mobile apps — from a simple checkout to one-click, subscriptions and multi-party settlement. If you are planning such a project, get in touch and we will help pick an operator and size the work.