Page Comparison

• 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 POST/v1/izi/order/{order_id}/event.

• 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}

• 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 integracjapay@inpost.pl.

• 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.

• How should the "browser" object be parameterized? (POST /v1/izi/basket/{basket_id}/binding)

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": "127.0.0.1",

        "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?

• /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":[].