## Transaction requirement
In order to carry out the transaction correctly, merchant’s website should offer transaction registering as well as handling transaction result.
# Definitions
**CVV** – card verification value/code.
**Cyclic Redundancy Check (CRC)** – unique key (String) obtained from Przelewy24 used to generate the checksum of the parameters sent.
**Dynamic Currency Conversion (DCC)** – process whereby the amount of card transaction is converted to the currency of the payment card’s country of issue at the point of sale.
**Merchant** – an institution or a private person using Przelewy24 services.
**Session ID** – unique ID used to identify single transaction in merchant system.
# Use cases
## How to display a full selection of payment methods in your shop?
In order to facilitate the process of payment, it is possible to move the customer's selection of payment method to the very stage of placing an order. If the customer additionally accepts the terms and conditions of Przelewy24 (in the request, you need to set 
Please note that the components of the sign checksum differ for individual requests sent or received from Przelewy24. The sign parameter value that must be passed in the transaction registration request is different from the sign value passed for the transaction verification request.
Examples of calculating the sign checksum for a transaction registration request:
PHP
JavaScript
Java
Python
$params = [
'sessionId' => 'unique-session-id', // Here you should put the unique generated session ID
'merchantId' => 999999, // Here you should put the Seller ID from the Przelewy24 panel
'amount' => 1234, // Here you should put the transaction amount in groszy, 1234 means PLN 12.34
'currency' => 'PLN', // Transaction currency should be placed here
'crc' => 'crc-z-panelu-p24', // Here you should place the CRC key downloaded from the Przelewy24 panel
];
// Combining parameters into a string
$combinedString = json_encode($params, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);
// Hashing with SHA-384
$hash = hash('sha384', $combinedString);
echo 'The checksum of the parameters is: ' . $hash;
const params = {
sessionId: "unique-session-id", // Here you should put the unique generated session ID
merchantId: 999999, // Here you should put the Seller ID from the Przelewy24 panel
amount: 1234, // Here you should put the transaction amount in groszy, 1234 means PLN 12.34
currency: "PLN", // Transaction currency should be placed here
crc: "crc-z-panelu-p24" // Here you should place the CRC key downloaded from the Przelewy24 panel
};
// Combining parameters into a string
const combinedString = JSON.stringify(params);
// Hashing with SHA-384
const hash = crypto.createHash('sha384').update(combinedString).digest('hex');
console.log('The checksum of the parameters is:', hash);
import hashlib
# Parameters in JSON format
json_string = '{"sessionId":"sessionId","merchantId":999999,"amount":1000,"currency":"PLN","crc":"crc"}'
# Hashing with SHA-384
checksum = hashlib.sha384(json_string.encode('utf-8')).hexdigest()
print('The checksum of the parameters is:', checksum)
import com.fasterxml.jackson.databind.ObjectMapper;
import java.nio.charset.StandardCharsets;
import java.security.MessageDigest;
public class ChecksumExample {
public static void main(String[] args) throws Exception {
String json = createJson("sessionId", 999999, 1000, "PLN", "crc");
String checksum = calculateChecksum(json);
System.out.println("The checksum of the parameters is: " + checksum);
}
private static String createJson(String sessionId, int merchantId, int amount, String currency, String crc) throws Exception {
return new ObjectMapper().writeValueAsString(Map.of(
"sessionId", sessionId,
"merchantId", merchantId,
"amount", amount,
"currency", currency,
"crc", crc
));
}
private static String calculateChecksum(String json) throws Exception {
byte[] hash = MessageDigest.getInstance("SHA-384").digest(json.getBytes(StandardCharsets.UTF_8));
StringBuilder hexString = new StringBuilder();
for (byte b : hash) {
hexString.append(String.format("%02x", b));
}
return hexString.toString();
}
}
Examples of calculating the sign checksum for a transaction verification request:
PHP
JavaScript
Java
Python
$params = [
'sessionId' => 'unique-session-id', // Here you should put the unique generated session ID
'orderId' => 999999, // Here you should put the numeric transaction ID received e.g. from a notification
'amount' => 1234, // Here you should put the transaction amount in groszy, 1234 means PLN 12.34
'currency' => 'PLN', // Transaction currency should be placed here
'crc' => 'crc-z-panelu-p24', // Here you should place the CRC key downloaded from the Przelewy24 panel
];
// Combining parameters into a string
$combinedString = json_encode($params, JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES);
// Hashing with SHA-384
$hash = hash('sha384', $combinedString);
echo 'The checksum of the parameters is: ' . $hash;
const params = {
sessionId: "unique-session-id", // Here you should put the unique generated session ID
orderId: 999999, // Here you should put the numeric transaction ID received e.g. from a notification
amount: 1234, // Here you should put the transaction amount in groszy, 1234 means PLN 12.34
currency: "PLN", // Transaction currency should be placed here
crc: "crc-z-panelu-p24" // Here you should place the CRC key downloaded from the Przelewy24 panel
};
// Combining parameters into a string
const combinedString = JSON.stringify(params);
// Hashing with SHA-384
const hash = crypto.createHash('sha384').update(combinedString).digest('hex');
console.log('The checksum of the parameters is:', hash);
import hashlib
# Parameters in JSON format
json_string = '{"sessionId":"sessionId","orderId":999999,"amount":1000,"currency":"PLN","crc":"crc"}'
# Hashing with SHA-384
checksum = hashlib.sha384(json_string.encode('utf-8')).hexdigest()
print('The checksum of the parameters is:', checksum)
import com.fasterxml.jackson.databind.ObjectMapper;
import java.nio.charset.StandardCharsets;
import java.security.MessageDigest;
public class ChecksumExample {
public static void main(String[] args) throws Exception {
String json = createJson("sessionId", 999999, 1000, "PLN", "crc");
String checksum = calculateChecksum(json);
System.out.println("The checksum of the parameters is: " + checksum);
}
private static String createJson(String sessionId, int orderId, int amount, String currency, String crc) throws Exception {
return new ObjectMapper().writeValueAsString(Map.of(
"sessionId", sessionId,
"orderId", orderId,
"amount", amount,
"currency", currency,
"crc", crc
));
}
private static String calculateChecksum(String json) throws Exception {
byte[] hash = MessageDigest.getInstance("SHA-384").digest(json.getBytes(StandardCharsets.UTF_8));
StringBuilder hexString = new StringBuilder();
for (byte b : hash) {
hexString.append(String.format("%02x", b));
}
return hexString.toString();
}
}
####BLIK#### - name: BLIK Use Cases x-displayName: BLIK Use Cases description: > # Introduction In addition to the standard payment based on redirection to P24 paymantwall, it is also possible to place Blik payments on the Merchant website. # How to place BLIK payment on the merchant's website? (BLIK level 0) Transaction may process with paymentMethod/blik/chargeByCode method. It's necessary to previously register transaction using transaction/register method. In this case only “token” and “blikCode” parameters are mandatory in paymentMethod/blik/chargeByCode method.
# What is 1-click BLIK payment?
As the name suggests the payment allows to make purchases with one click. It doesn't require entering the BLIK code, only simple one-click acceptance in the application.
# How to get information about an alias?
There are two ways to get information about an alias:
1. Acquiring information by handling asynchronous notification. (recommended)
2. In order to receive an alias for subsequent payments, call the getAliasesByEmail method.
The method returns a list of aliases (along with the type and status) created for a given e-mail address in the scope of a given merchant.
For Aliases registered with values call getAliasesByEmail{email}/custom
Due to the asynchronous character of the transaction status processing, the getAliasesByEmail method may return the current status of aliases within up to 60 seconds following a correctly performed transaction.
# How to register an alias for use in 1-click payment?
Transaction may process with paymentMethod/blik/chargeByCode method. The service allows to assign individual alias value and alias label value in input parameters.
If parameter “referenceRegister” = true during transaction registration process, the Alias registration request is transferred to BLIK and the Customer receives an invitation generated by the bank application to pay without the T6 code, in the merchant’s system.
Once this method is called, the amount provided during transaction registration is charged and alias is registered in P24/BLIK system.
Created alias may be used for processing OneClick payments.
Once the alias is registered, the Customer will not be asked to provide T6 code during the next payments.
In order to register another mobile application in BLIK system, method paymentMethod/blik/chargeByCode should be used with a 6-digit BLIK code generated by the application. The transaction in P24 must be registered on the same customer’s e-mail address.
The alias is created based on the e-mail address provided during transaction registration process. This means that only one alias of a given type may be registered on this e-mail address unless “aliasValue” and “aliasLabel” parameters are used.
In order to register more than one alias for provided e-mail address, include the alias value and alias label. This way merchant would assure that aliases are unique. The list of merchant’s aliases for a given e-mail may be obtained by getAliasesByEmail method. It is possible to register the same alias defined by the merchant with several e-mail addresses. In this case, getAliasesByEmail returns the same alias value for each e-mail.
# How to make a 1-click payment (only 1-click)?
ChargeByAlias is a one click payment method. It allows to charge customer using a previously obtained alias. Alias obtained must be provided in methodRefId parameter during transaction registration (transaction/register). Please use type=alias.
# How to handle two registered applications for one alias (only 1-click)? The method ChargeByAlias allows to charge customer using previously obtained alias and an “alternativeKey” key identifying customer’s mobile application. Additional parameter "alternativeKey" is used.
This method may be used only if chargeByAlias method returns „alias” type with error code 51 and http code 409 (the alias selected for the identification is ambiguous!) as well as the list of alternative keys identifying the customer’s mobile applications – "AliasAlternative".
The customer should select proper mobile application as a payment method. Alias should be selected from the "AliasAlternative" list.
This method is used with the "alternativeKey" type, only if the customer has more that one mobile application linked to the same UID type alias.
In case of receiving error 51, merchant should not record alternative keys and labels. These data are subject to change at the bank – by user in the bank application.
# How to handle with an expired token? (only 1-click) When a transaction is rejected due to error 68 (customer’s alias expired), you must re-register the transaction with a new alias - according to the information in section register an alias.
# What is BLIK recurring payment? BLIK recurring payment allows to make payments on the basis of a previously obtained alias. Merchant is the payment initiator.
There are 3 service models supported:
► **M** - merchant who wants to execute recurring transactions for a variable amount sends an invitation to create a recurring payment in the M model. Each recurring payment for a variable amount is authorized by the bank after it's confirmed by the User in the bank application.
► **A** - merchant who wants to execute recurring transactions for a fixed amount sends an invitation to create a recurring payment in model A with additional payment details. Each recurring payment for fixed amount is automatically authorized by the bank.
► **O** - merchant who wants to execute recurring transactions for a variable amount sends an invitation to create a recurring payment in model O with additional payment details. Each recurring payment for variable amount is authorized automatically by the bank.
# Requirements for implementing BLIK Recurring Payments In order to implement BLIK recurring payments, the following requirements must be met in accordance with BLIK Guidelines. # How to register an alias for recurring payments (PAYID)? Recurring invitation is called analogically to one-click – method paymentMethod/blik/chargeByCode - with additional “recurring” object. If the parameter "referenceRegister" = true is passed on transaction registration, the alias registration request will be sent to BLIK and the customer will receive invitation in the bank application to pay without the T6 code in the shop.
# How to set up payment frequency (only PAYID)?
To define recurring payment frequency following data should be passed:- Length of payment period, expressed in units of measurement.
- Units of measurement (D = Day, W = Week, M = Month, Q = Quarter, Y = Year).
- Type of day of payment execution (A = indicated day, N = next working day, P = Previous working day, W = Only working days).
- The day on which the first transaction will be initiated, counted from the date of sending the invitation (0 = the same day, 1=the next day, etc.). An „E” instead of number indicates the last day of a current period (point 2.).
If designated day of recurring payment falls on day which not exist in present month (eg. 31st of April) payment is executed on last day of month (30th of April).
Data provided in 3-4 are not automatic authorization criteria and are not presented to the User at the stage of creating an invitation. Data are used to supply “spending planners”.
Examples:
1MA0 - recurring payment will be executed every month at current day: 03.09.2019 (current day), 03.10.2019 (next payment)
1MAE - recurring payment will be executed on every last day of month 30.09.2019, 31.10.2019, 30.11.2019 etc.
# How to change PAYID during payment referenced by alias (only PAYID)?
You can change the PAYID during recurring payment. A new invitation is sent to the client which must be accepted.Afterwards, the API request should send the entire content of the invitation, not just changed parts.
Use the method: ChargeByAlias with the “recurring” object. # How to test BLIK (white label) in Sandbox? To test the BLIK White label payment using the T6 code in the Sandbox environment, use the 6-digit BLIK code in the format 777XXX for a successful transaction, where X is any digit from 0-9. To simulate a failed transaction, use any 6 digits. We also recommend not using the same BLIK code in short intervals to ensure correct answers. # Transfer title visible in the client's application? By default a client in their bank application sees the P24 transaction number as the main title. Additional lines also show the information passed in the description parameter in the transaction/register request, as an auxiliary value.
The customer could see personalized value sent by the merchant instead of the main P24 transaction title. In this case, the transaction/register request should contain the transferLabel parameter, which rewrites the main payment title.
- name: BLIK Additional x-displayName: BLIK Additional Notification description: > For any of BLIK type transaction, additional payment status notification is provided.
Notification is sent to the url given in the "urlCardPaymentNotification" parameter, which must be added to the transaction/register method, or to a fixed address saved in the P24 account configuration. The value from the token, if it was sent, is paramount.
Note! Please note that for the BLIK Pay Later payment method, the P24 system does not send additional notifications.
Introduction
To implement standard card transactions processed via P24 paymentwall, it is enough to perform standard integration (payment service) and there is no need to implement the following solutions. The solutions described below are additional card functionalities.
Card featuers are not enabled by deufalt, the scope of the card functionality and testing methods depend on the Acquirer. Please contact the support stuff via contact form.
# How to make in-shop card payment
In order to limit the number of steps in the payment process, it is possible to place the payment card form directly on the shop’s website. The implementation of the solution does not affect the processing of the credit card data – it is still run solely by Przelewy24, which allows to preserve all the safety requirements regarding the security of credit cards and to conform to the PCI DSS standard.
In order to carry out payments by payment cards, it is necessary to use the transaction/register method in order to register transaction in Przelewy24 and, subsequently, transfer the received transaction token for the call made by Przelewy24 JavaScript. The data provided in the form are transferred directly to Przelewy24, and, as a result, script on the shop’s part (indicated in the configuration) is activated.
A suitable contract is necessary for realisation of payments by payment cards on the shop’s website – please contact the Sales Department of Przelewy24 via contact form.
In-shop card payment process
- Transaction registration by transaction/register method, obtaining of a transaction token - Building DIV element on the merchant’s website for card payment form - Preparation of the JavaScript code which will be called on completion of the transaction
Field for card payment form
DIV element may be used to prepare the location on the website where the card payment form should be placed. The ID attribute of this element should be set to "P24FormContainer". Code should look as follow: ```html| GET | https://secure.przelewy24.pl/inchtml/ajaxPayment/ajax.js?token={TOKEN} |
|---|
URL for default styles:
https://secure.przelewy24.pl/inchtml/ajaxPayment/ajax.css In case of 3D-Secure required, link redirecting to new authorisation window will appear. After successful authorisation window will be closed and function for correct transaction will be called. The return address provided in "urlReturn" parameter should lead to the script placed in the same domain as the request script. It should enable the following function: ```javascript window.setTimeout(function(){ opener.P24_Transaction.threeDSReturn(window); window.close(); },1000); ``` # How to register a card or make a payment? 1. The card registration should be made as a normal payment. Card payment can be made in 3 ways: - p24 paymentwall - direct API (card / pay) - if card data is processed by Merchant resources, the solution requires PCI DSS
- form inside the store
2. Then, by card/info or additional notification, you can get information about the card, including the reference number necessary for subsequent charges.
3. Then, depending on whether we want to accept the payment, we perform transaction/verify or transaction/reject, if it was only a sample payment, e.g. for 1 PLN.
# How to get card information?
There are two ways to get information about a card:
- Use method card/info
- Use additional notification
The notification can be used for any card transactions:
- in the card/chargeWiths3ds, card/charge, card/pay processes for immediately displaying a message to a customer about a successful / failed transaction
- in the RISK process on the part of the Partner to check the client's card and protect against fraud
- when saving the card to the 1-click process, there is no need to ask for the card reference number
Card reference number must be provided during transaction registration in methodRefId parameter.
-->
# How to make a 1-click card payment with 3DS?
The dedicated card/chargeWith3ds method is used for this purpose.Card reference number must be provided during transaction registration in methodRefId parameter.
The method will return a link to redirect the client and handle 3ds.
# How to handle payments without customer participation (recurring)?
The method card/charge enables recurrent card charging based on transferred reference number. Card reference number must be provided during transaction registration in methodRefId parameter
The refId parameter value obtained from transactions paid through wallet methods (e.g., Google Pay, Apple Pay, VISA Mobile) cannot be applied to recurring payments. Attempting to pay such a transaction will result in an error and ultimately a failure to process the payment.
Customer’s participation is not required to initiate the process.
# How to handle 3ds (including 3ds 2.X)? Both 3ds and 3ds 2.X are handled in the same way. 3ds is handled automaticlly for solutions based on p24 paymentwall or form inside the store. Merchant doesn't have to do anything.
During registration process 3D-Secure service may be enabled (disabled by default). In case it is enabled, additional notification containing the address for redirection to 3D-Secure (to be defined in the P24 panel) is sent.
In case using card/pay or card/chargeWith3ds method for this purpose, you should redirect customer to the URL obtained from the answer.
Remember that after 3ds, the client will always be redirected to urlReturn. Merchant must process customer’s return from the bank website on their own. The returned link is active for 15 minutes.
# How to register a card or pay in a mobile application? Card registration or payment in the mobile application can be done in two suggested ways. You can open a p24 paymentwall in WebView, preferably with forced payment method for given cards. Another way is to use the card/pay method. Remember that the card/pay method should be called directly from the application to P24 without the participation of Merchant servers. Otherwise, you'll need a PCI DSS certificate. # How to test cards in a Sandbox environment? To test card payments in a test environment, use the card numbers from the Saferpay documentation and any date as an expiry date from the future and a random 3-digit CVV.
To test Google Pay, we recommend joining the Google Google Pay API Test Cards Allowlist - Google Groups development group. After joining the group, several test card numbers (from Google) will be assigned to your Google account, selectable after pressing the Google Pay payment button. Please note that card services are not enabled by default for the production or sandbox environment. # Will the Merchant process full card details? PCI DSS certification is required to process full card data. P24 solutions support operations performed this way.
However, many solutions provide full card functionality, in which Merchant doesn't use full card data and therefore is no need to have PCI DSS. In such situations, Merchant only obtains the card's reference number (e.g. for later 1-click payments or recurring charges) and a set of insensitive data such as expiration date or BIN.
- name: Card Notification x-displayName: Card Additional Notification description: > Notification is sent to the url given in the "urlCardPaymentNotification" parameter, which must be added to the transaction/register method, or to a fixed address saved in the P24 account configuration. The value from the token, if it was sent, is paramount.
**For positive authorization**
In case the authorisation/pre-authorisation fails, following options are possible:
- cancellation of card authorisation/pre-authorisation – takes place when merchant does not send confirmation of concluded transaction to the card organisation. Funds are not transferred to merchant and the amount blocked on the customer’s card is released
The service allows to separate the following steps: Authorisation, Capture. ## Service implementation The implementation of the service is analogous to REST v1 standard process. ## Transaction registration CARD The transaction is registered by transaction/register method. ## Notification obtaining Notification obtaining proceeds as in the case of a standard transaction. Once the notification is sent, the card payment is only authorised, i.e. a blocked amount appears on the account of the cardholder. If verification is not successful, the payment will not be cleared and the blocked amount is released. In case of the above mentioned functionality, the system does not expect any return transaction verification. The transaction is considered as completed once merchant responds with code HTTP 200. If there is no correct response, the notification is re-sent at the same time intervals as in standard cases. ## Transaction verification Transaction verification is carried out with the transaction/verify method. The only difference is that it is possible to send smaller amount than amount of Pre-authorisation, (i.e. the amount provided during token registration). The amount must be higher than 0. The "sign" parameter is calculated based on the current value of "amount" parameter. Transaction amount is overwritten. As a result of a successful verification, authorisation completion (capture) including the amount of the verification is sent to the card operator. Requested amount is transferred for clearing and the remaining amount is released. Transaction status changes to 2 (completed). In case of an incorrect status on the card operator side, the P24 transaction changes its status to current and a relevant notification is generated in the API. ## Transaction rejection The release of funds (cancellation of authorisation) is carried out with the transaction/reject method. Transaction cancellation request is sent to the card operator and the P24 transaction changes its status to 3 (returned). In case of incorrect status on the card operator side, the P24 transaction changes its status to current, and a relevant notification is generated in the API. ## One-click and recurrence One-click and recurrence proceed analogically to the traditional payment. The process has been devided into two stages (authorisation and capture). Pre-authorisation process is available only in REST communication, which requires transaction verification. ## Collecting card details Collecting card details from pre-authorised transactions proceeds as in the case of the traditional payment so it is delivered by additional notification. It is also possible to use the REST Card/Info method. ####END CARD#### - name: Additional services Additional Notifications x-displayName: Additional asynchronous notifications for transactions description: > For payment methods (e.g., installments or PIS payments) that require additional information about the transaction, it is possible to obtain additional notifications. To declare the return address, pass the `urlNotify` parameter during the transaction registration request.
Output parameters
| Field name | Type | Description | |---------------|:---------------------|:----------------------| | orderId | INT| Transaction number assigned by P24 | | sessionId | STRING | Unique identifier from merchant's system | | method | INT | Payment method used by customer (e.g. for installment payments = 303)| | result | OBJECT | Transaction result object, individual for each method| | merchantId | INT | Merchant identification number | | posId | INT | Shop identification number (defaults to merchant ID)| | sign | STRING | Checksum of parameters calculated with the use of sha384:({"merchantId":int,"posId":int,"orderId":int,"sessionId":"string","method":int,"result":"object", "crc":"string"}) |
Result object
| Field name | Type | Description | |---------------|:---------------------|:----------------------| | generalStatus | STRING | General status of transaction | | detailedStatus | STRING | Detailed status od transactionthe value depending on banks | | paymentId | STRING | Payment identification number | | provider | STRING | Installment provider (given only for installment payments) |
IMPORTANT! In case json_encode function is used, the following attributes should be added "JSON_UNESCAPED_UNICODE | JSON_UNESCAPED_SLASHES"
The notification for a correctly booked transaction
```json { "orderId":int, "sessionId":"string", "method":int, "result": { "generalStatus":"done", "detailedStatus":"string", "paymentId":"string", "provider":"string" }, "merchantId":int, "posId":int, "sign":"string" } ```The notification for a transaction awaiting bank confirmation
```json { "orderId":int, "sessionId":"string", "method":int, "result": { "generalStatus":"done", "detailedStatus":"string", "paymentId":"string", "provider":"string" }, "merchantId":int, "posId":int, "sign":"string" } ```The notification for a transaction accepted for execution by the bank
```json { "orderId":int, "sessionId":"string", "method":int, "result": { "generalStatus":"done", "detailedStatus":"string", "paymentId":"string", "provider":"string" }, "merchantId":int, "posId":int, "sign":"string" } ```The notification for a rejected transaction
```json { "orderId":int, "sessionId":"string", "method":int, "result": { "generalStatus":"done", "detailedStatus":"string", "paymentId":"string", "provider":"string" }, "merchantId":int, "posId":int, "sign":"string" } ```The notification for a pending transaction (waiting for execution by the bank)
```json { "orderId":int, "sessionId":"string", "method":int, "result": { "generalStatus":"done", "detailedStatus":"string", "paymentId":"string", "provider":"string" }, "merchantId":int, "posId":int, "sign":"string" } ```The notification for a cancelled transaction
```json { "orderId":int, "sessionId":"string", "method":int, "result": { "generalStatus":"done", "detailedStatus":"string", "paymentId":"string", "provider":"string" }, "merchantId":int, "posId":int, "sign":"string" } ``` ####GPAY#### - name: GPay Description x-displayName: Google Pay Description description: >
Google Pay is fast and simple method of payments offered by Google. Card details are safely stored on Google servers. Service allows users to perform the payment process without manually filling card details or contact form.
Google Pay allows to obtain the customer’s encrypted card details which are required to charge it. In order to proceed Google Pay payment, customer first must save payment card details in Google account using any Google platform (e.g. purchasing an application in Google Play, paying for storage on Google Drive, etc.) or directly on https://pay.google.com
In order to use the service, a relevant contract with the card operator must be signed first. To enable this functionality, contact Partner Support via contact form
## Communication scheme
Once the customer clicks „Pay with Google Pay” button, the Google Pay form is displayed. This form allows customer to confirm Google account and choose card to be used for payment process. At this stage card may be changed to a different one (previously saved) or new card may be added. Google Pay script displays encrypted card details using postMessage function which the shop must intercept, encrypt once again using the base64 function and send in "methodRefId" parameter along with the transaction data.Merchant’s system may call the script available on Google’s website. Details available at:
https://developers.google.com/pay/api/web/guides/tutorial
In order to add P24, it is necessary to modify the processor’s data in the script call: ```javascript var tokenizationSpecification = { tokenizationType: 'PAYMENT_GATEWAY', parameters: { gateway: 'przelewy24', gatewayMerchantId: '[MerchantID from P24]' } } ``` ## Transaction registration In order to register Google Pay transaction, additional "methodRefId" parameter must be used. The parameter can be obtained from Google by **postMessage (paymentMethodToken.token)** and should be encrypted with base64 encryption.
| POST | https://secure.przelewy24.pl/api/v1/transaction/register |
|---|
Introduction
Thanks to Apple Pay, you don't have to set up any accounts or fill out long forms when shopping on websites opened in Safari on your iPhone, iPad or Mac. And because the Touch ID reader is also available in the MacBook Air and MacBook Pro, finalizing the transaction requires only a fingerprint and is faster, easier and safer than before.
## Description
During the shopping process, Apple Pay uses the number assigned to a specific device and a unique transaction code. As a result, your card number is never stored on your device or Apple servers. And at the time of payment, Apple never makes card numbers available to sellers.
The service requires prior signing of the contract with the card operator, for detailed information please contact the Sales Department of Przelewy24).
## Creating Merchant ID And Domain Certification
Transaction processing via ApplePay requires the Seller to create a merchant and pass domain certification. The process is described at https://developer.apple.com/documentation/apple_pay_on_the_web/configuring_your_environment.
## Creating Apple Pay Payment Processing Certificate
Before proceeding with the process of creating a certificate, obtain a CSR file (for detailed information, please contact the Implementation Department of Przelewy24 via contact form/a>).
After logging in to your Apple Developer account: - select the Certificates, IDs & Profiles option, - select the Identifiers / Merchant IDs option, - select the Merchant ID created in the previous step and go to the Edit option, - select the Create Certificate option in the Apple Pay Payment Processing Certificate section, - select the Continue option, - upload the CSR file received from the Przelewy24 Implementation Department, using the Choose File option, - download the generated certificate and forward it to the Przelewy24 Implementation Department. ## Communication Scheme After clicking the "ApplePay" button, the Apple form appears on the screen, where the user can select a card saved on the device. The background script passes the encoded card data in the paymentData object, which the store must take over, and then encode via base64 again and send it in the methodRefId parameter together with the transaction data. The store on its website must call the script provided by Apple (details available at https://developer.apple.com/documentation/apple_pay_on_the_web). The background script passes the encoded card data, which the store must take over, and then encode via base64 again and send it in the methodRefId parameter together with the transaction data. ## Transaction Registration In order to register Apple Pay transaction, additional "methodRefId" parameter must be used. The parameter can be obtained from Apple by **postMessage (paymentMethodToken.token)** and should be encrypted with base64 encryption.
| POST | https://secure.przelewy24.pl/api/v1/transaction/register |
|---|
Note!
To ensure proper implementation of the solution:
- for card methods method 241 or 242 is required to be enabled - in accordance with business arrangements
- for Google Pay method 264 or 265 is required to be enabled - in accordance with business arrangements
- for Apple Pay method 252 or 253 is required to be enabled - in accordance with business arrangements
```javascript /* Initialize card form */ const P24 = new Przelewy24CardTokenization(merchantId,"sessionId","sign"); /* Render the iFrame form and additional styling settings */ const options = {}; P24.render("type", "#id", options); ``` In order for class P24 to be properly implemented, relevant values for the specific parameters must be provided during the implementation process, consistent with the scheme provided below:
In order for the card form to be displayed correctly on the page, you must call the method `P24.render("type", "#id", options)` where `"type"` means the type of the presented form, `"#id"` is the HTML identifier of the block , where the form is to be displayed, and `options`, which contains additional information about form styling.
`"card"` - clears the card number field,
`"cvv"` - clears the card CVV/CVC field,
`"exp"` - clears the card expiry date field,
`"cardholder"` - clears the cardholder details field.
Calling the function without function arguments results in clearing all the fields of the form. - name: Form initialization v2 x-displayName: Form initialization - SDK (in preparation) description: | Card transaction processing is based on JavaScript downloaded from Przelewy24 server. Payment card and Click to Pay transactions are effected by calling the iFrame window based on the ready-made SDK indicating the Przelewy24 library. The library contains all offered objects and related methods used for correct form integration and customization. Example view of card form without Click to Pay service disabled
Example view of the card form with Click to Pay enabled
Within the Click to Pay service, for the moment there is no possibility to use the payer profile data to permanently enroll data that could later be used for oneClick transactions, recurrences, etc.
## Library
Calling the library for the production environment:
```javascript
```
Calling a library for a sandbox environment:
```javascript
```
## Class Przelewy24CardTokenization
In order to generate a card form in an iFrame window, use the implemented library to define the Transfers24CardTokenization class and call the render method
```javascript /* Initialize card form */ const P24 = new Przelewy24CardTokenization(merchantId,"sessionId","userId","sign"); ``` Class `Przelewy24CardTokenization` parameters should be taken as:
## Method render The render method allows you to indicate in which HTML element you want the iframe to be built and to style it by passing an options object. ```javascript /* Initialize card form */ const P24 = new Przelewy24CardTokenization(merchantId,"sessionId","sign"); /* Render the iFrame form and additional styling settings */ const options = {}; P24.render("type", "#id", options); ``` Take as parameters of the `P24.render()` function:
In addition, there is a simulator that allows you to style the form yourself, then copy the finished code and paste it directly into your project.
{
"lang": "pl",
"c2p": "true",
"psu": {
"email": "Jan.Kowalski@gmail.com"
},
"labels": {
"cardholder": "Imię i nazwisko posiadacza karty",
"card": "Numer karty",
"cvv": "Numer CVV/CVC karty",
"exp": "Data ważności karty"
},
"buttons": {
"tokenize_temporary": {
"label": "Zapisz kartę"
}
},
"styles": {
"font": {
"basic": {
"size": "20px",
"family": "Roboto"
}
}
}
}
{
"c2p": "true",
"psu": {
"email": "Jan.Kowalski@gmail.com"
},
"placeholders": {
"card": "Podaj numer karty",
"cvv": "Podaj numer CVV/CVC karty",
"exp": "Podaj datę ważności karty",
"cardholder": "Podaj imię i nazwisko posiadacza karty"
},
"agreement": {
"contentEnabled": {
"enabled": true,
"checkboxEnabled": false
}
},
"buttons": {
"tokenize": {
"label": "Zapisz kartę"
}
}
}
{
"placeholders": {
"card": "",
"cvv": "",
"exp": "",
"cardholder": ""
},
"agreement": {
"contentEnabled": {
"enabled": true,
"checkboxEnabled": true
}
},
"styles": {
"font": {
"basic": {
"size": "20px",
"family": "Roboto"
}
},
"background": {
"basic": {
"color": "#F6F3FD"
}
}
}
}
- loading event - sent at the beginning of the form rendering. If the options.loader: true parameter was passed in the render method, this is the moment from which the loader will be visible on the Merchant page.
- start event - sent after the form is rendered. It is explicit to close the loader, which was started earlier.
- ready event - sent depending on the status of the completed form by the Payer. Event indicates when a particular button embedded in Merchant's page can be activated. Buttons in the iFrame will automatically activate/deactivate depending on the situation.
- success event - sent after the creation of a token allowing the Payer to charge the payment card
- fail event- sent when problems are detected, e.g. the card number provided by the Payer is incorrect. Example message values for the error parameter:
- minWidth370px - a smaller iframe width than is allowed is given
- cardHolderLabelMaxLength40Chars - the allowed number of characters for the labels.cardholder parameter was exceeded
- buttonTokenizeLabelRequired - no text specified for card data permanent write button
- invalidCardHolder - payer entered incorrect data for cardholder field
- aregulationsIsRequired - the payer did not accept the regulations after checking the checkbox
- invalidTokenizationType - card data cannot be saved. An attempt to save Click to Pay profile data has occurred
- `"permanent"` - allows you to create a permanent token, which you can then use for oneClick or recurring payments,
- `"temporary"` - Allows you to create a temporary token for one-time payments.
Tokenization is performed by calling the `P24.tokenize()` method in the JavaScript code. ```javascript /* Initialize card form */ const P24 = new Przelewy24CardTokenization(merchantId,"sessionId","sign"); /* Render the iFrame form and additional styling settings */ const options = {}; P24.render("type", "#id", options); /* Invoking card tokenization with the appropriate type after pressing the button */ const tokenizeTemp = document.getElementById("tokenizeTemp"); tokenizeTemp.addEventListener('click', function () { P24.tokenize("temporary") }) ``` The `P24.tokenize()` function can take two properties:
Flow of enrollment of card data from Click to Pay. A buttons object and a c2p parameter with the value true have been passed in options. The payer has the Click to Pay profile stored in the device.
During the creation of the iframe on the merchant page, the loading event will be sent. The start event will be passed as soon as the card form view is rendered. According to the assumptions, until the ready enent is passed with the status set to true, the buttons for saving card data must be inactive. Before the view in the iframe is rendered, the verification of the payer's login to Click to Pay by the stored device takes place. If the payer's login to Click to Pay succeeds, an event start will be sent and immediately an event ready with a status of true, but only for the temporary button. At the moment, within Click to Pay there is no possibility to save data pernamentally. When you click on the temporary button, the P24.tokenize method with the temporary parameter will be called. In response, you may see a fail event with an error message or a success event with the data needed to charge the payer. In order to process the payment later, you need to register the transaction and use a dedicated library for this. Read more
Flow of enrollment of card data from Click to Pay. The options passed a buttons object and a c2p parameter with the value true. The payer does not have the Click to Pay profile memorized with the device.
During the creation of the iframe on the merchant page, the loading event will be sent.
The start event will be passed as soon as the card form view is rendered.According to the assumptions, until the ready enent is passed with the status set to true, the buttons for saving card data must be inactive. Before the view in the iframe is rendered, verification of the payer's login to Click to Pay takes place. If it fails, the card form view with the option to log in to Click to Pay is rendered. The payer selects the option to log in to Click to Pay. He enters his email and then the OTP code. Only after the payer correctly logs into the Click to Pay profile will an event be transmitted ready with a status of true for the temporary button. At the moment, there is no way to save data permanently within Click to Pay. When the temporary button is clicked, the P24.tokenize method will be called with the temporary parameter. In response, you may see a fail event with an error message or a success event with the data needed to charge the payer. In order to process the payment later, you need to register the transaction and use a dedicated library for this. Read more
Flow of enrollment of card data from Click to Pay. The options passed a buttons object and a c2p parameter with the value true. The payer sets up a Click to Pay profile
During the creation of the iframe on the merchant page, the loading event will be sent. The start event will be passed immediately after the card form view is rendered. The assumption is that until the ready enent is passed with the status set to true, the buttons for saving card data must be disabled. Before the view is rendered in the iframe, the payer's login to Click to Pay is verified. If it fails, the card form view with the option to log in to Click to Pay will be rendered. An event ready with a status of true for both types of buttons will be sent after the payer completes the required data (name of the cardholder, card number, expiration date and cvv/cvc of the card). In addition, there will be a checkbox with the option to save the card in Click to Pay. Once it is checked, an event ready will be sent with a status of false for both buttons. A 'next' button will appear in the iFrame. After the payer clicks it, an additional view will be presented asking for email address, phone number and country. Once it is completed correctly, an event ready will be sent with a status of true for the temporary button. At the moment, there is no possibility to save data permanently within Click to Pay. When you click on the temporary button, the P24.tokenize method with the temporary parameter will be called. In response, you may see a fail event with an error message or a success event with the data needed to charge the payer. In order to process the payment later, you need to register the transaction and use a dedicated library for this. Read more
- name: Card payment flow
x-displayName: Card payment flow
description: >
The Przelewy24 process allows you to execute card transactions based on standardized JavaScript. The system recognizes the method, userId and transaction registration used and executes the transaction according to them.
One-time payment - register a transaction using transaction/register method with the token that was passed in the refId parameter in the success type event after using cardTokenizationIframe.min.js library. The cardData.means.referenceNumber parameter should pass the refId value and the TransacationType should take the standard value. In the response, a transaction token will be passed, which must be passed when the script is executed: https://{{environment}}.przelewy24.pl/whitelabel/card/javascript/{{token_transakcyjny}}
Recurring payment and oneClik - register a transaction using transaction/register method with the token that was passed in the refId parameter in the success type event after using cardTokenizationIframe.min.js library. In the cardData.means.referenceNumber parameter, the refId value should be passed and the TransacationType should take the initial value. In response, you will be given a transaction token, which you need to pass when executing the script: https://{{environment}}.przelewy24.pl/whitelabel/card/javascript/{{token_transakcyjny}}. Any subsequent use of the token from the refId parameter for subsequent transactions will require a corresponding change in the TransacationType parameter to a value of oneClick or recurring, depending on the type of transaction that will take place.
JavaScript Callback:
```
```
- name: Recursion (doPayment)
x-displayName: Recurrence
description: >
In order to register a recurring transaction, it is necessary to send transaction registration request first to /transaction/register endpoint. . For the transaction to be performed, the `“cardData”` object must be added in the transaction registration request.
```json
{
"cardData": {
"means": {
"card": {
"pan": "1234123412341234",
"expYear": "2027",
"expMonth": "01",
"clientName": "Name and surname",
"securityCode": "123"
}
},
"transcationType": "recurring",
"traceID": ""
}
}
```
Description of the specific parameters of the object:
- the `"card"` object contains card data such as:
- `"pan"` - 16-digit card number
- `"expYear"` - card expiry year
- `"expMonth"` - card expiry month
- `"securityCode"` – CVV/CVC code
- `"transactionType"` - takes the “recurring” value
- `"traceID"` - initiating transaction reference number (required for recurring, if the following have been provided: card, schemeToken)
Provided that all the parameters in the transaction registration request are correct, a token required for `transaction/doPayment` request is returned in response.
- name: Card notification
x-displayName: Card notification
description: >
In case of the forms of payment that require additional information on transaction progress, it is possible to obtain additional notification. In order to declare return address, provide urlNotify parameter during transaction registration
## Posivite notification
In the case of a positive result of the transaction, where payment was made by card, the following notification will be provided:
``` pod 'P24SDKAll', :git => 'https://github.com/przelewy24/p24-sdk-ios.git' ``` ### Initialization Before any action is performed, the following modules must be loaded at application startup: ```json P24.shared.install(modules: [ CardTokenizeModule(), CardChargeModule() ]) ``` - name: Mobile payment (Android) x-displayName: Mobile payment (Android) description: > ## Introduction P24 SDK is a mobile library for Android designed to facilitate various payment processes. It offers a few modules, including `core`, `card-tokenize` and `card-charge`. This documentation focuses on the integration and use of the card-tokenize module for the tokenization of card data with the use of a secure form. - `core` - basic functionalities required for SDK P24 - `card-tokenize` - allows card tokenization via the form - `card-charge` - allows cards to be charged Card Tokenization Module
The `card-tokenize` module allows safe tokenization of card details by means of a nested form. The module provides an easy-to-use interface for collecting and tokenizing card information, which is crucial for ensuring PCI conformity and safe payment processing. ## Card tokenization ### Card tokenize initialization Download and import
The SDK P24 pack is currently available in the form of a .zip file containing Maven repository. In order to add it to your project, perform the following steps: Download the SDK P24 .zip file from the source provided. Next, extract the .zip file to the requested location. Adding to Dependencies
Add the local Maven repository to your build.gradle: ```json repositories { maven { url uri('/path/to/unzipped/repository') } } ``` Add the `core` and `card-tokenize` dependencies to your dependencies block: ```json dependencies { implementation 'pl.p24.sdk:core:1.0.0' implementation 'pl.p24.sdk:card-tokenize:1.0.0' } ``` ### Load module Before you make the first request, it is best to load the module at application startup: ```kotlin P24.install( CardTokenizeModule ) ``` ### Creating a Tokenize Card Request To initialize the card tokenization form, create a `TokenizeCardRequest` using the `TokenizeCardRequestBuilder`. Here’s how to set up and start the process in Kotlin:
Step 1. Create the Request Builder ```kotlin val request = TokenizeCardRequestBuilder() .merchantId("your-merchant-id") .sessionId("your-session-id") .sign("checksum-signature") .allowedModes(setOf(TokenizationMode.Permanent, TokenizationMode.Temporary)) .environment(Environment.Sandbox) .formStyle(FormStyle()) // Example style, actual styles TBD .termsOfServiceConfig(TermsOfServiceConfig()) .callback(object : TokenizationCallback { override fun onStarted() { // Handle start of the tokenization process } override fun onSuccess(tokenizedCard: TokenizedCard) { // Handle successful tokenization } override fun onFailed(errors: List
`sessionId` - The session ID for tracking the request.
`sign` - A checksum or signature for request validation.
`allowedModes` - Set of allowed tokenization modes (`TokenizationMode.Permanent`, `TokenizationMode.Temporary`).
`environment` - Determines the API environment (`Environment.Production`, `Environment.Sandbox`).
`formStyle` - Style of the form. More details provided in section: "Form styling"
`callback` - Call back interface for managing various stages of tokenization.
### Form styling The `FormStyle` class is used for defining the layout of the card tokenization form. It allows to adjust various entry fields and buttons in order to adjust them to the app design and improve user comfort. Components of FormStyle - cardNumber: adjusts the style in the card number field. - cardHolder: adjusts the style in the cardholder field. - cvv: adjusts the style in the CVV field. - expiryDate: adjusts the style in the card expiry date field. - payButton: adjusts the style of the pay button. - saveAndPayButton: adjusts the style of the “Save and Pay” button.
InputStyle and ButtonStyle The `InputStyle` i `ButtonStyle` classes define how the input fields and buttons are styled. Class `InputStyle`: - placeholder: text displayed in the field, the co-called placeholder. - label: text of the label displayed above or next to the entry field. - border: defines the border style, including the border color. - background: entry field background. Class `ButtonStyle`: - label: Text displayed on the button. - color: The background color of the button. - labelColor: The color of the button text.
"Terms of service" configuration The `TermsOfService` class is used to define the behavior and visibility of the Terms of Service (ToS) checkbox in the card tokenization form. It allows customization in order to ensure that users proceed to the payment process only after they have accepted the terms. Components of `TermsOfServiceConfig`: - isVisible: Determines whether the Terms of Service info is visible to the user. The default value is `true`, meaning it will be shown by default. - checkbox: Customizes the behavior and initial state of the checkbox through the `TOSCheckbox` data class.
The `TOSCheckbox` class provides further ToS checkbox adjustment options. - isUserAllowedToChange: indicates whether the user may change the checkbox status. In case the false value is selected, the checkbox will be displayed, yet not interactive. - isChecked: sets the initial state of the checkbox. The default value is false, which indicates that the checkbox is not initially checked. ## Card charge Please download the P24 SDK file `p24-repository.zip` from the provided source. Then, extract the .zip file to your desired location. Then add the repository in Gradle: ``` maven { url("/PATCH_TO_DIR_WITH_REPO/p24-repository") } ``` Then add a dependency in the `dependencies`` section: ```json implementation("pl.p24.sdk:card-charge:0.0.1") ``` Preparing a request for the SDK: ```json val request = P24.cardRequest() .token(p24Token) .environment(Environment.Sandbox) //default Environment.Production .callback { event -> ... } .build() ``` Launching: ```json request.start() ``` Process interruption: ```json request.cancel() ``` Event types: - ProcessStarted - Need3DS - ProcessCompleted - ProcessCanceled - ProcessError ####GPAY#### - name: Google Pay x-displayName: Google Pay description: > ## Communication scheme Once the „Pay with Google Pay” button is clicked, the Google Pay payment form will be displayed on the customer’s screen. The customer confirms their Google account and the card to be used for payment (at this stage, they may change the card to an earlier added one or add a new card). The background script transfers encrypted card data with postMessage function which the shop must receive and subsequently encrypt with Base64 function.
On its website, the shop must call the script made available by Google. For details, see:
https://developers.google.com/pay/api/web/guides/tutorial
In order to add Przelewy24, modify the Processor data in the script call: ```javascript var tokenizationSpecification = { tokenizationType: 'PAYMENT_GATEWAY', parameters: { gateway: 'przelewy24', gatewayMerchantId: '[MerchantID from P24]' } } ``` ## Transaction registration Transaction registration with Google Pay involves adding two additional parameters in the transaction registration request in the `"cardData > means > xPayPayload"` object. The value obtained from Google via postMessage (paymentMethodToken.token) and encrypted with base64 function, as well as the `“type”` parameter with the `“googlepay”` value must be provided in the `“payload”` parameter.
| POST | https://secure.przelewy24.pl/api/v1/transaction/register |
|---|
Creating Apple Pay Payment Processing Certificate:
Before proceeding with the process of creating a certificate, obtain a CSR file (for detailed information, please contact the Implementation Department of Przelewy24 via contact form).
After logging in to your Apple Developer account:
- select the Certificates, IDs & Profiles option,
- select the Identifiers / Merchant IDs option,
- select the Merchant ID created in the previous step and go to the Edit option,
- select the Create Certificate option in the Apple Pay Payment Processing Certificate section,
- select the Continue option,
- upload the CSR file received from the Przelewy24 Implementation Department, using the Choose File option,
- download the generated certificate and forward it to the Przelewy24 Implementation Department.
## Communication Scheme
Once the „ApplePay” button is clicked, the Apple payment form will be displayed on the customer’s screen. The customer selects the card saved in the device. The background script transfers encrypted card data in paymentData object which the shop must receive, subsequently encrypt again with base64 function and send in the transaction registration request.
The store must run the script provided by Apple on its website (details available at: https://developer.apple.com/documentation/apple_pay_on_the_web ).
The script in the background transfers encrypted card data which the shop must receive, subsequently encrypt again with base64 function and send in the payload parameter along with other transaction details.
## Transaction Registration
Transaction registration with Apple Pay involves adding two additional parameters in the transaction registration request in `"cardData > means > xPayPayload"` object. The value obtained via postMessage (paymentMethodToken.token) and encrypted with base64 function, as well as the `“type”` parameter with the `“applepay”` value must be provided in the `“payload”` parameter.
| POST | https://secure.przelewy24.pl/api/v1/transaction/register |
|---|
• on the main webpage,
• on the list of products
• on the product card and
• at checkout
Be aware of the fact that customers who choose to pay in instalments usually have limited funds at their disposal. While still determined to make the purchase, they are looking for the most advantageous offer. Post information on instalments on the main webpage. Use a slider or a top banner.
This is how you’ll reach a wide circle of customers. Newcomers will get the signal that they may pay in instalments.
Add the instalments logo to the payment methods presented in the webpage’s footer. That’s one of the key spots where customers look for information on the payment methods available.
If your website is internally complex (categories, subcategories), place the “Buy in instalments” button on the subpages as well.
Informing customers on the availability of payment in instalments on product cards serves to increase the conversion of this payment method by over 40%, while it is only 8% when the information is provided as late as at the cart stage or at checkout.
The minimum option is static graphic ads. Thanks to them, you will let your customer know that Przelewy24 Instalments service is available.
List of products is yet another spot where you can attract your customers to make quicker shopping decisions or to add additional products to their carts.
Basket / order summary - this is where placing information on instalments is a must.
Home stretch. You don’t want your customer to abandon the cart at this point. Give a clear signal concerning the finalisation of instalment payments. Remember that at this stage the customer will already have selected the payment method, so make sure you keep telling them about instalments from the very start of their purchasing journey.
Checkout - place the instalment payment method at checkout.
To find out how to display a given payment method, visit
How to display the full selection of payment methods on the shop’s website?
By default, the instalment method is available as method=303. Redirection should be done in compliance with the z guidelines
All graphic materials are available here: (https://www.przelewy24.pl/storage/app/media/do-pobrania/p24_raty/p24_raty_materialy_graficzne.zip)
- name: Widget
x-displayName: Widget
description: >
Present the lowest possible instalment for a given product.
Once customers click on the widget, any element may be displayed, for example a pop-up window with information on Przelewy24 I Instalments.
In order to activate the widget, the following java script must be entered:
MINI version
```javascript
```
MAX version
```javascript
```
- name: Simulator
x-displayName: Simulator
description: >
This is a way to increase user engagement. The calculator allows you to present more detailed information about the available installments.
“Clicking through” different installment options will bring the customer closer to the next stage of the purchasing path.
Przykłady gotowych kodów do prezentacji symulatora na stronie
MINI version with click and call calculator in modal
MAXI version with click and call calculator in modal
MINI widget with click and receive link to calculator
MAXI widget with click and receive link to calculator
Custom button with click and calculator call in modal
Custom button with click and receiving link to calculator
MINI version with click and call calculator in modal
```javascript ```MAX version with click and call calculator in modal
```javascript ```MINI widget with click and receive link to calculator
```javascriptMAXI widget with click and receive link to calculator
```javascriptsha384({„crc”:”string”,”posId”:int,”method”:int}) |
| posId | Shop ID (by default Partner ID) |
| method | By default 303 |
| amount | Amount in grosz |
| lang | Allowed: pl |
| currency | Allowed: PLN |
Parameters optional to call the widget or the simulator:
| Parametr | Description |
|--------------|:----------------------|
| test | Allowed: true, false |
When the test parameter is sent with the value `true`, the `sign`, `posId` and `method` fields are not validated, but must instead be passed in the `config` object.