Płatności

Problem#

Płatność w marketplace to jedna transakcja kupującego, która musi rozłożyć się na kilku odbiorców, przetrwać zwrot i dać się uzgodnić miesiąc później. Jest to jednocześnie jedyny obszar, w którym błąd jest widoczny natychmiast i kosztuje pieniądze.

Podział odpowiedzialności#

Ta granica jest najważniejszą rzeczą w rozdziale i warto ją mieć zapisaną, zanim powstanie pierwsza linia kodu.

Minimalna wersja#

• Jedna płatność kupującego, z zapisanym podziałem na sprzedawców w momencie pobrania środków.
• Podział istnieje jako osobny zapis, nawet gdy ma jeden element.
• Stan płatności rozróżnia autoryzację, pobranie, zwrot częściowy i pełny.
• Każde zdarzenie od dostawcy trafia do rejestru z jego własnym identyfikatorem.

Podział zapisany w chwili pobrania środków jest tym samym wzorcem co snapshot z rozdziału o checkoucie, tylko dotyczy pieniędzy. Bez niego zmiana stawki prowizji przelicza wstecz coś, co już się wydarzyło.

Czego nie budować teraz#

• Abstrakcji nad dostawcami płatności przed drugim dostawcą.
• Własnego systemu antyfraudowego.
• Automatycznego rozstrzygania sporów.
• Wypłat natychmiastowych. To osobny rozdział i ma własne wyzwalacze.

Zaplanuj z góry#

Zdarzenie dostawcy to nie zdarzenie biznesowe#

Informacja, że środki zostały pobrane, nie mówi, że zamówienie jest opłacone, ani że można wypłacać. Platforma musi mieć własny stan i własną interpretację, bo dostawca nie wie nic o Twoich prowizjach, zwrotach ani karencji.

Powiadomienia przychodzą wielokrotnie i nie po kolei#

Rejestr zdarzeń z identyfikatorem od dostawcy załatwia trzy rzeczy naraz: odsiewa powtórki, pozwala odtworzyć kolejność i daje odpowiedź na pytanie, czy dane zdarzenie w ogóle dotarło. Bez rejestru pierwsze powtórzone powiadomienie o zwrocie odejmie kwotę dwa razy.

Zwrot dotyka czterech rzeczy naraz#

Zwrot zmienia stan zamówienia, kwotę do wypłaty, naliczoną prowizję i, jeśli pieniądze już wyszły, wymaga cofnięcia przelewu. Model musi wiedzieć, ile z danej płatności zostało zwrócone, a nie tylko że zwrot był.

Wyzwalacze#

• pierwszy zwrot częściowy;
• pierwsze powiadomienie od dostawcy, które przyszło dwa razy;
• pierwsza rozbieżność między Twoim zapisem a wyciągiem;
• sprzedawca pyta, dlaczego kwota jest inna, niż się spodziewał;
• pojawia się drugi sposób płatności o innym przebiegu, na przykład odroczony.

Następny etap#

Po drugim wyzwalaczu: rejestr zdarzeń, jeśli jeszcze go nie ma. Po trzecim: prosty raport rozbieżności do przejrzenia ręcznie, zanim zbudujesz automatyczne uzgadnianie. Po piątym: dopiero wtedy warstwa abstrakcji nad dostawcami, bo dopiero wtedy wiadomo, co abstrahować.

Częste błędy#

Co się sprawdza w praktyce#

Przy płatnościach najważniejsze było potraktowanie zdarzeń od dostawcy jako informacji do zinterpretowania, a nie jako polecenia do wykonania. Każde przychodzące zdarzenie ląduje w rejestrze, a dopiero potem platforma decyduje, co ono znaczy dla zamówienia, prowizji i wypłaty. Ten jeden krok pośredni zdjął całą klasę problemów z powtórzeniami i kolejnością.

Drugą rzeczą, która okazała się nie do pominięcia, jest trzymanie kwot pobranych i zwróconych jako wartości narastających przy każdej części płatności. Zwroty częściowe pojawiają się szybciej, niż się zakłada, a flaga logiczna nie jest w stanie ich opisać.

Checklista#

• Granica odpowiedzialności między dostawcą a platformą jest zapisana.
• Podział kwoty jest utrwalany w momencie pobrania środków.
• Kwoty pobrane i zwrócone są liczbami, nie flagami.
• Każde zdarzenie od dostawcy ma rejestr z jego identyfikatorem.
• Istnieje sposób porównania własnego zapisu z danymi dostawcy.
• Platforma ma własny stan płatności, niezależny od statusu u dostawcy.