How it works

The user initiates the Recurring Payment in the merchant's service by selecting the "BLIK Recurring Payment" method and entering the BLIK code.

In this model, after creating a Recurring Payment, Repeat Transactions initialized by the merchant are authorized by the Bank automatically:

without confirmation by the User in the banking app (except for the first payment with the BLIK code that initiates BLIK Recurring Payment),
for a fixed amount,
at a fixed frequency,
until the set expiration date

IMPORTANT

A Recurring Transaction must align with the Recurring Payment. If there is an attempt to execute a Recurring Transaction for a different amount or frequency, Bank won't authorize such transaction automatically, therefore user will need to authorize the transaction in banking app.

Required information displayed on the Merchant's side while initiating the Recurring Payment in the A Model

Even if the user receives the mandatory information about the payment method in the banking app (on the payment authorization screen), part of it should be displayed on the merchant's side before the payment.

These fields are:

Field Name	Field description in Merchant System	Available Values	The value displayed in the Banking App	Mandatory
Name	Name of the product, along with the name of the Recurring Payment.	Agreement number User ID Plan Name Name of the product or service	Merchant Name/URL + Alias Label value Read More about Alias Value here.
Amount	The amount charged within the specified period.	X.XX PLN (the amount in the A Model is fixed)	Amount in X.XX PLN format
Frequency	Frequency of Recurring Transactions occurrence within the specified time unit.	Specified time unit for occurrence of each Recurring Transaction Available units of measurement: day week month quarter year Available quantity: 0-999 Correct examples: Every three weeks Every month Every 6 months Every 2 weeks Once a year Once a month	Specified time unit for the occurrence of each Recurring Transaction with the information of payment authorization (in Model A → user will be charged automatically, without any confirmation).
Valid to	The expiration date of the Recurring Payment.	The day, month, and year are displayed in the specified format.	Date in DD.MM.RRRR format
Next Payment	The precise date of the upcoming Recurring Transaction.	The day, month, and year are displayed in the selected format.	Date in DD.MM.RRRR format
Now you will pay	The user will be charged the exact amount while initiating the Recurring Payment. If the fee is solely for verification purposes, the merchant should display the details of its returnability.	The currency value with precision to two decimal places. Example: 0,00 0,01 returnable 29,99	Value in X.XX PLN format or No amount displayed in the case of 0.00 PLN transactions

Example of Recurring Payment process in A Model

Green screens - store
Purple screens- user's banking app

Example of Recurring Payment initiation process in A Model

images/download/attachments/107840442/image-2024-4-24_10-40-59-version-1-modificationdate-1713948059844-api-v2.png

First Recurring Transaction amount while Recurring Payment initiation

Transaction amount can be 0,00 PLN or higher, it depends on the use case. A certain amount above 0,00 PLN may be the fee for the first month of the subscription, the payment for an invoice, or a 1,00 PLN fee (that will be returned to the user).

Example of the process of charging the user for the initial period while initiating a Recurring Payment

images/download/attachments/107840442/image-2024-4-11_15-18-2-version-1-modificationdate-1712841482379-api-v2.png

Example of the process of charging the user with a returnable fee for verification purposes while initiating a Recurring Payment

