Its rules, by facet
33 Rules, each in its record's own words with its own status. A rule reached only through the authorisation says so; a rule that also applies to another transaction type names it.
Finality 2
When a BLIK order is in and when it can no longer be withdrawn Corroborated (authoritative primary)
A BLIK transaction order counts as entered into PSP's system as soon as the BLIK code and the transaction data reach PSP. Once the issuer authorises it, the authorisation is irrevocable: neither a participant nor anyone else can withdraw the order. By authorising a transaction that goes to clearing, the issuer takes on the duty to pay the acquirer, or Mastercard for BLIK-C, through the BLIK system; for a transfer to the user's account the duty runs the other way, from the acquirer to the issuer. Issuer and acquirer must both keep a durable record of every authorisation decision.
Rests on rule. Confidence high. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.order-entry-and-irrevocable-authorisation
The settlement order is entered and fixed at positive authorisation Corroborated (authoritative primary)
The moment PSP's system registers the issuer's positive authorisation is the moment the settlement order enters the BLIK system; for an indirect participant, the order counts as entered by the direct participant that settles for it. From then on the settlement order cannot be revoked. The payment orders PSP later places in SORBNET3 on participants' behalf have the effect of settlement orders under the Settlement Finality Act (article 1 point 12), which is what protects them in an insolvency.
Rests on rule. Confidence high. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.settlement-order-irrevocable
Settlement 6
Net clearing of BLIK transactions, fees included Corroborated (authoritative primary)
PSP clears BLIK mobile transactions in net amounts: for each issuer one net obligation to the BLIK system, for each acquirer and for Mastercard one net claim, all after the fees due to issuers, acquirers and Mastercard, which PSP sets in Annex 2. Orders are handled first in, first out, so transactions are cleared in the order they entered. In the single-session edition PSP clears on every business day and settlement data sets and files are produced on business days; the multi-session edition leaves the business day wording out of those sentences and puts the timing in its session timetable.
Rests on rule. Confidence high. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.net-clearing
Clearing and settlement sessions, multi-session model Corroborated (authoritative primary)
For participants in the multi-session model, several clearing sessions are grouped into settlement sessions that settle together in SORBNET3, and the timetable of both sits in the non-public operating procedure for clearing and settlement. Transactions authorised on a Polish public holiday go into the settlement session processed on the next business day. The duties to publish, check and correct settlement files are as in the single-session model.
Rests on rule. Confidence medium. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.sessions-multi-session-edition
Clearing sessions, single-session model Corroborated (authoritative primary)
For participants in the single-session model, each PSP clearing session ends at midnight (24:00). Transactions authorised on a Polish public holiday go into the session cleared on the next business day. PSP publishes each participant's settlement and reconciliation files promptly after the session closes; the participant must check them and report discrepancies at once, and PSP regenerates the files if needed. BLIK-C refunds are the exception: they join a session only when Mastercard reports them.
Rests on rule. Confidence high. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.sessions-single-session-edition
Every participant settles through a settlement entity Corroborated (authoritative primary)
A participant either is itself a settlement entity, with its SORBNET3 account linked to BLIK as an external system, or names another settlement entity to receive what clearing owes it. A settlement entity that settles for another participant must credit that participant's account after the run with the amount of its position. An indirect participant uses the account of a direct issuer that has agreed to pass on its settlement orders.
Rests on rule. Confidence medium. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.settlement-entity
Settlement guarantee among issuers Corroborated (authoritative primary)
If an issuer lacks funds on its NBP account in the main settlement run, or in a first reserve run held after technical errors, every BLIK order in that run is withdrawn and the run does not settle. PSP blocks the short issuer (and with it the secured acquirers and indirect participants that settle through it) and tells NBP. The other issuers stand behind the shortfall: PSP recomputes settlement with their obligations raised by a formula in a non-public procedure and settles in a reserve run. If that also fails, nothing settles through SORBNET3; issuers instead pay acquirers, Mastercard and each other bilaterally on PSP's instructions, and NBP is told. The issuer that caused it must promptly repay the others with statutory interest.
Rests on rule. Confidence high. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.settlement-guarantee
Settlement in SORBNET3 through PSP's auxiliary account Corroborated (authoritative primary)
BLIK settles in central bank money in NBP's SORBNET3 system, with BLIK attached as an external system under SORBNET3's settlement procedure A. From PSP's clearing data PSP enters one net debit order per issuer (covering the indirect participants it settles for, and for a securing issuer its secured acquirers), then, in the same session, credits each acquirer and Mastercard with single orders from PSP's auxiliary account at NBP. Settlement is one run, completes within one business day except when the guarantee forces bilateral settlement, happens Monday to Friday except Polish public holidays, and leaves the auxiliary account at zero before and after. Issuers must manage liquidity on their NBP accounts so the run can settle.
Rests on rule. Confidence high. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.sorbnet3-settlement-run
Hours 2
The scheme runs around the clock Corroborated (authoritative primary)
The BLIK scheme works every day of the year, around the clock, apart from planned technical breaks, and users may start transactions whenever it is running. For registering a transaction the date and time of PSP's system count. Settlement is different: it runs only on Polish business days.
Rests on rule. Confidence high. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C), Phone transfer (P2P), Transfer request (P2P-R). blik:rule.continuous-operation
How long a one-time BLIK code lives Corroborated (authoritative primary)
The rulebook leaves a one-time code's validity to the non-public Technical Specification. PSP's own FAQ tells users a code is valid for 2 minutes; Stripe also says 2 minutes and Adyen 120 seconds. A code serves one transaction only, and PSP generates and manages codes centrally.
Rests on guidance. Confidence medium. Also applies to Code payment to a merchant, Cash withdrawal or deposit. blik:rule.one-time-code-validity
Limits 2
Each bank sets its users' BLIK limits Corroborated (public primary)
Amount and count limits for BLIK are set by each bank for its own users, including limits for contactless BLIK; whether recurring transactions count toward them also depends on the bank.
Rests on guidance. Confidence medium. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C), Phone transfer (P2P), Transfer request (P2P-R). blik:rule.issuer-set-limits
Scheme per-transaction limit: set, but not public Corroborated (authoritative primary)
To contain operational risk, a participant may send for authorisation only transactions up to the single-transaction limit the Technical Specification sets, and PSP's system rejects a larger one with an error code. The figure and the code are in the non-public specification.
Rests on rule. Confidence medium. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.per-transaction-limit-unpublished
Return 2
Complaints run from participant to PSP through a ticket system Corroborated (authoritative primary)
Complaints and other reports about BLIK go from a participant to PSP through PSP's ticket system, or by e-mail or another agreed channel when the ticket system is down. PSP investigates. It charges a complaint fee from Annex 1 to the participant whose failure caused the event, or to the filer when nobody was at fault, and waives it in cases the complaints procedure lists. For a BLIK-C complaint handled with Mastercard, PSP also collects Mastercard's fee from the issuer or passes on a fee Mastercard pays. The detailed steps, required documents and deadlines are in a non-public operating procedure. PSP keeps complaints for 6 years from the end of the year they close.
Rests on rule. Confidence medium. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.complaint-ticket-process
A declined transaction never settles Corroborated (authoritative primary)
A settlement order exists only once PSP registers a positive authorisation from the issuer, so a transaction the issuer declines, or PSP rejects before authorisation, never enters clearing and moves no money. BLIK has no return message for a settled payment; money goes back through a separate refund, a cancellation or correction, or a complaint.
Rests on rule. Confidence medium. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.declined-authorisation-never-settles
Recall 1
Cancellation or correction within 13 months Corroborated (authoritative primary)
After the issuer has authorised a mobile transaction, PSP or the acquirer may cancel it when a technical error occurred. A mobile transaction can be cancelled or corrected for 13 months from the day it was authorised. Corrections of amounts under complaint are made by PSP under the non-public complaints procedure. There is no recall by the user.
Rests on rule. Confidence high. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.cancellation-or-correction-13-months
Liability 5
Who answers for bad-faith, criminal or intruder transactions Corroborated (authoritative primary)
The acquirer answers to other participants and PSP for BLIK transactions that it or its merchant put into PSP's system in bad faith or through a crime, including unauthorised acts of third parties in the acquirer's or merchant's systems. The issuer answers in the same way for such transactions put in by itself or its users, including intrusions into its systems or its mobile app. Every participant must work to reduce users' and other participants' exposure to crime, and answers for subcontractors as for itself.
Rests on rule. Confidence high. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.bad-faith-and-crime-liability
Alert when complaints pass 3 percent Corroborated (authoritative primary)
PSP alerts a participant when complaints about mobile transactions for reasons on that participant's side exceed 3 percent of its BLIK transactions of the last 30 days, and number at least 50. Other alerts cover a ready settlement report, a guarantee run caused by an issuer's shortfall, and events the Technical Specification lists.
Rests on rule. Confidence high. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.complaint-alert-threshold
In a complaint the party at fault pays, PSP decides doubt, silence means fault Corroborated (authoritative primary)
When a complaint carries a concrete claim by a user, institutional user, merchant or participant that arose because PSP or a participant broke its obligations, that party bears the cost of the claim. PSP tells the participants involved who caused the event and the account into which that participant must transfer the claimed amount. PSP resolves any doubt over who is responsible. A participant that does not answer a complaint within the deadline in the complaints procedure is treated as accepting that it was at fault.
Rests on rule. Confidence high. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.complaint-fault-pays
Goods and services disputes stay between user and merchant Corroborated (authoritative primary)
PSP and each participant answer only for their own failure to follow the participation agreement or the rulebook. None of them answers for whether the merchant delivered, or delivered what was agreed; such claims are settled directly between the user and the merchant. Whatever PSP does as a result of a complaint leaves that relationship untouched and is no proof that the user took part in the transaction or received anything from it.
Rests on rule. Confidence high. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.disputes-over-goods-outside-scheme
Issuers report unauthorised transactions within two business days Corroborated (authoritative primary)
Each issuer must run a procedure to monitor unauthorised BLIK transactions, meaning transactions started by someone not entitled to, and report each case it identifies to PSP within two business days. It must also warn users about the risks of paying online and with mobile apps. PSP reports unauthorised transactions to NBP and other authorities as the law requires.
Rests on rule. Confidence high. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C), Phone transfer (P2P), Transfer request (P2P-R). blik:rule.unauthorised-transaction-reporting
Consumer law 2
The issuer is the user's payment service provider Corroborated (authoritative primary)
The BLIK scheme is a payment scheme under the Payment Services Act of 19 August 2011 and the BLIK system a payment system under the Settlement Finality Act of 24 August 2001, both run by PSP. Toward the user, the payment service (making the payment instrument available and executing transactions) is the issuer's; the acquirer only takes part as an intermediary. The user's statutory rights therefore run against the issuer [Inference: the Act itself was not read].
Rests on rule. Confidence medium. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C), Phone transfer (P2P), Transfer request (P2P-R). blik:rule.issuer-is-users-payment-service-provider
Users complain to their own bank Corroborated (public primary)
PSP tells users to complain about a BLIK transaction, including contactless and recurring ones, to the bank whose app they used, since that bank holds the transaction details and can act. PSP itself deals only with participants.
Rests on guidance. Confidence medium. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C), Phone transfer (P2P), Transfer request (P2P-R). blik:rule.user-complains-to-own-bank
Messages 4
Four ways a BLIK authorisation travels Corroborated (authoritative primary)
Issuers authorise every BLIK transaction with a BLIK code. With a code PSP generated, the issuer asks PSP for it on the user's request, the user types it into the acceptance device, the acquirer sends it with the transaction data to PSP, and PSP finds the mobile account and issuer and asks for authorisation. With a code the acceptance device shows, the user pulls it into the app, the issuer registers it with PSP, and the rest runs the same way. With an alias, a standing code the issuer registered, the acceptance device obtains the alias as the Technical Specification sets. For BLIK-C, PSP obtains a Mastercard token for the alias, the phone passes it to the terminal, Mastercard's tokenisation system forwards it to PSP, and the answer goes back through Mastercard. In every flow the issuer's accept or reject goes back to PSP and then to the acceptance device. Adyen's BLIK OneClick, paying without a code at a shop the user saved as trusted in the bank app, appears to use the alias flow [Inference].
Rests on rule. Confidence medium. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.authorisation-flows
Message formats and error codes live in the Technical Specification Corroborated (authoritative primary)
PSP sets the technical standards for the scheme and for communication with participants and Mastercard, checks each transaction against the Technical Specification for Participants, and tells a participant when its messages do not conform. Message formats, error codes, code validity and the transaction limit are in that specification, Annex 3 to the rulebook, which PSP does not publish. Participants must report doubts about a transaction to PSP at once, in the way the specification sets.
Rests on rule. Confidence medium. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C), Phone transfer (P2P), Transfer request (P2P-R). blik:rule.message-standards-technical-specification
Recurring payment flags and the one public BLIK error code Corroborated (authoritative primary)
A merchant can send refuseNoPayId set to true so BLIK rejects the transaction when the user's bank does not support recurring payments, and handle the error. Without that flag, and with such a bank, a set-up carried on a transaction above zero is shown to the user as a plain payment without the recurring invitation, while a zero-amount set-up is rejected by BLIK with error code ER_PAYID_UNHANDLED and never reaches the bank. The NODELAY flag (models A and O) skips the 72 hour retry period. Every acquirer must support both flags.
Rests on rule. Confidence medium. blik:rule.recurring-flags
Recurring payment models A, M and O Corroborated (authoritative primary)
PSP offers three models. In model A later transactions go through without the user confirming, for a fixed amount at a fixed frequency until an expiry the merchant must set, at most 10 years ahead; only one automatic transaction per frequency period is allowed, and a charge with another amount, or a second one in the same period, needs the user's confirmation in the app. In model M the user confirms every recurring transaction, and amounts and frequency may vary; the consent may run to a date or until cancelled. In model O transactions go through without confirmation even though amount and frequency may vary; it too may run to a date or until cancelled. Not every bank supports recurring payments, and merchants must say which do.
Rests on rule. Confidence medium. blik:rule.recurring-models
Participants 1
What issuers and acquirers must do Corroborated (authoritative primary)
Issuers: give users the app or another code-based function and authenticate them in it; get one-time codes from PSP, and register with PSP the mobile accounts and any codes they create themselves; authorise only on a code PSP issued or registered; update a mobile account's status at once, for example when a user leaves; and keep sanctioned persons out. Acquirers: tag each merchant with an ISO merchant category code and offer BLIK only to merchants that act lawfully and ethically, are not on sanctions lists and do not use the BLIK mark misleadingly. Everyone: run BLIK and connect to it as the Technical Specification sets, submit to tests and audits, follow anti money laundering law, and promote BLIK with its mark. Securing issuers, secured acquirers and indirect participants carry extra account and funding duties, and each category must offer the functions Annex 5 marks mandatory for it.
Rests on rule. Confidence medium. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C), Phone transfer (P2P), Transfer request (P2P-R). blik:rule.participant-duties
Human decision points 4
The issuer decides; an acquirer's no-confirmation hint is only advice Corroborated (authoritative primary)
Whether a BLIK transaction can go ahead is the issuer's decision. At an acquirer's request PSP may let it send issuers a recommendation to authorise without asking the user to confirm in the app; the issuer may ignore it, and the acquirer using it must put measures in place against unauthorised transactions.
Rests on rule. Confidence medium. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.issuer-decides-authorisation
PSP rejects on fraud monitoring and blocks illegal gambling domains Corroborated (authoritative primary)
PSP's system itself stops two kinds of transaction before the issuer decides. It rejects one when PSP's monitoring shows the participant would refuse it because fraud is likely. It halts, and never sends to the issuer, a payment for a service offered through a domain on Poland's register of domains offering gambling unlawfully; that block does not relieve participants of their own legal duties on gambling payments. PSP monitors BLIK transactions for rule breaches, unauthorised use and fraud under the Payment Services Act, alongside the participants' own monitoring.
Rests on rule. Confidence medium. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C). blik:rule.psp-fraud-and-gambling-rejection
Recurring transaction short of funds: 72 hours of bank retries Corroborated (authoritative primary)
When a recurring transaction cannot be authorised because funds are short or a limit is exceeded, the bank has the next 72 hours to tell the user why and ask for funds or a limit change, and tries again to authorise; if the problem remains it declines. In models A and O the merchant can skip that period with the NODELAY flag, and the transaction is marked unsuccessful at once; the merchant may then retry manually, and PSP recommends leaving 24 hours between attempts. PSP's FAQ adds that a recurring payment not made for lack of funds may be retried by the bank or the merchant.
Rests on guidance. Confidence medium. blik:rule.recurring-retry-72-hours
PSP may block a participant temporarily Corroborated (authoritative primary)
PSP may cut a participant off from BLIK for a time on three kinds of ground. Conduct: a breach of PSP's security rules, behaviour that endangers BLIK's continuity, or a finding PSP asked it to fix still open after the deadline. Faulty traffic: messages in a format the Technical Specification does not allow, or messages BLIK does not expect at that stage of a transaction. Failure at scale: no timely answer to any authorisation request sent in the last 15 minutes, or refusals making up half or more of its authorisation answers where neither the user nor PSP caused them. Once the participant e-mails PSP that the cause is removed, the block is lifted.
Rests on rule. Confidence medium. Also applies to Code payment to a merchant, Cash withdrawal or deposit, Refund to the user, Contactless BLIK (BLIK-C), Phone transfer (P2P), Transfer request (P2P-R). blik:rule.temporary-block
No facet on the record 2
Recurring payment: the user sees and cancels it in the bank app Corroborated (authoritative primary)
The user can see every recurring payment in the banking app, including whether it charges automatically or needs confirmation, and can cancel one by deleting it there. Deleting it stops BLIK charges but does not necessarily end the user's contract with the merchant. A recurring payment does not move with the user to another bank; it has to be set up again there.
Rests on guidance. Confidence medium. blik:rule.recurring-cancel-in-banking-app
Recurring payment: consent started at the merchant, confirmed in the bank app Corroborated (authoritative primary)
A BLIK recurring payment is the user's consent for a merchant to start later transactions. The user starts it in the merchant's site or app, typically by choosing BLIK recurring payment and entering a BLIK code, and confirms it in the banking app, which shows the merchant, amount, frequency and expiry. Setting it up charges nothing by itself; each later charge is a separate recurring transaction, though the first charge may be taken at set-up. The rulebook's definition of a merchant already covers one that starts a BLIK transaction under authority the user gave it earlier.
Rests on rule. Confidence medium. blik:rule.recurring-consent-in-banking-app