Widget 2.0 [ENG]

Widget 2.0 [ENG]

 

Widget

The InPost Pay Widget is a JavaScript plugin embedded on the webpage by adding a script as in the example presented below:

<html> <head> <script src="https://inpostpay-widget-v2.inpost.pl/inpostpay.widget.v2.js"></script> </head> <body> <script type="application/javascript"> const widgetOptions = { merchantClientId: 'b73ca9fc-0123-4567-8912-5ac02c6af6e9', basketBindingApiKey: 'QdMW9xtB9POfNG7GiGIO4EFPEKSvzOuW', unboundWidgetClicked: (productId) => new Promise() }; const widget = InPostPayWidget.init(widgetOptions); </script> ... <inpost-izi-button data-product-id="123" binding_place="PRODUCT_CARD" variation="..." ></inpost-izi-button> ... </body>

Environments:

Merchant Client Id Id is a value assigned by InPost.

By default, Widget 2.0 may be called from the domain defined on the merchant account as home page. If the merchant calls the widget from a different domain, it is necessary to add an appropriate URL address as custom origin. For this purpose, it is necessary to send a request to integracjapay@inpost.pl, indicating the appropriate URL address in the body of the message.

Want to test on the local environment?

In order to provide remote access to the local environment, an additional workaround is required in the form of tunneling traffic from the public domain to a local address. Without such a workaround, there is no way to connect directly to the local environment.
Recommended solution
The current recommended tool is ngrok, which allows you to quickly set up a tunnel between the public URL and the local environment. All you need is a free account that provides one permanent public domain. This domain can redirect traffic to a local application or a closed test environment.
Requirements
After creating a free public domain, you need to provide its address in the Contact -> Sandbox form to receive credentials and all test traffic can be routed to that address.


 

Lifecycle notes

  1. There could be only one widget instance per page, since we offer only one kind of placeholder and widget can't distinguish and apply different configuration

  2. It's up to merchant when to initialise the widget, depending when widget placeholder is added to DOM or configuration becomes available, so can be done at root level (as above) or can be deferred and called after some async actions

  3. Widget's lifecycle:

    1. right after initialisation, it'll retrieve its configuration from WidgetAPI for given merchantId

    2. if basketBindingApiKey is provided as string or undefined - it'll make a call to Widget API to get basket binding status

    3. if basketBindingApiKey is provided as promise - it'll first await for promise to resolve and only then make a call to Widget API to get basket binding status

    4. once page is fully loaded and call to Widget API is made, it will check if any placeholder is present on the DOM and render the widget in appropriate state

Specification

export type BasketBindingApiKey = undefined | string | Promise<string> export type WidgetBasketEvent = | 'basketDeleted' | 'basketProductChanged' | 'orderCreated' export type WidgetBasketEventHandler = ( event: WidgetBasketEvent, ) => boolean | Promise<boolean> export interface WidgetInitOptions { /** * Merchant Client Id. */ merchantClientId: string /** * Unique basket binding API key - it's obtained from InpostPay API. * If it's known at the page render: can be provided as string. * If it can be resolved during page load: can be a promise. * Otherwise: 'undefined', widget will assume that basket is not bound, because it can't check basket binding status without knowing api key. * And in such case, it's mandatory for 'unboundWidgetClicked' to return a 'apiKey', otherwise baskets can't be bound. */ basketBindingApiKey: BasketBindingApiKey /** * This callback function is mandatory for unbound basket and for binding_place=PRODUCT_CARD. * It'll be called to add the product to merchant's basket when user clicks on the widget. * When the promise is rejected with Error('UNDELIVERABLE_PRODUCT') widget won't show error popup or binding popup. * @return promise with 'basketBindingApiKey' */ unboundWidgetClicked?: (productId?: string) => Promise<string> /** * Callback function to reflect basket updates on merchant's page. * If not provided or returning false - widget will refresh the entire page. * @return 'true' if widget should not refresh the page. */ handleBasketEvent?: WidgetBasketEventHandler /** * Widget-API base url used for frontend to API communication. * By default, https://inpostpay-widget-api.inpost.pl is used. */ apiBaseUrl?: string /** * If set to true BrowserId will be persisted and read from localStorage. * If set to true the app will always try to open a https deep link, if false the deep link url * will be deducted based on the UserAgent. * Default: false */ webView?: boolean /** * Custom language. By default, widget will use browser's language and 'pl' as fallback */ language?: string } export interface InPostPayWidget { refresh: (options?: Partial<WidgetInitOptions>) => void } export interface InPostPayWidgetNamespace { init: (options: WidgetInitOptions) => InPostPayWidget } declare global { export interface Window { InPostPayWidget: InPostPayWidgetNamespace __INPOST_PAY_WIDGET__?: InPostPayWidget } } declare function initialiseInpostPayWidget( options: WidgetInitOptions, ): InPostPayWidget

 

Widget placeholder

In order to correctly position widget buttons, the code below must added to the webpage in the appropriate place (under the “Add to basket” button or next to “Checkout”)

<inpost-izi-button data-product-id="" binding_place="" variation="" ></inpost-izi-button>

The placeholder supports the following parameters:

Parametrer

Required

Description

Additional remarks

binding_place

Yes

Possible values: 

  • PRODUCT_CARD

  • BASKET_SUMMARY

  • ORDER_CREATE

  • BASKET_POPUP

  • THANK_YOU_PAGE

  • CHECKOUT_PAGE

  • MINICART_PAGE

  • REGISTERFORM_PAGE

  • LOGIN_PAGE

 

data-product-id

Yes, if binding_place=PRODUCT_CARD
 

 

 

variation

No

A list of styles, i.e.

"dark primary size-m rounded"

Default:

"secondary size-l"

Available styles:

  • round - maximum widget border radius

  • rounded - medium widget border radius (border radius 8px). If indicated together with “round”, then “round” is used.

  • dark - text under the button is white

  • primary - yellow widget color

  • predefined widget dimensions (if more than one has been indicated, then the lower size is considered of higher priority):

    • size-xs

    • size-sm

    • size-md

    • size-lg

    • size-xl

 

In order to display the "Thank You Page" <inpost-thank-you></inpost-thank-you> must be added in the appropriate place on the webpage with the thank you for the order.

Sequence diagrams for InPost Pay and Widget 2.0

The articles below contain sequence diagrams for InPost Pay and Widget 2.0.