Developer DocumentationsFAQ InPost Pay [ENG]

FAQ InPost Pay [ENG]

  • What is the limit on the number of "suggested" products?

There is no limit to the number of suggested products, however, due to the purpose of the InPost Pay application for mobile devices, it is recommended to add no more than 10 suggested products.

  • How will the communication between the Merchant and InPost Pay be secured? 

Securing of the communication between the Merchant and InPost Pay has been described in the documentation section entitled Merchant Backend API - Headings.

  • What happens if a customer decides to complete a purchase on the Merchant's website? Is the cart deleted from the InPost application?

Purchases finalized on the Merchant's website result in transforming the cart into an order and giving it the status of ORDER_COMPLETED. Such an order is still visible in the InPost Mobile app, but it cannot be paid for or rejected using it.

  • What happens if the price or availability of the product in the store changed before the customer placed the order? 

Each time before placing an order, the InPost Pay application downloads full cart data from the Merchant's website, including the price and product availability (using the GET/v1/izi/basket/{basket_id} method). Then, the downloaded cart is compared with the cart previously stored in the application, and when their values differ - the appropriate message is presented to the customer - the end of the order creation process on the outdated basket. To continue, you need to refresh your cart.

  • Is it possible to keep several carts at the same time at one Merchant?

No, every cart created on the Merchant's website corresponds to one cart in the InPost app. 

  • Free products – can the customer "bypass" the terms of the promotion and add more free products using the function of increasing the quantity in the cart? 

No, the number of free products that can be added is dictated by the terms of the promotion set by the Merchant, and the limitation is made using the iziCanBeBound method.

  • Will the app send a reminder to the customer to finalize the cart? Is it possible to set the time or frequency of notifications according to the Merchant's needs (to avoid sending notifications at unfavourable times in terms of business).

Currently, the solution is not available, it will be introduced in subsequent versions of InPost Pay.

  • When is the cart deleted from the InPost application? Is it possible to set the "on hold" time for the cart?

The storage time of the cart in the InPost Pay application is determined by the Merchant, forwarded to the Basket App in response to POST v1/izi/basket/{basket_id}/confirmation, object "basket_expiration_date".

  • What if the customer (registered) clicks once to add the product to the cart using the InPost Pay widget, and then adds the product using the store button?

Then the product will be added to the store cart, and in the mobile application it will be added to the InPost Pay cart after refreshing it, as a result of Merchant calling the POST/v1/izi/order/{order_id}/event method.

  • What about a store where guest shopping is not possible?

The InPost Pay service is dedicated primarily to customers, who do not want to create a customer account. InPost makes every effort to meet all customer requirements, so contact the InPost Pay Project Manager to jointly develop a solution that satisfies you.

  • Can a customer cancel a paid order? How will it be presented in InPost Pay?

A paid order cannot be canceled from the InPost Pay app. In such situations, the standard return procedure applies.

  • Is the order history presented in InPost Pay?

Yes, in the InPost Mobile application you will find a new "Shopping" section with two tabs: "Carts" and Orders. "Orders" stores all orders, along with their statuses, and after pressing on the selected order, its details will be displayed.

  • What does communication between components look like? Must, for example, the Merchant's backend constantly listen for cart updates from InPost Pay? 

The communication between the components is described in detail and presented on the sequence diagrams in the chapter of the technical documentation entitled Sequence diagrams for InPost Pay & Widget. P.S. You will also find videos with a discussion there;)

  • Does Merchant receive information from InPost Pay about how the customer paid for the order?

Information on the form of payment for the order is provided in the POST v1/izi/order method, in the "payment_type" object, which can be: CARD, CARD_TOKEN, GOOGLE_PAY, APPLE_PAY, BLIK_CODE, BLIK_TOKEN, PAY_BY_LINK, SHOPPING_LIMIT, DEFERRED_PAYMENT, CASH_ON_DELIVERY.

  • What happens if the product(s) selected by the customer cannot be delivered to a parcel locker?

