Versions Compared

Old Version 3

changes.mady.by.user Michał Machowski

Saved on

compared with

New Version Current

changes.mady.by.user Joanna Wołosz

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

InPost Pay

Solution Concept

The InPost Pay solution helps finalize the purchasing process (checkout) in the InPost Mobile app based on the integration with different platforms/online stores.

The solution addresses basic problems present on the e-commerce market:

  • Purchases in the guest mode, without the need to create an account in several stores

  • No need to provide the delivery/invoice data etc.

  • Shortening the time required from displaying the product to finalizing the purchase

  • Reducing the number of abandoned baskets

The Merchant – Inpost Merchant – InPost Pay integration includes the following elements:

  • InPost Pay - Widget – - A widget that makes it possible to integrate the websites (frontend) of merchants with InPost Paythe Merchants with the backend of the Merchants' platform, and which provides access on the Merchant's backend to the methods of the Merchant Backend API, which the InPost Pay service will call.

  • InPost Pay (Basket_App) – - a module which provides access to the API, which makes it possible to exchange information regarding the basket and the processing of the order

  • The basic scenario of using InPost Pay by an end user is as follows:

    1. The user displays the website of a merchant (the mobile version, and the desktop version), when moving to the page of the product chosen

    2. The User selects the button "Kup z InPost Pay"

    3. The Product is added to the basket at a merchant's. The merchant transfers the basket's data to InPost Pay (Basket App). The basket is marked as synchronized with InPost Pay.

    4. The InPost Mobile displays the message push: A new basket awaiting for payment appears.

    5. The user opens the InPost Mobile app with the selected basket on their phone.

    6. The app automatically sets the delivery method chosen, and the default payment form on the basis of the user's profile in InPost Mobile.

    7. After choosing the operation "Kupuję i płacę " (Buy and pay), InPost Pay creates an order at the merchant based on the current basket.

    8. The user makes the payment in the InPost Mobile app

    9. The merchant is notified of the execution of the payment

    10. 10.  The Merchant creates and sends the shipment in the standard way.

    11. 11.  The merchant notifies InPost Pay of the shipment they used to fulfill the given order.

  • Integration with InPost Pay takes place through "the basket". The products the user wants to buy using Inpost Pay are added to the basket at a merchant's. The merchant notifies InPost Pay of any changes in the basket. The notification is made only for such baskets, for which the user selects the action Kup z InPost Pay at least once (the basket is synchronized with InPost Pay)

  • When the user makes changes in a synchronized basket on the merchant's website (number of pieces changed, new products added to the basket), the merchant transfers the changes to InPost Pay. InPost Mobile refreshes the screen with the basket in the app for the user.

    • The Integration assumes that the user can perform in InPost Mobile specific operations on the basket, for instance change the number of pieces, enter a rebate code etc. Each time, such an information is transferred to the merchant. Upon calculating the content

    • of

    the basket,

    • the

    merchant sends it back to InPost Pay.

  • Before purchasing, the user accepts the merchant's terms and conditions.

    • The User may pay for a synchronized basket on the merchant's website. In such a case, the

    • order

    is not realized by InPost Pay. The merchant notifies InPost Pay of finalizing the basket in another channel.

    Info

    The Integration with InPost Pay does not affect the integration with InPost's systems rekated to generating shipments, currently implemented by the merchant.

    Headers

    The following headers (headers) are added to all services called by Merchants in Basket-app. Currently, they are optional. Eventually Basket-app will have these headers set as required:

    x-signature - signature

    x-signature-timestamp - ISO8601 datetime string in UTC timezone with time of signature generation ex. 2023-05-11T15:02:23.429Z

    x-public-key-ver - version of keys used to generate signature

    x-public-key-hash - SHA-256 hash of public key used to generate signature

    Signature verification algorithm

     

    Signature verification algorithm:

    Recipient receives signed request with headers:

  • x-signature - signature

    • x-signature-timestamp - ISO8601 datetime string in UTC timezone with time of signature generation ex

    • .

    2023-05-11T15:02:23.429Zx-public-key-ver - version of keys used to generate signature

  • x-public-key-hash - SHA-256 hash of public key used to generate signature

  • Recipient checks if already have cached public key with given version

    1. key present in cache:

      • recipient checks if public key hash matches calculated as: SHA-256 hash from public_key_base64 field. if verification is:

        • positive - continue

        • negative - reject request

    2. key not present in cache:

      • obtain public key from /v1/izi/signing-keys/public/{keyVersion} or /api/v1/izi/signing-keys/public and verify hash as above

  • Prepare base64 string that consists of DIGEST,external-merchant-id,x-public-key-ver,x-signature-timestamp. Values are separated with commas

    • x-public-key-ver, x-signature-timestamp from headers, use empty value if header is missing.

    • merchant_external_id value comes from endpoints /v1/izi/signing-keys/public/{keyVersion} and /v1/izi/signing-keys/public as merchant_external_id field

    • DIGEST: base64 form of SHA-256 hash (Message Digest) generated from request body. Use empty byte array as request body if body is missing.

  • Decode base64 signature and verify it with the SHA256withRSA algorithm for the given public key and signature string. If verification:

    1. positive - continue

    2. negative - reject request

  • Recipient compares x-signature-timestamp value to current time. If difference is:

    1. less or equal to 240s - continue

    2. bigger than 240s - reject request

    •  

    Manual signature verification:

    • curl --location 'http://{basket-app-host}/basket-app/api/v1/izi/signing-keys/public/{keyVersion}' replace {Unknown macro: { {keyVersion}}}

      with value from header: x-public-key-ver

    • echo "$PUBLIC_KEY_BASE64" | openssl base64 -d -A | openssl rsa -pubin -inform DER -outform PEM -out pubkey.pem replace $PUBLIC_KEY_BASE64 with value from field: public_key_base64

    • DIGEST=$(echo -n "$(<message_body)" | openssl dgst -sha256 -binary | openssl enc -base64 -A) where message_body is a file with EXACT request body (without any additions, whitespaces etc.)

    • echo -n "$DIGEST,$EXTERNAL_MERCHANT_ID,$KEY_VERSION,$SIGNATURE_TIMESTAMP" | openssl enc -base64 -A -out signature_string where $EXTERNAL_MERCHANT_ID value is from public key endpoint - field merchant_external_id, $KEY_VERSION value is from header x-public-key-ver and $SIGNATURE_TIMESTAMP value is from x-signature-timestamp

    • openssl enc -base64 -d -A -in request_signature -out signature.bin where request_signature is a file with value from header x-signature

    • openssl dgst -sha256 -verify pubkey.pem -signature signature.bin signature_string should print Verified OK

    Glossary

    Term

    Definition

    InPost Pay

    An

    The entire IT solution consisting of several systems which handle the process of finalizing the purchase

    finalizing process for different merchants

    by the user in the InPost Mobile app.

    InPost

    Moblie

    Mobile

    The currently

    operational

    functioning InPost

    Moblie app which makes it possible to track and send

    app allowing for track, send, and return shipments.

    Merchant

    A store/a platform which offers product sales online, integrated with InPost Pay.

    Basket

    One or several products that the

    User

    user selects on the

    merchant

    Merchant's website. The content of the basket is transferred to InPost Pay.

    User

    An end user

    who makes purchases om the merchant

    purchasing at a Merchant's

    website

    platform and

    who has

    having the InPost

    Moblie

    Mobile app.

    Bank

    Aion Bank - payment operator.

    InPost Pay Widget

    An element embedded on the Merchant's website, which makes it possible to select the

    options

    Kup z InPost Pay (Buy with InPost Pay) option, and to

    link

    bind a

    computer

    browser with the InPost

    Moblie application

    Mobile app. The Widget is used to couple with the use of a telephone number./QR, or to quickly add an InPost Pay basket for a registered user.

    Order

    An entity created from

    This is a basket

    after its purchase is initiated by the User

    for which the payment process was started.

    Trusted/linked browser

    An instance of a web browser which operates on

    the

    a specific device, added to

    trusted IM apps

    the trusted ones to the InPost Mobile app. Only a trusted browser may add products to a basket in InPost

    Moblie

    Mobile.

    Merchant onboarding

    Integration of the Merchant with InPost Pay system. The process of "creating" a Merchant in the Aion systems for the needs of processing the payments, and for Merchant Financing

    InPost Mobile onboarding

    Downloading the InPost Mobile app, and logging a user in by entering and verifying a phone number.

    InPost Pay onboarding

    Acceptance of the Terms and Conditions of InPost Pay service and entering the first name, last name, and the e-mail address for retail customers (natural persons not businesses).

    In this chapter:

    Child pages (Children Display)
    depth3
    allChildrentrue
    style
    sortAndReverse
    first0