FAQ InPost Pay [ENG]

What is the limit to the number of "suggested" products?

There is no limit to the number of suggested products, but due to the fact that the InPost Pay app is intended for mobile devices, it is recommended to add no more than 10 suggested products.

How will communications between the Merchant and InPost Pay be secured?

A section of documentation titled Merchant Backend API - Headers has been dedicated to addressing the issue of securing the communication between the Merchant and InPost Pay.

What happens when a customer decides to finalize a purchase on the Merchant's website? Is the basket deleted from the InPost app?
There are two possible cases:

What happens if the price or availability of a product in the store has changed before a customer places an order?

Each time before placing an order, the InPost Pay app fetches the full details of the basket from the Merchant's page, including the price and availability of the product (using the GET/v1/izi/basket/{basket_id} method). The fetched basket is then compared with the basket currently stored in the app, and when their values differ – an appropriate message is displayed to the customer and the process of creating an order on an outdated basket is terminated. In order to continue it is necessary to refresh the basket.

Is it possible to run several baskets simultaneously at one Merchant?

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

Complimentary products - can a customer "get around" the terms and conditions of the promotion and add more complimentary products using the functionality of increasing quantity in the basket?

No, the number of complimentary products that can be added is dictated by the terms and conditions of the promotion established by the Merchant. In response to the basket update event, the Merchant returns the current contents of the basket in the store.

Will the app send a reminder to the customer that the basket has been finalized? Is it possible to set the time or frequency of notifications according to the Merchant’s needs (to avoid sending notifications at a time unfavorable from a business perspective).

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

When is the basket deleted from the InPost app? Is it possible to set a basket "suspension" time?

The basket retention time in the InPost Pay app is determined by the Merchant, communicated to the Basket App in response to POST v1/izi/basket/{basket_id}/confirmation, "basket_expiration_date” object.

What if a (registered) customer clicks once to add a product to the basket using the InPost Pay widget, and later adds a product using the store button?

The product will then be added to the store's basket, and in the mobile app it will be added to the InPost Pay basket after it is refreshed, as a result of the Merchant calling the PUT/v2/izi/basket/{basket_id} method.

What about a store where it is not possible to shop in guest mode?

InPost Pay service is intended primarily for all customers who do not want to set up a customer account. InPost makes every effort to meet all customer requirements, so contact the InPost Pay Project Supervisor to work together to develop a solution that satisfies your needs.

Can a customer cancel an order for which payment has already been made? How will it be presented in InPost Pay?

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

Is order history presented in InPost Pay?

Yes, in the InPost Mobile app you will find a new "Shopping" section, with two tabs: "Baskets" and Orders. "Orders" tab stores all orders, along with their statuses, and when you click on a selected order, its details will be displayed.

How is the communication between components? For example, does the Merchant's backend have to constantly listen for basket updates from InPost Pay ?

Communication between components is described in detail and shown in sequence diagrams in the section of the technical documentation titled Sequence diagrams for InPost Pay and Widget 2.0.

Does the Merchant receive information from InPost Pay about the payment method used by the customer to pay for the order?

Information about the payment method used to pay for an order is passed using the POST v1/izi/order method, in the "payment_type" object, which can take the following values: 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 product(s) selected by the customer cannot be delivered by APM?

The available delivery options and its parameters such as estimated delivery time and price are set separately for each product, in the "delivery_type" object of the POST /v1/izi/basket/{basket_id}/confirmation method.

Will we get access to the test application?

Yes, we will provide you with an application on the Sandbox environment, on which it will be possible to simulate the operation of the InPost Pay service.

Are the Merchant's marketing consents presented to customers in InPost Pay? How?

Consents presented in InPost Mobile are fetched from the Merchant's page, in the response to POST/v1/izi/basket/{basket_id}/confirmation containing basket details, including the mandatory "consents" object. Multiple consents can be passed, with links to the full wording (1 link for 1 consent), a description, version and requirement (optional, required once, required always). InPost Mobile stores information about the consents from the relevant Merchant, so that consents with a “for new version only" requirement are fetched only once for the relevant assigned consent ID and version. Consents required “always” must be accepted every time an order is placed.

Is the “personal pickup” delivery option possible in InPost Pay? Is it possible to organize shipment through another forwarder?
Only orders with delivery by courier or InPost APM are supported in the InPost Pay process.

Can the Merchant backend query the Basket App for payment status?

Once the payment is made in the mobile app, Basket App calls the POST/v1/izi/order/{order_id}/event method to the Merchant's backend with information that the payment has been made, which is in turn a trigger for Merchant to further process the order (packing and shipping). Merchant has the ability to use the same method to provide information about the next steps in the order fulfillment process, including to provide the shipment reference number.

Is the URL provided by/to the Merchant used for two-way communication?

Yes, the Merchant's backend and the Basket App module are involved in the communication. The communication is two-way, the components exchange information about the linking of the basket, basket and order updates. A detailed description of the communication is presented in the section of the technical documentation titled Sequence Diagrams for InPost Pay and Widget 2.0.

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

Merchant needs to embed a dedicated widget on its site that communicates with the backend. The rest of InPost Pay communication occurs between the Merchant's backend and Basket App according to the diagrams shown in the Sequence Diagrams for InPost Pay and Widget 2.0 section.

