BLIK recurring payments - BLIK requirements for your flow
BLIK defines how a store presents BLIK Recurring Payments and what the customer must see before entering the BLIK code. This page collects these requirements in one place, together with descriptions of the example screens from the BLIK materials. The technical integration is described on the BLIK - recurring payments page.
- Model O - BLIK reviews your flow before your point is enabled. You attach the materials (mockups, a recording or test access) to the request in the dpay panel, and dpay passes them on to BLIK. If BLIK has comments, you fix the flow and send the materials again.
- Models A and M - the same presentation and consent rules apply. A well-built flow is also your evidence in a customer complaint.
In the tables, Required means a BLIK requirement and Recommended a BLIK recommendation.
You can check the whole flow, including the error screen for a bank without recurring payments, in test mode - with no real money and no request. You can also prepare the recording or test access for your request there.
Payment method presentation
| Requirement | What to do | Status |
|---|---|---|
| Payment method name | Use exactly "BLIK Recurring Payments" (in Polish "Płatności Powtarzalne BLIK"), keeping the letter case. | Required |
| Separate payment method | BLIK Recurring Payments must be a visible payment method that the customer selects directly on your website - separately from regular BLIK. | Required |
| Recurring payment information | Next to the method, the customer must see that the payment will be recurring, not one-time. | Required |
| Message next to the method name | A recommended message next to the method name - it depends on the model (below). | Recommended |
| Banks supporting recurring payments | During the purchase, the customer must know which banks support BLIK Recurring Payments. dpay will give you the current list of banks. | Required |
| Bank list in the method selection | Names and logos of the banks in the payment method selection section. | Recommended |
| Bank list before the code | After the customer selects BLIK Recurring Payments and before they enter the code, a popup or an intermediate screen with the list of banks. | Recommended |
| Bank without recurring payments | When the transaction is declined because the customer's bank does not support recurring payments (code ER_PAYID_UNHANDLED), show an error message, the list of supported banks and an option to retry with another bank or choose another method. | Required |
| BLIK code field | The BLIK code field directly above the submit button, with no other content or actions in between. The other rules for the code field are the same as for BLIK Level 0. | Recommended |
Recommended messages next to the method name:
| Model | Message |
|---|---|
| A | "You can create a BLIK Recurring Payment. Transactions will be initiated automatically at certain periods." |
| M | "You can create a BLIK Recurring Payment. Transactions will be initiated automatically at certain periods and require your confirmation." |
| O | "You can create a BLIK Recurring Payment. Transactions will be initiated automatically." |
Example screens from the BLIK materials:
- Payment method selection - a list of three methods: "BLIK Recurring Payments" with the BLIK logo, regular "BLIK" and "Credit card". When BLIK Recurring Payments is selected, the message for the model appears under the name (for example "Transactions will be initiated automatically at certain periods"), followed by "Payment method is available for users of banking apps:" and the list of banks (logo and name of each bank). Below, the "Next" and "Back" buttons.
- Error: bank without recurring payments - an illustration, the heading "Sorry", the text "You cannot create a BLIK Recurring Payment", information that the method is currently available to users of the listed banks' apps (list), and a request to retry with a BLIK code from one of these apps or to choose another method. Two buttons: "Try again" and "Choose another payment method".
Payment details before checkout
Before the customer enters the BLIK code, show them the recurring payment terms. The order and layout of the fields are up to you - adapt them to your design system.
| Information | What to show | A | M | O |
|---|---|---|---|---|
| Name | The name of the product or service together with the name of the recurring payment, for example an agreement number, a customer ID or a plan name. | Required | Required | Required |
| Amount of future charges | Model A: the exact amount, for example "PLN 29.00". Models M and O: the exact amount or clear information about variability - "As per agreement", "As per price list" or a range "PLN X.XX - Y.YY". | Required | Required | Required |
| Frequency | How often the charges happen, for example "Every month", "Every 2 weeks", "Every 6 months", "Once a year". For a variable frequency, clearly describe when the customer can expect a charge, for example "Upon each service use". | Required | Recommended | Recommended |
| Expiration date | "Valid to: DD.MM.YYYY" or, without a date, "Valid until further notice". | Required | Recommended | Recommended |
| Date of the first or next payment | "Next payment: DD.MM.YYYY". Without a specific date, explain when the charge happens, for example "You will be charged upon service use". | Required | Recommended | Recommended |
| Amount now | The amount charged at registration: "Now you will pay: PLN 50.00", "Now you will pay: PLN 0.00". If you will refund it, say so: "Now you will pay: PLN 1.00 (returnable)". | Required | Required | Required |
| Possible change of amount and frequency | For a steady amount and frequency in model O, inform the customer that they may change without additional confirmation (for example when changing the plan). | - | - | Recommended |
In model O, the customer does not see the amount or frequency of future charges in the banking app. Your website is the only place where they learn them - which is why the details screen matters so much here, also in a complaint.
If you send the frequency (frequency) at registration in model M, the bank shows it to the customer and you must adhere to it - the model A rules for presenting the frequency then apply. The same goes for the date of the first charge (init_date): if you send it, you must not charge the customer earlier.
Example screen from the BLIK materials (model A) - the heading "Payment details" with the fields: Name "Standard plan", Amount "29,00 PLN", Frequency "once a month", Valid to "31.08.2026", Next payment "12.09.2024" and Now you will pay "29,00 PLN". Below, the "Payment method" section with "BLIK Recurring Payments" and the "BLIK code" field, and at the bottom the "Pay" and "Back" buttons.
What the customer sees in the banking app
After entering the code, the customer sees the "Pay and activate recurring payment" screen in the banking app (for PLN 0, some banks show only "Activate recurring payment", without an amount). With one PIN, the customer confirms both the current payment and the recurring payment.
| Screen element | Where it comes from |
|---|---|
| Information about the payment and the recurring payment activation (or only about the activation for PLN 0) | The registration amount (value) |
| Amount of the current transaction - "Now you will pay" | value |
| Website address | Your website address from the payment point configuration in dpay (the fourth line of the BLIK transaction description) |
| Recurring payment label | recurring_registration.label |
| Authorization method - "Payment will be charged automatically" (A, O) or "will require confirmation" (M) | recurring_registration.model |
| Expiration date - a date or "valid until further notice" | recurring_registration.expiration_date |
| Amount and frequency of the charges (model A) | limit_amt, frequency |
| Date of the next payment (for a steady frequency) | recurring_registration.init_date |
Example screens from the BLIK materials - four variants of the same screen: the "Recurring payment" header with the BLIK logo, the title "Pay and activate recurring payment", a countdown bar (43 s), a card with the website address and the label (for example "SuperUbezpieczenia.pl / Insured 23817263172/p/0/o/12A"), the sentence "Payment will be charged automatically", "Valid to 11.05.2025" or "valid until further notice", a large "Now you will pay" amount (PLN 29.99, PLN 0.01 or PLN 0.00), the PIN field and the "Confirm" and "Deny" buttons. In the fourth variant, for a registration without a fee, the title is "Activate recurring payment" and there is no amount.
Recurring payment label
The label (recurring_registration.label, aliasLabel in BLIK) is the title of the recurring payment. The customer sees it in the banking app together with your website name - when accepting the payment and later in the list of their recurring payments. It must let them recognize what they are paying for.
- At most 35 characters - this is the BLIK limit; the API rejects a longer label with a validation error.
- Recurring payment identifier - points to a specific recurring payment at your store, for example the customer's login or e-mail. It prevents mistakes when one person has several accounts with you.
- Additional identifier - only when a customer can have several recurring payments with you, for example for two different products. Use the product name or number.
- The additional identifier must be fixed. In model O the customer can change the plan without a new registration, so do not use values that change (for example "Standard", "Gold").
- Mask personal data - show e-mail addresses and phone numbers partially, for example
ja**@po***pl.
| Website | Label | What the customer sees |
|---|---|---|
| rental.pl | ja**@po***pl | "rental.pl ja**@po***pl" |
| energy-home.pl | agreement 642/56 | "energy-home.pl agreement 642/56" |
| games-online.pl | ja**@po***pl game XY | "games-online.pl ja**@po***pl game XY" |
| games-online.pl | ja**@po***pl game AB | "games-online.pl ja**@po***pl game AB" |
Parameters sent at registration
BLIK requires the registration to carry the parameters needed to show the invitation in the banking app. In the dpay API, you send them as follows:
| BLIK parameter | Field in the dpay API | A | M | O |
|---|---|---|---|---|
| Recurring payment identifier (Alias Value) | recurring_registration.alias | Yes | Yes | Yes |
| Recurring payment title (Alias Label) | recurring_registration.label | Yes | Yes | Yes |
| Amount charged at registration | value | Yes | Yes | Yes |
| Frequency | recurring_registration.frequency | Yes | Optional - if you send it, you must adhere to it | No |
| Amounts charged during the recurring payment | limit_amt, tot_limit_amt | Yes | Not sent to the bank | No |
| Date of the first charge | recurring_registration.init_date | Yes | Optional - if you send it, you must adhere to it | Allowed by BLIK, currently not sent by dpay |
| Expiration date | recurring_registration.expiration_date | Yes | Optional | Optional |
In models A and O, you can send a charge with no_delay: true - the bank responds immediately instead of waiting for the customer's confirmation when automatic authorization is not possible (for example when the charge was not qualified as MIT). In model M, no_delay: true is not allowed.
Example flows
Descriptions of the example model O flows from the BLIK materials. Green screens are the store, purple screens are the customer's banking app. Each flow has six steps: the order, the payment method selection, the payment details with the BLIK code field, the consent screen in the banking app, the confirmation in the bank ("Payment succeeded, recurring payment has been created" with a button to the list of recurring payments) and the confirmation in the store ("Payment succeeded").
Steady amount and frequency - streaming service
- Valid until further notice, charged once a month, a steady amount of PLN 50.00.
- The customer pays for the first period at registration (PLN 50.00).
- Payment details: Name "Standard Plan", Amount "50,00 PLN", Frequency "once a month", Next payment "12.09.2024", Now you will pay "50,00 PLN".
- In the banking app, the label contains the customer's masked e-mail, next to "Payment will be charged automatically" and "valid until further notice".
- Typical for services with several pricing plans - in model O the customer can change the plan without a new registration.
Steady frequency, variable amount - energy supplier
- Charged once a month, the amount depends on the usage and the agreement.
- The customer pays nothing at registration.
- Payment details: Name "Subscriber code: 123456", Amount "as per pricelist", Frequency "once a month", Valid to "31.08.2026", Now you will pay "0,00".
- In the banking app, the label contains the agreement number, and the expiration date shows "31.08.2026".
- Typical for utilities: electricity, water, gas.
Variable frequency and amount - bike rental
- The expiration date is limited to the agreement or valid until further notice, charged upon each use, the amount as per the price list.
- The customer pays PLN 0.01 at registration, returnable - a verification fee.
- Payment details: Name "City Bike Rental", Amount "as per pricelist", Frequency "upon each service use", Now you will pay "0,01 PLN (returnable)".
- Typical for mobility: scooters, bikes, rides.
Amount charged at registration
The amount of the transaction carrying the invitation can be zero or more. The BLIK materials show three variants:
- Fee for the first period - for example PLN 50.00 for the first month or the current invoice. On the store page and in the bank: "Now you will pay 50,00 PLN".
- Returnable verification fee - for example PLN 0.01 that you refund later. In the payment details, always with "(returnable)".
- No fee - PLN 0.00. In some banks the consent screen then shows no amount, only the PIN prompt.
The initial fee and its refund are described on the BLIK - recurring payments page.
Sources
- BLIK: Model O - information required on the merchant side, example flows, recurring payment label.
- BLIK: BLIK Recurring Payments - Certification Checklist - requirements and recommendations for models A, M and O.