(warning) Requirement
(info) Recommendation

Value

Area

Scenario

Expected result

Example ENG

Example PL

Model A

Model M

Model O

Payment method presentation

(warning)

BLIK Recurring Payments Naming

  1. Go to the payment method selection screen

The naming convention to follow (case sensitive): 

  • ENG: "BLIK Recurring Payments"
  • PL: "Płatności Powtarzalne BLIK"

(warning)

BLIK Recurring Payments as a separate Payment Method

  1. Go to the payment method selection screen

BLIK Recurring Payments must be a visible, selectable form of payment directly from the shop's service as a separate payment method.

(warning)

BLIK Recurring Payments Info

  1. Go to the payment method selection screen

Information indicating that payment will be recurring instead of one-time must be included

  • Model A, O
  • Model M








  • Model A, O
  • Model M






(info)

BLIK Recurring Payments Info

  1. Go to the payment method selection screen

We recommend adding additional message near the payment method name.

Recommended message:

  • Model A
    ENG: "You can create a BLIK Recurring Payment. Transactions will be initiated automatically at certain periods."
    PL: "Możesz utworzyć płatność powtarzalną BLIK. Środki będą pobierane automatycznie w określonych odstępach czasu."

We recommend adding additional message near the payment method name.

Recommended message:

  • Model M
    ENG: "You can create a BLIK Recurring Payment. Transactions will be initiated automatically at certain periods and require your confirmation."
    PL: "Możesz utworzyć płatność powtarzalną BLIK. Płatności będą inicjowane automatycznie w określonych odstępach czasu i będą wymagały Twojego potwierdzenia."

 

We recommend adding additional message near the payment method name.

Recommended message:

  • Model O
    ENG: "You can create a BLIK Recurring Payment. Transactions will be initiated automatically."
    PL: "Możesz utworzyć płatność powtarzalną BLIK. Środki będą pobierane automatycznie."

 

(warning)

Information about which banks support BLIK Recurring Payments

  1. Begin the purchase process

User has to be informed throughout the purchase process about banks that currently support BLIK Recurring Payment.

Refer to Acquirer to obtain a valid list of supporting banks.

(info)

Information about which banks support BLIK Recurring Payments - Payment method selection section

  1. Begin the purchase process
  2. Proceed to the payment method selection section


Information, along with logos and names, regarding supporting banks is provided in the payment method selection section.

(info)

Information about which banks support BLIK Recurring Payments - Information before checkout

  1. Begin the purchase process
  2. Proceed to payment method selection section
  3. Choose BLIK Recurring Payments as Payment Method

Before proceeding to checkout and entering the BLIK code,  user is presented with information in the form of a popup or a middle screen containing a list of banks that currently support BLIK recurring payments.

(warning)

Information about which banks support BLIK Recurring Payments- Error Handling

  1. Begin the purchase process
  2. Proceed to payment method selection section
  3. Choose BLIK Recurring Payments as Payment Method
  4. Make a transaction with a Bank which doesn't support BLIK Recurring Payments

In cases of a failed transaction due to the user's bank not supporting BLIK Recurring Payment, user should be shown an appropriate error message, along with a list of supporting banks and an option to retry with another bank.



See refusePayId Mechanism for more information

(info)

Recurring Payment Details - BLIK code field

  1. Select product and BLIK Recurring Payments as a Payment Method
  2. Go to the checkout page with the field for entering the BLIK code

The field for entering the BLIK code is positioned directly above the "submit" type button, with no additional information or actions required between them.

Refer to Level 0 - UX Certification Checklist to see all requirements regarding the BLIK Code field presentation.

Recurring Payment Details Presentation

(warning)

Recurring Payment Details - Amount 

  1. Select product and BLIK Recurring Payments as a Payment Method

Before proceeding with payment, the user must be informed about the future Recurring Transactions amount. Information should include precise value.

Example Recommended values:

  • X.XX PLN

Before proceeding with payment, the user must be informed about the amount of future Recurring Transactions. Information should include precise value or in instances of variable amount, include clear information about variability.

Example Recommended values:

  • X.XX PLN
  • ENG: "As per agreement" 
  • ENG: "As per price list" 
  • ENG: 'X.XX - X.XX PLN" 
  • PL: Zgodnie z warunkami umowy" 
  • PL: "Zgodnie z cennikiem"  
  • Amount: 29,00 PLN 
  • Frequency: once in a month
  • Expiration Date: 31.08.2026
  • Date of next recurring transaction: 12.09.2024

  • Kwota: 29,00 PLN 
  • Częstotliwość: raz w miesiącu
  • Data ważności: 31.08.2026
  • Data następnej Transakcji Powtarzalnej: 12.09.2024

(warning) /(info)

Recurring Payment Details - Frequency 

  1. Select product and BLIK Recurring Payments as a Payment Method

(warning) Before proceeding with payment, the user must be informed about Frequency. Info should include the frequency of recurring transactions occurrence within the specified quantity of the designated unit of measurement.


Examples: 

  • Every three weeks
  • Every month 
  • Every 6 months
  • Every 2 weeks
  • Once a year
  • Once a month


Refer HERE for more information about frequency


(warning) /(info) Before proceeding with payment, user should be informed on whether the frequency will be fixed or variable. Info should include the frequency of recurring transactions occurrence within the specified quantity of the designated unit of measurement. In instances of variable frequency, include clear information regarding variability or  explanation about the circumstances in which the user might expect a Recurring Transaction.


If a frequency was provided during the recurring payment setup, merchant must obligatorily follow frequency UX requirements for 'A Model.

