FAQ InPost Pay [ENG]

Owned by Joanna Wołosz
Last updated: Nov 06, 2024
12 min read

  • What is the limit of the quantity of "suggested" products?

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

  • How is communication between the Merchant and InPost Pay secured?

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

  • What happend when a customer decides to finalize their purchases on the Merchant's website? Will the basket be removed from the InPost app?

    Two cases are possible:

    • The customer has created an unpaid order using the InPost app, but the purchase has been finalized on the Merchant's side.
      In such a case, using the method POST /v1/izi/order/{order_id}/event, the Merchant transfers the status ORDER_COMPLETED. Such an order is visible in the InPost Mobile app but it cannot be paid or rejected through it.

    • The customer has bound the basket with the InPost Mobile application, and then finalized their purchases through the Merchant's store website. In such a case, using the method DELETE/v1/izi/basket/{basket_id}/binding, the merchant notifies InPost of the removal of the basket from the app together with the flag "if_basket_realized ": true.

  • What happens when the price or the availability of the product at the store has changed before the order is placed?

    Each time before the order is placed, the InPost Pay app picks up full details regarding the basket from the Merchant's website, including the price and the availability of the product (with the use of the method GET/v1/izi/basket/{basket_id}). Then, the basket downloaded is compared with the basket previously stored in the app, and when their values differ - the customer is presented with the respective message -the process of creating an order for an invalid basket is over. To continue, the basket needs to be refreshed.

  • Is it possible to run several baskets at the same time for one Merchant?

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

  • Free products – can a customer "bypass" the terms of a promotion and add more extra free products using the feature of increasing the quantity in the basket?

    No, the quantity of extra free products available for adding results from the promotion terms specified by the Merchant, and the limitation is set by the method iziCanBeBound.

  • Will the application remind the customers to finalize a basket? Can it set a time or frequency for the reminders as required by the Merchant (to avoid sending notifications when it is not beneficial for the business).

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

  • When will a basket be removed from the InPost app? Will it be possible to set the time to "expand" the basket?

    The time of storing the basket in the InPost Pay app is specified by the Merchant, transferred to the Basket App in response to POST v1/izi/basket/{basket_id}/confirmation, object "basket_expiration_date".

  • What if a (registered) customer clicks adding a product to the basket once using the widget InPost Pay, and then adds a product using the store's button?

    Then, the product is added to the store's basket, and it will be added in the mobile app to the InPost Pay basket upon refreshing, as a result of the Merchant calling the method PUT/v1/izi/basket/{basket_id}.

  • What if the store has no option of purchasing as a guest?

    The InPost Pay service is dedicated, most of all, to the customers who do not want to register a customer account. InPost makes any effort to meet all the clients' requirements, therefore get in touch with the InPost Pay Project Owner to develop a satisfactory solution together.

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

    A paid order cannot be cancelled from the level of the InPost Pay app. In such situations, the standard returning procedure applies.

  • Can InPost Pay present the ordering history?

    Yes, the InPost Mobile app contains a new section "Zakupy", and in it, two tabs,: "Koszyki" and "Zamówienia.". "Zamówienia" contains all the Orders, along with their statuses, and upon clicking an order, its details will be displayed.

  • How does the communication between the components looks like? Eg. does the Merchant's backend need to continuously observe the basket updates in InPost Pay?

    The communication between the components has been described in detail and presented in sequence diagrams in the technical documentation chapter entitled Sequence Diagrams for InPost Pay & Widget.

  • Is the Merchant notified by InPost Pay of the form which the customer uses to pay for the order?

    The payment form is presented in the method POST v1/izi/order, w obiekcie “payment_type”, który może przybierać wartości: CARD, CARD_TOKEN, GOOGLE_PAY, APPLE_PAY, BLIK_CODE, BLIK_TOKEN, PAY_BY_LINK, SHOPPING_LIMIT, DEFERRED_PAYMENT, CASH_ON_DELIVERY.

  • What happens when the products selected by the customer cannot be delivered using an Automatic Parcel Locker Device?

    The shipment forms available and their parameters such as the estimated delivery time and the price are being specified separately for each product, within the object "delivery_type" of the method POST v1/izi/order.

  • Can we access the test app?

    Yes, we make the app available to you in the Sandbox environment where it will be possible to simulate the operation of the InPost Pay service.

  • Does InPost Pay present the customers with the Merchant's marketing consents? And how?

    The consents presented in InPost Mobile are being downloaded from the Merchant's website in response to POST/v1/izi/basket/{basket_id}/confirmation which contains the basket's details, including the required object "consents". It is possible to provide several consents, together with the links to their full content (1 link for 1 consent), a description, the version, and the requirement status (optional, required once, required always). InPost Mobile stores the information regarding the consents for a given Merchant, so that the consents required for "a new version" were collected only once for the given ID assigned and the consent's version. The user must accept the consents that are required "always" for each order placed.

  • Is the delivery method "collection in person" available within InPost Pay? Is it possible to dispatch using another forwarding agent?

    Within the InPost Pay process, only the orders to be delivered by couriers or InPost Parcel Locker Devices are handled.

  • Can the Merchant's backend request the payment status from the Basket App?

    Once the payment is made within the mobile app, the Basket App calls the method POST/v1/izi/order/{order_id}/event to the Merchant's backend with the payment status, which in turn triggers further processing of the order for the Merchant (packing and dispatching). The Merchant may notify by the same method of subsequent steps within the order implementation process, including, among others, transfer the reference number of the shipment.

  • Can the URL made available by/to the Merchant be used to double-track communication?

    Yes, the communication involves the Merchant's backend and the Basket App module. The communication proceeds in two ways, the components exchange information regarding the baskets' assignment, updates, the orders. A detailed description of the communication method has been presented in the Chapter "Sequence Diagrams for InPost Pay & Widget" of the technical documentation.

  • What scope of works is required at the frontend of the Merchant's website?

    The Merchant needs to embed a dedicated widget in their website, which communicates with the backend. The remaining communication of InPost Pay proceeds between the Merchant's backend, and the Basket App according to the diagrams presented in the chapter "Sequence Diagrams for InPost Pay & Widget".

  • Why does the basket /order parameterization require specifying several prices, including the "base price" and "final price"?

    Several fields related to prices make it possible to present the customer with any changes in the prices of the basket/order, namely the price before and after any discount.

  • Let's assume that InPost cannot reach the Merchant's endpoint, since it's server is malfunctioning and is not responding. Meanwhile the customer has paid for the order by using the mobile app? What happens when there is no communication?

    We have queues set to check the status and to communicate with the Merchant, who, in such a situation, will repeat communication attempts. These are supplementary to the option of refreshing the basket in the app (force refresh, drag and drop the basket).

  • In our offer, we have products we don't want to cover with the InPost Pay service (formal issues). Can it be enabled for selected products?

    Yes, to specify the availability of a product for the InPost Pay basket, use the iziCanBeBound widget method.

  • Why can't I couple the basket using a QR code? The app does not respond!

    The reason for the impossibility of coupling the basket using a QR code may be the impossibility of connecting from the Merchant's website with the Basket App. The reason for the issue may be an incorrect address of the services, or an error is present at the authorization. Consult the issue with us, by sending a notification to the address integracjapay@inpost.pl.

  • I scanned a QR code and coupled my basket successfully with my phone number. Unfortunately, when trying to open the basket in the app, I receive the message "Ups…".

    Probably the reason for the issue is parsing the data of the basket. Is a response to POST /v1/izi/basket/{basket_id}/confirmation send by the Basket App, the Merchant transfers the full data of the basket to InPost Pay. Check if the response contains all the fields required together with the correct values, in line with the scheme. Consult the issue with us, by sending a notification to the address integracjapay@inpost.pl.

  • I click the InPost Pay widget, but the product is not added to the basket!

    Check the value iziCanBeBound has for the given product, FALSE blocks adding the product to the basket.

  • In what form does the Basket App transfer the information regarding the address? Are the data separated into the street, house, number fields etc.?

    The information about the delivery address is transferred within the object delivery_address and the parameter address. The additional object address_details includes the data broken down into the fields street, building, flat. The values in address_details are generated automatically from the data provided by the user, their correctness is not guaranteed.

  • Where to find the object "browser_id" for iziGetBindingData?

    “browser_id” jest zapisywane w cookies pod nazwą BrowserID.

  • How to parameterize the object "browser "? (POST /v1/izi/basket/{basket_id}/binding)

    The field browser contains certain information from further fields (namely platform, architecture). In such a case, these values must be "copied" from browser_id and pasted as the suitable parameters eg.
    "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": "127.0.0.1",
    "port": "8080"
    },

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

    "location" - the location of the Merchant website user. If the Merchant is not able to provide the location by the user IP, they may enter any value e.g.. "location": "Poland".
    "data_time" -current time, eg. "data_time ": "2023-02-08T10:41:19.664Z "
    "port" -if the client enters through https- 443, http- 80.np. "port ": "8080"

  • I tried to couple my basket several times specifying the same data, and I receive no push notification on my phone.

    When trying to couple my basket, InPost Pay verifies the security/spam rules of the binding for the phone number. If a particular telephone number has been used multiple times in short intervals, coupling is temporarily disabled. This is to be expected, to ensure security to the users of the InPost Pay service.

  • The app "behaves strangely", most actions result in the message "Ups…".

    Make sure that you use the newest version of the InPost Mobile Sandbox app. If after the reinstallation the issue persists, contact us by sending a notification to the address integracjapay@inpost.pl.

  • Where can I find the script of the plugin?

    The full documentation is made available in the chapter InPost Pay of InPost's developer documentation. It also contains sections dedicated to the plugin, and the script is available here. We still work to improve our documentation, therefore if you have any comments - send them to the address integracjapay@inpost.pl.

  • Will the URLs related to the Merchant backend API be called by the Widget, will the InPost app request them from a different host?

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

  • Can the client change the product variants in the app (eg. the size)? We attach a complete 'variants' array to the product but such an option does not appear in the app.

    The API has been presented in the final version, but the InPost Mobile app does not support this at this time. Two-way communication will be expanding successively.

  • What steps must we undertake to implement InPost Pay in the production environment?

    In order to facilitate the process of implementing the InPost Pay solution in the production environment, you will receive a dedicated checklist with clearly specified steps necessary to complete as well as with the teams responsible for a given stage and the support teams identified.

  • The app processes the delivery costs incorrectly. In the basket, the cost of PLN XX.XX was displayed, but the cost is equal to PLN 0 in the order.

    According to the documentation, the object "order_final_price" should include the total cost of the order along with the dispatch costs. If the object "order_final_price" does not contain the correct value, namely only the value of the product ordered is included without the delivery price, it will not be included in the order.

  • In the app, the amount displayed next to the product is not multiplied, even if the user has added several pieces of the same product to the basket. Is it an error of the application, or should we send multiplied "prices" in such a case?

    We are working on updating the app in this respect, so that it calculates the amount according to the number of pieces of the product in the basket and presents the right amount to the user.

  • What is pos_id in order_details?

    pos_id is the Merchant's unique ID for handling the services related to payments (the merchant's website, the API). It is assigned at the On-Boarding process.

  • Is InPost Pay responsible for dispatching the shipments? Is it the Merchant who should handle dispatching the shipments on their own?

    It is the Merchant who is responsible for sending the shipments. They should generate a label and a delivery references list, and then transfer the delivery references lists in the box "delivery_references_list", the planned delivery time in the field "delivery_date", and the information regarding the price of the shipment and additional options in "delivery_options".

  • We must return a large amount of data to the POST /v1/izi/order endpoint. We receive a lot of information together with the request. Should we validate these data before transferring them as a reply?

    The data should be validated by the Merchant at the first request, in which they transfer the basket details, namely in the response within the service POST /v1/izi/basket/{basketId}/confirmation.

  • What is the purpose of the flag "if_basket_realized" in the endpoint DELETE v1/izi/basket/{basket_id}/binding?

    The flag if_basket_realized makes it possible to tell the reasons for un-coupling the basket, to tell a situation when the customer wants to couple it with the use of a different telephone number from a situation in which the basket was realized on the Merchant's website and thus the purchase was not completed through InPost Pay and will not be presented in the app anymore. All the reasons for the removal are stored for analytic purposes.

  • I click "Kupuję i płacę" in the app, and receive "UPS… "

    The issue lies with the hash of the basket, its value generated by the Merchant's website is not equal to the value stored in the app, which makes it impossible to place the order. The reason for this situation may be eg. the value of "delivery_date" transferred as a response to GET/v1/izi/basket/{basket_id} being too dynamic.

  • Can I place any website as a thank you page? For instance the existing "Thank you page" of the store?

    We make sure that the InPost Pay service was as universal as possible, therefore, we have designed a dedicated "Thank you page", which should be applied in the method iziCanBeBound. The Merchant displays the "Thank you page" when an order is being submitted but not paid yet, and it informs the user what to do next in InPost Mobile, therefore it should be the one we have prepared.

  • What currencies are supported in InPost Pay?

    Currently, only the Polish zloty (PLN) is supported.

  • Question regarding "basket_notice ": in POST /v1/izi/basket/{basket_id}/event. Will the ERROR and ATTENTION message types available here differ one from the other? From the point of view of the app's users, I don't see any difference between them.

    Yes, at the level of the app, ERROR and ATTENTION will have different forms of presenting the message to the customers, e.g. upon entering a rebate code, situations may take place which will exclude any promotions or applying the rebate code only partially. According to those, the basket will be recalculated, and the information about the rebate applied could be returned using ATTENTION. If an error is present in the recalculation of the basket, then the event could be notified using ERROR.
    To sum up, ATTENTION is used to transfer important information to a customer regarding their basket, and ERROR informs of an error which prevents a specific action from being performed on the basket.

  • What is "page_index" and "page_size" in GET/v1/izi/baskets and in GET/v1/izi/orders? Are these optional parameters? What if they're not specified?

    "page_index" and "page_size" are paging parameters. These are optional parameters, if not specified, default page 0 size 10 will be set.

  • How to notify of the option of paying cash on delivery for a given basket?

    In the parameter "payment_type", we provide the value CASH_ON_DELIVERY, and the value COD in the parameter "delivery_CODe_value". We consider the Cash on Delivery service one of the additional options to be chosen within the chosen delivery method, for which we enter an additional cost.
    Example:
    "payment_type": [
    "CARD",
    "CARD_TOKEN",
    "GOOGLE_PAY",
    "APPLE_PAY",
    "BLIK_CODE",
    "BLIK_TOKEN",
    "PAY_BY_LINK",
    "CASH_ON_DELIVERY"
    ]
    "delivery": [
    {
    "delivery_type": "APM",
    "delivery_date": "2023-09-04T23:59:59.000Z",
    "delivery_price": {
    "net": 8.13,
    "gross": 10,
    "vat": 1.87
    }
    },
    {
    "delivery_type": "COURIER",
    "delivery_date": "2023-09-04T23:59:59.000Z",
    "delivery_options": [
    {
    "delivery_name": "Kurier - pobranie",
    "delivery_code_value": "COD",
    "delivery_option_price": {
    "net": 4.07,
    "gross": 5,
    "vat": 0.93
    }
    }
    ],
    "delivery_price": {
    "net": 8.13,
    "gross": 10,
    "vat": 1.87
    }
    }
    ]

  • What if a product in the basket can be delivered neither by Courier nor using an Automatic Parcel Device?

    If, for a given basket, no delivery can be realized using an Automatic Parcel Device or by a Courier, then the Merchant provides an empty array in the basket details with the delivery:
    "delivery":[].