Example of the process without charging the user while initiating a Recurring Payment (amount 0,00 PLN may be displayed in the banking app but it's not a requirement in this case)

The information displayed in Mobile Banking Apps in A Model

Examples of payment authorization screens in the banking app in different possible configurations (with a description of all mandatory data)

images/download/attachments/107840442/Model_A-version-2-modificationdate-1711537498357-api-v2.png

Invitation data

Every invitation in A Model must contain:

PAYID Alias Value

alias Value

A lphanumeric string up to 64 characters, unique for given Recurring Payment

Merchant's WEB Address

goods/@line-4

When the invitation is sent with the WEB_PURCHASE transaction - it contains the merchant's web address.

Merchant's Name

merchData/name/@short

When the invitation is sent with the POS_PURCHASE transaction type - it contains the merchant's name.

Alias Expiration Date

In model A, the expiration date must be specified and may be up to 10 years.

Alias Label

aliasLabel

Alias label (aliasLabel), alphanumeric string up to 35 characters which contains title of the BLIK Recurring Payment. This value along with merchant name/url should allow user to recognise particular Recurring Payment in Recurring Payment list in a banking app

How to correctly define Alias Label in the A model:

Alias label should be a value that along with merchant name enables user to identify the given BLIK Recurring Payment on the BLIK Recurring Payment list available in the user's mobile banking app.

To provide clear information, alias label must contain:

Recurring Payment Identifier: This allows the identification of the specific BLIK Recurring Payment within the given merchant. This secures cases where one person has multiple accounts in the one merchant's system. For example, the user's login or email.
Additional Identifier: This is necessary only in cases where one user can have multiple BLIK Recurring Payments set-up e. g. for 2 different products or services. For example, the product name or ID.

When using personal user information such as email or phone numbers, these values must be masked.

Examples:

MERCHANT NAME/ URL	ALIAS LABEL		FINAL VALUE VISIBLE IN BANKING APP
	RECURRING PAYMENT IDENTIFIER	ADDITIONAL IDENTIFIER	FINAL VALUE VISIBLE IN BANKING APP
rental.pl	user@em*com	-	"rental.pl user@em*com"
utilitybill.pl	agreement642/56	-	" utilitybill.pl agreement642/56"
gamepass.pl	user@em*com	game XY	" gamepass.pl user@em*com game XY"
gamepass.pl	user@em*com	game AB	" gamepass.pl user@em*com game AB"

Info

Refer to Acquirer's API to see how to correctly provide the information above.

Frequency

In model A when sending an invitation to create a Recurring Payment, merchant obligatory specifies the frequency at which he will execute Recurring Transaction within given Recurring Payment as well as the date of first Recurring Transaction.

IMPORTANT

Automatic authorization (without user confirmation in the banking app) is possible only for one recurring transaction within a specified frequency. If a second recurring transaction attempt occurs within the given frequency, user confirmation will be required.

When setting the frequency of Recurring Transaction execution, merchant shall specify:

I. How often does recurring transaction happen within the given quantity of designated unit of measurement:

Available units of mesurements:

- day
- week
- month*
- year

Available quantity: 0-999

Correct examples:

- Every three weeks
- Every month
- Every 6 months
- Every 2 weeks
- Once a year
- Once a month
- Every 999 weeks

II. The day on which the first Recurring Transaction will be executed /initDate/:

Merchant must point the exact date of next Recurring Transaction while creating Recurring Payment

IMPORTANT INFO

In case the designated day for processing a Recurring Transaction falls on a day that does not exist in a given month (e.g., the 31st of April), the transaction will be automatically authorized on the last day of that month (e.g. the 30th of April).
For M (month) unit of frequency, we recommend setting the date of the first payment (@initDate) between the 1st and the 28th of the month. This is to avoid executing the Recurring Transaction in the next payment period, which would consequently require the next recurring transaction to be confirmed by the User in the Authentication Module (AM).

Examples of Frequency for A Model:

For a frequency of 1M and an initDate of 15.01.2024, One Recurring Transaction will be automatically authorized in model A within the periods 15.01.2024-14.02.2024 (one month), 15.02.2024-14.03.2024 (one month), 15.03.2024-14.04.2024 (one month), and so on.
For a frequency of 1W or 7D and an initDate of 17.01.2024, One Recurring Transaction will be automatically authorized in model A within the periods 17.01.2024-23.01.2024 (one week = 7 days from Wednesday to Tuesday), 24.01.2024-30.01.2024 (one week = 7 days from Wednesday to Tuesday), and so on.
For a frequency of 30D and an initDate of 15.01.2024, One Recurring Transaction will be automatically authorized in model A within the periods 15.01.2024-13.02.2024 (30 days), 14.02.2024-15.03.2024 (30 days), 16.03.2024-14.04.2024 (30 days), and so on.

Info

Refer to Acquirer's API to see how to correctly provide the information above.