Refer to the 'A Model' column in this row


Examples: 

  • Upon each service use
  • other similar information clearly explaining variable frequency system

(info) Before proceeding with payment, user should be informed on whether the frequency will be fixed or variable Info should include the frequency of recurring transactions occurrence within the specified quantity of the designated unit of measurement. In instances of variable frequency, include clear information regarding variability or  explanation about the circumstances in which the user might expect a Recurring Transaction.

Examples:

  • Upon each service use
  • other similar information clearly explaining variable frequency system

(warning)/(info)

Recurring Payment Details - Expiration Date

  1. Select product and BLIK Recurring Payments as a Payment Method

(warning) Before proceeding with payment, user must be informed about the Recurring Payment Expiration Date.

(info) Before proceeding with payment, the user should be informed about the Recurring Payment Expiration Date. In instances where there is no specified expiration date, include information about the indefinite duration of the expiration date.

Examples: 

  • Valid to: DD.MM.YYYY
  • Valid to: Until further notice
  • Valid Indefinitely

(warning)/(info)

Recurring Payment Details - Date of First recurring transaction 

  1. Select product and BLIK Recurring Payments as a Payment Method

(warning) Before proceeding with payment, the user must be informed about first Recurring Transaction date. In instances without a specified date of the first payment.

(info) Before proceeding with payment, user should be informed about next Recurring Transaction date. In instances without a specified date of the next payment include an explanation about the circumstances in which the user might expect a Recurring Transaction.

Examples: 

  • Next payment: DD.MM.YYYY
  • You will be charged upon service use

(warning)/(info) Before proceeding with payment, user should be informed about next Recurring Transaction date. In instances without a specified date of the next payment include an explanation about the circumstances in which the user might expect a Recurring Transaction.


If the date of the first transaction was provided during the recurring payment setup, merchant must obligatorily follow Init Date UX requirements for 'A Model.

Refer to the 'A Model' column in this row

(warning)

Recurring Payment Details - Amount charged upon Recurring Payment creation

  1. Select product and BLIK Recurring Payments as a Payment Method

Before proceeding with payment, the user must be informed about the amount charged upon Recurring Payment creation 
If the charged amount is going to be returned, include such information. 

Examples: 

  • "Now you will pay: 50,00 PLN"
  • "Now you will pay: 0,00 PLN"
  • "Now you will pay: 1,00 PLN - returnable"

(info)

Recurring Payment Details - Information about possible changes in frequency & amount

  1. Select product and BLIK Recurring Payments as a Payment Method
  2. Go to the checkout page with the field for entering the BLIK code

N/A

N/A

In instances with a steady amount and frequency, the user should be informed that these values can be changed without requiring additional confirmation.

Recurring Payments Initialization

(warning)

Parameters for saving the shop in the banking app

  1. Go through the purchase process and create a BLIK Recurring Payment with confirmation in the banking app

While creating Recurring Payment, the shop sends the parameters needed to display and create an invitation to start Recurring Payment (registering the Alias PAYID).

In Model A These parameters are:

  • Alias Value - unique alphanumeric ID of a Recurring Payment.  
  • Alias Label - Recurring Payment title. 
  • Amount charged throughout RP duration
  • Frequency 
  • Amount charged upon Recurring Payment Creation 
  • Date of First Recurring Transaction


Please refer to your Acquirer's technical documentation for exact instructions on how to send the parameters.

While creating Recurring Payment, the shop sends the parameters needed to display and create an invitation to start Recurring Payment (registering the Alias PAYID).

In Model M These parameters are:

  • Alias Value - unique alphanumeric ID of a Recurring Payment.  
  • Alias Label - Recurring Payment title. 
  • Frequency - optionally*
  • Amount charged upon Recurring Payment Creation 

*Providing Frequency value will result in showing this info in user's banking app during Recurring Payment set-up. If sent it must be strictly adhered to.


Please refer to your Acquirer's technical documentation for exact instructions on how to send the parameters.

While creating Recurring Payment, the shop sends the parameters needed to display and create an invitation to start Recurring Payment (registering the Alias PAYID).

In Model O These parameters are:

  • Alias Value - unique alphanumeric ID of a Recurring Payment.  
  • Alias Label - Recurring Payment title.  
  • Amount charged upon Recurring Payment Creation 
  • Date of first Recurring Transaction /initDate/ - optionally*


*Sending  initDate will result in showing this info in user's banking app during Recurring Payment set-up. If sent it must be strictly adhered to 


Please refer to your Acquirer's technical documentation for exact instructions on how to send the parameters.




(warning)

Parameters for saving the shop in the banking app - Alias Label


Alias Label must be constructed in line with A model requirements for aliasLabel. 

These can be found HERE.

 

Alias Label must be constructed in line with M model requirements for aliasLabel. 

These can be found HERE.

 

Alias Label must be constructed in line with O model requirements for aliasLabel. 

These can be found HERE.


(info)

Parameters of Recurring Payment execution


 In A Model  the flag for immediate authorization  (noDelay = true) can be set. This indicates that there will be an immediate authorization response, without waiting for user confirmation of the transaction, in cases where automatic authorization might not be possible (e.g., if the conditions for automatic authorization are not met)

Refer HERE for more information 

 N/A

 In O Model  the flag for immediate authorization  (noDelay = true) can be set. This indicates there will be an immediate authorization response, without waiting for user confirmation of the transaction, in cases where automatic authorization is not possible (e.g., if the transaction has not been classified in the PSP system as exempt from SCA as initiated by the Merchant (MIT)

Refer HERE for more information