Page Comparison

1. Po wybraniu przez użytkownika opcji „Kupuję i płacę” w aplikacji InPost Mobile, przed faktycznym rozpoczęciem płatności za koszyk, InPost Pay weryfikuje stan koszyka, poprzez pobranie aktulanego koszyka od merchanta i porównanie z koszykiem zapisanym w InPost Pay.  . W przypadku braku dostępności produktu lub niespełnieniu innej walidacji zamówienie nie jest tworzone. W takim przypadku użytkownikowi prezentowany jest komunikat oraz może dalej edytować koszyk.

2. Po poprawnym utworzeniu zamówienia, koszyk przestaje być edytowalny z poziomu InPost Mobile oraz nie powinien być dostępny do edycji na stronie merchanta.

3. Przy tworzeniu zamówienia InPost Mobile przekazuje do merchanta:

   1. Identyfikator koszyka na podstawie, które mam być utworzone zamówienie

   2. Finalną cenę za koszyk uwzględniającą koszt dostawy

   3. Wybraną przez klienta formę płatności

   4. Dane zamawiającego (Imię, Nazwisko, Adres email, numer telefonu)

   5. Adres zamawiającego (opcjonalny)

   6. Formę i adres dostawy

   7. Dane do faktury

   8. Uwagi do zamówienia

   9. Informacje o zaakceptowanych zgodach

4. W przypadku, gdy klient opłaci zamówenie w aplikacji InPost Pay, informacja ta jest przekazywana do merchanta w celu rozpoczęcia realizacji zamówienia

5. W przypadku wybrania płatności COD, zamówienie od razu traktowane jest jako opłacone.

6. Merchant powinien mieć możliwość zmiany statusu zamówienia wraz z przekazaniem informacji o przesyłkach (jedna lub kilka) przy pomocy których zostało zamówienie wysłane. W ramach obsługi zamówienia merchant mam możliwość zmiany statusów:

   1. Statusu technicznego - służącego do określenia uprawnień jakie może wykonać klient na zamówieniu w aplikacji InPost Pay. Wyróżniamy statusy:

      1. ORDER_COMPLETED -- status nadawany przez merchanta, informujący aplikacje InPost Pay, że zamówienie zostało zakończone. Zamówienie ze statusem ORDER_COMPLETED, nie może być opłacone oraz odrzucone w aplikacji InPost Pay

      2. ORDER_REJECTED - status nadawany przez merchanta lub klienta w aplikacji InPost Pay (klient w aplikacji InPost Pay ma możliwość odrzucenia zamówienia przed opłaceniem). Status oznacza odrzucenie zamówienia. Zamówienie ze statusem ORDER_REJECTED, nie może być opłacone w aplikacji InPost Pay.

      3. ORDER_PROCESSING - status nadawany automatycznie przez aplikacje InPost Pay, po otrzymaniu informacji o merchanta o utworzeniu zamówienia. Zamówienie ze statusem ORDER_PROCESSING może być opłacone w aplikacji InPost Pay
         

Status opisowy prezentowany klientowi w aplikacji InPost Pay -Każdy merchant może nazywać status według własnego procesu, tak aby statusy prezentowane w InPost Mobile były zgodne ze statusem w platformie merchanta. 

7. Aplikacja InPost Mobile udostępnia funkcjonalność anulowania  zamówienia, przed jego opłaceniem. Dostępność funkcjonalności anulowania jest konfigurowalna per merchant.

8. Statusy płatności - W ramach obsługi płatności za zamówienie w Basket App będą dostępne następujące typy płatności:

Możliwość opłacenia jest w przypadku, gdy UNPAID.

Możliwość ponowienia jest w przypadku, gdy DECLINED, CANCELLED, ERROR.

9. Płatności - po złożeniu zamówienia, następuje przekierowanie do procesu płatności na poziomie aplikacji InPost Mobile. Dostępne formy płatności:

W celu uruchomienia integracji InPost Pay wymagane jest wykonanie prac implementacyjnych po stronie Merchanta opisanych w poniższych punktach.

1. Konfiguracja konta Merchanta - uzupełnienie danych o sklepie zgodnie z instrukcją i wygenerowanie danych dostępowych.

2. Autoryzacja - implementacja autentykacji i autoryzacji.

3. Widget frontend - implementacja Widgetu InPost Pay.

4. Widget backend - wystawienie endpointów opisanych w Merchant Backend API, których celem jest obsługa funkcjonalności zgodnie z diagramami sekwencji.

5. Integracja z InPost Pay (Basket App) - integracja z metodami API opisanymi w rozdziale InPost Pay (Basket App).

6. Przetestowanie poprawnego działania usługi na swoim sklepie (InPost Pay - podstawowe scenariusze testowe).

7. Po zakończeniu technicznego wdrożenia zgłoszenie integracji do audytu za pomocą formularza kontaktowego poprzez opcję “Dla Biznesu” i zakładkę “Audyt”. Usługa przekazywana do audytu powinna być dostępna tylko dla testerów pod dedykowanym linkiem.

Widoczność widgetu InPost Pay podczas implementacji i testów

Podczas implementacji oraz testowania usługi InPost Pay na sklepie produkcyjnym, widget płatności InPost Pay powinien być ukryty dla klientów sklepu. Widoczność widgetu musi być ograniczona wyłącznie do testerów i osób zaangażowanych w proces wdrożenia.
Cel:
Ukrycie widgetu zapobiega sytuacji, w której potencjalni klienci sklepu mogliby próbować korzystać z niekompletnej lub niedziałającej jeszcze usługi InPost Pay. Dzięki temu minimalizujemy ryzyko negatywnych doświadczeń użytkowników i unikamy problemów związanych z nieprawidłowością działania funkcji płatności.
Sposób działania:

• Widoczność widgetu powinna być kontrolowana na poziomie kodu lub konfiguracji sklepu. Można to osiągnąć poprzez implementację mechanizmu autoryzacji dostępu do widgetu, który pozwala wyświetlać go jedynie pod dedykowanym url-em wywołując go z odpowiednim parametrem na przykład https://shop.url?showInPostPay=true

• Ograniczony dostęp: Podczas testów widget InPost Pay jest wyświetlany wyłącznie dla określonych użytkowników (np. poprzez filtrowanie na podstawie adresu IP lub kont testowych).

• Pełna aktywacja widgetu następuje dopiero po zakończeniu testów, przejściu audytu z wynikiem pozytywnym i pełnym wdrożeniu usługi, gdy zostanie ona uznana za gotową do użycia przez wszystkich klientów sklepu.