Page Comparison

Koncepcja rozwiązania

Rozwiązanie InPost Pay pozwala na finalizację procesu zakupu (checkout) w aplikacji mobilnej InPost Mobile w oparciu o integrację z różnymi platformami/sklepami internetowymi.

Rozwiązanie adresuje podstawowe problemy, występujące na rynku e-commerce:

• Zakupy w trybie gościa, bez konieczności zakładania konta na wielu sklepach

• Brak konieczności uzupełniania danych dostawy/ faktury itp.

• Skrócenie czasu potrzebnego od wyświetlenia produktu do finalizacji zakupu

• Zmniejszenie liczby porzuconych koszyków

W skład integracji Merchant – InPost Pay wchodzą elementy:

• https://dokumentacja-inpost.atlassian.net/wiki/spaces/PL/pages/130023427/Widget+Backend – widget pozwalający na integrację stron www (frontend) Merchantów z backend platformy merchanta Merchanta oraz udostępniający na backend merchanta Merchanta metody Merchant Backend API, które “wołała będzie” usługa InPost Pay.

• InPost Pay (Basket App) – moduł udostępniający API, pozwalający na wymianę informacji o koszyku i realizacji zamówienia 

1. Podstawowy scenariusz wykorzystania InPost Pay przez użytkownika końcowego przebiega następująco:

   1. Użytkownik wyświetla stronę www merchanta (w wersji mobilnej, jak i desktop).

   2. Użytkownik naciska przycisk „Kup z InPost Pay”.

   3. Produkt zostaje dodany do koszyka u merchanta. Merchant przesyła informacje o koszyku do InPost Pay (Basket App). Koszyk zostaje oznaczony jako synchronizowany z InPost Pay.

   4. Aplikacja InPost Mobile wyświetla komunikat push: pojawił się nowy koszyk do opłacenia.

   5. Użytkownik klikając w komunikat push wybudza aplikację InPost Mobile na powiązanym koszyku.

   6. Aplikacja automatycznie podstawia ostatnią wybraną formę dostawy oraz domyślną formę płatności na podstawie profilu użytkownika w InPost Mobile.

   7. Po wybraniu akcji „Kupuję i płacę”  InPost Pay tworzy u merchanta zamówienie w oparciu o aktualny koszyk.

   8. Użytkownik dokonuje płatności w aplikacji InPost Mobile.

   9. Informacja o wykonaniu płatności przekazywana jest do merchanta.

   10. Merchant tworzy i wysyła przesyłkę tak jak do tej pory, usługa InPost Pay nie wpływa na proces tworzenia i nadawania przesyłki.

   11. Merchant przekazuje do InPost Pay informację, za pomocą jakiej formy dostawy zostało zrealizowane zamówienie.

2. Integracja z InPost Pay odbywa się „przez koszyk”. Produkty, które użytkownik chce kupić przy pomocy InPost Pay, dodawane są do koszyka u merchanta. Merchant przekazuje informacje o zmianie koszyka do InPost Pay. Przekazywanie informacji odbywa się tylko dla takich koszyków, dla których użytkownik wybrał chociaż raz akcję Kup z InPost Pay (koszyk jest synchronizowany z InPost Pay).

3. W przypadku gdy użytkownik dokona zmian w synchronizowanym koszyku na stronie merchanta (zmiana liczby sztuk, dodanie nowych produktów do koszyka), merchant przesyła cały koszyk do aplikacji InPost Pay w celu aktualizacji lub utworzenia koszyka. InPost Pay po otrzymaniu informacji aktualizuje istniejący koszyk lub wiąże z numerem telefonu przypisanym do przeglądarki zaufanej koszyk i zwraca informację zwrotną potwierdzającą zakończenie operacji sukcesem.

4. Integracja zakłada, że użytkownik w InPost Mobile może wykonać określone akcje na koszyku np. zmiana ilości sztuk, wprowadzenie kodu rabatowego itp. Każdorazowo taka informacja jest przekazana do merchanta. Merchant po przekalkulowaniu zawartości koszyka odsyła go do InPost Pay.

5. Przed dokonaniem zakupu, użytkownik akceptuje regulaminy wymagane przez merchanta.

6. Użytkownik zawsze ma możliwość finalizacji koszyka na stronie merchanta. W takim przypadku zamówienie nie jest realizowane przez InPost Pay. Merchant przesyła informacje do InPost Pay o finalizacji koszyka innym kanałem.

Integracja z InPost Pay, nie wpływa na obecnie wykonaną przez merchanta integrację z systemami InPost w zakresie generowania przesyłek.

Nagłówki

Do wszystkich usług wołanych przez Merchantów w InPost Pay (Basket App) zostają dodane poniższe nagłówki (headery). Obecnie nagłówki są opcjonalne, ale docelowo będą wymagane.

Nagłówek

Opis

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

Algorytm weryfikacji sygnatury

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

Słownik pojęć