Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

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 Pay integration includes the following elements:

  • InPost Pay - Widget – A widget that makes it possible to integrate the websites (frontend) of merchants with InPost Pay

  • 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

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

  2. 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)

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

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

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

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

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:

  1. Recipient receives signed request with headers:

    1. x-signature - signature

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

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

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

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

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

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

  5. 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 entire IT solution consisting of several systems which handle the purchase finalizing process for different merchants in the InPost Mobile app.

InPost Moblie

The currently operational InPost Moblie app which makes it possible to track and send shipments.

Merchant

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

Basket

One or several products that the User selects on the merchant's website. The content of the basket is transferred to InPost Pay.

User

An end user who makes purchases om the merchant's website and who has the InPost Moblie app.

Bank

Aion Bank.

Pay Widget

An element embedded on the Merchant's website, which makes it possible to select the options Kup z InPost Pay, and to link a computer with the InPost Moblie application.

Order

An entity created from a basket after its purchase is initiated by the User

Trusted/linked browser

An instance of a web browser which operates on the specific device, added to trusted IM apps. Only a trusted browser may add products to a basket in InPost Moblie.

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

  • No labels