BLIK: Poland's Mobile Payment System Explained
BLIK is a Polish payment system run by Polski Standard Płatności that lets a customer approve a transfer from their own bank account using a six-digit code generated in their banking app. It works at online checkouts, at physical terminals, for phone-number transfers and for cardless ATM withdrawals.
For merchants selling into Poland, the practical point is that BLIK is neither a card nor a stored-value wallet. It is a rail between a checkout and the buyer's own bank, and that difference shapes how refunds, disputes and integration work.
How a BLIK payment works step by step
The flow is short, and understanding it explains most of the operational questions that come up after launch.
- The customer selects BLIK at checkout and enters a six-digit code. That code is generated fresh in their mobile banking app for this one transaction, and it expires quickly.
- The merchant's payment provider passes the code to the BLIK system, which routes it to the customer's bank.
- The bank shows the customer the transaction details in its own app: amount, merchant and what is being bought. The customer confirms there.
- The bank approves or declines, and the result returns to the merchant in seconds.
- Funds settle from the customer's account. The merchant's acquirer or payment service provider credits the merchant, typically after its own settlement cycle.
The customer never types card details and never shares bank credentials with the merchant. The bank performs the authentication itself.
What the six-digit code actually is
The code is a one-time token, not a password and not a customer identifier. It is useless to anyone who intercepts it after expiry, and it cannot be reused. That is why a code can pass safely through a merchant's checkout page: its value is bound to a single pending transaction.
Where people use BLIK
BLIK works through a short six-digit code generated inside a banking app, and the experience differs by which channel the payment starts from. The table below compares the main ways people in Poland use it.
| Use case | How it works | What the payer needs | Typical timing |
|---|---|---|---|
| Online checkout | Shop displays a BLIK code field; the customer enters the six digits generated in their bank app | Bank account with BLIK enabled, phone with the bank's app | Confirmation in the app usually within seconds |
| In-store payment | Terminal shows a code; the customer types it into the app and approves | Same as online, plus a terminal that accepts BLIK | Completed at the till, comparable to a card tap once the code is entered |
| Transfer to a phone number | Sender enters the recipient's mobile number instead of an account number | Recipient's number registered with BLIK | Near-instant, with the recipient confirming in their own app |
| Cash withdrawal at an ATM | ATM requests a BLIK code instead of a card; the customer enters it in the app | Cardless withdrawal enabled in the banking app | Cash dispensed after in-app approval |
Timing and availability vary by bank: not every institution supports every use case, and limits on single transactions and daily spending are set by the bank rather than by the BLIK system itself. The six-digit code also expires after a short window, which is why the flow assumes the phone is at hand at the moment of payment. For merchants, settlement arrives through payment processors that already handle card and transfer payments, so accepting BLIK rarely requires a separate integration.
Key terms behind a BLIK payment in Poland
BLIK sits inside the Polish banking system, so a few local terms come up in documentation and support conversations.
- Polski Standard Płatności (PSP): the company that operates the BLIK scheme and sets its rules.
- Issuer bank: the customer's bank, which generates codes and authorizes each payment in its app.
- Acquirer or payment service provider: the provider that connects a merchant to BLIK and handles settlement and reporting.
- Elixir and Express Elixir: Polish interbank clearing systems. Express Elixir supports near-instant transfers between participating banks, which matters for faster merchant settlement.
- Code expiry: codes are valid for a short window, so a checkout that sits idle for minutes may need a new code.
If you already handle European bank-transfer methods, BLIK will look familiar. It is closer to an instant account-to-account transfer with a confirmation step than to a card authorization.
What makes BLIK different from cards and wallets
Three differences show up in day-to-day merchant operations.
No card number exists to store. There is no PAN, no CVV and no stored credential on the merchant side. That reduces the data you hold, but it does not remove your compliance obligations for the personal data you do collect.
Disputes work differently. A BLIK payment is authorized by the customer inside their own banking app, with the transaction details shown at that moment. Chargeback-style reversal routes that card schemes use do not map directly onto this rail. Refunds are normally processed by the merchant or provider back to the original account, following the scheme's rules.
Confirmation is bank-side. The customer approves in their bank's app, not on your site. If your checkout assumes the customer stays on your page, test the return flow carefully so orders are not left pending after a successful confirmation. Merchants that also serve audiences outside Europe often evaluate other rails with different risk properties, including accepting crypto payments, where settling without chargebacks changes the dispute model.
Common misconceptions about BLIK
Several assumptions cause avoidable integration work. The table below pairs each one with what actually happens.
| Assumption | What actually happens | Practical consequence |
|---|---|---|
| Stored wallet balance | No balance; funds come from the linked bank account at confirmation | No top-up, no stored-value questions |
| Card-style chargebacks | Disputes run through the authorizing bank | Card dispute playbooks do not transfer |
| Codes reusable | One code, one pending transaction, short lifetime | Stale codes need a new payment request |
| Online only | Also used at physical terminals via app code | In-store and online flows may need separate setup |
| Availability follows the scheme | Offered at the merchant's provider's discretion | Check provider coverage before promising it |
Two of these deserve a closer look. "It's a wallet" is the most common error: no balance sits with BLIK, because every payment draws on the customer's bank account at the moment of confirmation, so there is nothing to top up. "Any code works anywhere" is the second: codes are tied to one pending transaction and die quickly, so support scripts that ask customers to read out an old code will resolve nothing. If a customer calls twenty minutes after checkout, that attempt's code has expired and the order usually needs a fresh payment link.
None of this makes BLIK hard to accept. It means you should confirm three things with your provider before launch: whether BLIK is enabled for your merchant account, how refunds and disputes are handled, and whether your checkout page tells customers that the code expires.
Why BLIK matters to cross-border merchants
Poland has a large base of bank-app users, and BLIK is one of the payment options many of them reach for first. Offering it removes a friction point: customers who prefer it can complete a purchase without pulling out a card. For a merchant selling into Poland, that is a conversion question, not a novelty.
Before adding it, check the operational details with your provider. A German retailer billing in EUR through a Polish subsidiary faces different onboarding than a US merchant billing in PLN through an acquirer, so confirm the terms for your own setup rather than relying on older guides.
| Check | What to confirm | Why it matters |
|---|---|---|
| Eligibility | Whether your legal entity and billing currency are supported | A method enabled for one entity may not be enabled for another |
| Refunds | How refunds and reversals route back to the customer's bank | Refund timing affects customer support and cash flow |
| Settlement | The payout cycle and any currency conversion applied | Mismatched cycles complicate reconciliation across markets |
| Risk profile | How disputes and confirmations are handled | Bank-side confirmation differs from card chargeback rules |
Run those checks before you advertise the method on your checkout page. Scheme rules and local regulation can change, so verify current terms with Polski Standard Płatności and your provider.
A worked example (illustrative numbers)
Suppose a customer in Poland buys a PLN 240 item from a merchant based in Germany. The numbers below are illustrative only; real fees and settlement times depend on your provider contract.
The customer taps BLIK at checkout and generates a code in their bank app. They enter it, the app shows "PLN 240 — Example Store," and they confirm. The merchant sees approval within seconds. The acquirer batches the transaction and settles to the merchant's account, for instance the next business day, minus a per-transaction fee agreed in the contract. Later, the customer returns one item worth PLN 60. The merchant issues a refund through the same provider, and the funds return to the original bank account rather than to a wallet balance.
Two lessons come out of this example. First, the confirmation step is where the customer sees the amount, so pricing errors surface fast and visibly. Second, refunds must be built for a rail without stored credentials.
Practical takeaway
BLIK is a Polish mobile payment scheme in which a six-digit, single-use code generated in the customer's banking app authorizes a transfer from their own account. It requires no card details, confirms inside the bank app, and settles through Polish interbank clearing. If you sell into Poland, confirm provider support, test the return-to-merchant flow and the refund path, and check scheme documentation for current rules. This article is general information, not financial, legal or tax advice.