Koszyk i checkout

Problem#

Koszyk w sklepie jest listą pozycji. Koszyk w marketplace jest listą pozycji należących do różnych ludzi, z których każdy ma własną wysyłkę, własne zasady zwrotów i własne rozliczenie. Kupujący ma tego nie zauważyć, a system musi o tym wiedzieć od pierwszej pozycji.

Checkout dokłada drugą rzecz: jest jedynym momentem, w którym można zapisać, jak wyglądał świat w chwili zakupu. Wszystko, czego nie zapiszesz wtedy, będzie później odczytywane z żywych rekordów, które zdążą się zmienić.

Minimalna wersja#

• Pozycja koszyka zna swojego sprzedawcę. To jedno pole i jest warunkiem wszystkiego, co dalej.
• Koszyk potrafi pogrupować pozycje po sprzedawcy, nawet gdy grupa jest jedna.
• Wysyłka jest wybierana i liczona na grupie, nie na całym koszyku.
• Walidacja dostępności i kompletności danych dzieje się przy tworzeniu zamówienia, nie przy dodawaniu do koszyka.

Co zapisać w chwili zakupu#

To jest właściwa treść rozdziału o checkoucie. Nie chodzi o formularz, tylko o listę rzeczy, które przestają być odczytywalne później.

Czego nie budować teraz#

• Osobnych koszyków per sprzedawca w interfejsie. Kupujący ma widzieć jeden koszyk, podział jest sprawą systemu.
• Kalkulatora wysyłki z regułami wagowymi i gabarytowymi, zanim ktokolwiek o to poprosi.
• Zapisywania koszyków między urządzeniami, dopóki nie masz kont z realnym użyciem.
• Rezerwacji towaru na czas dłuższy niż sesja checkoutu.

Zaplanuj z góry#

Klucz grupowania osobno od sprzedawcy#

Dziś grupujesz po sprzedawcy. Jutro może dojść lokalizacja wysyłki albo sposób dostawy. Jeżeli grupa jest wyliczana z jawnego klucza, a nie zaszyta jako „po sprzedawcy", dołożenie drugiego wymiaru jest zmianą jednej funkcji zamiast przebudowy checkoutu.

Płatność i zamówienie jako dwa zdarzenia#

Udana płatność nie znaczy, że zamówienie powstało. To dwie operacje w dwóch systemach i między nimi może się wszystko wydarzyć. Model musi dopuszczać stan pośredni i dawać sposób, żeby go domknąć albo wycofać.

Walidacja w jednym miejscu#

Sprawdzenie dostępności, kompletności adresu i poprawności wysyłki ma być jedną operacją wykonywaną tuż przed utworzeniem zamówienia. Rozsypanie tych sprawdzeń po interfejsie kończy się tym, że każda nowa ścieżka zakupu omija któreś z nich.

Wyzwalacze#

• kupujący pyta, dlaczego musi zapłacić dwa razy za wysyłkę;
• pierwsza płatność, po której nie powstało zamówienie;
• sprzedawca zmienia cenę w trakcie, gdy ktoś ma towar w koszyku;
• pojawia się druga ścieżka zakupu, na przykład szybki zakup bez konta;
• kupujący chce anulować część zamówienia.

Następny etap#

Po drugim wyzwalaczu: narzędzie do uzgodnienia płatności z zamówieniami, choćby lista rozbieżności do przejrzenia ręcznie. Po czwartym: wyniesienie walidacji do jednej operacji wywoływanej przez wszystkie ścieżki. Po piątym: to już rozdział o modelu zamówienia.

Częste błędy#

Co się sprawdza w praktyce#

Z perspektywy kilkunastu miesięcy najbardziej opłaciło się potraktowanie checkoutu jako momentu zapisu, a nie jako formularza. Wszystko, co dotyczy pieniędzy, jest utrwalane wtedy: wartości pozycji, zastosowana stawka i wybrana wysyłka. Dzięki temu późniejsze zmiany w katalogu i w konfiguracji nie ruszają niczego, co już się wydarzyło.

Drugą lekcją było rozdzielenie płatności od zamówienia. Sytuacja, w której pieniądze zostały pobrane, a zamówienie nie powstało, zdarza się rzadko, ale zdarza się na pewno. Jeżeli model tego nie przewiduje, jedynym wyjściem jest ręczne dochodzenie w danych.

Checklista#

• Pozycja koszyka zna sprzedawcę, niezależnie od dzisiejszego modelu.
• Grupowanie jest wyliczane z jawnego klucza, nie zaszyte w kodzie checkoutu.
• Wysyłka jest wybierana i liczona na grupie.
• Walidacja dzieje się raz, tuż przed utworzeniem zamówienia.
• Wszystkie wartości potrzebne do rozliczenia są zapisane w chwili zakupu.
• Istnieje sposób wykrycia płatności bez zamówienia.