Available forms of shipping and its parameters such as estimated delivery time and price are determined separately for each product in the "delivery_type" object of the POST v1/izi/order method.

  • Will we get access to the test application?

Yes, we will provide you with an app in the UAT environment, where you will be able to simulate the operation of the InPost Pay service.

  • Are Merchant's marketing consents presented to customers in InPost Pay? And how?

Consents presented in InPost Mobile are downloaded from the Merchant's website, in response to the POST/v1/izi/basket/{basket_id}/confirmation containing cart details, including the mandatory "consents" object. It is possible to provide several consents, along with links to their full content (1 link for 1 consent), description, version and requirement (optional, required once, always required). InPost Mobile stores information about consents of the given merchant, so that consents requiring "when new version" are downloaded only once for the respective ID and version of consent. Consents that are "always" required, must be accepted by the user when the order is placed.

  • Is the form of delivery "personal collection" possible as part of InPost Pay? Is it possible to ship with another forwarder?

In the InPost Pay process, only orders with delivery by courier or InPost Paczkomat parcel locker are handled.

  • Can the Merchant's backend ask the Basket App about the payment status?

After making a payment in the mobile application, the Basket App calls the POST/v1/izi/order/{order_id}/event method to the Merchant's backend with information about the payment, which in turn is a trigger for the Merchant to further process the order (packaging and shipping). Merchant has the option of notifying about the next steps in the order fulfillment process using the same method, including, among others, providing the reference number of the shipment.

  • Is the URL shared by/for the Merchant used for two-track communication? 

Yes, the Merchant's backend and the Basket App module are involved in communication. Communication takes place in two ways, the components exchange information on how to link the cart, update the cert, order. A detailed description of the communication is presented in the chapter "Sequence diagrams for InPost Pay & Widget" of the technical documentation.

  • What scope of work is required on the frontend of the Merchant's website? 

The merchant must embed a dedicated widget on their website that communicates with the backend. The rest of the InPost Pay communication takes place between the Merchant's backend and the Basket App in accordance with the diagrams presented in the chapter "Sequence diagrams for InPost Pay & Widget".

  • Why is it required to provide several prices in the product parameterization, including "base price" and "final price"?

Several price fields allow you to present your customers with changes in the price of the product, i.e. the price before and after the discount. 

  • Let's assume that InPost cannot reach the Merchant's endpoind, because the Merchant experiences a server failure and is not responding. And during this time, the customer paid for the order using the mobile application? What happens if there is no communication?

We have queues set up to check the status and communicate with the Merchant, which in such a situation will repeat communication attempts. They are complementary to the possibility of refreshing the cart in the app (force refresh, dragging the cart).

  • We offer products that we do not want to include in the InPost Pay service (due to formal issues). Can it be disabled for selected products?

Yes, the widget's iziCanBeBound method is used to determine the possibility of adding a product to the InPost Pay cart.

  • Why can't I pair the cart with a QR code? There's no reaction from the app!

The reason for the inability to pair the basket with the QR code may be the inability to establish a connection from the Merchant to the Basket App. The reason for the problem may be an incorrectly set service address or an authorization error. Please consult us by sending a request to

  • I have scanned the QR code and successfully paired the shopping cart with the phone number. Unfortunately, when I try to open the cart in the app, I get the "Oops..." message.

Probably the source of the problem is parsing of the cart data. In response to the POST /v1/izi/basket/{basket_id}/confirmation sent by the Basket App, the Merchant provides full cart details to InPost Pay. Check that the answer contains all the required fields along with the correct values, according to the diagram. Remember about the dedicated chat where you can report this issue!

  • I click on the InPost Pay widget, but the product does not add to the cart!

Check what value it adopts for a given product at  iziCanBeBound, FALSE blocks the possibility of adding the product to the cart.

  • How does the Basket App communicate address information? Are the data broken down into street fields, block number, etc.?