Why do several prices need to be provided in the parameterization of the basket/order, including "base price" and "final price"?

Several price fields allow you to show customers the changes in the price of the basket/order, i.e. the price before and after the reduction.

Suppose InPost cannot tap into the Merchant's endpoint because the latter has a server failure and is not responding.
Meanwhile, the customer has paid for the order using the mobile app. What happens if there is no communication?

We have queues set up for checking status and communication with the Merchant, which will make repeated attempts at communication in such a situation. These are supplementary to the ability to refresh the basket in the application (force refresh, dragging the basket).

We have products in our offer that we do not want to be included in the InPost Pay service (formal issues). Can it be turned off for selected products?

Yes, in such case the widget should not be displayed on such products. If the pairing is done from the basket level, you can use the products.delivery_product object to pass information that delivery is not available for that product.

Why can't I pair my basket using a QR code? There is no response from the app!

The reason for the inability to pair a basket using a QR code may be the inability to establish a connection between the Merchant's website and the Basket App. The reason for the issue may be an incorrectly set service address or an authorization error. You can consult us about your issue by sending a ticket to integracjapay@inpost.pl.

I have scanned the QR code and successfully paired the basket with my phone number. Unfortunately when I try to open the basket in the app I get the "Oops...” message.

Most likely the issue is the parsing of the basket data. In response to POST /v1/izi/basket/{basket_id}/confirmation sent by the Basket App, the Merchant passes the full basket data to InPost Pay. Check whether the response contains all the required fields with correct values, according to the schema. You can consult us about your issue by sending a ticket to integracjapay@inpost.pl.

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

Check that the widget on the product card has been implemented according to the specifications.

In what form does Basket App pass address information? Is the data broken down into street, building number fields, etc.?

Information about the delivery address is passed in the delivery_address object and the address parameter. An additional address_details object contains data broken down into street, building, flat fields. The values in address_details are generated automatically from the data provided by the user, their veracity is not guaranteed.

Where to find the "browser_id" object?

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

I tried several times to pair the basket by entering the same data and I do not receive push notifications on my phone.

When attempting to pair a basket, InPost Pay verifies the security/spam rules for the link to the phone number. If a phone number has been used multiple times in a short period of time, the ability to pair will be temporarily blocked. This is an expected result that ensures the security of InPost Pay users.

The application "behaves strangely," with most actions resulting in an "Oops..." message.

Make sure you are using the latest version of the InPost Mobile Sandbox app. If the problem persists after reinstalling, consult with us by sending a ticket to integracjapay@inpost.pl.

Where can I find the plugin script?

Full documentation is provided in the InPost Pay section of the InPost developer documentation. There you will also find sections dedicated to the plugin, and you can download the script here. We are still working on improving the documentation, so if you have comments - submit them to integracjapay@inpost.pl.

Will the Merchant backend API URLs be called by the Widget or will the InPost app query for them from another host?

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

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

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

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 that need to be completed 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 "order_final_price" object should include the total cost of the order along with the shipping costs. If the object "order_final_price" does not contain the correct value, namely only the value of the product ordered 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 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?

The pos_id parameter is the Merchant's unique ID for handling the services related to payments (merchant's website, API). The value of this parameter along with other data needed for API integration can be found at https://merchant.inpost.pl.

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 consignment note, and then transfer the consignment notes in the "delivery_references_list” field, the planned delivery time in the "delivery_date” field, 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 this data before it is passed in the response?

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

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

The if_basket_realized flag makes it possible to differentiate reasons for unpairing the basket, to differentiate a situation when the customer wants to link the basket to a different phone 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 analytical purposes.

I click “Buy and Pay" in the app and receive “Oops… "

The issue lies with the basket hash, 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 e.g. the value of "delivery_date" passed in 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 every effort to ensure that the InPost Pay service is as universal as possible, that is why we have designed a dedicated "Thank you page". The Merchant displays the "Thank you page" when an order has been placed, but payment has yet to be made. It contains information about what the user should do next in InPost mobile, therefore it should be exactly the page we 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 be different? From the app user’s perspective, I do not see a difference between them.

Yes, at the app level, ERROR and ATTENTION will have different forms used to present the message to the customer, e.g. upon entering a discount code, there may be situations that exclude the application of any promotions or allow for a discount code to be applied only partially. The basket will be recalculated accordingly to the above situations and the information about the applied discount can be returned using ATTENTION. If there is a basket recalculation error, then information about the event may be passed using ERROR.
In summary, ATTENTION is used to communicate important information to the customer about their basket, and ERROR provides information about an error that prevents a certain 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 do I communicate information the cash on delivery option is available for the relevant basket?

We pass the CASH_ON_DELIVERY value in the “payment_type” parameter and the COD value in the “delivery_code_value” parameter. We consider the Cash on Delivery payment method as one of the additional options that may be selected for the selected delivery option, therefore it is available against additional payment.
Example:

What if a product in the basket cannot be delivered by either Courier or APM?

If delivery by APM or Courier is not possible for a given basket, Merchant passes an empty array in the basket details with the delivery: "delivery":[].