Page Comparison

1. Po wybraniu przez użytkownika opcji „Utwórz koszyk z InPost Pay” w aplikacji InPost Mobile, przed faktycznym rozpoczęciem płatności za koszyk, InPost Pay weryfikuje stan koszyka, poprzez pobranie aktualnego koszyka od Merchanta i porównanie go 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 odpowiedni 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órego mam być utworzone zamówienie

   2. Finalną wartość koszyka 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ówienie 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 ma możliwość zmiany statusu zamówienia wraz z przekazaniem informacji o przesyłkach (jednej lub wielu), przy pomocy których zostało zamówienie wysłane. Statusy obsługiwane przy zamówieniu:

   1. Status techniczny - służy do określenia uprawnień, jakie może wykonać klient na zamówieniu w aplikacji InPost Pay. Wyróżniamy 3 statusy techniczne:

      1. ORDER_COMPLETED - status nadawany przez Merchanta, informujący aplikacje InPost Pay, że zamówienie zostało sfinalizowane na stronie Merchanta. 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 aplikację InPost Pay, po otrzymaniu informacji od Merchanta o utworzeniu zamówienia. Zamówienie ze statusem ORDER_PROCESSING może być opłacone w aplikacji InPost Pay.

   2. 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 z platformy Merchanta. 

7. Aplikacja InPost Mobile udostępnia możliwość anulowania zamówienia przed jego opłaceniem. Możliwość anulowania zamówienia jest konfigurowalna per merchant.

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

   1. UNPAID - status po utworzeniu zamówienia, nieopłacony. Nadawany przez InPost Pay (Basket App);

   2. STARTED - status inicjujący proces płatności przez klienta w aplikacji InPost Mobile. Nadawany przez InPost Pay (Basket App) na podstawie informacji z aplikacji InPost Mobile;

   3. PENDING - uruchomienie procesu. Status nadawany przez InPost Pay (Basket App) na podstawie informacji przekazanej z aplikacji InPost Mobile;

   4. AUTHORIZED - płatność zakończona z sukcesem. Status nadawany przez InPost Pay (Basket App) na podstawie informacji przekazanej z systemu płatniczego (bramki płatniczej)

   5. DECLINED - odmowa płatności. Status nadawany przez InPost Pay (Basket App) na podstawie informacji przekazanej z systemu płatniczego (bramki płatniczej);

   6. CANCELLED - transakcja odrzucona. Status nadawany przez InPost Pay (Basket App) na podstawie informacji przekazanej z systemu płatniczego (bramki płatniczej);

   7. ERROR - błąd. Status nadawany przez InPost Pay (Basket App) na podstawie informacji przekazanej z systemu płatniczego lub z aplikacji InPost Mobile.

   8. COD - płatność przy odbiorze

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:

a. CARD - płatność kratą debetową/kredytową

b. CARD_TOKEN - płatność kartą stokenizowaną

c. GOOGLE_PAY - płatność z wykorzystaniem Google Pay

d. APPLE_PAY - płatność z wykorzystaniem Apple Pay

e. BLIK_CODE - płatność BLIKIEM

f. BLIK_TOKEN - płatność BLIK ONE-CLIK

g.PAY_BY_LINK - płatność PBL

h. SHOPPING_LIMIT - płatność z wnioskiem o limit (AION)

i. DEFERRED_PAYMENT - płatność odroczona (AION)

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.