Currently, the address is provided in its entirety, without breaking it down into fields. 

  • Where to get the “browser_id” object for iziGetBindingData? 

"browser_id" is stored in cookies under the name BrowserID.

The browser field contains some information from further fields (i.e. platform, architecture). In this case, these values should be "pulled" from the browser_id and substituted under the appropriate parameters, e.g.

"browser": {

        "browser_id": "26e95acb-2bf4-4ca3-9bc9-e93ebf6fd6a6",

        "user_agent": "Testzilla 1.0",

        "description": "Test agent",

        "platform": "Ino Linux 2.0",

        "architecture": "x86-64",

        "data_time": "2023-02-08T10:41:19.664Z",

        "location": "Poland",

        "customer_ip": "",

        "port": "8080"


  • What are the parameters "location", "data_time", "port" of the browser object?

"location" - the location of the merchant's website user. If the Merchant is not able to provide a location on the basis of user's IP, it can enter any value, e.g. "location": "Poland".

"data_time" - current time, e.g. "data_time": "2023-02-08T10:41:19.664Z"

"port" - If the customer enters via https - 443, http - 80. e.g. "port": "8080"

  • It attempts to pair the cart several times with the same data and I do not receive push notifications on the phone.

When attempting to pair a shopping cart, InPost Pay verifies the security/spam binding rules for the phone number. If a given phone number has been used repeatedly in a short period of time, the pairing will be temporarily blocked. This is the expected result, ensuring the safety of InPost Pay users.

  • The application "behaves strangely", most of the actions result in the "Oops..." message.

Make sure you're using the latest version of the InPost Mobile UAT app. During re-installation, you will need the authorization code again to receive it, please contact us using the dedicated chat.

  • Where can I find the plugin script?

Full documentation is available in the InPost Pay chapter of the InPost developer documentation. There you will also find sections dedicated to the plugin, and the script can be downloaded here. We are still working on improving the documentation, so if you have any comments - please report them in our dedicated chat :)

  • Are the urls regarding Will theMerchant backend API be called by Widget or will the Inpost application ask for it from another host?

The services described in the  above link are used by InPostPay (Basket App), the widget does not call them.

  • Will the customer be able to change the product variant (e.g. size) in the app? We send the completed table for the 'variants' product, but this option does not appear in the app.

The API has been prepared in the target version, but the InPost mobile app does not support it yet. Increasing two-way communication will take place successively.

  • What steps do we need to take on our part to be able to introduce InPost Pay to the production environment? 

In order to facilitate the process of introducing the InPost Pay solution to the production environment, you will receive a dedicated checklist with a clear definition of the necessary steps as well as an indication of the teams responsible for the respective stage and support teams.

  • The application incorrectly processes delivery costs. The cart displayed the cost of PLN XX.XX, but in the order the cost is equal to PLN 0.

According to the documentation, the "order_final_price" object should include the total cost of the order, including shipping costs. If the appropriate value is not provided in the "order_final_price" object, i.e. only the value of the ordered product without the delivery price is provided, it will also not be included in the order.

  • In the application, the amount presented next to the product is not multiplied, even though the user has added several pieces of the same product to the cart. Is this an application error, or should we send a multiplied "price" for such a case?

We are working on updating the application in this regard so that it converts the amount according to the number of items in the cart and presents the user with the appropriate amount.

  • What is pos_id in order_details?

pos_id is the Merchant's unique identifier for handling payment-related services (merchant portal, API). It is awarded during onboarding.

  • Is InPost Pay responsible for shipment? Should the Merchant handle the shipping themselves?

It is the Merchant who is responsible for handling the shipping. It should generate a label and a waybill, and then provide the waybills in the "delivery_references_list" field, the planned delivery time in the "delivery_date" field and information about the price of the shipment and promotional codes in the "delivery_options" field.