Level 0 - guidelines for implementation of BLIK with code
Requirement
Recommendation
Value | Area | Scenario | Expected result | Example ENG | Example PL |
---|---|---|---|---|---|
Payment method presentation | |||||
| Visibility of the BLIK logo |
| The BLIK payment method is marked with the BLIK logo. The logotype used is consistent with the BLIK brand book. | ||
| BLIK in Level 0 on the first screen for selecting a payment method |
| BLIK must be a visible, selectable form of payment directly from the shop's service. | ||
BLIK is first on the list of payment methods |
| We encourage you to display BLIK first on the list, as it is the most popular online payment method in Poland. | |||
Rules of spelling |
| All references to BLIK are written in capital letters. | BLIK | BLIK, BLIKIEM, BLIKOWI itd. | |
Entering the BLIK code and transaction initiation | |||||
BLIK code field - input without numeric placeholder |
| Input for entering the BLIK code should be an empty input without any numerical placeholder (e.g. 111 111, 123 456, or other string of digits). | |||
BLIK code field - length of the field |
| The width of the field should match the value to be entered there (6 characters with a gap after 3 characters). | |||
BLIK code field - two groups of three digits |
| The BLIK code should be displayed centered, in two groups of three digits in a single field. | |||
BLIK code field - numeic keyboard (mobile) | Perform the tests on your mobile device:
| On mobile, the input should call up the numeric keyboard. | |||
BLIK code field - character restrictions |
|
| |||
BLIK code field - no autocomplete |
| Input for entering the BLIK code should not have the autocomplete attribute (disabled prompting for last entered BLIK codes or other passwords) | |||
BLIK code field - activation by pressing the field |
| Input for entering the BLIK code should not be automatically activated, it should only activate when the user presses it. | |||
BLIK code field - field naming and supporting messages |
| The text should clearly inform the user that they are to generate a BLIK code in the banking application and then confirm the payment.
In relation to the BLIK code, the terms are not used:
| |||
BLIK payment - instructions, tooltips |
| Additional elements (instructions, tooltips, etc.) relating to BLIK payment are not links to external websites or other elements that "throw" the User out of the process. Additional elements should not cover the BLIK code entry field at any time during the payment process. In addition, they should not affect the ability to quickly identify the input field as a BLIK code entry field. | |||
Moving to the next payment step using the commit button |
| Moving to the next payment step after entering a valid BLIK code should be done using a commit button. Recommended button wording: "Pay", "Next". We recommend that the button should not contain an icon inappropriate to its function, e.g. a padlock icon | |||
Empty field for entering the BLIK code |
| The user should receive an error message. We recommend dynamic handling of this type of error.
| |||
Location of the BLIK code input |
| The field for entering the code should be in the same section of the service as the selection of a payment method (the user focusing his/her eyes on the selection of a payment method may not notice that input for entering the BLIK code has appeared in another section). Input for entering the BLIK codes should be visible, immediately identifiable as one where the should enter a BLIK code (and not, for example, a discount code) and not covered by any other system element. | |||
Confirmation in the banking application | |||||
Confirmation in the banking application - user guide |
| If the BLIK code is correct, a message should be displayed prompting the user to confirm the payment in the banking application. On the screen, the user shouldn't have any other actions to perform at this step, the user's attention shouldn't be distracted to confirm the transaction. Recommended text is shown on the screen:
A graphic/icon/animation of the phone is recommended. | |||
Transaction success | |||||
Display of the successful payment status page |
| The shop presents the user with information on successful payment - displaying a thank-you page for the purchase. | |||
Display of thanks page for purchase - commit button |
| We recommend adding a commit button to return to the order details page instead of using an automatic redirect. | |||
Authorization errors | |||||
Unsuccessful transaction - displaying status information and clearing the BLIK code entry field |
| When an error occurs:
| |||
Wrong BLIK code |
| The user should receive an error message. Recommended content: "Incorrect BLIK code was entered. Try again." | |||
Expired BLIK code |
| The user should receive an error message. Recommended content:
| |||
Cancelled BLIK code |
| The user should receive an error message. Recommended content:
| |||
Used BLIK code |
| The user should receive an error message. Recommended content:
| |||
Insufficient funds |
| The user should receive an error message. Recommended content:
| |||
Exceeding the transaction limit |
| The user should receive an error message. Recommended content:
| |||
Rejection due to incorrect PIN |
| The user should receive an error message. Recommended content:
| |||
Rejection by the user |
| The user should receive an error message. Recommended content:
| |||
User timeout |
| The user should receive an error message. Recommended content:
| |||
System timeout |
| The user should receive an error message. Recommended content:
| |||
Mobile app timeout |
| The user should receive an error message. Recommended content:
|
Level 0 z OneClick UID - an extension of the guidelines for Payments without a BLIK code
Requirement
Recommendation
Value | Area | Scenario | Expected result | Example ENG | Example PL |
---|---|---|---|---|---|
Payment method presentation | |||||
Visibility of the BLIK logo |
| The BLIK payment method is marked with the BLIK logo. The logotype used is consistent with the BLIK brand book. | |||
BLIK is first on the list of payment methods |
| We encourage you to display BLIK first on the list, as it is the most popular online payment method in Poland. | |||
BLIK in Level 0 on the first screen for selecting a payment method |
| BLIK must be a visible, selectable form of payment directly from the shop's service. If the user didn't save the shop in the mobile app, the "BLIK" payment method is first on the payment methods list (as it is the most popular online payment method in Poland). If the user saves the shop the first method on the list of payment methods is "BLIK without code" (with the mobile app label displayed), followed by "BLIK with code" (the name of the "BLIK" payment method changes to "BLIK with code" when the user remembers the shop). | |||
Rules of spelling |
| All references to BLIK are written in capital letters. | BLIK | BLIK, BLIKIEM, BLIKOWI itd. | |
Alias registration | |||||
Payments without the BLIK code are only available for users logged in to the shop's service |
| Payments without the BLIK code in the Level 0 OneClick model should only be available to users logged in to the shop's service. If the user is not logged in to the shop's service, the invitation to remember the shop shouldn't be displayed in the bank application, where the user confirms the payment. | |||
Parameters for saving the shop in the banking app |
| With each BLIK transaction, the shop sends the parameters needed to display and create an invitation to remember the shop in the user's banking application (registering the Alias UID). These parameters are:
| |||
Aliases management |
| Aliases can only be managed (saved/deleted) from within the bank's mobile app. It is not possible to execute Payment without a BLIK code using a deleted or expired Alias. The "BLIK without code" payment method is not visible in the list of payment methods. Only the "BLIK" method is available in the list of payment methods.
| |||
The way to mask Alias UID label data |
| If the shop uses customer data as an Alias label, the data are masked, e.g: The recommended rule for email masking: shorten by replacing all characters except the first and last two with three dots. If there is an @ in the string, then both parts of the string are divided by @ | |||
Selection of a saved alias and initiation of a transaction | |||||
No registered Alias |
| If Alias is not registered, the only payment method available in the shop's system is BLIK and the user can only pay using the BLIK code. | |||
Choice of Alias |
| If the user saves the shop the first method on the list of payment methods is "BLIK without code" (with the mobile app label displayed), followed by "BLIK with code" (the name of the "BLIK" payment method changes to "BLIK with code" when the user remembers the shop). | |||
Multi-banking |
| Saved Aliases are visible in both banking app X and banking app Y. Saved Aliases have the same label and expiry date set accordingly - in line with the data sent by the shop. | |||
Multi-banking - presentation of a list of multiple aliases |
| If more than 1 alias is saved, the shop presents all saved aliases. The user has the option to select one of the saved aliases:
| |||
Multi-banking - authorization in selected banking app |
| The selected Alias triggers authorization in the selected Mobile Application. The transaction is completed successfully. | |||
Change of choice to payment with the BLIK code |
| The user has the option to change the payment method - from "BLIK without code" to "BLIK with code". | |||
First payment without BLIK code - one-time information |
| If this is the user's first payment after registering the alias, a one-off message explaining how OneClick payments work should be presented to the user. Alternatively, you can display this information with each BLIK payment without a code. Recommended content:
| |||
Multiagent handling | - | It is also possible to use UID and PAYID Aliases if the shop uses more than one integrator providing it with the BLIK payment service (Multiagent option). In such a case, it may happen that the Alias registered as a result of a transaction sent via one integrator is used to complete a transaction via another integrator. In order for such a transaction to be processed, the value of the Alias sent to the BLIK system for a given customer should have the same value regardless of the selected intermediary operator for the transaction (i.e. the operator should not interfere with the value of the Alias), and the Shop should notify its agent in advance of its wish to use the Multiagent option. | |||
Confirmation in the banking application | |||||
Confirmation in the banking application - user guide |
| A screen appears instructing to confirm the payment in the banking app. On the screen, the user shouldn't have any other actions to perform at this step, the user's attention shouldn't be distracted to confirm the transaction. Recommended text is shown on the screen: "Confirm the payment in your banking app". A graphic/icon/animation of the phone is recommended. | |||
Transaction success | |||||
Display of the successful payment status page |
| The shop presents the user with information on successful payment - displaying a thank-you page for the purchase. | |||
Display of thanks page for purchase - commit button |
| We recommend adding a commit button to return to the order details page instead of using an automatic redirect. | |||
Authorization errors | |||||
Unsuccessful transaction - display of status information and possibility to repeat the transaction (only with BLIK code) |
| In the case of transactions without a BLIK code, when an error occurs:
| |||
Incorrect BLIK code on repeat - input cleaning |
| In the case of a transaction with the BLIK code, when an error occurs that allows the transaction to be repeated, the field for entering the code is cleared and the user can immediately enter a new code. | |||
Wrong BLIK code |
| The user should receive an error message. Recommended content:
| |||
Expired BLIK code |
| The user should receive an error message. Recommended content:
| |||
Cancelled BLIK code |
| The user should receive an error message. Recommended content:
| |||
Used BLIK code |
| The user should receive an error message. Recommended content:
| |||
Insufficient funds |
| The user should receive an error message. Recommended content:
| |||
Exceeding the transaction limit |
| The user should receive an error message. Recommended content:
| |||
Rejection due to incorrect PIN |
| The user should receive an error message. Recommended content:
| |||
Rejection by the user |
| The user should receive an error message. Recommended content:
| |||
User timeout |
| The user should receive an error message. Recommended content:
| |||
System timeout |
| The user should receive an error message. Recommended content:
| |||
Mobile app timeout |
| The user should receive an error message. Recommended content:
| |||
Too high amount |
| The user should receive an error message. Recommended content:
presented on a full-screen failure message (without the possibility to enter a code) | |||
Alias rejection |
| The user should receive an error message. Recommended content:
| |||
General error |
| The user should receive an error message. Recommended content:
| |||
TAS error |
| The user should receive an error message. Recommended content:
| |||
System error |
| The user should receive an error message. Recommended content:
| |||
Issuer rejection |
| The user should receive an error message. Recommended content:
| |||
Invalidation of a transaction after TIMEOUT |
| In the event that a transaction is deemed to have failed after a In the event of unsuccessful registration of the invalidation, the shop should repeat the invalidation at increasing intervals, no less than until the end of the next business day and no longer than 7 days. |